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的な指標としてもまずまずの性能。
[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年以上前にも同じことを言っていて結局公開しない可能性もあるが…

Gemma 7B, Llama 3 8B, Phi-3 mini, recurrent gemma 2B 等の機械翻訳性能

小規模でも性能が良いと主張するモデルが次々と発表されている(OSS – arXiv最新論文の紹介 (devneko.jp))。7Bから8BのモデルはGPU 1つでも実行でき使い勝手が良い。一方で過去の検証では十分な機械翻訳性能を出すことが難しそうである [1]

最新モデルで上記制約が解消しているのか機械翻訳性能を検証してみた。性能評価に使用したデータは以前(DAMO PolyLM-13Bの機械翻訳性能 | ぷるーふおぶこんせぷと (staka.jp))と同じ。検証環境は環境はColab Pro+を用いた。基本的にfp16で扱っている。

本件の検証では手で回答抽出をする代わりにGPT-4 Turboを用いて回答抽出を行った結果を併記した。評価指標はBLEU、使用したツールやtokenizerは以前と同じ(sacrebleu –tokenize ja-mecab)である。

「0 shot」と「1 shot」の比較でICLやRAGなどプロンプト内にデータを与えた時の性能、「出力そのまま」と「GPT-4で回答抽出」の比較で指示のしやすさをザックリとみる事ができる[2]。

モデル・条件param0 shot /
出力そのまま
0 shot /
GPT-4で回答抽出
1 shot /
出力そのまま
1 shot /
GPT-4で回答抽出
google/gemma-1.1-7b-it · Hugging Face8.54B17.117.132.532.2
meta-llama/Meta-Llama-3-8B-Instruct · Hugging Face8.03B11.916.220.630.2
Qwen/Qwen1.5-7B-Chat · Hugging Face7.72B17.817.918.919.0
microsoft/Phi-3-mini-128k-instruct · Hugging Face3.82B12.612.720.020.3
google/recurrentgemma-2b-it · Hugging Face2.68B7.98.720.320.9
(参考)gpt-3.5-turbo27.126.937.137.0
各種小規模モデルのBLEU

より大規模なモデルについても検証を行った。こちらはollamaを用いて検証を行っている。

実は上記表のモデルも当初ollamaを用いて検証を行っていたが性能が悪かった。4bit量子化の影響ではないかと考えている[3]が詳細は不明である。下表の結果もfp16で実行した場合、より良い結果になる可能性がある。

モデル・条件param0 shot /
出力そのまま
0 shot /
GPT-4で回答抽出
1 shot /
出力そのまま
1 shot /
GPT-4で回答抽出
command-r-plus (ollama.com)104B27.429.437.136.8
llama3:70b-instruct (ollama.com)71B17.316.521.032.3
(参考)gpt-3.5-turbo27.126.937.137.0
各種大規模モデルのBLEU

結果と結論

Llama 3 8B, Gemma 7Bはパラメータ数の割に機械翻訳性能が高い。特にGemmaは日本語対応、命令の理解共に性能が高い。Llama 3 8B Instructは出力に不要な部分(今から翻訳しますなどのリード文)が出る事が多くそれが見た目のBLEUに影響していた。主たる文章のみを抜き出せば性能は悪くない。日本語を継続学習したバージョンや日本語の命令セットでSFTしたバージョンに期待である。

より小型のPhi-3、reccurent gemma 2Bは実用には厳しそうだが期待のできる結果を出しているように思う。特にreccurent gemmaのように新たなアーキテクチャ[4]には期待大である。機械翻訳ではSSMのような状態を扱えるモデルだと利点が多い。例えば「単語対応の辞書」や「訳調」、「定型文」などを状態に押し込んでおくことで、欲しいスタイルの機械翻訳を実行可能になる。FuguMT ver 2はこのような機能で構築する予定である。

より大規模なモデルとしてはCohereのCommand R+はさすがの性能である[5]。Llama 3 70Bについては量子化の影響を受けていそうなのでfp16での性能を試してみたいところ。

FuguMT ver2(辞書・翻訳スタイル指定可能なLLMベースの機械翻訳モデル)公開に合わせて、これら検証データの最新化やベンチマークの公開もしたい[6]。

脚注

[1] 以前の検証では7Bクラスと14Bクラスで大きな差が出ていた。PaLM2 / ELYZA-japanese-Llama-2-7bの機械翻訳性能 | ぷるーふおぶこんせぷと (staka.jp)
[2] モデルに合わせたプロンプトチューニングは行っていないため、特に後者は本当にザックリとである。
[3] Llama3の量子化の影響についての検証は GitHub – Macaronlin/LLaMA3-Quantization が詳しい。
[4] Fugu-MT 論文翻訳(概要): RecurrentGemma: Moving Past Transformers for Efficient Open Language Models (fugumt.com)、GriffinアーキテクチャFugu-MT 論文翻訳(概要): Griffin: Mixing Gated Linear Recurrences with Local Attention for Efficient Language Models (fugumt.com)
[5] Command R+ (cohere.com)Introducing Command R+: A Scalable LLM Built for Business (cohere.com)、研究目的用にCC-BY-NC-4.0で公開されている商用モデルであるので当たり前かもしれないが。。
[6] だが、時間の余裕がない状況が続く。既存FuguMTの問題修正もいい加減やりたい。。。

PLaMo-13B, Qwen-14Bの機械翻訳性能

日本語が扱える大規模言語モデルの発表が相次いでいる。以前取り上げたQwenについても前回検証時より大規模なモデルが公開されていた。

今までと同様、上記の機械翻訳性能を検証してみた。性能評価に使用したデータは以前(DAMO PolyLM-13Bの機械翻訳性能 | ぷるーふおぶこんせぷと (staka.jp))と同じ。検証環境は環境はColab Pro+を用いた。PLaMo-13Bが8bitで読み込み[1]、Qwen-14Bはfloat16で読み込んだ。前回同様、日本語を多く含むPLaMoについて指示を日本語にしたプロンプトも試している[2]。

本件の検証ではQwen-14Bは回答部分を手で抽出はしておらず、PLaMo-13Bは手で回答を抽出した。PLaMo-13Bはinstruction tuning前なこともあり制御が難しい事、PLaMo-13Bの回答部分をルール抽出するコードを書く時間が無かった事が理由である。

モデル・条件zero shot1 shot [3]
GPT-3.5 [4]26.737.0
PLaMo-13B [5] / 8bit読み込み / 日本語指示4.823.1
PLaMo-13B [5] / 8bit読み込み / 英語指示 5.218.3
Qwen-14B-Chat [6]22.935.1
【参考】 Qwen-7B-Chat [7]14.523.3
PLaMo-13B(事前学習済みモデル・未チューニング), Qwen-14B-Chat, GPT-3.5-TURBO-16KのBLEU

結果

PLaMo-13Bはチューニング前の状態であるからか制御が難しい。特に長文で回答部分のみを出力させる事が簡単ではない。日本語指示、英語指示の差や出力からは「機械翻訳」というタスクを十分に認識させられていないように見受けられた。これはモデルの問題ではなくプロンプト作成側(筆者側)の問題であるように思う。チューニングされたモデルが公開されたら再度試してみたいところ。タスク認識がうまくいっている事例ではまずまずの翻訳文が出てきていたので表の数値は参考程度。個人的には期待大。

Qwen-14Bの機械翻訳性能は高くLlama-2 13B(回答そのままだと33.1、手での抽出を行って35.1)以上である。Qwen-7Bと比べて大きくスコアを伸ばしており機械翻訳タスクにおけるパラメータサイズの重要性が示唆される結果になっている[8]。

PLaMo-13BはApache License v2.0と非常に使いやすいライセンス。今後の発展に期待したい。おそらく早期にinstruction tuning後バージョンが公開されると思われるため、その時にまた試行を行いたい[9]。

Qwenは独自ライセンスではあるが「Our code and checkpoints are open to research purpose, and they are allowed for commercial purposes. Check LICENSE for more details about the license. If you have requirements for commercial use, please fill out the form to apply.」と研究目的での制約は強くない。周辺ツールが整備されており使いやすい印象を受ける[10]。

脚注

[1] PLaMo-13Bの処理時間が非常に長かったため16bitでの読み込みをあきらめた。
[2] 前回と異なり相応の効果が見えた。
[3] 以前と同じでOpenICL、TopkRetrieverにより取得
[4] gpt-3.5-turbo-16k-0613
[5] pfnet/plamo-13b · Hugging Face
[6] Qwen/Qwen-14B-Chat · Hugging Face
[7] Qwen/Qwen-7B-Chat · Hugging Face
[8] Llama-2-7b-chat-hf: 20.1 (回答を手動抽出して 23.9)、Llama-2-13b-chat-hf: 33.1 (回答を手動抽出して 35.1)とLlama-2もほぼ同傾向となっている。
[9] 機械翻訳を重視したバージョンを自分でやるかもしれない(やりたい)が、時間がとれなさそう。。。
[10] 開発チームはモデルの評価や周辺ツールの開発などにもかなりのリソースを投入している。研究だけでなく実用化でも非常に競争が激しくなっている。