Development of an LLM-Based System for Automatic Code Generation from HEP Publications

この論文は、高エネルギー物理学の出版物から分析手順を抽出して実行可能なコードを生成する LLM ベースのプロトタイプシステムを開発し、ATLAS 実験のオープンデータを用いたベンチマーク評価を通じて、その再現性支援における可能性と現在の限界（確率的な挙動やハルシネーションなど）を明らかにしたものである。

要約

この論文は、**「物理学の論文から、自動的に実験のプログラム（コード）を作る AI」**の開発について書かれたものです。

少し難しい専門用語を、身近な例え話に置き換えて説明しましょう。

🎯 何をやろうとしているの？（目的）

高エネルギー物理学（素粒子の研究）の世界では、実験の結果を「再現する（同じ結果をもう一度出すこと）」ことがとても重要です。しかし、過去の論文には「実験のやり方」が書かれているだけで、実際にその通りに動く「プログラム」は書かれていないことが多く、それを人間がゼロから書き直すのは、**「レシピ（料理の作り方）だけを見て、プロのシェフがいない状態で、完璧な料理を再現しようとする」**ような大変な作業です。

そこで、この研究チームは**「論文というレシピを読み解き、AI が自動的に料理（実験プログラム）を作ってくれるシステム」**を作ってみました。

🛠️ 仕組みは 2 段階（2 ステップ）

この AI システムは、2 つの工程に分かれて動きます。

第 1 段階：レシピの整理（情報の抽出）

まず、AI は論文（PDF）と、その論文が引用している他の論文を全部読みます。

• 何をする？ 「どの粒子を拾うか」「どの条件を満たすものだけを使うか」といった**「選び方のルール」**を抜き出します。
• 工夫： 単に文字をコピーするだけでなく、AI が「ここは重要だ」「ここは別の論文に書いてあるな」と考えながら、**「選び方のリスト」**という整理された形にまとめます。
• 例え： 料理のレシピ本を読みながら、「卵は 3 個、塩は小さじ 1 杯」という部分を抜き出し、**「料理のチェックリスト」**に書き写す作業です。

第 2 段階：料理の作成（コード生成）

次に、先ほど作った「選び方のリスト」を使って、実際に動くプログラム（コード）を作ります。

• 何をする？ AI がコードを書き、それをコンピューターで実行して、結果が正しいかチェックします。
• 工夫： 一度で完璧に作れるとは限らないので、「エラーが出たら直す」「結果がおかしいからやり直す」という**「試行錯誤」**を繰り返します。
• 例え： チェックリストを見ながら、実際に料理を作ってみる。味見をして「塩が足りなかった」と思えば、AI が自分で「塩を足すコード」を書き直して、また味見をする、という作業です。

🧪 実験の結果はどうだった？（評価）

このシステムが本当に使えるかテストするために、**「ATLAS 実験（大型ハドロン衝突型加速器）」**の有名な実験データ（オープンデータ）を使ってテストしました。

• 良い点：
  • 最新の AI（特に大きなモデル）は、論文から必要なルールをかなり正確に抜き出せるようになりました。
  • 場合によっては、人間が手作業で作ったプログラムと全く同じ結果を出すこともできました。
• 悪い点（課題）：
  • ハルシネーション（嘘をつく）： AI が「論文に書いてないのに、勝手にルールを作ってしまう」ことがありました。
  • 不安定さ： 同じことを 10 回やっても、10 回とも同じ結果が出るとは限りません（確率的なバラつき）。
  • 実行失敗： 作ったプログラムが動かないこともありました。

💡 結論：AI は「助手」だが「監督」にはまだなれない

この研究からわかったことは、**「今の AI は、人間がチェックする『優秀な助手』としては素晴らしいが、人間がいなくても勝手に実験を完結させる『監督』としてはまだ頼りない」**ということです。

• 人間が関与する（Human-in-the-loop）： AI が作ったリストやコードを、物理学者が「本当にこれで合ってる？」と最終確認する仕組みが、今のところ最も安全で効果的です。
• 未来への期待： 今後は、AI がもっと賢くなって、論文の「曖昧な部分」を指摘したり、より複雑な実験も再現できるようにしていくことが目標です。

📝 まとめ

この論文は、**「AI に物理学の論文を読ませて、実験のプログラムを自動で作らせる実験」でした。
まだ完璧ではありませんが、「AI が人間を助けて、科学の再現性を高める」**という道筋が、すでに開け始めていることを示す、とてもワクワクする研究です。

まるで、**「AI が料理のレシピを読み解いて下ごしらえをしてくれるが、味見と最終確認は人間がする」**ような、新しい協力関係の始まりと言えるでしょう。

技術概要

高エネルギー物理学（HEP）出版物からの自動コード生成 LLM システム開発に関する技術的サマリー

本論文は、高エネルギー物理学（HEP）における研究結果の再現性確保を目的とした、大規模言語モデル（LLM）を活用した概念実証（PoC）システムの開発と評価について報告しています。著者らは、HEP 論文から分析手順を抽出し、実行可能な分析コードを自動生成する 2 段階のワークフローを提案し、ATLAS 実験のオープンデータを用いたベンチマークを通じて、オープンウェイト LLM の能力と限界を定量的に評価しました。

以下に、問題提起、手法、主要な貢献、結果、および意義について詳細をまとめます。

1. 背景と課題

• 問題: 高エネルギー物理学のデータ分析は複雑化しており、環境構築やコード記述に高度な計算機スキルと時間を要します。これが学生や新規参入者の参入障壁となっています。
• 現状の課題: 既存の LLM はコーディング支援に有望ですが、確率的な変動や「ハルシネーション（虚構の生成）」により、検証なしの完全自動化は信頼できません。
• 目的: 論文から分析手順を抽出し、実行可能なコードを生成する「人間が関与する（Human-in-the-loop）」フレームワークを開発し、再現性の支援と論文の品質向上に寄与すること。

2. 提案手法：2 段階のワークフロー

本システムは、LLM をブラックボックスではなく、検証可能な協力者として位置づけるため、人間が読みやすい中間表現を介した 2 段階のプロセスで構成されています。

ステージ 1：選択基準の抽出（Selection Extraction）

• 目的: 対象論文およびその参考文献から、イベント選択基準、オブジェクト定義などの分析情報を抽出し、構造化された選択リストを作成する。
• 手法:
  • マルチドキュメント処理: 重要な定義が参考文献に委ねられている場合が多いため、対象論文と引用文献の両方を参照します。
  • 反復的ワークフロー: Planner（次の参照文献と読書目標の決定）、Loader（PDF から Markdown への変換とテキスト抽出）、Reader（基準の抽出）、Merger（結果の統合）の 4 つのコンポーネントで構成される LangGraph ベースのループを実行します。
  • モード: 全文を一度に処理する「Bulk モード」と、セグメントごとに処理する「Chunk モード」を比較評価しました。
  • 出力形式: 単なる数値リストではなく、コメントや参照元（プロベナンス）を含む構造化された中間表現を生成し、下流のコード生成と人間の検証を容易にします。

ステージ 2：コード生成（Code Generation）

• 目的: ステージ 1 で得られた構造化された選択基準に基づき、分析コードを生成・実行・検証する。
• 手法:
  • 制御された環境: 現時点では HEP 固有のドメイン知識（API 仕様など）を RAG などで自律的に取得する機能は実装されておらず、プロンプトに必要な変数や制約を明示的に提供します。
  • 反復的生成と検証: Generator がコードを生成し、Executor（Singularity コンテナ内で ROOT, numpy, uproot 等を実行）が実行し、Validator が実行結果とコード自体を検証します。
  • フィードバックループ: 検証失敗時にはエラーログや失敗したコードスニペットをフィードバックし、Generator がコードを修正するまでループします。

3. ベンチマークと評価プロトコル

• 対象: ATLAS 実験の $H \to ZZ^* \to 4\ell$ 分析（2015-2016 年のプロトン - プロトン衝突データ、ATLAS Open Data）。
• グランドトゥルース: 著者らが手動で再現した分析コードと、27 個の明確に識別可能な選択基準リスト。
• 評価指標:
  • ステージ 1: 正しく抽出された基準の数、ハルシネーション（矛盾する記述）の数。
  • ステージ 2: 生成されたコードが手動ベースラインとイベントレベルで一致するか（Exactly Matched）、実行失敗（Execution Failed）かなど。

4. 主要な結果

ステージ 1（抽出）の結果

• モデルサイズの影響: 300 億パラメータ以上のモデル（Qwen3:235B, Gemini 2.5 Flash など）は、27 個の基準の多くを正しく抽出し、一部の実行では全基準を特定できました。一方、40 億パラメータモデルは性能が低かったです。
• 確率性とハルシネーション: どのモデルも実行ごとの変動（確率性）が大きく、矛盾する記述（ハルシネーション）が完全に排除されませんでした。
• Chunk モードの課題: 限られたコンテキストウィンドウを持つモデル向けにテキストを分割して処理する「Chunk モード」は、正解数を増加させましたが、ハルシネーションとワークフローの失敗率を劇的に増加させました。

ステージ 2（コード生成）の結果

• 完全一致の実現: 800 億パラメータモデル（Qwen3-Coder-Next）と 1200 億パラメータモデル（GPT-OSS）は、それぞれ 10 回の実行のうち 3 回と 2 回で、ベースラインと完全に一致するイベント選択コードを生成しました。300 億パラメータモデルは完全一致は 0 回でした。
• 実行成功と物理的正確性の乖離: コードが実行成功しても、生成されたイベント選択が物理的に正しいとは限りません（Not Matched のケース）。これは、実行成功が物理的正確性の代理指標ではないことを示しています。
• 安定性の欠如: 多くの実行で「Not Matched」や「Execution Failed」が発生しており、現在のオープンウェイト LLM は自律的な分析エージェントとして信頼するには至っていません。

5. 主要な貢献

1. 検証可能なワークフローの構築: 論文から構造化された選択基準を抽出し、それを介してコードを生成・検証する、人間が関与する LLM ワークフローを実装しました。
2. 定量的評価: ATLAS Open Data を用いたベンチマークにより、オープンウェイト LLM の「文書理解」と「コード生成」の能力を分離して評価し、その強みと限界を明確にしました。
3. 再現性評価フレームワーク: 成功すれば十分なドキュメントがあることを示し、失敗すれば記述の欠落や曖昧さを示唆するツールとしての可能性を提示しました。

6. 意義と今後の展望

• 現状の位置づけ: 現在のオープンウェイト LLM は、完全自律型の分析エージェントとしては信頼性が不足していますが、**「人間を介した協働ツール」**として非常に有望です。物理学者が中間状態を検証するプロセスを支援することで、再現性を高めることができます。
• 課題: PDF からのテキスト変換の不安定性、確率的変動、ハルシネーション、実行失敗などが依然として大きな課題です。
• 将来の方向性:
  • ステージ 1 の誤りがステージ 2 にどう波及するかを評価するエンドツーエンド評価の実施。
  • HEP 固有のドメイン知識（ROOT API など）を取得するための RAG（検索拡張生成）の統合。
  • 対象分析の拡大による汎用性の検証。
  • 論文出版前の曖昧さを特定し、論文の質を向上させるツールの開発。

本研究は、LLM を単なるコード生成器ではなく、科学文献の構造を解析し、再現性を担保するための「検証可能な協力者」として活用する新たなパラダイムを示唆しています。