TL;DR
Dittanyは、LLMマルチエージェントアプリの実行中に、タスク要件から期待される貢献と受入条件をグラフ化し、失敗箇所と再利用可能な結果を特定して、局所修正かグラフ再構成かを選ぶ修復フレームワークです。30アプリ・9,000タスクで検出精度88.28%、再現率79.18%、タスク精度84.76%を報告しています。Nativeより精度は26.74ポイント高い一方、推定トークン消費は17.92%増です。
既存手法との違い
原論文の比較では、30アプリ・6つのMASフレームワーク・9,000タスクの条件で、Dittanyのタスク精度84.76%に対し、Native execution 58.01%、Reflexion 63.48%、Iterative Rollback 58.21%、SupervisorAgent 48.39%、AgentTether 50.41%と報告されています。DittanyはNative比で26.74ポイント、最強の復旧ベースライン比で21.28ポイント高い精度です。推定デプロイ時トークンはNativeの317.963Mに対しDittanyは374.948Mで17.92%増ですが、Reflexionより24.19%、Iterative Rollbackより13.05%低いとされています。AgentTetherの詳細な方式は提示本文からは確認できません。
使える条件
対象はLLMベースのマルチエージェントシステム（MAS）アプリケーションです。MAS仕様として、エージェント定義・メソッドの入出力・利用条件・依存関係をソースコード等から抽出でき、フレームワークアダプタを通じて実行時の観測と修復適用ができることが前提です。既存プランがある場合はそれを利用します。評価はAutoGen/AG2、CrewAI、LangGraph、Google ADK、HelloAgents、OpenAI Agents SDKの6フレームワーク、30アプリ、9,000タスクで行われています。計算資源やデプロイ環境の詳細な前提は提示本文からは確認できません。RAG専用の手法ではありません。
限界と未検証の範囲
評価範囲は提示本文にある30アプリ・6フレームワーク・9,000タスクに限られ、それ以外の領域やフレームワークへの一般化は確認できません。検出性能は完全ではなく、精度88.28%、再現率79.18%です。トークン消費はNativeより17.92%多く、ReflexionやIterative Rollbackより低いものの、実行コスト増は残ります。MAS仕様抽出、検証ポリシー構築、LLMによるメソッド記述に依存する点も前提です。本記事は追試を行っていません。
解説
ねえ智也くん、この『Dittany』って、LLMマルチエージェントの実行失敗を直す話？
そう。MASアプリは、途中で使える結果が出てても、タスク要件を満たしてないことがある。
え、普通に動いてても失敗なの？
うん。出力の形は正しくても、必要な情報が抜けてたり、複数の結果を合わせると予算超過したり。間違った結果が共有コンテキストに入ると、後ろのエージェントも引きずる。
じゃあ、全部やり直す？
それは無駄が多い。最新のアクションを同じ入力でリトライしても足りないことがあるし、全部再実行すると正しかった作業も繰り返す。だから、まだ使える結果を見つけて、足りない作業だけ直す必要がある。
そこで貢献グラフ？
Dittanyは、タスク要件とメソッド仕様から、期待される貢献と受入条件を出す。その依存関係を貢献グラフにつなぐ。実行中にチェックして、満たされてない条件と、まだ使える結果を特定する。
修復の範囲はどう決めるの？
入力が足りてればアクション単位の修正。前提が足りないとか、未完了の作業を変える必要があればグラフ単位の回復。どっちも検証済みの貢献は残して、修復後の出力も次に使う前にチェックする。
なるほど、局所修正とグラフ再構成を選ぶんだ。比較はどうなってるの？
本文では既存手法として、反省ベース、実行時監視、ロールバック、事後診断が挙げられてる。比較はNative実行と4つの復旧ベースライン。Dittanyは貢献グラフで使える結果を残して修復範囲を選ぶところが違う。
評価の数字は？
30アプリ、6つのMASフレームワーク、9000タスク。検出は精度88.28%、再現率79.18%。タスク精度は84.76%で、Nativeが58.01%、Reflexionが63.48%、Iterative Rollbackが58.21%、SupervisorAgentが48.39%、AgentTetherが50.41%。
けっこう差があるね。
Native比で26.74ポイント、最強の復旧ベースライン比で21.28ポイント高い。推定トークンはNativeの317.963Mから374.948Mで17.92%増。でもReflexionより24.19%、Iterative Rollbackより13.05%低い。AgentTetherの詳しい方式は本文からは確認できない。
精度は上がるけど、コストは増えるってことか。
そう。あとアブレーションでは、2つの修復スコープを組み合わせる方がグラフ単位だけより精度が高くてトークンも低い、と報告されてる。
意義は、明示的なエラーだけじゃない失敗を見つけて、使える結果を再利用しながら直せることだね。
うん。ただし万能じゃない。検出は完璧じゃないし、トークンもNativeより増える。評価は提示本文の30アプリ・6フレームワーク・9000タスクに限られる。
他のフレームワークや領域でも同じかは？
本文からは確認できない。それに、MAS仕様の抽出、検証ポリシー、LLMによるメソッド記述、フレームワークアダプタで実行時の観測と修復適用ができることが前提。既存プランがあればそれを使う。計算資源の詳細な前提も本文からは確認できない。
そっか。記事では追試してないもんね。
そう。原論文の報告と、ここでの解釈は分けて読む必要がある。
じゃあ、私の途中まで書いたレポートも貢献グラフで修復してほしいな。使える部分は再利用してさ。
まずタスク要件を明確にして、提出期限を確認してくれ。