arXiv論文整理エージェント FuguReport

論文確認時にAIを使うことが多くなっていることもあり、arXiv最新論文の紹介の完全自動化を行った。今後は「FuguReport」に引っ越す(?)[1]予定である。

FuguReportの概要と実装方針

Fugu ReportにはDaily ReportとWeekly Reportの2つがある。Daily Reportは注目すべき個別論文の紹介、Weekly Reportは週次で注目すべきテーマの紹介を行う構成にしている。大体のイメージは下表のとおりである。

Daily ReportWeekly Report
① 毎日自動作成
② 日次で注目すべき最大5論文を選びそれぞれを要約する
③ 論文の抽出はfugumtのスコアの他、他サイトの注目度を加味する[2]
① 週次で日曜日に自動作成
② 過去1週間に盛り上がった3テーマについてレポートを作成する
③ テーマの選別はfugumtのスコアの他、論文間の距離を利用して遠いテーマを選別する

両レポートともfugumtのスコアを活用している事、ライセンス関係に気を付けている事[3]、日本語と英語版の2つを作成する事は共通である。今のところ基本部分の生成にはGPT-5.4、レビュー修正にはClaude Opus 4.6を用いている[4]。なお、ツールとして独立できる部分はMCP Serverとして分離する構成にしている。次々とツール使っているAI Agentと呼んで良いアーキテクチャになっている。

Daily Reportの生成手法

Daily Reportは下記の方針で生成。オーソドックスなフローとなっている。

  1. 対象論文の選定
    • Creative Commonsライセンスか否か(および本文取得が可能か)、fugumt score、引用件数、SNSやWEBサイトでの言及数[5]などから注目すべき論文を選定
  2. メタデータと論文情報の取得
  3. 著者所属、キーワード及びその階層構造、プロジェクトサイトやgithubリポジトリなど重要情報の取得
  4. Draft(GPT-5.4)→ Review(Claude Opus 4.6)→ Translate(GPT-5.4)の 3 段階で処理

Weekly Reportの生成手法

WeeklyレポートはDaily Reportより凝った構成としている。

  1. 週次で盛り上がったテーマを選定
    • fugumt scoreをベースに対象週の候補論文群を選定
    • 候補論文群のそれぞれの論文のベクトルを求めそれぞれの距離を計算
      • Abstract、論文カテゴリ、キーワードの 3 種 embedding を取得しコサイン距離を計算[6]。
    • 3 テーマ選定、最高スコア論文を 1 テーマ目として採用し、2 本目以降は「選択されたテーマから遠くかつスコアが高い」論文を選択
      ※ テーマの多様性を確保
  2. 各テーマの代表論文の選定
    • 各テーマに関連する論文でCC ZERO、CC BY、CC BY-SAと本文が扱えるものを選定
    • 最大 10 本を比較プールに蓄積し、fugumt score、論文の意味的距離、LLM as a Judgeによる比較選定を組み合わせ、最大 3 本を決定
  3. Introduction / Future Work の抽出
    • 代表論文の本文のうち、IntroductionとFuture Workに関する部分を抽出
      ※ 全く抽出できない場合は次順位の論文を試す
  4. 段階的なレポート生成
    • テーマ現状の生成、代表論文 3 本の Introduction を中心として「主要課題」「研究の方向性」「代表論文の役割分担」を 記述
    • 週内進展の生成、テーマに属する週内論文(上位 10 件)についてテーマのどの点を前進させたかを記載
    • 展望の生成、代表論文 3 本の Future Work と週内進展を入力として「近い将来に増えそうな方向性」「技術的ボトルネック」「次の論点」を記述
  5. 別モデルによるレビューと全文リライト
    • 初稿生成とは別モデルで査読、最終版を確定
  6. 日本語翻訳
  7. インフォグラフィクス生成

週次で盛り上がったテーマ選定に力を入れたフローとなっている。この選定はLLM as a judgeでは困難であり、fugumt scoreやWEB/SNSでの反応といったProxy的な指標が重要となる。段階的な生成と別モデルによるレビューも品質向上には効果があった[7]。

所感

生成AIの品質が向上していることもありレポートのクオリティはかなり高い。しばらくはチェックしながらの運用になると思うがdevneko.jpは3月末で更新を停止する予定である。

いろいろと試していて思ったがDaily Report、Weekly Reportとも難しいのは要約そのものよりも評価に関わる部分、という印象だった。[8]。
※ここ最近のfugumt score推しは上記が原因

対象テーマ選定や対象論文選定ができれば、それ以降の処理は自動化が容易で生成品質も高い。別モデルでのレビューは効果があるので入れているもののレビュー・修正は1回で十分な印象。すごい時代になったなーと思う。

脚注

[1] もはや人が関わっていないので紹介Blogではなく整理システムになっている。
[2] 本文を扱うことが多いので基本的にCreative Commonsライセンスの論文を選択する。
[3] 本文を扱う場合はCC ZERO、CC BY、CC BY-SAの論文を使用する。v1とv2のライセンスが異なる場合もあるので取得可能な全バージョンについて確認している。
[4] 著者所属、カテゴリ、論文分類など基礎情報の整理にはGPT-4.1、GPT-4.1 nano、Mistral Small、DeepSeek V3.2を用いているなど複数のLLM/LRMを使い分けている。
[5] 一部は十分に効いていないので今後強化を行う予定。
[6] Abstractのみよりも効果があった。
[7] 英語での処理を優先しているのはコストパフォーマンスを上げるためである(元データが英語なのでできるだけ英語で扱った方が品質面で有利でありトークンも節約できる)
[8] 実際のところ人間にも難しい。(が、これは凄い!と思う直観が働くことは少なからずある。AIの能力向上でこのあたりも解決するかもしれない。)

arXiv論文と引用の関係、fugumt scoreの検証

前記事の分析時にarXiv論文のソースファイルを取得したので、bibファイルを用いてarXiv論文内で引用がどのように行われているか分析してみた[1]。結果として注目論文を引用した論文が出るまで2-3か月というスピード感、および、fugumtのscoreによる判別力が高注目論文でROC AUCで0.8を超えまずまずの水準であることが分かった。

分析と結果

分析は以下のように実施した。bibファイルを用いて行っているため実際に本文引用されているかは保証していない[2]。また分析対象はAI関連かつソースファイルを取得可能な論文に限られる点にも注意が必要である。

  1. 2024年1月から2025年12月までのarXiv論文についてそのソースを取得し、bibファイルを抽出する[3]。
  2. bibファイルからarXiv IDを抜き出す。
    ※ このIDを引用された論文とみなす[4]。
  3. 引用状況について、発表された論文がどの程度前の論文を引用しているかを分析する。2024年1月から2025年12月のarXiv論文が引用した論文について、被引用論文の発表時期をヒートマップで表す。
  4. 2024年1月から2024年12月に発表された論文についてそのスコアと一定期間後の引用数を集計し、スコアが引用数の予測に役立つかを分析する。

arXiv論文の引用状況

縦軸を論文発表月、横軸を被引用論文の発表月としてその数を集計、全引用数からの割合を算出すると下図のようになる。赤枠になっているのは論文発表月=被引用論文発表月になるマスであり、その右にはタイムラインの関係で論文は出ていないはずである[5]。(ヒートマップには2025年のデータも含めて描画している)

論文の被引用回数を集計すると一部の論文が突出して引用されている。それがうっすらと縦線が見える理由である。例えば2024年10月(横軸=2410)に見える縦線には[2410.21276] GPT-4o System Cardが、2025年5月(横軸=2505)に見える縦線には[2505.09388] Qwen3 Technical Reportが大きく影響している。

縦線が濃くなっていく過程(=注目論文の引用数が増えていく過程)を見ると、上記のような影響度の高い論文が出てからだいたい2-3か月でそれらを引用する論文が発表されているようである[6]。

fugumt scoreの判別力

fugumt scoreの品質を検証するため、短期間(論文発表後3か月)、長期間(論文発表後12か月)でスコアとその後の引用数の関係を分析した。結果として発表後3か月で高い引用数になる論文をスクリーニングする上で一定の効果があることが分かった。

下図のように長期間でもスコアと平均引用数はまずます良い関係にありそう[7]。
※スコア100超は前述のヒートマップで線が見えるような極めて引用数の多い論文が含まれるので注意が必要(もっともそれを予測できているともいえる)

  • == 分析対象期間: 3_months (公開から 3 ヶ月以内) ===
    • データ数 (n): 107,281 件
    • ROC-AUC (被引用数 > 0): 0.6520
    • ROC-AUC (被引用数 >= 10): 0.8100
      • 10回以上引用された割合: 1.08% (1,159件)
  • === 分析対象期間: 1_year (公開から 12 ヶ月以内) ===
    • データ数 (n): 107,281 件
    • ROC-AUC (被引用数 > 0): 0.6566
    • ROC-AUC (被引用数 >= 10): 0.7528
      • 10回以上引用された割合: 9.86% (10,576件)

所感

bibファイルからarXiv内の引用関係を分析してみた。現状、重要な論文が出ると3か月程度でその論文の引用数が増加するようである。国際会議を待てない現状に沿った結果になっていて、AI研究のスピード感がすごいことが分かる。

論文を探すうえでは当初3か月程度はfugumt scoreのような代替指標が必要になるかもしれないが、それ以降は引用数を使ってもよさそうに思えた。1年程度すれば国際会議発表を引用する事例が支配的になるはずで短期、中期、長期で指標を変えるのがよさそうである[8]。

脚注

[1] あくまでarXiv内の分析となっている。国際会議等で発表後はそれを引用することが多いため参考程度の情報。もっとも3か月というスピード感ではarXivを引用することが多いと思われるので実態には近いと思っている。
[2] 引用していないとしても参照していることは確かで意味はあると思っている。
[3] 発表月の判定はarXiv ID(.の前の4桁の数字)で行っている。
[4] 主要論文についてはこの処理で引用数として概ね妥当な数が出ることを確認している。
[5] 実際はID抽出時のノイズやバージョン差異の状況などにより0にはならない。が概ね良い結果になっている。
[6] 肌感にも合うが本当にスピードが速い。
[7] ROC AUC > 0.75はあるものの短期に比べROC AUCが低くなっている。これは国際会議を通した引用等によってarXivを参照することが減っていくことと整合的に思える。
[8] 短期は3か月未満、中期は半年程度、長期は1年以上を想定している。

arXiv論文の分析(研究機関別分析)

5年間以上運営しているFugu-MT: arxivの論文翻訳(概要)に関連しarXivデータを用いた研究機関別の分析を行った。分析データ構築からLLMを積極的に活用[1]、各研究機関の違いなど興味深い結果が出た[2]。

分析の方法

研究機関別の状況を分析するため、まずはarXivデータを基礎として著者所属の取得と論文のカテゴリ判定を実施した。fugumt.comで付与しているスコアも利用し分析を進める手順とした。基礎データ作成時にはコスト削減のための工夫を行っている[3]。基礎データ作成後の分析はChatGPT(GPT-5.4 Pro)とClaude(Sonnet 4.6拡張)に任せた[4]。

  1. arXivのTeXデータをダウンロード、main部分のTeXソースを取得し、著者情報や所属が書かれていると思われる部分をヒューリスティックに取得する。
  2. 取得した情報からLLMで著者情報、所属を取得する。さらにLLMを用いて表記ゆれを排除する。
  3. 取得が失敗した論文についてはPDFデータをダウンロードしテキスト抽出処理を行う。
    ※PDFから抽出したテキストと画像データをLLMに投入、著者情報と所属を取得、LLMを用いて表記ゆれに対処する。
  4. fugumt.comで収集した論文情報(著者一覧、アブストラクト)を用いて各論文をスコアリングする[5]。加えてアブストラクトから論文カテゴリとキーワードを抽出、LLMを用いて上位カテゴリを推定、3階層の構造に変換する。
    Fugu-MT:arXivの最新論文 のスコアが70を超える論文にarXiv over_70というフラグを付けている。
  5. 著者、所属、キーワード、カテゴリについてマッピングテーブルを用いて表記を統一する[6]。
    ※LLMのみでは対応の難しい表記ゆれに対処する。
  6. 整理したデータをChatGPTとClaudeで分析する。

基礎データ構築は「数十万本の多様な論文を様々な手法で整理する」という泥臭く大変な作業だった…ということで6.の分析は既存ツールに任せている。大変な部分は人間が実施、面白いところはAIが実施と、いかにも今っぽい分業になっている。

分析結果

AIによる分析結果は次の通り。全体的に面白く[7]、下記の言い切りはなかなか凄いと思う。スコアリングや集計方法による影響もあるが、新規参集の研究者が増えている傾向、重要論文の比率が相対的に下がっているのではないか?という懸念など一定の納得感がある。

「論文が増えれば影響力のある研究も増える」とは限らない。2025年は明確に、投稿量の膨張が注目度の成長を上回った年だった。

over_70比率:18.6%(2024)→ 15.7%(2025)、−2.9pt

ぜひ、分析結果とプレゼンテーション資料を見ていただきたい。

世界のAI研究機関、いま何で戦っているのか — arXiv × NeurIPS データで読み解く2025年の研究地図 (プレゼンテーション資料:arxiv_report_2025_ja.pdf2024年のワードクラウド2025年のワードクラウド

せっかくなので英語版も作ってもらった。Who’s Winning the AI Research Race, and How — Mapping 2025 Through arXiv and NeurIPS Dataarxiv_report_2025_en.pdf

特に下記、研究ポートフォリオの分析結果はなかなか興味深い。

大学・企業・スタートアップ
セクター別の戦い方

企業:LLMを核にEfficiencyとRLに賭ける

Microsoft・NVIDIA・Google・Alibaba・Tencent——いずれもポートフォリオの30〜36%をLLM/Foundation Modelsが占める。その上に何を重ねるかで差が出る。MicrosoftはEfficiency(15%)と評価(21%)の三位一体、NVIDIAはEfficiency(14%)とScaling(18%)で推論インフラを強化、AlibabaはRL/Agents(18%)でQwen系のagentic拡張に注力している。

大学:評価・ベンチマークが共通の主軸

上位6大学(清華・SJTU・NUS・Berkeley・Stanford・Fudan)のカテゴリ分布を並べると、すべての大学でEval/Benchmarkが最大テーマ(31〜44%)という共通点が際立つ。大学が「評価インフラ」を担うというエコシステム上の役割分担が、データに明確に表れている。差異はその外側にある。BerkeleyはRL/Agents(11%)とScaling(8%)が高く、embodied AI・sim-to-realの先端を行く。Stanfordは評価設計・Preference Optimizationを軸に agent の研究ループを主導。Fudanの Eval 44% は大学群で最大の特化度だ。

スタートアップ:NeurIPSを待たず、戦略は今見えている

スタートアップ各社の研究ポートフォリオは、一枚岩ではない。大きく二極に分かれている。

総合型:StepFunはLLM・Efficiency・GenAI/Videoを同時に展開し、既存大手に最も近いbroad portfolioを持つ。Kimi/MoonshotはMoE・長文・agentic benchmarkを前面に出しEfficiency 25%が際立つ。

極特化型:DeepSeekはLLM+RL+Evalの3テーマだけで構成され、reasoning・attentionへの集中度は全機関中最大。HiDreamはGenAI/Video 63%と完全な diffusion/media 特化だ。

所感

分析はChatGPTとClaudeに任せたものの「③ 新興勢の発見はNeurIPSを待たない
 StepFun・Inclusion AI・DeepSeek——これらはarXiv over_70で先に信号を出した。査読会議への反映は6〜18ヶ月遅れる。先行指標として over_70 を使えば、競合分析の精度が上がる。」とFugu-MT: arxivの論文翻訳の有効性を示したのは少し嬉しかった[8]。

大学と企業の違いであるとか、研究ポートフォリオ構成はなかなか面白い示唆だと思う。著者別の分析や共同研究の状況など細かく見ていると様々な発見がありそう。もっとも見方によってスコア分割の方法などを決めないといけないなど細かい部分はChatGPT、Claudeとも今一歩という印象がある。時間があれば私自身の手でも分析してみたい。

今っぽいと言いつつ「大変な部分は人間が実施、面白いところはAIが実施」が一般化すると嫌だなーと思う。泥臭い部分を含めてAIに任せられる日は来るのだろうか…[9]

脚注

[1] データ準備段階では所属研究機関抽出と表記ゆれの解消、論文カテゴリとキーワードの分類、階層構造の作成などに活用。データ分析自体は完全にAIにまかせた。これらを処理するプログラム作成は概ねCodexにまかせている。
[2] 若干無理のある仮定はあるが、大きな認識のずれはない。
[3] 分析予算は上限1000USD。かかったコストはAWSからの転送コストとLLM APIの利用料が主。PDFから著者情報を取得するアプローチ(3.)だとコストが10倍以上かかると予想されたため現状のパイプラインとなっている。
[4] 様々な角度からの集計や分析はGPT-5.4 Proの強さが目立ち、プレゼンテーション作成はClaude Sonnet 4.6のうまさが目立った印象。
[5] 論文著者の過去の実績(主としてトップカンファレンスでの採録数)をベースにスコアを決めている。論文内容自体の評価でない点には要注意ではある。
[6] マッピングテーブルはヒューリスティックな手法、ルール(典型的なノイズ削除)に加え、LLMの内部知識の活用とそのチェックなど、複数手法を組み合わせて作成している。
[7] ストーリーやメッセージの甘さなど指摘事項は多数あるとはいえ、読み物として面白い。
[8] fugumtのスコアリングも過去のカンファレンス実績をベースにしているのでやや誇大広告ではある。ただ、先行指標としては有効なのは本当。研究機関のスコアと次の年のNeurIPS発表数の相関係数はかなり高く、over_70の相関係数はさらに高くなる(1年後としてr=0.744)。ランキングの評価ではHuggingFace Daily papersと比較してROC AUC > 0.8など注目論文のproxy的な指標としてもまずまずの性能。発表後3か月で引用数10を超える(arXiv内でTOP 1%の論文)の判別力もROCAUC > 0.8。AIのように動きの速い分野では研究機関別のトラックレコードを見るよりも研究者の動向、共同研究の動向や所属の変化を見たほうが実態に近くなる。(とはいえ研究の質とまで言い切るのは危険。他に良いProxy指標が無いので無理を承知で使ってみたというのが実態に近い。)
[9] それはそれで人間がいらなくなる未来になってしまうわけだが・・・

arXiv AI論文翻訳サイトのMCP対応

Fugu-MT: arxivの論文翻訳(概要)をMCP(Model Context Protocol [1] )に対応させた。実装にはGradio(Building Mcp Server With Gradio)を使っている。Claude desktopからも接続ができ便利である。

Gradio[mcp]

fugumt.comのMCP対応にはgradio[mcp] [2] を用いた。gradioでは 「(1) included a detailed docstring for our function, and (2) set mcp_server=True  in  .launch()」 とするだけでMCP serverを実装できる。具体的なコードは

def search_papers(keywords: str, start: str, end: str):
    """arXivのAI関連論文を検索しMarkdownで返します。AI関連論文のみのデータベースなので検索キーワードは5個以下にすることをお勧めします。現状はベクトル検索に対応していません。
    
    Args:
        keywords: 検索用の単語リスト。" "スペース区切りを想定。全てが必須のキーワードで3 - 5 wordsが推奨値。
        start: 検索の開始日。yyyy-mm-dd表記を想定。この日付以降の論文を検索。
        end: 検索の終了日。yyyy-mm-dd表記を想定。この日付以前の論文を検索。
    """

である。上記に対応してmcpsearch.fugumt.com/gradio_api/mcp/schemaのようにschemaが作られる。使用方法などはhttps://mcpsearch.fugumt.com/?view=apiから確認できる [3] 。

Claude desktopでの利用例

Claude desktopでfugumtのMCP serverを利用するにはFor Claude Desktop Users – Model Context Protocolのようにセットアップし、「claude_desktop_config.json」に下記設定を行えばよい。

{ 
  "mcpServers": {
    "fugumt": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcpsearch.fugumt.com/gradio_api/mcp/sse"
      ]
    }
  }
}

Building Mcp Server With Gradioの3.に書かれているように「Some MCP Clients, notably Claude Desktop, do not yet support SSE-based MCP Servers. In those cases, you can use a tool such as mcp-remote. First install Node.js. 」であるため、Claude desktop利用時はNode.jsのインストールも必要である [4]。

実行例は下記の通り。

fugumt.comのMCPサーバを利用した応答ができている(https://claude.ai/share/f19d4dda-e264-4486-a3ad-0af1d723ed76)。

gradioを使うと非常に簡単にMCP serverを実装できる。arXivのAI関連論文を検索を含めてarXiv論文を探す場合にぜひ利用してほしい [5]。

脚注

[1] AIアシスタント(LLMアプリケーション)がデータソースやツールと連携するためのプロトコル(Introducing the Model Context Protocol \ Anthropic
[2] Building Mcp Server With Gradioの通り。
[3] 使用方法などドキュメントを含めて自動生成されるのはとても便利。
[4] クライアントによっては「”url”: “https://mcpsearch.fugumt.com/gradio_api/mcp/sse”」の記載でOKのよう。
[5] と言いつつ安定稼働はしていないと思われる… vector searchへの対応や関連論文リスト取得をサポートするなど拡張もしていきたいと思っている。

OpenManusを使ったサイトへのエージェント組み込み

Introducing Operator | OpenAIに支援してもらう飲み会[1]が面白かったのと、Manusが流行っていることもあって、FuguMTへのエージェント組み込みを試してみた。OpenManus[2] を用い、下記の動作を実装している。

  1. ユーザによるリクエストを受け付ける
  2. OpenManusを用いてリクエストを処理する
    • OpenManusをFuguMTに特化した動作を行うようにカスタマイズ[3]
    • fugumt.com以外のサイトへはアクセスしないよう制御
  3. 処理過程(Linuxデスクトップの動作)を適時スクリーンショットしてブラウザに表示する

実際の動作例は下記の通り。エージェントへの入力以降の処理、ブラウザの立ち上げや使用するツール選定、ツールの操作などはOpenManusが行っている[4]。WEBアプリとして実装しており、ブラウザの中でブラウザが立ち上がっているような不思議な光景となっている。

OpenManusの基本性能は高く見ていて面白い。OpenAIのOperatorでは(fugumt.comのようなマイナーな)個別サイトの構成や機能を知ることは難しい。個別サイトで用意されたエージェントとOperatorが会話、マルチエージェント的に協調する将来もあるのではないかと思う[5]。そこまでいかなくてもユーザからの問い合わせに対応してくれるエージェントはとても便利[6]。エージェントがブラウザを操作するため、サイト側での開発が必要ない点は大きなメリットである。

OpenManusのようなOSSなエージェントフレームワークは増えていくことが予想される。LLM based Agentを用いると個別にシステム開発するよりも多様なニーズに対応しやすい。このようなエージェントは今後様々なサイトに導入されていくであろう[7]。

一時的に[8] Fugu-MT:Agentで実行可能としているので興味のある方は試してほしい。

脚注

[1] 実際に注文をOperatorにやってもらった。ブラウザ対応の注文インタフェースをもつ居酒屋は多い。竜田揚げを人数分頼もうとしたり、やたら枝豆を頼もうとしたり、なかなか面白い挙動をしていた。Operatorによるとホッケに合うお酒は新政らしい。(先行事例としてみんなで飲みにいくんですけど、Devinさんも来ます? – Devin観察日記|Daiki Teramotoがある)
[2] GitHub – mannaandpoem/OpenManus: No fortress, purely open ground. OpenManus is Coming. MITライセンスのOSS
[3] fugumt.comのサイト構造、URL構成、提供しているツールの使い方などを事前設定している。これによってOpenManusのタスク達成率がかなり上がる。
[4] MLLMとしてGPT-4oを使用している。
[5] Operator用のナビゲーションファイルを置いておけばよいという説もある。AI Agent用のrobots.txt的なものが必要なのでは?という議論は多い。LLM用だとThe /llms.txt file – llms-txtだが、もっとヴィジュアルになっていくんだろうか。
[6] わざわざブラウザ使わなくても良いのではないかという説もある。
[7] すごく流行るかは微妙なところだが可能性は感じた。fugumt.comのような小さな個人サイトでも必要な機能を個別に作っていくより処理内容を自然言語でAIエージェントに指示しておく方が楽かもと思う。(処理時間やコストや色々と無駄など諸々の問題はあるが…)
[8] APIのコストが高いので限定公開の予定。

CyberAgentLM3-22B-Chat (CALM3-22B-Chat)の機械翻訳性能

公式のニュースリリースや論文発表はされていない気がするが[1]、HuggingFaceリポジトリでCALM3 22Bが公開されていた(cyberagent/calm3-22b-chat · Hugging Face

いつもの設定で機械翻訳性能を検証してみた。性能評価に使用したデータは以前(DAMO PolyLM-13Bの機械翻訳性能 | ぷるーふおぶこんせぷと (staka.jp))と同じ。検証環境は環境はColab Pro+ (A100)を用いリポジトリの推奨設定[2]でロードしている。

前回のGemma 2 9Bと同様に余計なトークンが入ることが少なく[3] GPT-4oを用いた回答部分の特定は行っていない。評価指標はBLEU、使用したツールやtokenizerは以前と同じ(sacrebleu –tokenize ja-mecab)である。「0 shot」と「1 shot」の比較でICLやRAGなどプロンプト内にデータを与えた時の性能をザックリとみる事ができる。いつもの通り非常に限定された機械翻訳ベンチマークであることに注意が必要である。

モデル0 shot1 shot
cyberagent/calm3-22b-chat · Hugging Face24.738.9
CALM3-22B-Chatの機械翻訳性能(BLEU)

結果と所感

Gemma 2 9Bと比べると評価が難しいが性能はかなり高い。Gemma 2 9Bとのスコア差は今使っているベンチマークが機能していない可能性高く要再検証であると思う[4]。

日本の会社による高性能LLMがApache 2ライセンスで公開されている意義は大きい。他のベンチマークでの検証結果も気になるところ[5]。

脚注

[1] Xでは話題になっている。
[2] model = AutoModelForCausalLM.from_pretrained(“cyberagent/calm3-22b-chat”, device_map=”auto”, torch_dtype=”auto”)
[3] <|im_start|>assistant ~ <|im_end|>をとる方針で十分だった。
[4] 外務省のページが自動取得不可になったようで他の省庁のデータでベンチマークを再構成中
[5] Nejumi LLMリーダーボード3 | llm-leaderboard3 – Weights & Biases (wandb.ai) はかなり参考になる

Gemma 2 9Bの機械翻訳性能

GoogleからGemma2がリリースされた[1]。9B[2]と27Bが公開されている。Llama3を超える性能とのことで検証してみた。性能評価に使用したデータは以前(DAMO PolyLM-13Bの機械翻訳性能 | ぷるーふおぶこんせぷと (staka.jp))と同じ。検証環境は環境はColab Pro+を用いた。 量子化によって性能が変わるという話もあり、量子化方針を変えて実験している。

Gemma2は回答に余計なトークンが入ることが少なく[3]、本件の検証ではGPT-4oを用いた回答抽出は行っていない。評価指標はBLEU、使用したツールやtokenizerは以前と同じ(sacrebleu –tokenize ja-mecab)である。「0 shot」と「1 shot」の比較でICLやRAGなどプロンプト内にデータを与えた時の性能をザックリとみる事ができる。いつもの通り非常に限定された機械翻訳ベンチマークであることに注意が必要である。

モデルと量子化0 shot1 shot
google/gemma-2-9b-it · Hugging Face / 16bit [4]29.143.5
google/gemma-2-9b-it · Hugging Face / 8bit [5]29.342.5
google/gemma-2-9b-it · Hugging Face / 4bit [6]25.440.2
Gemma 2 9BのBLEU

結果と所感

Gemma2 9Bの機械翻訳は非常に高く商用モデルに匹敵している[7]。訳抜けなど若干の問題はあるとはいえ1 shotであれば機械翻訳モデルとしても実用に達していそうな性能。この品質が公開モデルで達成できることに正直驚いた[8]。

量子化による性能劣化は8bitまでは大きくなさそうに見えるが、4bitまで落とすとさすがに影響が出ている。

蒸留を介している構築方針も興味深くNemotron-4 340B – arXiv最新論文の紹介 (devneko.jp)のような合成データ構築にフォーカスしたLLMも併せて特化型・独自LLMの可能性を感じる。

脚注

[1] Google launches Gemma 2, its next generation of open models (blog.google)
[2] 9Bモデルはより大規模なモデルから蒸留によって構築されているとのこと(「We also train the 2B and 9B models with knowledge distillation (Hinton et al , 2015) instead of next token prediction. The resulting models deliver the best performance for their size, and even offer competitive alternatives to models that are 2-3× bigger.」(gemma-2-report.pdf (storage.googleapis.com)より引用)。
[3] <bos><eos><end_of_turn>は機械的に除去している。
[4] torch.bfloat16
[5] BitsAndBytesConfig(load_in_8bit=True)
[6] BitsAndBytesConfig(load_in_4bit=True)
[7] leakageの疑いはあるが…
[8] ベンチマークがベンチマークとして成立しているか若干疑問が出てきたため、より実用的なデータセットを構築しようかと考えている最近。

Qwen2-7B, GLM-4-9Bの機械翻訳性能

中国からもWeightを公開している or オープンなモデルの発表が続いている。いつもの通り機械翻訳性能を検証してみた。性能評価に使用したデータは以前(DAMO PolyLM-13Bの機械翻訳性能 | ぷるーふおぶこんせぷと (staka.jp))と同じ。検証環境は環境はColab Pro+を用いた。基本的にfp16で扱っている。

本件の検証でもGPT-4oを用いて回答抽出を行った結果を併記しているが、基本的に指示への対応は安定していた。評価指標はBLEU、使用したツールやtokenizerは以前と同じ(sacrebleu –tokenize ja-mecab)である。「0 shot」と「1 shot」の比較でICLやRAGなどプロンプト内にデータを与えた時の性能、「出力そのまま」と「GPT-4で回答抽出」の比較で指示のしやすさをザックリとみる事ができる。いつもの通り非常に限定された機械翻訳ベンチマークである[1]ことに注意が必要である。

モデル0 shot /
出力そのまま
0 shot /
GPT-4oで回答抽出
1 shot /
出力そのまま
1 shot /
GPT-4oで回答抽出
Qwen/Qwen2-7B-Instruct · Hugging Face20.520.429.730.0
THUDM/glm-4-9b · Hugging Face25.525.530.430.6
Qwen2, GLM4の機械翻訳性能

結果と所感

Qwen2 7B、GLM 4 9Bとも機械翻訳性能は高い。さすがマルチリンガル利用を想定され構築されたモデルである。Qwen2とGLM4の性能差はパラメータサイズによるものに見える。

今までの検証結果を振り返ると、同様に構築されたAya-23 8B [2]と比べると出力の安定性(使いやすさ)はQwen, GLMが優れ、絶対性能は競合的またはややAya-23が優位といえそう [3]。

サイズが近く有名なモデルにはMistral 7B v0.3やGemma 7B、Llama 3 8Bがある。これらと比べると0 shot性能ではQwen, GLMが優れ、1 shot性能はほぼ互角である。0 shot性能はLLM内の知識に依存し、日本語での継続学習・SFTを行うと性能拡張の余地も大きそう。

Qwen2 7BはApache-2ライセンスと完全なOSSであることも重要。絶対性能が高く、命令追従性が良い、かつ、周辺ツールもよく整備されている強力で使いやすいモデルであるように思う。

脚注

[1] このあたりのザックリ感はいつもと同じ。
[2] Aya-23はCC-BY-NCと商業利用が禁止されているため使いどころは限られる。
[3] BLEUで測れるのかという話はあるが…

Mistral 7B v0.3, Phi-3 small/medium, Aya 23 8Bの機械翻訳性能

オープンなモデルの発表が続いている。ローカル環境での動作がやりやすい7B, 8B, 14Bのモデルについて機械翻訳性能を検証してみた。性能評価に使用したデータは以前(DAMO PolyLM-13Bの機械翻訳性能 | ぷるーふおぶこんせぷと (staka.jp))と同じ。検証環境は環境はColab Pro+を用いた。基本的にfp16で扱っている。

本件の検証でも出力形式が一定しないことが多かったためGPT-4oを用いて回答抽出を行った結果を併記した。評価指標はBLEU、使用したツールやtokenizerは以前と同じ(sacrebleu –tokenize ja-mecab)である。「0 shot」と「1 shot」の比較でICLやRAGなどプロンプト内にデータを与えた時の性能、「出力そのまま」と「GPT-4で回答抽出」の比較で指示のしやすさをザックリとみる事ができる[1]。ただし、非常に限定された機械翻訳ベンチマークである[2]ことに注意が必要である。

モデル0 shot /
出力そのまま
0 shot /
GPT-4oで回答抽出
1 shot /
出力そのまま
1 shot /
GPT-4oで回答抽出
mistralai/Mistral-7B-Instruct-v0.3 · Hugging Face10.714.427.029.7
microsoft/Phi-3-small-8k-instruct · Hugging Face (7B)17.918.426.826.9
CohereForAI/aya-23-8B · Hugging Face11.323.511.034.7
microsoft/Phi-3-medium-128k-instruct · Hugging Face (14B)23.523.434.536.2
各種小規模モデルのBLEU

結果と所感

Mistral 7B v3は日本語性能がかなり向上しているようでv2と比べて大幅にスコアが上がっている。Apache-2ライセンスと正真正銘のOSSであり活躍の機会が多そう。Phi-3は小型高性能の名に恥じない結果になっており、以前検証したmini、今回検証したsmall、mediumで順当にスコアが上がっている。こちらもMITライセンスと正真正銘のOSS。FuguMTの性能が0 shotで32前後であることを考えると、Phi-3 medium(14B)は用途によっては実用レベルに達しているかもしれない。

AYA 23は上記のモデルと印象が異なり、命令への追従はあまりできていないがモデルの絶対性能はとても高い。「1 shot / GPT-4oで回答抽出」の性能はプロンプトの工夫で達成できると思われ、AYA 23のように多言語想定で作られたモデルであれば8Bでも実用レベルの性能が出せるかもしれない。より大規模なASA 23 35Bも試してみたいところ[3][4]。

脚注

[1] 毎度のことながら本当にザックリとしか見れない。
[2] 日本語・英語の文書ともにデータがインターネット上で公開されているため、潜在的なLeakの可能性がある。BLEUではそもそも性能を測れないなど注意点は多い。(ぼちぼち改善しようと思ってはいるが……)
[3] 35Bだと8bit以下に量子化しないと実行が厳しい。
[4] ライセンスはCC-BY-NC、併せてCohere For AI Acceptable Use Policyも守る必要がある。ざっくりとは商用利用不可。

GPT-4o, Gemini Pro, Gemini Flashの機械翻訳性能

5月上旬はGPT-4o, Gemini Flashと商用MLLMの発表が相次いだ(Hello GPT-4o | OpenAIGoogle Gemini updates: Flash 1.5, Gemma 2 and Project Astra (blog.google))。公式、非公式を問わず検証結果が発表されており、いつものデータセットで性能を検証してみた。

性能評価に使用したデータは以前(DAMO PolyLM-13Bの機械翻訳性能 | ぷるーふおぶこんせぷと (staka.jp))と同じ。なお、GPT-4oのoでもあるテキスト以外の情報は使っていないため性能評価としては参考程度である[1]。

評価指標はBLEU、使用したツールやtokenizerは以前と同じ(sacrebleu –tokenize ja-mecab)である。「0 shot」と「1 shot」の比較でin context learningの有効性をザックリとみる事ができる[2]。

モデル0 shot1 shotコスト(USD) [3]
1Mトークン、入力/出力別
GPT-4o31.842.55 / 15
GPT-4 Turbo29.435.410 / 30
【参考】 GPT-3.5 Turbo27.137.10.5 / 1.5
Gemini 1.5 Pro / gemini-1.5-pro-preview-051426.843.43.5 – 7.0 / 10.5 – 21.0 [4]
Gemini 1.5 Flash / gemini-1.5-flash-preview-051429.434.80.35 – 0.70 / 1.05 – 2.10 [4]
【参考】Gemini 1.5 Pro / gemini-1.5-pro-preview-040934.450.13.5 – 7.0 / 10.5 – 21.0 [4]
各種APIのBLEU、コストは2024-05-18時点

結果

GPT-4oは高速・低コストであるにもかかわらず以前のGPT-4 Turboより高い性能を示した。tokenizerもGPT-4 Turboより日本語に適しているためGPT-4 Turboからの置き換えが進むだろう。

Gemini Proは以前よりもスコアが低くなっているが、「出力にMarkdownの装飾が混ざる」「一文毎に訳する形になる」など出力形式が揺れていることが原因である。プロンプトを調整すれば性能は向上すると思われる[5]。Gemini Flashは高い性能を持つが安価と発表の通りコストパフォーマンスが非常に高い。

GPT-3.5 TurboとGemini 1.5 Flash、GPT-4oとGemini 1.5 Proは競合しており、それぞれに特色がある。用途によって選定することになるのではないかと思う。

その他

今使っているデータ・評価指標ともに完璧なものだとは思っていないが、複数のモデルを同じように比較できるのは便利。間違いの分析やモデル特性の変化を検知できることも重要である。

検証に使っているデータは外務省(GPT-4を用いた翻訳の検証(vs GPT-3.5 vs FuguMT) | ぷるーふおぶこんせぷと (staka.jp)MPT-30B-Chat + In-Context Learningの性能 | ぷるーふおぶこんせぷと (staka.jp))のものでライセンス的な問題はないため、データ構築過程を自動化し公開しようかと思わなくもない[6]。時系列変化や(Leakageが入らないと思われる)最新データでの比較なども可能など、便利なデータであるはず[6]。

脚注

[1] 評価指標が色々と問題あるBLEUであり、Leakageの心配もあって本当に参考の参考
[2] こちらもざっくりとしか見れない
[3] tokenizerが異なるため一律比較はできない、2024-05-18時点の情報で「Pricing | OpenAI」「Gemini API の料金  |  Google AI for Developers  |  Google for Developers」から取得。
[4] Gemini 1.5はプロンプトの長さで価格が異なる
[5] 適切な評価データを持つ、出力の分析をすることが重要
[6] 1年以上前にも同じことを言っていて結局公開しない可能性もあるが…