RAGの精度が出ない。
top-k を増やす。
Vector DB を変える。
rerank を足す。
ど典型です。
でも、その前に見ないといけないことがあります。
いま壊れているのは、本当に retrieval でしょうか。
検索している。context も渡している。LLM も返している。
それでも答えがズレるとき、手を増やすほど、直す場所が見えなくなります。
この記事は、trend-to-rule という小さな実装で踏んだ「failure mode を分けないまま手を増やす」ズレの記録です。コードは出しません。切り分けのフレームだけ書きます。
踏んだズレ：失敗を一箇所に寄せていた
RAG がズレたとき、最初は「検索結果が悪い」で片付けていました。
Vector DB が弱いのか。検索クエリが悪いのか。retrieve はできているが LLM が解釈を間違えたのか。それとも、解釈は合っているのに最後の output で崩れたのか。
このあたりが混ざると、急に直しづらくなります。検索している。context も渡している。LLM も返している。でも、どこを直せばいいのか分からない。
ここで top-k を増やしても、当たることはあります。でも、なぜ当たったのか分からないので、次に外したときにまた振り出しに戻ります。
先に、失敗している場所を4つに分ける
手を増やす前に、失敗を置き場所で分けます。
1. DBに入っていない
2. 入っているが retrieve できていない
3. retrieve できたが LLM が解釈を間違えている
4. 解釈は合っているが output で崩れている
この4つは、直す場所が全部違います。
- DBに入っていない → 情報を追加する。検索の調整では直らない。
- retrieve できていない → query や search strategy を見る。
- 解釈を間違えている → schema や中間生成物を見る。
- output で崩れている → final answer の組み立てを見る。
ここを分けないまま query expansion・top-k 増・MMR・chunk size 変更・reranker 追加・agentic RAG を足していくと、直しているつもりで別の場所をいじることになります。どれも「取りに行き方」を変える手段で、1番と3番と4番には効きません。
一番重かったのは、1番を直すコストだった
自前の Vector DB を運用していて、しんどかったのは、1番（DBに入っていない）を直すのが重いことでした。
DBに足りない、と気づいても、追加するには RSS を取り直して、ingest して、chunk して、embedding して、index を更新する必要があります。一回の検証が pipeline 一周になる。
すると、何が起きるか。「DBに入っていないのでは」と思っても、足すのが面倒で、精度を上げたいのに上げる手前で止まる。failure mode の1番が、コストのせいで直せない場所になる。
さらに、trend-to-rule が扱っていたのは fashion / trend で、evidence に鮮度がありました。DBを育てるほど、今を見たいのに過去の evidence も一緒に抱える。DBの中身が、少しずつ「今」ではなくなる。検索したいだけだったのに、DBの鮮度管理が始まる。
やったのは、責務を設計の外に出すことだった
そこで、貯めて検索するのではなく、その時点で必要な evidence を取りに行く方向（Web 検索寄り）に変えました。
ここで大事なのは、検索サービスの勝ち負けの話ではないことです。やったのは、4分類のうち1番と2番を、設計側で減らせる形にしたことです。
DBに入っていない → 貯めないので、そもそも起きにくい
DBに入っているが古い → その時取りに行くので、起きにくい
追加・更新が重い → pipeline を持たないので、消える
「検索が悪い」という一つの結論に畳んでいたら、ここには辿り着きませんでした。Web 検索が効いたのではなく、Web 検索で外せる failure mode を見つけた。持つべきでない責務を、設計の外に出しただけです。
もちろん、これは Vector DB 不要論ではありません。社内文書・仕様書・契約書のような自前 corpus が要る用途では、Vector DB は普通に必要です。trend-to-rule のように「公開情報を、鮮度込みで、その時取りに行きたい」用途で、貯める責務が重かった、という話です。
一般化すると
RAG がズレたとき、見るべきは「どの手を足すか」ではなく、どの failure mode で止まっているかでした。
手（top-k・rerank・MMR・agentic RAG）は、時点の正しさでしかありません。土台が変われば、要否も変わる。でも、4分類の切り分けは、検索基盤を変えても腐りませんでした。
手は消える。責務の切り分けは残る。
検索結果を増やす前に見るべきだったのは、検索結果の数ではなく、どの責務がどこで止まっているのか、でした。
もう少し体系的に見たい場合
この「failure mode を分ける」は、RAG の責務を順に分けていく話の一部です。
検索クエリ設計、retrieved evidence、rerank が本当に効いているか、共通ルールの取り出し、output boundary まで、実装の出自・外した判断・観測した根拠をPDFにまとめました。