マルチエージェント開発でトークン消費量と実行時間を圧縮するテクニックとして、調査結果の共有というものがあります。
それぞれのエージェントが個別に調査するのではなく、一つの調査用エージェントに調査をさせ、他のエージェントはその結果を参照するのです。
誤った内容の伝播
困るのは、調査結果に誤りがあるケースです。
LLMを多用するユーザーなら、LLMが間違いを犯すこともよく知っているはずです。
その間違いはエージェントの性能向上によって減ってはいますが、残念ながらゼロになることはありません。
つまり、調査結果は必ず正しいとは限らないのです。
特に広範囲のソースコードが関係するケースにおいて、エージェントの判断や要約が必要な調査では、その傾向が強まります。
それに多くのケースで、調査は「単純作業」に分類され、低い性能のモデルにやらせる場合も多いでしょう。
それは誤りが起こる可能性を引き上げることになります。
その誤りは全体のごく一部の、小さなものかもしれません。
単一の作業で使用されるだけなら、影響範囲も小さいものです。
ですが、それが複数のエージェントの複数の工程で繰り返し参照され、かつ途中で問題に気づいたエージェントによる訂正の機会がないような仕組みだと、問題は途端に大きなものになります。
最終レビューで問題に気づけば、大幅な手戻りが発生し、せっかく節約したトークンも時間も無駄になってしまいます。
最悪のケースはレビューでも見逃された場合であり、誤った実装が採用されることになります。
対策
レビュー
誤りを防ぐ対策は、やはりレビューが有効です。
コードをレビューするのと同じように、調査結果をレビューさせましょう。
最も望ましいのは、別のAIや別のセッションによるレビューですが、同じセッションの使い回しでも、調査担当に自己レビューフェーズを設けることで、問題は緩和されます。
出典表記
ファイルパス、行番号、URL。
根拠の在処さえ書かれていれば、検証の速度とコストはかなり下がります。
調査時点で出典を明記させましょう。
訂正可能性
後続の作業エージェントが調査結果の誤りに気づいたときには、編集やコメントができるような仕組みがあると、問題がより修正されやすくなります。
まとめ
上記のいずれの手法も、節約したかったトークンと時間をトレードオフとするアプローチにはなります。
しかし複数のエージェントがそれぞれゼロから調査するコストや、実際に誤りが伝播されてしまった場合のコストを考えると、対策によって発生するコストは許容範囲かと思われます。
調査結果の共有は節約の観点において強力なアプローチですが、正しく実行できなかった際の被害は大きなものになりえます。
マルチエージェント開発は、作業パイプライン全体で開発の効率や正しさを保証する目的がありますが、その根幹が揺るがされかねないこの問題には、対処することをおすすめします。
原文: https://sijiaoh.com/posts/agent-research-reuse-error-propagation/