このティップス集について：パラメータの「手探り」を終わらせる
RAG（検索拡張生成）システムは、知識グラフを活用して関係性を強化するGraphRAG（Amazon Bedrock Knowledge BasesでのAmazon Neptune Analytics連携など、マネージドサービスへの統合も進行中）や、画像・図表まで統合して扱うマルチモーダル対応へと進化を続けています。しかし、どんなに上位レイヤーが高度化しても、そのバックエンドを支えるベクトルデータベースのパフォーマンスがボトルネックになっては意味がありません。
現在、専用のベクトルデータベース（Qdrantや、ストレージ最適化技術との統合が進むMilvus、Weaviateなど）に加え、pgvector（PostgreSQL）のようなRDBMS拡張の採用も広く普及しています。多様化する選択肢の中で、システムごとの最新機能や推奨構成は目まぐるしく変化するため、選定や運用の際は必ず各サービスの公式ドキュメント（milvus.io/docs や weaviate.io/docs など）で最新のリリースノートを確認し、自環境への影響を評価することが重要です。
実際、多くのプロジェクトで「とりあえず導入してみたけれど、期待したほど検索速度が出ない」「精度（Recall）が安定しない」といった課題が報告されています。
原因を探っていくと、多くの場合、インデックスアルゴリズムのパラメータ設定に行き着きます。特に、現在主流となっている近似最近傍探索アルゴリズム「HNSW（Hierarchical Navigable Small World）」の設定です。注意すべき点として、HNSWは単一のソフトウェアバージョンが存在するわけではなく、Apache Luceneやpgvector、Apache Dorisなど、各データベースの裏側で独自の実装と最適化が継続されています。
そのため、公式ドキュメントを見ると、実装に依存した M、efConstruction、efSearch といったパラメータが並んでいます。正直なところ、「これ、何をどう変えればいいの？」と途方に暮れた経験はありませんか？
「とりあえずデフォルト値で」
「ネット記事で見かけた値をそのままコピー」
もしそうしているなら、少しもったいないかもしれません。これらのパラメータは、検索システムの「アクセル」と「ハンドル」のようなものです。実装ごとに最適なチューニングが求められる中、仕組みを知らずに運用するのは、高性能なスポーツカーで渋滞に突っ込むようなものと言えるでしょう。
とはいえ、数式だらけの論文を読み解く必要はありません。実務において必要なのは、「この値を上げると、裏側で何が起きるか」という物理的なイメージを持つことです。
今回は、難解なHNSWのパラメータを「地図と探索」という身近なメタファー（比喩）に置き換えて解説します。そして、なぜ人間による手動チューニングが限界を迎えるのか、AIによる自動化にどう繋げていくべきかをお話しします。
このティップスを読み終える頃には、無機質なパラメータの数値が、意味のある「操作レバー」に見えてくるはずです。
Tip 1：HNSWを「高速道路と一般道」の地図としてイメージする
まず、HNSWというアルゴリズムが何をしているのか、イメージを共有しましょう。HNSWは、膨大なベクトルデータの中から「似ているもの」を高速に見つけるための技術です。
これを「世界地図の中から、特定の住所（目的地）に一番近い家を探す」ゲームだと考えてください。
もし、全ての家を一件ずつ訪問して確認したら（全探索）、時間がかかりすぎて日が暮れてしまいます。そこでHNSWは、地図に「階層構造」を作ります。
- 最上層（高速道路）: 主要都市だけが繋がっている粗いネットワーク。遠くまで一気に移動できる。
- 中間層（幹線道路）: 地域ごとの主要な拠点が繋がっている。
- 最下層（一般道）: 全ての家（データポイント）が存在し、細かく繋がっている。
検索プロセスは、まず上空から高速道路を使って大まかなエリア（例：東京）に飛び、そこから幹線道路（例：渋谷区）へ降り、最後に一般道で目的地周辺を歩き回る、という流れです。
パラメータ「M」は交差点の接続数
ここで登場する重要なパラメータが M です。
M は、この地図上の「各交差点（ノード）から伸びる道路（エッジ）の最大本数」を表しています。
Mが小さい場合（例: M=4）:
交差点から伸びる道が少ない田舎道のような状態です。メモリ消費は少なくて済みますが、道が少ないため、目的地にたどり着くまでに何度も交差点を曲がる必要があり、遠回りになりがちです。Mが大きい場合（例: M=64）:
五差路や六差路どころか、数十本の道が放射状に伸びる巨大なロータリーのような状態です。どこへでもすぐに行ける「近道」が増えるため、検索時の移動回数（ホップ数）は減ります。しかし、地図の情報量が増えるため、メモリ消費量は激増し、地図を作る（インデックス構築）時間も長くなります。
グラフ構造の密度のバランス感覚
実務における勘所は、「メモリ容量と検索ホップ数のトレードオフ」です。
M を増やせば検索性能（特にRecall）は向上しやすいですが、ベクトルデータベースのメモリコストが跳ね上がります。逆に減らしすぎると、グラフの連結性が弱まり、検索時に「孤立したエリア」に取り残されて、正解にたどり着けないリスクが高まります。
一般的には M=16 から 48 程度がよく使われますが、これは「道路網の複雑さ」を決めているのだと理解してください。
Tip 2：インデックス構築時の「efConstruction」は品質への投資
次に、efConstruction です。これはインデックス（地図）を「作る時」の設定値です。
地図を作る際、新しい家（データ）をどの交差点と道路で繋ぐかを決める必要があります。この時、「近所の家をどれだけ念入りに調査するか」を決めるのが efConstruction です。
時間をかけて良い地図を作るか、雑に作るか
efConstructionが小さい場合:
「とりあえず近くに見えた家と繋いでおこう」という突貫工事です。インデックス構築は爆速で終わりますが、出来上がった地図は「最適な道」が繋がっていない、品質の低いものになります。後で検索する人が苦労します。efConstructionが大きい場合:
「周辺の家を広範囲に調査し、最も効率的に移動できるベストな接続相手を探す」という丁寧な工事です。構築には時間がかかります（CPUリソースを食います）が、出来上がる地図は非常に高品質で、検索時の効率が良くなります。
検索時の速度には直接影響しないという誤解
ここでよくある誤解が、「efConstructionを上げると検索が遅くなるのでは？」という懸念です。
実は、efConstruction は検索時のレイテンシ（反応速度）には直接悪影響を与えません。むしろ、高品質なグラフができることで、検索効率が上がり、結果的に検索が速くなることもあります。
つまり、efConstruction は「インデックス構築時間（コスト）」を通貨として支払い、「検索品質（将来の利益）」を買う投資なのです。データの追加頻度が低く、一度作ったら検索ばかりするシステムなら、ここはケチらずに大きめの値を設定するのが定石です（例：100〜500など）。
Tip 3：検索時の「efSearch」はどこまで寄り道するか
インデックスが構築され、実際に検索を実行する段階で重要な役割を担うのが efSearch（システムによっては単に ef と表記されます）です。
これは、検索プロセスにおいて「候補リスト（訪問予定リスト）に常時いくつの地点を保持しておくか」を決定する値です。地図の探索に例えるなら、「目的地を探す際、どれだけ広範囲に寄り道して聞き込みを行うか」という探索の深さや執念の度合いを示しています。
再現率（Recall）を左右する最大のレバー
efSearchが小さい場合:
「おそらくこっちだ」と推測した方向へ一直線に進みます。探索範囲が絞られるため計算量が少なく、圧倒的なスピードで結果が返ってきます。しかし、「実は一本隣の道にもっと近い家があった」という見落としが発生しやすくなります。つまり、取りこぼしが増え、検索の精度（Recall）が低下するリスクを伴います。efSearchが大きい場合:
「こっちかもしれないし、あっちの可能性もある」と、有望なエリアを広範囲かつしらみつぶしに探索します。見落としが減少し、正解（真の近傍）を見つけ出す確率（Recall）は劇的に向上します。ただし、その分だけ計算負荷が増加し、検索速度（QPS）はトレードオフとして低下します。
レイテンシとの完全な比例関係
efSearch は、単なる技術的な設定値ではなく、ビジネス要件に直結する重要なパラメータです。
「ユーザー体験を損なわないよう、多少精度が落ちても0.05秒以内で応答を返したい」という要件であれば、efSearch を低く設定します。
一方で、「RAG（検索拡張生成）の回答品質を極限まで高めたい。0.2秒かかっても正確なドキュメントを確実に引き当てたい」というケースでは、efSearch を高く設定する必要があります。とくにRAGシステムにおいて検索の取りこぼしは、AIのハルシネーション（もっともらしい嘘）の引き金になりやすいため、この精度の担保は非常に重要です。
このパラメータの最大の利点は、インデックス構築後であっても、検索クエリの特性に合わせて動的に変更できることが多い点にあります。状況に応じて探索の深さを柔軟にコントロールできるため、ここが検索パフォーマンス最適化の主戦場となります。
Tip 4：手動チューニングが「モグラ叩き」になる理由
ここまで読むと、「なるほど、Mで道路を整備し、efConstructionで地図の質を高め、efSearchで速度と精度のバランスをとればいいんだな」と理解できたと思います。
しかし、実際にやってみると、これが一筋縄ではいきません。なぜなら、これらのパラメータは相互に依存しているからです。
パラメータ間の相互依存性
例えば、M（道路数）を増やすと、探索の選択肢が増えます。すると、同じ efSearch の値でも、処理すべき計算量が変わってきます。また、M を変えれば最適な efConstruction の値も変わる可能性があります。
「精度を上げたいから M を増やしたらメモリが溢れた」
「メモリを節約しようと M を減らしたら、efSearch を極端に上げないと精度が出なくなり、結果として遅くなった」
このように、あちらを立てればこちらが立たず、という状態になりがちです。
データ分布の変化で設定が腐る現象
さらに厄介なのが、「最適な設定はデータセットによって異なる」という事実です。
10万件のデータでテストして完璧な設定を見つけたとしても、データが1000万件に増えたら、その設定はもはや最適ではありません。また、データの次元数（768次元なのか1536次元なのか）や、データの分布（クラスター状に固まっているか、一様に散らばっているか）によっても、HNSWの挙動は変わります。
人間が手動で「この値がベストだ！」と決めても、データが増え続ける運用環境では、その設定はすぐに「賞味期限切れ」を起こします。これが、手動チューニングが「終わりのないモグラ叩き」になってしまう理由です。
Tip 5：AIによる自動チューニングの第一歩は「評価指標」の定義から
ここで、AIや機械学習を用いた「パラメータ自動チューニング」（Auto-tuning）の出番です。
最近の高度なベクトルデータベースやMLOpsツールには、ベイズ最適化などの手法を使って、最適なパラメータの組み合わせを自動探索する機能が含まれているものがあります。
しかし、AIに「いい感じにしておいて」と丸投げすることはできません。AIは優秀なナビゲーターですが、「目的地（ゴール）」は人間が決める必要があるからです。
「なんとなく速く」ではなくQPSとRecallで語る
自動チューニングを成功させるためには、「評価関数（Objective Function）」を明確に定義する必要があります。
具体的には、以下の2つの指標のバランスを数値で指定します。
- QPS (Queries Per Second): 1秒間にどれだけ検索できるか（スループット）。またはレイテンシ（応答速度）。
- Recall (再現率): 正解データ（Ground Truth）のうち、どれだけを上位に含められたか。
例えば、「Recall@10 が 0.95 以上である条件の中で、QPSを最大化せよ」といった指示です。
Ground Truth（正解データ）の準備
ここで最も重要な準備が、「正解データ（Ground Truth）」の作成です。
HNSWは「近似」探索なので、誤差を含みます。その精度を測るためには、「時間をかけて全探索（Brute Force）した、間違いのない正解リスト」が必要です。
自動チューニングを行う前には、一部のデータを使ってこの「正解リスト」を作成し、それを教師データとしてAIにパラメータを探索させるプロセスが必要になります。この準備を怠ると、AIは「何をもって良いとするか」が分からず、見当違いなチューニングをしてしまいます。
まとめ：パラメータ調整はAIに任せ、検索体験の設計へ
ベクトル検索の主要なパラメータ（M、efConstruction、efSearch）は、直感に反する挙動を示すことが多く、手動での最適化は容易ではありません。
- M: 地図の道路数（メモリ消費と探索効率のバランス）
- efConstruction: 地図作りの丁寧さ（インデックス構築コストと品質への投資）
- efSearch: 検索時の寄り道範囲（検索速度と精度の調整弁）
これらを「地図」のイメージとして理解しておくことは、システム運用時のトラブルシューティングにおける基礎体力として必須です。しかし、日々の運用において、これらを人間が微調整し続けるのは現実的ではありません。
目指すべきは、「評価指標（ゴール）を正しく定義し、調整作業自体はAIや自動化ツールに委ねる」という運用スタイルです。最近のRAG（検索拡張生成）の動向を見ても、検索精度を向上させるためには、単純なベクトル検索の調整だけでなく、検索意図の解釈やハイブリッド検索の活用がより重要視されるようになっています。
パラメータの数値調整から解放されれば、より本質的な課題——「ユーザーはどのような意図で検索しているのか」「RAGにどのようなコンテキストを与えれば回答品質が向上するのか」といった、検索体験そのものの設計にリソースを集中できるようになります。
「自社のデータで最適なパラメータが見つからない」「自動チューニングを導入したいが、評価指標の設計に迷っている」といった課題は、多くのプロジェクトで珍しくありません。自社への適用を検討する際は、専門的な知見を活用することで導入リスクを軽減できます。個別の状況に応じたアドバイスを得ることで、技術的な側面だけでなく、データに基づいたより効果的な戦略の策定が可能です。
また、パラメータの挙動をより深く理解するためには、実際のデータセットを用いたハンズオン形式での学習や、パフォーマンスの変化をリアルタイムで可視化するデモの活用が効果的です。このテーマをさらに実践的に学ぶために、最新の技術動向や事例を継続的に収集していくことが重要です。
コメント