本当に動くRAG：本番のための検索パターン

検索拡張生成（RAG）は試作は簡単なのに、確実に動かすのは驚くほど難しい。ドキュメントを埋め込み、上位一致をプロンプトに詰める——このデモは試したクエリでは動き、試さなかったクエリで崩れます。出荷できるRAGと、静かにハルシネーションを起こすRAGを分けるものを見ていきます。

検索品質がすべてを決める

正しいチャンクがコンテキストウィンドウに無ければ、どんなモデルも正しく答えられません。だから最初に測るべきは答えの品質ではなく検索リコールです。実際の質問群に対して、正しい出典が上位結果に現れるか。

チャンク設計は設計判断

小さすぎれば意味を刻んでしまい、大きすぎれば埋め込みが薄まり予算も食う。まず300〜500トークン前後に少しのオーバーラップから始め、ブログの初期値ではなく自分のリコール値に対して調整します。

ハイブリッド検索はベクトル単体に勝る

密なベクトルは意味に強く、完全一致——製品コード、エラー文字列、固有名——に弱い。両方を組み合わせます。

両方を走らせ、統合した集合をクロスエンコーダで再ランクする。多くのRAGパイプラインに欠けている、最もROIの高い改善です。

答えを根拠づけ、証明させる

取得したコンテキストだけから答え、コンテキストが薄いときは「分かりません」と言うようモデルに指示します。そして引用させる。使った出典IDを返させ、人——あるいは評価——が答えと突き合わせられるようにします。

出典を示せないRAGは、手数の多いチャットボットにすぎません。

検索と生成を別々に評価する

二つのダイヤル、二つの測定。検索リコールと回答の忠実性を独立に追い、品質が落ちたときにどちらの半分が壊れたか分かるようにします。両方をLLM出力を評価するの評価ハーネスに組み込み、固まったらはじめてのLLM機能を出荷するの規律でデプロイします。