一般的にRAG（検索拡張生成）システムを構築する際、現場では共通の課題によく直面しますよね。
「最新のモデルに移行したのに、社内ドキュメントの内容を正しく答えてくれない」
「ハルシネーション（もっともらしい嘘）がなかなか減らない」
こういった壁にぶつかったとき、まずはプロンプトの最適化に取り組むケースが多いのではないでしょうか。ペルソナを付与したり、Chain-of-Thought（思考の連鎖）を試したりと、試行錯誤を重ねるのは現場の定石です。もちろん、こうした工夫は現在でも欠かせないアプローチです。
しかし、ここで少し視点を変えてみましょう。
AIが事実と異なる回答を生成する根本的な原因は、LLM（大規模言語モデル）の性能やプロンプトではなく、実は前段の「検索」プロセスに隠れていることが多いんですよ。
具体的には、システムに組み込んだベクトルデータベースの初期設定が、回答精度を大きく左右している可能性があります。今回は、広く使われているベクトルデータベースのChromaを例に、その仕組みを現場目線で掘り下げていきます。
従来のシステム開発では「検索処理は速ければ速いほど優れている」と信じられがちですが、生成AIのシステムにおいてその前提は必ずしも正解とは限りません。むしろ、あえて「速度を妥協する」ことが、RAGの精度を大きく高める現実的な解決策になるというお話をしたいと思います。
なぜRAGの精度改善は「プロンプト」止まりなのか
RAGシステムは、大きく分けて「Retrieval（検索）」と「Generation（生成）」という2つのフェーズで構成されています。システムの回答精度が低いと感じたとき、私たちはどうしても目に見えやすい「Generation」の側、つまりLLMの性能そのものやプロンプトエンジニアリングに原因を求めてしまいがちですよね。
LLMのせいにする前に疑うべき「検索の質」
これを料理に例えて考えてみましょう。どんなに腕の良い一流シェフ（LLM）を雇ったとしても、鮮度の落ちた質の悪い食材や、オーダーとは全く関係のない食材（検索結果）を渡されたら、美味しい料理（的確な回答）を作ることはできません。
「カレーを作ってほしい」という明確なオーダーに対して、リンゴとペンチを渡されたらどうなるでしょうか。シェフは混乱して適当な創作料理を出すか、あるいは調理を拒否するはずです。実は、これこそがRAGにおけるハルシネーションを引き起こす主要な要因の一つなのです。
実際の開発現場において、回答精度の低さに悩むあまり、プロンプトの微調整を延々と繰り返す「プロンプト沼」に陥るケースは珍しくありません。現在、詳細な役割指定や反復的なプロンプト最適化といったベストプラクティスが広く知られており、モデルのアップデートも継続的に行われています。
しかし、システムログを冷静に分析してみると、質問に対する正解が含まれたドキュメントが、そもそもベクトル検索の結果（上位チャンク）に含まれていなかったという事実が頻繁に浮かび上がってきます。
これでは、最新の高性能モデルを用い、どれほど高度なプロンプト最適化を施したとしても、正解を導き出すことは物理的に不可能です。この「検索漏れ（Recall不足）」こそが、多くのRAGシステムにおける真のボトルネックとなっています。
近年注目を集めているGraphRAG（ナレッジグラフを活用した検索）や、図表を含めたマルチモーダルRAGへの進化は、まさにこの「検索フェーズでの取りこぼし」を防ぎ、より深い文脈理解を実現するためのアプローチだと言えます。プロンプト調整に膨大な工数をかける前に、まずは「正しい情報が過不足なく取得できているか」を強く疑う方が、費用対効果の高いアプローチだと言えます。
近似最近傍探索（ANN）の「近似」が孕むリスク
では、なぜそもそも検索漏れが起きてしまうのでしょうか。その根本的な理由は、Chromaを含む現代のベクトルデータベースの多くが、近似最近傍探索（ANN: Approximate Nearest Neighbor）という技術を基盤としている点にあります。
「近似」という言葉が示す通り、これは「厳密に一番近いものを探す」のではなく、「だいたい近そうなものを、圧倒的に高速に探す」ための技術です。
数百万、あるいは数億という膨大なベクトルデータの中から、すべてのデータに対して厳密に距離計算を行い、最も類似したデータを探し出す（全探索）のは、計算コストの観点から現実的ではありません。そのため、精度を多少犠牲にしてでも実用的なレスポンス速度を確保するアルゴリズムが発展してきました。その代表格がHNSW（Hierarchical Navigable Small World）です。
HNSW自体は非常に優秀なアルゴリズムであり、主要なデータベース製品でも標準的に採用されている業界のデファクトスタンダードです。
しかし、デフォルトの設定をそのまま鵜呑みにしてしまうと、この「精度の犠牲」がビジネス上無視できないレベルになることがあります。例えば、極めて高い網羅性が求められる特許調査や、一言一句の正確性が問われる契約書確認といったクリティカルな業務において、最も重要なドキュメントが「近似」の過程で切り捨てられてしまうリスクは、システム設計者が常に意識すべき重大な課題です。
「速さ」と「正確さ」のトレードオフを正しく認識し、システムの用途に応じてパラメータを緻密に調整する、あるいはキーワード検索と組み合わせたハイブリッド検索を実装するといった、アーキテクチャレベルでの現実的な対策が不可欠となります。
HNSWのブラックボックスを開ける：Chromaの裏側で起きていること
パラメータの調整に入る前に、Chromaの内部で何が起きているのか、HNSWアルゴリズムの仕組みを少し覗いてみましょう。
スモールワールド現象とナビゲーションの仕組み
HNSWは、「スモールワールド（狭い世界）ネットワーク」という概念に基づいています。「友達の友達」を数回たどれば世界中の誰とでもつながれる、という考え方です。
ベクトル空間上のデータポイント（ドキュメントのチャンク）を「家」だとすると、HNSWは、これらの家同士を道路でつないで地図を作ります。
ただし、すべての家と道路をつなぐわけではありません。
- 高速道路レイヤー（上層）: 遠く離れた家同士をつなぐ、長距離移動用のネットワーク。
- 一般道レイヤー（下層）: 近所の家同士をつなぐ、地域密着型のネットワーク。
検索クエリ（質問）が来ると、アルゴリズムはまず上層の高速道路を使って、目的地の「だいたいのエリア」まで一気に移動します。そこから徐々に下層の一般道へ降りていき、最終的に目的の家にたどり着くという効率的な動きをします。
パラメータ「M」と「ef」が決定するグラフの解像度
この地図作りと移動において、インフラ設計の観点から重要なパラメータが2つあります。
M（Max Links）: 各ノード（家）から伸びる道路の最大本数です。
Mが大きいと、選択肢が増えます。地図は複雑になりますが、目的地へたどり着ける確率（精度）が上がります。- 逆に
Mが小さいと、メモリは節約できますが、最適なルートを見逃すリスクが高まります。
ef（Exploration Factor）: 探索時に「寄り道して確認する候補の数」です。
efが大きいと、より多くの候補をリストアップしながら進むため、正解を見つける確率が高まります。しかし、計算量は増えます。efが小さいと、脇目も振らずに進むので高速ですが、正解の家の隣を通り過ぎてしまうかもしれません。
Chromaのデフォルト設定は、あくまで一般的な用途向けにバランスよく調整されているものだと認識しておく必要があります。
速度至上主義からの脱却：ビジネスRAGにおける「遅さ」の許容
ここで、エンジニアとしての設計思想を少し転換してみましょう。これまでのWeb開発における「高速化こそ正義」という常識を、RAGにおいては一度疑ってかかるべきです。
ミリ秒を削る意味は本当にあるのか？
従来のWebシステム開発において、検索レイテンシは極めて重要な指標でした。検索結果の表示が0.1秒遅れるだけでユーザーの離脱率は跳ね上がるため、ミリ秒単位のチューニングが命でした。そのため、ベクトル検索の中核を担うHNSWなどのアルゴリズムも、長年「いかに精度を落とさずに高速化するか」に注力して進化してきました。
現在では多くのデータストアがHNSWベースのインデックスを採用し、高速なベクトル検索を実現しています。しかし、ここで立ち止まって考えてみてください。
RAGアプリケーションにおいて、ユーザー体験（UX）を決定づける最大のボトルネックはどこにあるでしょうか？
それは検索速度ではなく、LLMの生成時間です。ユーザーが質問を投げかけ、LLMが回答を生成し終わるまでには、数秒から場合によっては数十秒の時間がかかります。この長い待ち時間の中で、検索にかかる時間が「50ミリ秒」か「200ミリ秒」かは、ユーザーの体感にとって誤差でしかありません。
LLMの生成時間と比較した際の検索レイテンシの無意味さ
LLMの生成プロセスと比較すると、ベクトル検索の遅延短縮がもたらす恩恵は実は限定的です。むしろ、検索時間を意図的に延ばしてでも、検索の再現率（Recall）を極限まで高める方が、最終的なユーザー満足度は確実に向上します。
HNSWなどのアルゴリズムでは、探索パラメータ（ef_searchなど）を調整することで、速度と精度のトレードオフをコントロールできます。あえて「遅く」することで、より正確なドキュメントを見つけ出すことが可能です。
以下の2つのシナリオを比較してみましょう。
- シナリオA（速度重視）:
- 検索は高速（0.05秒）だが、精度が低く重要なドキュメントを取りこぼす。
- LLMは不十分な情報を元に、時間をかけて（5秒）誤った回答や幻覚（ハルシネーション）を生成する。
- シナリオB（精度重視）:
- 検索に時間はかかる（0.5秒）が、パラメータ調整により適切なドキュメントを確実に見つけ出す。
- LLMは正確な情報を元に、時間をかけて（5秒）ユーザーが求めていた的確な回答を生成する。
ビジネス価値が高いのは、間違いなくシナリオBですよね。
「データベースはミリ秒単位で高速であるべき」という従来の固定観念にとらわれず、RAGにおいては「ユーザーが許容できる待ち時間の範囲内で、検索リソースを最大限に使い精度を高める」という現実的な設計思想が重要です。最新のデータベース機能が提供するパラメータ調整の余地を、速度ではなく精度のために活用することを強くお勧めします。
Chromaにおける具体的な最適化戦略：再現率99%への道
現在のベクトル検索のデファクトスタンダードとなっているHNSWアルゴリズムですが、多くの開発現場ではデフォルト設定のまま運用されがちです。しかし、RAGシステムにおいて「回答の正確性」を最優先するならば、以下のパラメータに対する理解と介入が不可欠です。ここではChromaを例に、現場で使える精度重視のチューニング戦略を解説します。
ef_construction：インデックス構築時の設定
まず見直すべきは、インデックスを作成する（データを登録する）際のパラメータef_construction（Chromaの設定ではhnsw:construction_efなどで指定）です。これはグラフ構造を構築する際に、各ノードが探索する近傍候補の数を決定します。
- デフォルト: 多くの場合、100程度のバランスの取れた値に設定されています。
- 推奨戦略: 大幅に高い値へ設定します。
この値を引き上げると、データの登録（インデックス構築）にかかる計算コストと時間は確実に増加します。しかし、考えてみてください。RAGシステムにおけるドキュメントのインデックス化は、ユーザーを待たせるリアルタイム処理ではなく、バックグラウンドでのバッチ処理であることが大半ですよね。
インデックス構築時に計算リソースをしっかり「投資」することで、生成されるグラフの品質が高まり、結果として検索時の精度（Recall）が向上します。構築時間の増加は、システム全体の品質を担保するための必要なコストと捉えるのが現実的です。
ef_search：実行時の探索深度の調整
次に、実際に検索クエリを投げる際のパラメータef_search（またはef、Chromaではhnsw:search_ef）です。これは探索時にどれだけの深さ・広さで候補を探るかを制御します。
- デフォルト: 高速な応答を優先し、低めの値になっていることが一般的です。
- 推奨戦略: 許容できるレイテンシの限界まで値を上げます。
この値を上げると、当然ながら検索にかかる時間（レイテンシ）は増加します。しかし、ビジネスユースのRAGでは、0.1秒の高速な誤答よりも、2秒かかっても正確な回答の方が圧倒的に価値が高いケースが珍しくありません。
実際に、efの値をデフォルトから引き上げるだけで、取りこぼしていた重要なドキュメントがヒットし、回答精度が劇的に改善するケースは現場でもよく見られます。
動的なパラメータ調整というアプローチ
さらに費用対効果を高めるアプローチとして、クエリに応じた動的なパラメータ調整をおすすめします。すべてのクエリに対して常に最高負荷の設定を適用する必要はありません。
- 単純な事実確認: 低い
ef設定でリソースを抑え、高速にレスポンスを返す。 - 複雑な推論・分析: 高い
ef設定で、時間をかけてでも広範囲の情報を収集する。
Chromaを含む多くのベクトルデータベースでは、クエリ実行時にこれらのパラメータをオーバーライドすることが可能です。ユーザーの意図やクエリの複雑度に応じて探索深度を動的に切り替えることで、リソース効率と精度の最適なバランスを実現できます。
結論：アルゴリズムを「使い倒す」エンジニアへ
今回の要点をまとめます。
- RAGの精度が出ないときは、LLMを疑う前にベクトル検索の取りこぼしを疑う。
- HNSWのデフォルト設定は「速度重視」であり、ビジネス要件には足りないことがある。
- LLMの生成時間を考慮すれば、検索速度を犠牲にしてでも精度（Recall）を高める方が合理的である。
ef_constructionとef_searchを引き上げ、Chromaの潜在能力を解放する。
便利なライブラリやマネージドサービスを使っていると、ついブラックボックスの中身への関心を失いがちです。しかし、技術の専門家としての真の価値は、そのアルゴリズムの特性を理解し、現場のビジネス要件に合わせて適切に制御できることにあります。
特にHNSWは、特定のツールに依存しない普遍的なエンジニアリング資産です。「デフォルト設定」から一歩踏み出し、現実的な課題解決に向けてパラメータを調整してみてください。それが、ユーザーに届くシステムの価値を劇的に変えるはずです。
コメント