RAGの精度向上手法
今プライベートでRAGシステム作ってるけど、普通に検索しただけだと全然精度でないので、
GPTに聞いてみた
ひとまず全部試してみよう...🥸
🐹 “RAG(Retrieval-Augmented Generation)”で精度をあげる方法って、理論も実践も奥が深いんだけど、代表的&効果的なテクニックをいくつか紹介するね。それぞれでトレードオフ(計算コスト、レイテンシ、開発の複雑さとか)が出てくるから、そのあたりも一緒に意識するといいよ。
以下、精度改善の主要手法と、それぞれのポイント・注意点をまとめるね。
(「精度」って:Retriever が正しい文書を引けること + Generator が正しい・矛盾なく答えること、の両方を含むイメージで語るよ)
🎯 代表的な精度向上の手法
ハイブリッド検索(Sparse + Dense 組み合わせ) 単にベクトル検索(semantic)だけだと、専門用語や固有名詞の一致が効きにくいことがあるから、BM25 や TF-IDF のような伝統的なキーワード検索と組み合わせる。 → ベクトル検索で「意味的に近い」文章を、キーワード検索で「キーワード一致」を補う。 → Redis がハイブリッド検索をサポートしてて、実際に精度向上に効くって報告がある。(Redis)
チャンク分割(Chunking/Parsing 最適化) 文書をどう分割するかで、Retriever に渡る情報の粒度や質が変わる。
再ランキング (Re-ranking) / マルチステージランキング 最初の検索(粗いスコア)で取ってきた上位候補群を、クロスエンコーダー(より重いモデル)で精査して順位を調整する。 → 初段階は高速・低コスト、再ランキングで精度を引き上げる。 → ただし再ランキングは計算コストと遅延を増す可能性も。(arXiv)
クエリ変換/拡張 (Query Rewriting / Expansion / Reformulation) 入力クエリをそのまま使うより、類義語を足したり、文意を補足したりして検索しやすい形式に「書き換える」技術。 → 例えば “癌 治療” → “癌 治療 方法 最新 薬剤” みたいに広げたり、補足説明を足したり。 → 最近の研究では、クエリ変換モジュールを複数生成して検索をかけ、複数クエリの結果を統合する手法もある。(arXiv)
Retriever/Embedding モデルのファインチューニング 一般的な埋め込みモデルだとドメイン固有語やニュアンスが捉えきれないことがあるから、コントラスト学習などで自分の分野向けにチューニングする。 → ドメイン知識を埋め込み空間に反映させて、意味的距離が正しく表現されるように。(Redis)
LLM のファインチューニング or Instruction チューニング Generator 側にも最適化をかけて、 retrieved context を読み取る能力や、一貫性・信頼性を改善するように調整する。 → 特定の応答フォーマットや検証手順をモデルが学ぶようになる。(Redis)
Corrective RAG / Self-RAG / フィードバックループ 検索 → 生成 という流れを一回きりで終わらせず、「この生成結果が retrieved context に整合しているかチェックする → 必要なら追加取得する/修正する」ような反復的プロセスを入れる手法。 → Self-RAG では、retriever/critic/generator の 3 モデルを使って “反省トークン (reflection token)” を生成しながら最適化するというアイデアもある。(Thoughtworks) → “Corrective RAG” も、誤った取得を訂正するようなステップを挟む技術。(Thoughtworks)
Retrieval Preference Optimization (RPO) 最近出た手法で、retrieval の「適切さ (relevance)」を implicit に評価モデルに取り込んで、retrieved context の信頼性を生成に反映させる。これにより、retrieval と生成を密に連携させる。(arXiv)
ハイパーパラメータ最適化
- トップ k(上位何件を取るか)
- チャンクサイズやオーバーラップ率
- リトリーバーの index 構造パラメータ(例:HNSW の M, efConstruction など)
- LLM の温度 (temperature) や max_tokens など こういうパラメータを変えて性能とコストのバランスを取ることがかなり重要。(arXiv)
知識フィルタ / ノイズ除去 取得された文書・チャンク内部に雑多なノイズ(無関係文、誤情報など)が混じることを抑えるフィルタリング処理を厳しくする。 → “Knowledge Filter” モジュールを設ける研究もある。(arXiv)
⚖️ 注意すべきトレードオフとかポイント
- 再ランキングとか反復処理を入れると、遅延 (latency) が増す → リアルタイム性との折り合いが必要
- チャンクが細かすぎると文脈がバラバラになって意味が失われる、逆に大きすぎると不要なノイズを入れる可能性が高くなる
- 埋め込みモデルや再ランキングモデルを重くしすぎるとコストも増大
- ドメイン知識とのズレ:一般モデルでは捉えられない語彙や表現があるから、ドメイン特化が効く場面も多い
- 評価基準を定めて「改善した・できてない」を可視化すること(Precision@k, Recall@k, F1, MRR 等)(Medium)