RAG を組むときの判断軸
RAG は「検索して、その結果を言語モデルに渡して答えさせる」構成を指す。ハルシネーションを抑え、社内資料など学習データに含まれない情報に基づいた回答を作れるのが利点だが、精度が出ないときの原因切り分けが難しい領域でもある。
精度が出ない原因は検索側にあることが多い
回答の質が悪いとき、生成モデルを高性能なものに替えたくなる。しかし関連度の低い資料を渡していれば、どんなモデルでも良い回答は作れない。改善の順序としては、まず検索段を疑うほうが費用対効果が高い。
- チャンク分割の単位 — 細かすぎると文脈が切れ、粗すぎると無関係な内容が混ざる
- 再ランク付け — ベクトル検索で拾った候補を関連度順に並べ替える工程を挟むと改善しやすい
- ハイブリッド検索 — キーワード一致と意味検索を併用する。固有名詞や型番はキーワードのほうが強い
コンテキストは「入れるほど良い」わけではありません
扱えるコンテキストが長いモデルを使っても、無関係な資料を大量に渡せば的外れな参照が起きます。窓の大きさは「絞り込みを省ける」という意味ではなく「絞り込みの失敗を許容できる」という意味で捉え、検索で絞ってから渡す構成のほうがコストでも精度でも有利になります。
出典を示せる構成にする
RAG の実務的な価値は、回答の根拠を提示できる点にある。参照した文書へのリンクを回答と一緒に返し、利用者が原典を確認できるようにしておく。これがないと「もっともらしいが検証できない回答」になり、業務で使う際の最大の障壁が残ったままになる。
どこまでを自前で持つか
検索・分割・生成のすべてを自前で組む構成と、統合されたプラットフォームに任せる構成がある。前者は制御しやすいが工数がかかり、後者は速いがブラックボックスが増える。まず統合型で成立するかを試し、精度が足りない部分だけ自前に置き換える進め方が無駄が少ない。