ふくふくHukuhuku LLC
EP.01RAG 10分公開: 更新:

社内ナレッジRAGが「精度出ない」5つの典型パターン

「RAG入れたが回答が微妙」を、症状別に切り分ける診断マップ。自診断チェックリスト付き。

#RAG#LLM#精度改善
執筆 / 監修
松尾 亮合同会社ふくふく 代表社員

データ基盤・データパイプライン構築 / BI / 生成 AI 活用支援を専門とするエンジニア (28 年)。 本記事は AI 利用ポリシーに基づき、生成 AI の補助で執筆 → 人間が監修・編集して公開しています。

プロフィール詳細
シェア

「を社内に入れたが、欲しい答えが返ってこない」という相談が、この1年で爆発的に増えています。原因は無数にありますが、9割は5つの典型パターンに集約されます。今回は、症状別の切り分けマップを共有します。

5つの典型パターン

P1: 検索精度が低い関連文書が引けないP2: チャンク分割不適切途中で文が切れるP3: 古い情報を返す更新が反映されないP4: 業務文脈の喪失略語・隠語が理解されずP5: 出典が示されないハルシネーション疑念原因切り分け→ どの層で起きてるか
症状から原因への切り分けマップ

P1: 検索精度(再現率)が低い

ユーザーの質問と関連する文書が、そもそもベクトル検索でヒットしていないパターン。原因は「 モデルの言語対応」「クエリと文書の表現ギャップ」「インデックスの粒度」など。

P2: チャンク分割が不適切

「文書途中で切れて、文脈が壊れた状態でベクトル化」が起きているパターン。固定長分割の罠です。

P3: 古い情報を返す

の更新が遅延、もしくは「更新したのに古い文書がまだ取得される」。インデックス再構築のフローが定常運用に組み込まれていないケース。

P4: 業務文脈・略語の喪失

「うちの会社」「あの案件」「先方」のような社内コンテキストや略語、敬語と平易表現の差異で検索ヒットしない。 単体では解けない。 か による Query Expansion が必要。

P5: 出典が示されない /

「答えは合ってるけど、根拠の文書がない」「微妙に誤った数字を返す」。 の鉄則として、必ず出典文書とそのチャンクを LLM に渡し、「出典外の情報は答えるな」とプロンプト制約をかけます。

自診断チェックリスト

  • □ 想定質問10個に対して、関連文書がヒットするか確認した(再現率)
  • □ 出てきた回答が、ヒットした文書から導出可能か確認した(出典整合性)
  • □ 文書更新後5分以内に新情報が反映されるか確認した
  • □ 社内略語・固有名詞での質問が機能するか確認した
  • □ 「分からない」と正しく返せるか確認した

に診断を任せる

prompt:RAG ヘルスチェック
この RAG システムを5つの典型パターンで診断してください。

## チェック項目
1. P1 検索再現率: テスト質問10個 × 関連文書3つを準備、ヒット率測定
2. P2 チャンク品質: ランダム抽出100チャンクの可読性チェック
3. P3 鮮度: 過去1ヶ月の更新文書が反映されているか
4. P4 業務文脈: 社内用語リスト @docs/glossary.md で検索テスト
5. P5 出典整合性: 回答 vs 引用元の差分検出

## 出力
- 各パターンのスコア(0-100)
- 改善優先度TOP3
- 具体的な改善PR案

## ソース
@rag-system/
想定される実行結果(例示)
## RAG 診断結果

### P1 検索再現率: **62/100**(要改善)
- テスト質問10個中、関連文書TOP3に正解含むのが 6.2/10
- 主原因: Embedding モデル(all-MiniLM-L6-v2)が日本語性能不足
- 推奨: multilingual-e5-large への移行

### P2 チャンク品質: **74/100**
- 固定512トークン分割 → 28%のチャンクで文中切断
- 推奨: セマンティック分割(句読点・改行ベース)

### P3 鮮度: **88/100**
- 1日1回のフルインデックス更新 → 概ね問題なし
- 推奨: 重要文書はリアルタイム更新キュー

### P4 業務文脈: **45/100**(最優先改善)
- 社内用語50個中、22個が検索でヒットせず
- 推奨: glossary を Query Expansion 層に組み込み

### P5 出典整合性: **81/100**
- 回答の92%に出典付与、8%でズレあり
- 推奨: 出典強制プロンプトの厳格化

## 改善優先度
1. **P4 業務文脈**: glossary 連携で +25点見込み(PR案 #321)
2. **P1 検索再現率**: Embedding 切替で +20点(PR案 #322)
3. **P2 チャンク**: セマンティック分割で +12点(PR案 #323)

次回予告

EP.02 では、チャンク戦略の5つの分割方法と、それぞれの選び方を実装例とともに掘り下げます。

よくある質問

RAG とは何ですか?
Retrieval-Augmented Generation の略で、LLM が回答を生成する前に外部知識ベース (社内ドキュメント等) から関連情報を検索 (Retrieval) し、その内容を文脈に含めて回答を生成 (Generation) する手法です。LLM の知識カットオフや幻覚を抑え、学習に含まれていない最新情報・社内固有情報を扱えるようにします。
RAG と Fine-tuning の違いは何ですか?
RAG は「検索で都度参照」、Fine-tuning は「モデルパラメータに焼き込む」という構造的違いがあります。頻繁に更新される情報・ソース引用が必要な情報は RAG が向き、文体や形式の固定化・一貫性が重要な場合は Fine-tuning が向きます。多くの実務ケースは RAG 単独で十分です。
RAG の精度が出ない原因は何ですか?
代表的な原因は 4 つです: (1) チャンク戦略が不適切 (短すぎ・長すぎ・文脈が切れている)、(2) Embedding モデルが日本語に弱い、(3) 検索の上位 N 件が回答に必要な情報を含んでいない (再ランクが必要)、(4) プロンプトで「検索結果のみから答える」制約が弱い。本シリーズではこれらを 1 つずつ分解します。
RAG はどんなユースケースに向きますか?
社内ドキュメント検索、カスタマーサポート Bot、技術文書の Q&A、規約・契約書の参照、最新ニュースを含む質問応答、などに向きます。逆に「明確な正解が無い創作的な質問」「数学的な計算」「画像理解」などは RAG だけでは解決しません。
RAG にはどんなツールが使えますか?
ベクトル DB は Pinecone / Weaviate / Qdrant / Chroma / Milvus、フレームワークは LangChain / LlamaIndex / Haystack、Embedding モデルは OpenAI text-embedding / Cohere / multilingual-e5 / 日本語 BGE などが選択肢です。小規模なら自前実装、中規模以上はフレームワーク + マネージドベクトル DB が現実解です。
RAG とエージェントの違いは何ですか?
RAG は「検索 → 回答生成」の固定パイプラインです。エージェントは「LLM が状況を判断して、検索・計算・他 API 呼び出し等の Tool を選んで実行する」ループ構造です。RAG はエージェントが使う Tool の 1 つとして組み込まれることが多く、両者は競合ではなく補完関係です。
シェア

この記事の感想を教えてください

あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。

シリーズの外も探す:

まずは、現状を聞かせてください。

要件が固まっていなくて大丈夫です。現状診断と方針提案までを無料でお手伝いします。

無料相談フォームへ hello [at] hukuhuku [dot] co [dot] jp