検索とRAG

概要

検索拡張生成（RAG）は、言語モデルの前に検索ステップを置きます。ユーザーの質問を使って、答えを含む可能性が最も高い一握りの文章を見つけ、それをプロンプトに入れ、モデルは記憶からではなくそれらをもとに答えます。モデルに非公開の、最近の、あるいは大量のテキストへのアクセスを与える標準的な方法であり、事実に関することならファインチューニングより安価で、監査しやすく、更新も容易です。このハブは、そうしたシステムを構築またはデバッグするエンジニアのためのページです。

各部分を理解すべき理由は、RAGの失敗がほぼ常に検索の失敗だからです。答えが間違っているとき、最初の問いは正しい文章がそもそもプロンプトに入っていたかどうかであり、その問いには各段階を別々に計測しなければ答えられません。

重要な考え方

エンベディングはテキストを比較可能なベクトルにする

エンベディングモデルは、文章を数百から数千個の数値のベクトルに写像し、意味が似た文章同士が近くに置かれるようにします。近さは通常コサイン類似度で測ります。バイエンコーダはクエリと文書を独立に埋め込みます。これが数百万文書に対する検索を可能にしているもので、文書ベクトルは一度計算して保存されます。モデルの最大入力長は重要です。all-MiniLM-L6-v2（22 Mパラメータ、384次元、256トークンで切り詰め、Apache-2.0、2021年）は、このサイトの例で使う小さな既定モデルです。bge-m3（568 M、1,024次元、8 kトークン、MIT、2024年1月）とnomic-embed-text-v1.5（137 M、768次元、8 kトークン、Apache-2.0、2024年2月）は本番向けの一般的なオープンな選択肢です。OpenAIのtext-embedding-3-large（3,072次元、8,191トークン、2024年1月、パラメータ数非公開）は典型的なホスト型の選択肢です。異なるモデル、あるいは同じモデルの異なるバージョンのベクトルは比較できないので、エンベディングモデルを変えることはすべてを再インデックスすることを意味します。

チャンク化とインデックス作成

文書は埋め込む前にチャンクに分割します。レポート全体のベクトルでは、質問が必要とする細部が平均化されて消えてしまうからです。少しの重なりをもつ200から500トークンのチャンクが通常の出発点ですが、構造（見出し、段落、コードブロック、表の行）で分割するほうが固定の文字数より優れており、各チャンクには出典、セクションタイトル、日付などのメタデータを持たせ、結果をフィルタし引用できるようにします。次に索引が最近傍検索を速くします。フラットな索引はすべてのベクトルと比較する厳密なもので、数十万チャンクまでは問題ありません。HNSWは近傍のグラフを構築し、数百万ベクトルでも95%を超える再現率でミリ秒単位で答えますが、メモリを消費します。おおよそベクトルそのもの（件数×次元×4バイト）にグラフを加えた分です。直積量子化はメモリが限界のときにベクトルを圧縮します。

ハイブリッド検索とリランキング

密ベクトルは言い換えに強く、正確な文字列に弱いです。部品番号、エラーコード、名前、略語などです。BM25キーワード検索はその逆です。両方を走らせ、相互ランク融合でリストを統合するのは安価で、取りこぼしの一群をまるごと解消します。ほとんどの本番システムがハイブリッドなのはそのためです。次にリランカーが統合された候補をクロスエンコーダで再採点します。クロスエンコーダはクエリと文章を一緒に読むモデルで、バイエンコーダよりはるかに正確ですが、コーパス全体に対して走らせるには遅すぎます。50件取得して5件にリランクするのが一般的な形です。クエリの書き換え、つまり検索前にモデルが質問を拡張または言い直すことは、短い、あるいは曖昧なクエリや、質問が前のターンに依存するマルチターンのチャットで役立ちます。

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

実際の質問50から100件と、それぞれに答えるチャンクまたは文書からなるテストセットを作ってください。検索はrecall at kと平均逆順位（MRR）で測り、チャンク化、エンベディングモデル、融合の重みを変えるたびに観察します。生成は忠実性（すべての主張が与えられたチャンクに遡れるか）、回答の関連性、参照回答があれば正確性で測ります。RAGASなどのライブラリはこれらをLLM判定器で自動化します。傾向の追跡には有用ですが、サンプルを読むことの代わりにはなりません。プロンプトの長さにも注意してください。Liu et al.は2023年に、モデルは長いコンテキストの中央をうまく使えないことを見いだしました。平凡なチャンク10件は、良いチャンク3件より悪いことがあります。

どこから始めるか

最近傍検索をゼロから作るエンベディングと類似検索から始め、次にプロンプティング側のためにLLMをうまく使う、サービングのためにノートブックからサービスへに進んでください。ローカルエンベディングによる小さなRAGプロジェクトは、図のパイプラインをAPIキーなしでラップトップ上に組み立て、RAGパイプラインのチェックリストはリリース前のレビューです。

ツールとプラットフォーム

よくある間違い

• 最終回答だけを評価する。recall at kがなければ、検索の失敗とプロンプティングの失敗を区別できません。
• 表、コード、リストを文字数でぶった切ってチャンク化し、答えを含むチャンクが行の途中から始まる。
• クエリと文書を異なるモデル、あるいは同じモデルの異なるバージョンで埋め込み、すべての距離を無意味にする。
• フィルタを検索の内側ではなくtop-kの後に適用したために、テナントや権限をまたいで取得する。
• 取りこぼしを直すためにtop-kを上げる。チャンクが増えるとプロンプトが薄まり、正しいチャンクがコンテキストの中央に押しやられます。
• 再インデックスをしない。文書は変わり、自信ありげな引用の付いた古いチャンクは、回答なしより悪いです。

さらに深く

• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020。
• Karpukhin et al., Dense Passage Retrieval for Open-Domain Question Answering, 2020。
• Malkov and Yashunin, 航行可能なスモールワールドグラフによる近似最近傍検索に関するHNSW論文, 2016。
• Nogueira and Cho, Passage Re-ranking with BERT, 2019。および Khattab and Zaharia, ColBERT, 2020。
• Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation, 2023。
• sentence-transformersドキュメントと、索引の選び方に関するFAISS wiki。