復旦大学の 4 人の著者によるこの論文は、ツールドキュメントを固定された入力ではなく、LLM エージェントにとってのグラウンディングの資源として扱う。論文は、エージェント向けに書かれたドキュメントは、読み手と内容の両面で従来の API ドキュメントとは異なると指摘する。読み手はエージェントであり、コンテキスト内のテキストから直接ツールの機能を推測し、実行可能な呼び出しを生成しなければならない。そのため重点は、使用条件、パラメーターの意味、呼び出しの制約、出力の解釈へと移る。論文によれば、従来のドキュメント最適化手法の多くは、ドキュメントにすでにあるフィールドの範囲内で書き直し、修正、標準化、圧縮を行うものであり、そうしたフィールドが十分か、冗長か、特定のエージェントに適しているかにはあまり注意を払ってこなかった。

論文はまず実証研究を報告する。14 のツール利用データセットから 24,955 個のツールのドキュメントを収集し、その内容を 17 の情報フィールドに対応づけたうえで、WorkBench 上で、フィールドを 1 つずつ追加または削除したときにタスク成功率がどう変化するかを測定した。測定は 2 つのエージェントパラダイム — LangChain で構築した ReAct エージェントと、AutoGen で構築したマルチエージェントシステム — と 3 つのバックボーン(GPT-4o、GLM-5、Claude Haiku 4.5)の下で行われた。次に論文は DocsChisel を提案する。DocsChisel はツールとクエリをタスクドメインごとにグループ化し、対象エージェントを実行して失敗したトレースを収集したうえで、各ツールについて LLM の支援による 3 つのステップ — 失敗したトレースの診断、フィールド単位の追加・削除・洗練の操作の計画、元のドキュメントに基づく新しいドキュメントの生成 — を反復する。その際、失敗パターン、操作、編集に関するドメインレベルのメモリーが反復間で引き継がれる。候補は検証用のタスク成功率を下げない場合にのみ保持され、反復回数の上限(デフォルトは 5 回)に達した後に最良の候補が選ばれ、同点の場合は最も短いものが選ばれる。

要点

  • 14 のデータセット全体で、すべてのデータセットに現れたのはツール名と機能の説明だけであり、使用ガイダンスと呼び出しの制約は 2 つのデータセットにしか現れなかった。
  • 同じフィールドでも、設定が異なれば効果が異なる、あるいは逆になることがあった。GPT-4o と ReAct の組み合わせでは、3 つのタスクドメインをまたいで効果の方向が同じだったのは 17 フィールド中 6 つだけであり、3 つのバックボーンの間では 17 フィールド中 12 で効果の方向が変わった。また、ReAct からマルチエージェントに切り替えると、いくつかのフィールドの効果が逆転した。1 つのフィールドを追加または削除するだけで、タスク成功率は平均 6.34 パーセントポイント変化した。著者らは、固定されたドキュメントの慣習はエージェントの設定をまたいで汎化しないと結論づけている。
  • WorkBench と API-Bank の 9 つのタスクドメインにわたる 74 個のツールと 2,072 件のクエリで評価したところ、DocsChisel は評価したすべての設定で平均のツール呼び出しの正確さとタスク成功率が最も高く、元のドキュメントに対してそれぞれ 34.69% と 95.89%、EASYTOOL および DRAFT のベースラインに対して平均 30.83% と 75.15% 向上させた。
  • 最適化されたドキュメントは平均 189.23 トークンで、元のドキュメントより 24.02% 長く、DRAFT のものと同程度だった。最適化に使ったトークンは DRAFT より 6.35% 少なかったが、1 ツールあたり平均 12.65 分かかり、どちらのベースラインよりも長かった。
  • 最適化に用いるモデルは重要だった。Claude Haiku 4.5 を最適化器として用いた場合、GLM-5 や GPT-4o を用いた場合よりも結果がよかった。改善の大部分は初期の反復で得られ、メモリー機構を無効にすると、2 回目の反復以降は両方の指標がほぼ横ばいとなり、最終的なタスク成功率は完全なフレームワークに比べて 76.47% 低下した。

補足

著者らは、DocsChisel の優位性は、完全なエージェントトレースから失敗を診断し、フィールドの構成を対象エージェントに適応させる点にあるとし、固定テンプレートによる手法や、個々のツール実行からドキュメントを洗練する手法と対比している。また、一部の失敗はドキュメントの外に原因がある — タスク分解の誤り、確率的な推論、不完全なクエリ — ため、ドキュメントの最適化では取り除けないと指摘している。妥当性への脅威としては、パラダイム、バックボーン、データセットの選択、そしてフィールドの特定やドキュメントのバリエーション作成における手作業のステップが挙げられており、後者は独立したアノテーション(Cohen の kappa 0.862)によって緩和したとしている。各設定は 3 回の最適化と、それぞれ 5 回の評価で実行され、改善は Holm 補正を施した Mann-Whitney U 検定の下でも有意であった。エージェント向けにツールの説明を書き直すことに関する wiki 内の関連ページとしては、信頼性の高い LLM エージェントのツール利用に向けたツール記述の書き換えの学習 がある。