>_ DevTrendsja

言語

ホーム

言語

セクション

フロントエンド バックエンド モバイル DevOps AI / ML ゲーム開発 ブロックチェーン 組み込み セキュリティ
Tex

LLMエージェントに文脈を記憶させ、科学論文を再現させる方法

最近、PaperGuruベンチマークを見つけました。このベンチマークでは、研究者たちが自律型エージェントにおける厄介な問題に取り組むことにしました。現在のモデルのコンテキストウィンドウは100万トークンにまで拡大していますが、エージェントがリポジトリを探索し、何十もの論文を読み、動作するコードを書き出す必要がある複数日にわたるタスクは、まだうまくいかないことがあります。

通常、これはすべてメモリに起因します。ベクトルデータベースはコサイン類似度でテキストチャンクを見つけますが、時間経過に伴う関係性については完全に見落とします。ある論文が更新された場合、またはライブラリが時代遅れになった場合、標準的なRAGはその古いフラグメントを喜んでプロンプトに混入させます。PaperGuru-Benchmarkリポジトリでは、AutoTrustAIチームの 研究者が、データのライフサイクルを意識した長期記憶アーキテクチャ(Lifecycle-Aware Memory、略してLAM)と、複雑なベンチマークでのテスト結果を公開しています。

Agent performance comparison before and after PaperGuru

標準的なRAGの何が問題なのか

エージェントが大規模な文献レビューを書いたり、PDF論文からコードを再現したりする場合、平坦なエンベディング検索は基本的なことでつまずきます。

第一に、情報が古くなります。ある手法がより最近の論文で反証された場合、平坦なデータベースはそのことを知りません。

第二に、必要な証拠は、キーワードでクエリに似たチャンクにあるのではなく、引用グラフ内で2リンク離れた場所にあることがよくあります。

第三に、アーカイブが成長するにつれて検索コストが増加し、エージェントはノイズに溺れ始めます。

研究者たちは、メモリを扱うための4つのルールを定式化しました:

  1. コンテンツのバージョン管理。システムは編集、非推奨、論文の撤回を追跡します。
  2. マルチホップ構造的関連性。検索はベクトル類似性だけでなく、関係グラフを経由します。
  3. 無限のアーカイブ成長に対する有界のクエリコスト。
  4. 証拠のトレーサビリティ。各エージェントの主張は特定のソースに紐付けられます。

Capital Chunk Memoryアーキテクチャ

PaperGuru CCM architecture

テキストを均一なチャンクに分割してChromaやPineconeに投入する代わりに、PaperGuruアーキテクチャはメモリを2つの層に分割します。最初の層はチャンクヘッドと呼ばれます。これらは高速なルーティングに使用される各アーティファクトのメタデータを含むコンパクトなヘッダーです。2番目の層であるチャンクコンテンツは、生のテキストを保存し、実際に必要になったときにのみ遅延読み込みされます。

_routerは時間的アーティファクトグラフに依存しています。このグラフには2種類の関係が保持されています:構造的(例えば、citesimplementsbenchmarked-on)と因果的(deprecated-byretracted-bysuperseded-by)です。

Memory pipeline

生成パイプラインは4つのステップで構成されています:

  • 検索:アーカイブ内で一致するアーティファクトヘッダーの高速検索。
  • 抽出:必要なフラグメントを抽出し所谓的エヴィデンスカードと呼ばれるものをアセンブルします。
  • 推論:モデルが下書きとロジックチェックを行う生成と批評のサイクル。
  • 検証:ソース参照チェックを伴う最終検証。
Pipeline animation

テスト結果

研究者たちは、OpenAIのPaperBenchSurveyBenchという2つの難しいベンチマークでシステムをテストしました。

PaperBenchは、モデルがML論文のPDFを取得して実験再現を含む動作するリポジトリを書く能力を評価します。人間のベースライン(48時間の予算を持つML博士課程の学生)は41%です。

Overall PaperBench results

PaperGuruは23本の論文で平均66.05%の結果を示し、すべての公開ベースラインソリューションを上回りました。他のエージェントによる以前の最良の結果は35.74%でした。

Results by individual papers

既知のベースラインを持つ20本の論文中19本において、新しいメモリアーキテクチャは大幅な改善を示しました。例えば、classifier-free guidance論文の再現では、結果が68%向上しました,唯一低下したのはPINNタスク(-4.47%)のみで、ここでは元のベースラインが手動のドメイン固有ヒューリスティクスを使用していました。

Quality improvement distribution

SurveyBench(大規模な科学レビューの執筆品質を評価)では、Claude Opusベースのジャッジによるコンテンツ品質で94.66%を記録しました。

SurveyBench radar chart

Richness指標注目に値します。これは主観的な言語モデルの評価ではなく、生成された資料に含まれるコンパイルされたグラフ、表、動作するコード、正しい引用の実際の存在をカウントします。

Structure and content richness

ここでは、PaperGuruは43.76%を記録し、競合アプローチの半分は構造のないベアテキストのみを生成してゼロでした。

Accepted papers

リポジトリの内容

リポジトリは約350MBで、多くの実用的な資料が含まれています:

  • 再現可能な評価パイプラインを備えた完全なベンチマークインフラストラクチャ
  • すべてのベンチマーク論文の事前計算済みエンベディングとグラフ構造
  • LAMアーキテクチャコンポーネントのベースライン実装
  • 評価スクリプトと可視化ツール
  • すべての23本のPaperBench論文のすぐに使える提出物

READMEのすべてのグラフはローカルで再構築できます。assets/figures/フォルダには、すべての指標とビルドスクリプトを含むdata.jsonファイルがあります:

python scripts/rebuild_graphs.py

このプロジェクトを学ぶべき人

大規模なコードベースや複雑な技術ドキュメントを扱うエージェントシステムを構築している場合、このリポジトリは優れた参考資料を提供します。メモリを軽量ヘッダーと因果関係グラフに分割するというアイデアは、企業のナレッジベースにも簡単に応用できます。

PaperBench/submissions/フォルダ内の готовые提出物は、自分の論文からのコード生成パイプラインをテストしている人々に役立ちます。そこでは、モデルが単一のスクリプトだけでなく、依存関係とテストを含む動作するプロジェクトツリーを出力する必要がある、複雑なMLパイプラインの再現をどのように構造化するかを確認できます。