ハクソク

世界を動かす技術を、日本語で。

研究駆動型エージェント：エージェントがコードを書く前に読むとき

31日前原文(blog.skypilot.co)

概要

  • Coding agents はコードを書く前に 論文や競合プロジェクトを調査 することで、より優れた最適化案を生み出す
  • 自動リサーチループ に文献調査フェーズを追加し、llama.cppに適用して CPU推論速度を大幅向上
  • 3時間・4台のVMで 5つの最適化を発見 し、x86で+15%、ARMで+5%の高速化を実現
  • 競合プロジェクトの調査 がarxiv検索よりも多くの具体的アイデアを提供
  • ベンチマークとテストスイートがあるプロジェクト ならどれでも応用可能

コーディングエージェントの最適化アプローチの進化

  • 従来のエージェント はコードのみを分析し、微細な最適化（SIMD化やループアンローリング等）に終始する傾向
  • コード外の知見 （論文・競合プロジェクト・ドメイン知識）が重要な場合、コードだけでは浅い仮説しか立てられない
  • llama.cppのCPU推論 では、計算経路のマイクロ最適化がほぼ効果なし（メモリ帯域がボトルネック）
  • ドメイン知識 （Rooflineモデル、ハードウェア特性、他実装の工夫）が不可欠

文献調査フェーズの導入

  • 研究フェーズの追加 でエージェントの仮説品質を向上
    • 論文・フォーク・他プロジェクトの実装を調査
    • シニアエンジニアが未知のコードを触る前の準備と同様
  • 自動リサーチループ の流れ
    • コード編集→実験→メトリクス確認→結果判定に加え、調査→仮説立案→実験のサイクル
    • SkyPilot でクラウドVMに分散実験
    • エージェントがベンチマーク・正当性チェックスクリプトも自動生成

実験環境とターゲット

  • ターゲット ：TinyLlama 1.1B（Q4_0量子化）のCPU推論スループット
  • アーキテクチャ ：x86（AVX-512対応）、ARM（NEON対応）AWS VM
  • メトリクス ：llama-benchでtokens/secondを測定
  • 実験コスト ：3時間・4台VM・計約$29（CPU VM $20、API $9）

調査で得られた主な知見

  • ik_llama.cpp の独自量子化リパックで2.9倍高速化（既に本家に取り込み済み）
  • Blockbuster論文 ：FFN全体の演算融合を提案
  • CUDA/Metalバックエンド にはあるRMS_NORM + MUL融合がCPUには未実装
  • 競合プロジェクトやフォークの解析 が論文検索より実用的な最適化案を多く提供

最適化案の具体例（5件）

  • 1. Softmax融合
    • コピー・スケール・マスク加算の3パスを1パス化
  • 2. RMSノルム融合
    • コピー＋スケールの2パスを1パス化
  • 3. 適応的from_float並列化
    • 行数に応じて並列化戦略を変更し、プロンプト処理で+2.5%高速化
  • 4. グラフレベルRMS_NORM + MUL融合
    • 他バックエンドの手法をCPUにも導入
    • AVX2/NEON命令を明示的に使い、1パスで処理
  • 5. Flash attention KQ融合
    • （詳細割愛、KQタイルの3パスを1つのAVX2 FMAループへ融合）

コードのみ文脈の限界と研究フェーズの有効性

  • コードのみ では計算量ばかりに目が行き、根本的なボトルネック（メモリ帯域や他手法の存在）に気づきにくい
  • 調査フェーズ により、他実装の融合手法や未活用の最適化を発見できた
  • 複数の最適化 が積み重なり、特にx86で顕著な高速化を実現

まとめと今後の展開

  • 論文・競合分析を自動化したエージェント は、従来のコード専用エージェントを凌駕する最適化を発見可能
  • ベンチマーク・テストスイート が整備されていれば、他のプロジェクトにも容易に適用可能
  • クラウド分散実験 と自動調査の組み合わせが、今後の自動最適化の標準手法となる可能性

参考

  • 主要プロジェクト：llama.cpp, ik_llama.cpp, llamafile, PowerInfer, ExLlamaV2
  • 参考論文：FlashAttention, Blockbuster, LLM Inference Acceleration via Efficient Operation Fusion, ほか
  • 実験環境：AWS c6i.2xlarge (x86), c7g.2xlarge (ARM), SkyPilot
  • 主要技術：AVX2, NEON, FMA, SIMD, メモリ帯域最適化

Hackerたちの意見

https://github.com/adam-s/alphadidactic

└

一番の問題は、コーディングエージェントが「早く大きく失敗しない」ってことだ。騙されるように失敗するんだよね。GPT-2と3は早く（そして大きく）失敗してたから、嘘をついてるのがすぐ分かったけど。

プロンプトには#PPPCDCを使ってるよ：計画、計画、計画、そして確認：計画を既存のコードと比較する。計画を再読してドキュメントと比較する。自信がない部分を修正する。

Claudeを使ったことがある人なら、最初に計画を立てさせて、既存のコードをできるだけリサーチさせると賢く動くってことは知ってるよね…だからこの記事の結果には全然驚かないよ。ただ、この記事の最後にあるシェルスクリプトを自分のフローに追加した人の意見を聞いてみたいな。それって（本当に）Claudeを改善するの？

最近、arxivの論文からスキルを作ることに興味を持ってるんだ。例えば、マルチオブジェクトトラッキングのためのスキルがあるよ。それに、関連する重要な論文（30本以上）を説明したSKILL.mdがあって、各論文の完全な内容をreStructuredText形式で保存してるフォルダもあるんだ。Arxivの論文をLLMに供給するために、RSTが一番トークン数と忠実度の比率が良いことがわかったよ。Markdownは精度が足りないし、LateXは冗長すぎる。論文のURL、名前、日付を持ったスクリプトがあって、ArxivからLateXのzipをダウンロードして、解凍してRSTに変換して、正しいフォルダに追加してる。そしたらLLMに全文から要約を作らせて、その後、他のLLMに要約付きで再度全文を渡して、改善や校正をお願いしてる。これをやってる間に自分でも論文を読んで、最後に要約を読んで、気に入ったらスキルに追加してるよ。各論文について、記載されたアルゴリズムが一般的なベンチマークでどれくらい良いかの情報も追加してる。最先端の分野で働いているなら、同じようなことをすることを強くお勧めするよ。それに、私のやり方を改善するためのおすすめがあれば教えてほしいな。

└

「LLMナレッジベース」に似てるね。 https://xcancel.com/karpathy/status/2039805659525644595

└

RSTって何？

└

これがうまくいくように思えるけど、正直言って、もう30本の論文を全部読んでるなら、LLMに何をしてもらいたいの？ただのテンプレートだけ？

└

ctoth/research-papers-pluginに取り組んでるんだ。LLMがノートを抽出するためのパイプラインだよ。RSTをMarkdownよりも優れているっていう君の見解、めっちゃいいね！似たようなことをやってるみたいだし、絶対連絡するよ :)

└

それ、文脈に合ってるの？30本分の内容があったら、あふれちゃいそうだよね。

└

似たようなものを作ろうと思ってたんだ。何か見せられるものができたら報告するね。シェアしてくれてありがとう！

└

RSTの方がMarkdownより良いって思ったのは驚きだね。

最近これにすごく興味があるんだ。プロジェクトには、僕がQlatt[0]でやってるみたいに、注釈付きの論文が入った./papersディレクトリが必要だと思う。文字通り、すべてのプロジェクトにね。もしそれが何百万回も行われていることなら、良い文献があるってことだよね？そうじゃなければ、関連するものを見つけるのがもっと重要だよ！データベースやコンパイラみたいな、ただの難しいCSのことだけじゃなくて。UIを作ってるの？基にできる素晴らしいUIの研究があるはずだよ！あなたが作っているゲームのループは楽しいかな？それについての研究もあるかもしれないよ！

└

あのディレクトリ、もうめっちゃ大きいね！index.mdがエージェントが必要なものを見つけるのに役立ってると思うけど、Markdownファイル自体もすごく長いよね。これ、トークンを大量に消費しちゃうな。それに、どの論文が入るかを決めるのは誰なんだろう。ブログ記事では、エージェントが自分で検索できるって書いてあったね。

└

わあ、これすごい！あのMDファイル、全部手書きしたの？それとも、要約を抽出するような簡単なことにはLLMを使ったの？

MLプロジェクトをやってるんだ。いつもエージェントのチームを組んで、リーダー、アーカイビスト、リサーチアシスタント、研究者、開発者、テスターを配置してる。チームは論文に基づいて仮説を生成して、それをテストして、さらに改善していくんだ。すべてはラボノートで記録してる。トークンは消費しちゃうけど、いくつかの有望な戦略を見つけて試してるところだよ。

新しい問題をエージェントで解決したいときは、いつもその分野の先行研究を広くオンラインで検索させて、それを参考にして解決策を構築できるか分析させるんだ。「アイデアスペース」に解決策があると思ってて、エージェントに事前に検索させることで、最終的な解決策に収束する前にこのスペースを効率的に探ることができるんだ。

└

公開されている過去の研究がすべてトレーニングデータに含まれていると仮定しても安全じゃないの？ そしたら、長所や短所を提案するように促すことができるよね。* カットオフ以降の新しいものは除いて。

gfqlへの大きな変更のようなR&Dレベルのプロジェクトの前に、建築研究に価値を見出してる。結局、マルチステージになるんだ：- 論文やプロジェクトのための深い研究。ここではChatGPT Pro Deep Researchが好き。すぐに数百のソースを全体的な関連性で調査できるから。- 特定の論文やプロジェクトに深く掘り下げて、AIコーディングエージェントが関連する論文やプロジェクトをダウンロードしてローカル分析ループを行い、技術的な内訳をMarkdownウィキにまとめて、それを全体的な発見レポートにまとめる。Claudeコードは並列サブエージェントをうまくサポートしてるから、ここではちょっといい。- エージェントが論文リポジトリと自分たちのプロジェクトの間を反復して、提案やアイデアを洗練させる反復設計フェーズ。基本的に、これはワクワクするけど、同時に制限もあるんだ。関連するコミュニティからのベストプラクティスや良いアイデアを確保する「ソフトウェア崩壊」の一例だけど、LLMはここでクリエイティビティを発揮してるわけじゃなくて、ただ混ぜ合わせて選ぶ手助けをしてるだけなんだ。自動化ツールは良さそうだね。既存の能力からそれほど遠くないから、すぐにエージェントに組み込まれると思うよ。例えば、「関数foobarを反復的に最適化して、GPU文献を参考にする」みたいな感じで。

ちょっとバカみたいに聞こえるけど、リサーチの前にプロファイラーを見つけて、それを実行するフェーズを追加した方がいいんじゃないかな。単にどんな最適化が有益かを推測するだけじゃなくて。

これって、Vercelが「skills」よりも「AGENTS.md」の方が良いって感じた理由に似てるね。実際には、agents.mdはすでに拡張されたスキルに過ぎないのに。これは、より良いコンテキストエンジニアリングを強制する方法を見つけるパラダイムに合ってる。