社内ナレッジ検索は“索引づくり”が9割―RAGを長持ちさせる下ごしらえ
はじめに——答えは出るのに、肝心な時に外すのはなぜか
社内のQ&Aや手順書を読ませると、最初はよく当たるのに、規模が増えるほど外れが混じる。よく見ると、文章の分け方やタグの付け方、検索キーワードの前提がバラバラで、索引（インデックス）の作りが弱い。道具を替える前に、土台を整える話をします。
検索ベースの強化や“文脈を盛る”手法は各所で整理され、RAGの精度に直結することが報告されています。例えば「文脈付き埋め込み／BM25」を併用する手法や、文書設計のベストプラクティスが公開されています。(Anthropic)
まず決めるのは“どの質問に答えるか”
万能な検索はありません。先に、繰り返し出る具体的な質問を3〜5個だけ選び、これに必ず当てる設計から始めます。質問を決めると、必要な見出し、必要な断片の粒度、不要な装飾が見えてきます。
- よくある誤り：漫然と全文を埋め込む
- 望ましい始め方：質問→必要断片→見出し・タグ設計→インデックス作成の順
（ベンダ資料でも、文書の見出し・構造化・重複排除がRAGの成否に直結すると明記されています。） (AWS ドキュメント)
“切り方”が当たりを決める
断片（チャンク）は細かすぎても粗すぎても外れます。実務では次のルールが有効でした。
- 意味の固まりで切る：見出しや箇条書きを素直に使う
- 出典を必ず同梱：断片に原文URL/ファイル名＋見出しを持たせ、回答に出典を付ける
- 重複は1か所に寄せる：同義の手順が多拠点に散らばると、検索が割れます
（出典付き回答や“文の単位での根拠付け”は評価ガイドラインでも重視されます。） (RAG)
取り出し方は“ハイブリッド”で素直に
単一のベクトル検索に頼らず、キーワード検索と再ランキングを合わせます。特に略語や型番が多い社内文書では、単語ベースの拾い上げが効きます。文脈を付与して埋め込みを作る手法の併用は、取り漏れの削減に寄与します。(Anthropic)
権限は“検索時”ではなく“回答時”にも効かせる
権限を索引側にだけ持たせると、検索は通っても回答が越境してしまうことがあります。取り出し→生成の両方で権限を確認できる設計にしておくと事故が減ります。実装パターンと注意点はセキュリティ系の解説にまとまっています。(Amazon Web Services, Inc.)
“効いたか”は小さく測る
まずは選んだ3〜5問で、根拠付きの回答率と時間短縮を測ります。定義は簡単で構いません。
- 根拠付き回答率：出典を含み、レビューで妥当と判定された回答の割合
- 時間短縮：同じ質問に対し、従来フローとの差（分）
評価指標としては、**根拠（Support）／流暢さ（Fluency）／要素充足（Nugget）**といった枠組みが公開されています。自社向けに薄めて転用すると便利です。(RAG)
“運用”は小さい約束の積み重ね
- 文書は見出し→本文の順で整え、更新時は重複を寄せる
- 断片には**由来（どこから／いつ）**を残す
- 検索の設定は月1で見直し、質問セットで回帰テスト
- 権限は取り出し・回答の両方に掛ける
（検索やRAGの成熟度を段階的に高める設計図は、クラウドの実装解説にもまとまっています。） (Amazon Web Services, Inc.)
おわりに——“速い答え”より“当たる答え”を
新しいデータベースや巨大なモデルを探す前に、質問を決め、断片を整え、出典を付ける。この順番だけで、当たり外れは目に見えて変わります。索引づくりは地味ですが、RAGを“長持ち”させる近道です。
参考（一次情報）
- 文脈付き検索の手法と効果（Contextual Retrieval） 。(Anthropic)
- 文書設計とRAG最適化の実務ガイド（PDF）。(AWS ドキュメント)
- 権限制御を組み込んだRAGの設計パターン。(Amazon Web Services, Inc.)
- RAG評価（Support / Fluency / Nugget など）の公開基準。(RAG)
- 検索強化RAG／成熟度向上の設計例。(AWSビルダーセンター)
Discussion