「RAGを作ったが精度が出ない」はなぜ起きるか
生成AIの社内導入で最も多い相談が 「RAG（検索拡張生成）を組んだが、期待した回答が返ってこない」 です。
原因のほとんどは LLM ではなく、検索（Retrieval）側の設計にあります。本記事では実務で効いた改善手法を整理します。
1. Chunking 戦略 — 分割の粒度が精度を決める
文書を固定長で機械的に切ると、意味の途中で分断されて検索精度が落ちます。
- 固定サイズ + Overlap: シンプル。512〜1024トークン、20%オーバーラップが定番
- 意味単位分割: 見出し・段落・箇条書き単位で切る。構造化文書に有効
- 親子チャンク: 小さく検索し、回答時は親（大きい）チャンクを渡す
実務では「意味単位で切る + 親子構成」の組み合わせが安定します。
2. Re-ranking — 検索結果を並べ直す
ベクトル検索の top-k をそのまま渡すと、関連度の低いチャンクがノイズになります。
- Cross-encoder で top-k を再スコアリング（Cohere Rerank / bge-reranker 等）
- 検索で top-30 → re-rank で top-5 に絞る、が費用対効果良好
3. Query rewriting — 質問を検索向けに書き換える
ユーザーの質問はそのまま検索に向かないことが多い。
- HyDE: 仮の回答を生成してから、その回答で検索する
- Multi-query: 質問を複数の言い換えに展開して検索、結果をマージ
4. Contextual Retrieval — チャンクに文脈を追記する
Anthropic が提唱した手法で、各チャンクの前に「この文書全体における位置づけ」を1文追記してから embedding します。
これだけで検索失敗率が大きく下がるケースがあり、実装コストも低いので最初に試す価値があります。
5. Embedding の類似検索を速くする
- pgvector: 中小規模ならこれで十分、DB統合が楽
- HNSW / IVF-Flat インデックスで近似最近傍
- 100万件を超えるなら Pinecone / Qdrant / Weaviate を検討
トレードオフは 精度 vs コスト vs レイテンシ。要件に応じて選定します。
モデル選定 — OpenAI / Anthropic / 自社ホスト
- コスト最適化: 難易度で Sonnet ↔ Haiku を切り替え
- 長文の再利用: Anthropic の Prompt Caching が強力
- 機密要件: 自社ホスト（vLLM / Ollama）も選択肢
まとめ
RAG は「LLMを繋げば動く」ものではなく、検索側の設計・評価・改善のループが本体です。
IT.Skill では、PoC で終わらせず運用に乗せる RAG / 生成AI の導入を受託しています。
「何から始めるべきか」の顧問相談から、お問い合わせ ください。