RAGは「正解率」より先に、外した理由を追えるようにした方がいい
回答がおかしい時に、検索・データ・ルーティング・生成のどこで外れたか追えないRAGは、改善がだんだん勘になる。
RAGを作ると最初は「どれだけ正しい答えを返すか」を見たくなる。でも運用まで考えると、その前に欲しいものがある。外した時に、なんで外したか追えること。
AgentLink側ではRAG検証用に10個のagent設定を分離して動かす小さいharnessを作っている。ここで先に入れたのは豪華なvector DBではなく、source ID、run ID、agentごとの分離、health、validation、unknown agentの明示エラーだった。
source IDで最初の切り分けをする
回答が変だった時、source IDが残っていれば「変な文書を拾った」のか「正しい文書は拾ったのに生成で外した」のかを分けられる。前者ならretrievalやranking、後者ならpromptやgeneration側を見る。原因候補が一気に狭まる。
run IDで、その1回だけ追う
複数agentやretryが絡むと、時刻だけでログを追うのはつらい。run IDがあれば、その1回がrouting、retrieval、generationをどう通ったかをまとめて追える。
agent/corpus分離は精度事故に見える境界事故を減らす
別agentの文書が混ざると、モデルは普通にその文書を使って答える。hallucinationっぽく見えても、実際はroutingや境界の問題かもしれない。だからunknown agentを明示的に落とす、agentごとに文書を混ぜない、ID重複を弾く、といった保証を先に置く。
いまのproofでは5本のテストを固定
- 10-agent fleetが登録される
- retrievalが選択agent内に閉じる
- unknown agentがclean errorになる
- duplicate agent IDを拒否する
- 空document設定をvalidationで検知する
公開ケーススタディではこの5本がpassしている。これは「完成した高精度RAG」という意味ではなく、モデルやvector storeを豪華にする前に壊れ方を追えるoperating contractを固定したproof。
当たるRAGより、外した時に直せるRAG
最終的な回答精度は大事。でも本番で長く育てるなら、精度だけ上げるより、外した時に原因を追える方が改善速度は上がる。AIエージェント全体も、「何を答えたか」だけでなく「なんでそこに辿り着いたか」をあとから追える方が運用では強い。
Verified proof: AgentLinkの公開RAG Fleet Harness MVPは、10 isolated agent configurations、source-aware results、run IDs、validation、health reporting、unknown-agent handling、5 passing testsを記録している。case study / guide