RAG完全ガイド：社内FAQ検索の作り方と評価指標（正確性を上げる5つのコツ）

はじめに

社内ナレッジ（規定、手順書、FAQ、議事録）をLLMに答えさせるとき、最新・私有の情報を参照できない問題が壁になります。RAG（Retrieval-Augmented Generation）は、この壁を「検索で根拠文書を添付してから生成する」ことで乗り越える実装パターンです。本記事は、RAGを“運用できる品質”に持っていくまでの実務ガイドです。

RAGとは（30秒で把握）

• Retrieval：質問からクエリを作り、ベクタDBなどから関連文書を取り出す
• Augmented：取り出した根拠をプロンプトへ追加して文脈を拡張
• Generation：LLMが根拠に基づき回答を生成（根拠URLを添えるのが基本）

典型ユースケース

• 社内ヘルプデスク / IT運用FAQ
• コンタクトセンターの応対支援（根拠リンク同梱）
• ドキュメント検索（設計書・手順書・契約書）
• 法務・監査の条文/条項照合（要注意：最終判断は人）

アーキテクチャ最小構成

1. 文書取り込み（PDF, Docx, Slack, Confluence…）
2. 分割（チャンク化：段落/見出し単位、重なりを持たせる）
3. 埋め込み（テキスト→ベクトル）
4. 索引（ベクタDBに保存、メタデータ：部門/日付/機密度）
5. 検索（k件＋多様化：類似＋BM25のHybrid推奨）
6. プロンプト構築（ロール指示、根拠の引用ルール、トーン）
7. 生成＆根拠提示（回答＋出典URL＋スニペット）
8. 評価＆ログ（クエリ→検索→回答→フィードバックを記録）

データ準備の実務Tips

• チャンク長：日本語は350〜700字＋オーバーラップ50〜100字が無難。
• セクション粒度：見出し階層を保つ（H2/H3）→プロンプトに「セクション名」も渡す。
• 更新日メタ：最新優先の再ランクに効く。「古い規定の誤回答」を減らす。
• 機密タグ：権限でフィルタ。検索段階で除外するのが鉄則。

埋め込みモデル選定

• 日本語混在：多言語モデル or 日本語特化モデル
• 短文質問×長文回答：質問とチャンクで別々の埋め込みも有効
• 更新頻度：モデル差よりチャンク設計と評価運用の影響が大きい

索引・検索の設計

• Top-k：まずは k=3〜8 を比較。多すぎるとノイズで逆効果。
• Hybrid検索：ベクトル＋BM25のスコアを正規化して和。略称・専門用語に強くなる。
• 再ランク（クロスエンコーダ）：上位20を精密再ランク→k=3〜5に絞ると回答が安定。

プロンプト設計のコア

• 役割：「あなたは社内FAQ専門アシスタントです」
• ルール：
  1. 根拠文書の内容に限定
  2. 根拠が不足なら「不明」と答える
  3. 出典リンクと引用箇所を必ず提示
• 出力形式：箇条書き＋最後に要約、禁止事項（憶測、推測）

評価指標（最低限）

• Answer Accuracy（人手ラベル）
• Context Precision（提示根拠が正しい割合）
• Context Recall（必要根拠を取りこぼさない割合）
• Faithfulness（根拠に忠実＝幻覚の少なさ）
• Latency（P95応答時間）、Coverage（自己解決率）

簡易評価テンプレ（疑似）

(1) 評価用質問セットを20–50件用意（部署横断で収集）
(2) RAGなし / ベクトルのみ / Hybrid / 再ランクあり をAB比較
(3) 各回答に対し:
    - 正解△/×（人手）
    - 出典URLの妥当性（人手）
    - 応答時間（自動）
(4) 指標ダッシュボード化（Exact match率、Faithfulness、Latency）

品質を底上げする「5つのコツ」

1. Hybrid検索＋再ランクを標準化
2. チャンクに見出し・日付・章番号を埋め、プロンプトへ渡す
3. 古い規定は優先度を下げる（再ランクで減点）
4. 回答トーンを明確化（結論→根拠→注意点→出典）
5. “不明”を許容（無理に答えない文化：運用ルールに明記）

ミニ実装フロー（擬似コード）

ingest():
  docs = load_all()
  chunks = split(docs, size=500, overlap=80, keep_headings=True)
  vectors = embed(chunks)
  upsert_to_vector_db(vectors, metadata={section, updated_at, acl})

answer(question, user):
  cand = hybrid_search(question, top=20, filter=acl(user))
  reranked = cross_encoder_rerank(question, cand)
  ctx = select_topk(reranked, k=4)
  prompt = build_prompt(question, ctx, rules=STRICT)
  reply = llm(prompt)
  return reply + citations(ctx)

運用・ガバナンス

• ログ設計：質問→検索クエリ→候補→採用根拠→回答→ユーザー評価
• 学習ループ：低評価質問を週次レビュー→チャンク/プロンプト/再ランクを改善
• 権限：部署・機密区分で検索前フィルタ。生成側でのマスキングは最終防衛線。
• 改訂版管理：改訂履歴をメタデータで持ち、古版をサプレッション

失敗あるある

• チャンクが大きすぎる/小さすぎる → ノイズor断片化
• kが多すぎて迷走 → k=3〜5で堅く
• 根拠を表示しない→信頼されない・運用改善できない
• RAGを万能視→FAQ向き。計算・数値根拠は別処理（関数呼び出し）

まとめ

RAGは「検索の精度×プロンプトの統制×運用評価」の三位一体です。技術差よりも、データ作りと検証サイクルが勝敗を分けます。まずはHybrid＋再ランク＋k=4で土台を作り、“不明”を許容する評価文化を敷きましょう。

---