導入

pgvectorは、使い慣れたPostgreSQLにベクトル検索機能を追加できる手軽さから、多くの開発者にとって魅力的な選択肢となっています。シンプルなデモを動かすだけなら驚くほど簡単ですが、そこから堅牢な本番システムへと移行する過程では、一連の自明ではない課題や、重大なアーキテクチャ上の決断が待ち受けています。

この記事は、実際のプロダクションレベルでのpgvector実装から得られた、最も驚き、かつ影響の大きかった教訓をまとめたものです。よくある落とし穴を避け、より効果的なベクトル検索システムを構築するための実践的なガイドとして、現場のエンジニアの皆様にお届けします。

--------------------------------------------------------------------------------

1. 日本語の「意味」は、単純なベクトル化の最大の壁

英語と日本語のテキストをベクトル化するプロセスには、根本的な違いが存在します。この違いを理解しないまま進めると、検索精度が著しく低下する原因となります。

英語は「明示型（explicit）」言語であり、文章に含まれる単語や文法構造そのものが意味の大部分を担います。一方で、日本語は「含意型（implicational）」言語であり、テキスト化されていない非テキスト情報、すなわち文脈、ニュアンス、そして心の声・雰囲気・暗黙知といった文化的背景が意味を決定づける上で極めて重要です。

この違いは、「I Love You」という表現を例に取ると明確です。英語ではこのフレーズが直接的な愛情表現として機能しますが、日本語では状況に応じて様々な表現が使われます。直接的な「愛している」から、相手への気遣いを示すことで愛情を表現する「寒くない？」まで、その幅は非常に広いのです。

結論として、日本語の「意味」を正確に捉え、ベクトル検索の精度を高めるためには、単一の文字列をベクトル化するだけでなく、背景知識と文脈補完までを考慮に入れたシステム設計が不可欠となります。

--------------------------------------------------------------------------------

2. HNSWのフィルタ検索が「ほぼ何も返さない」謎の挙動

pgvectorのHNSWインデックスでメタデータによるフィルタ検索を行うと、直感に反して結果がほとんど返ってこないという、非常に紛らわしい問題に直面することがあります。

この挙動の原因は、pgvectorのデフォルトの処理順序にあります。これは、データベース全体からフィルタ条件に合うものを探すのではなく、まず類似度だけで選んだごく僅かな候補（デフォルトef_searchは40件）に対し、その中からフィルタを適用するためです。

ある実例では、LIMIT 501を指定したフィルタ付きクエリが、わずか32件の結果しか返しませんでした。これは、最初に選ばれた類似度上位40件のベクトルのほとんどがフィルタ条件に一致しなかったために発生した現象です。

この問題を解決するのが、pgvector 0.8.0以降で利用可能なhnsw.iterative_scan設定です。この設定を有効にすると、pgvectorは指定された件数の結果が得られるまで、繰り返しスキャンを実行するようになります。これにより、フィルタ条件を満たす十分な数の結果を取得できます。

hnsw.iterative_scanには2つのモードがあります。

• relaxed_order: 速度を優先するモード。精度がわずかに低下する可能性がありますが、多くの場合で十分な性能を発揮します。
• strict_order: 厳密な順序（精度）を優先するモード。速度は低下しますが、最も正確な結果セットを保証します。

この設定は、フィルタ付き検索のパフォーマンスと精度を両立させるための重要なチューニングオプションです。

--------------------------------------------------------------------------------

3. IVFFlatかHNSWか？メモリと更新頻度の天秤

pgvectorでインデックスタイプを選択する際、IVFFlatとHNSWのどちらを選ぶかは、単なる技術的な詳細ではなく、システムの根幹に関わるアーキテクチャ上の決断です。それぞれの特性を理解し、ユースケースに合った選択をする必要があります。

HNSW（Hierarchical Navigable Small World） は、インクリメンタルにインデックスを構築する性質を持つため、データの書き込みが頻繁に発生する動的なユースケースに最適です。新しいデータが追加されると即座に検索可能になりますが、その代償としてグラフ構造を維持するためにメモリを大量に消費することで悪名高いです。

IVFFlat（Inverted File with Flat Compression） は、ベクトル空間を事前に定義された数のパーティション（リスト）に分割します。このアプローチにより、HNSWに比べてメモリ効率が非常に高くなります。しかし、インデックス作成時に決定されたパーティションの中心（セントロイド）は固定されるため、後から追加されたデータが既存の分布と異なる場合、検索性能が徐々に劣化していきます。

--------------------------------------------------------------------------------

4. 「インデックス作成後も運用は続く」見過ごされがちな保守コスト

インデックスを作成すれば終わり、ではありません。pgvectorを本番環境で安定して運用するためには、開発初期段階では見過ごされがちな「隠れた」運用コストを考慮に入れる必要があります。

まず、IVFFlatには「再インデックスの責務」が伴います。 IVFFlatインデックスのセントロイドは作成時に固定されるため、異なる分布を持つ新しいデータを追加し続けると、インデックスの品質は時間と共に劣化します。これを回避し、検索精度を維持するためには、本番システムでは定期的にREINDEXを実行する戦略が不可欠です。

次に、HNSWには削除操作に伴うメンテナンス課題があります。 DELETE文でデータを削除しても、HNSWグラフ内の対応するノードは即座に物理的に削除されるわけではなく、「削除済み」としてマークされるだけです。これにより、更新や削除が頻繁なテーブルではインデックスが肥大化し、検索パフォーマンスが低下します。この「死んだ」ノードをクリーンアップするため、頻繁かつ積極的なVACUUMの実行は、HNSWを運用する上で「交渉の余地がない」必須作業となります。

--------------------------------------------------------------------------------

5. pgvectorの真価はメタデータによる「事前絞り込み」にあり

pgvectorが他の専門的なベクトルデータベースと比較して持つ最大の利点の一つは、メタデータによるフィルタリングとベクトル検索を単一のクエリ内で効率的に組み合わせられる点にあります。

最も正しく、かつ効率的なアプローチは、WHERE句でメタデータフィルタを先に適用し、その結果セットに対してORDER BY ... <->でベクトル検索を実行することです。この順序により、PostgreSQLのクエリプランナは、まず標準的なB-treeインデックスを使って検索対象を劇的に絞り込み、その後のベクトル検索の計算負荷を大幅に削減できます。

これは、先に大量のベクトルを取得してからアプリケーション側でフィルタリングを行う「事後フィルタリング」という非効率なアプローチとは対照的です。事後フィルタリングは、パフォーマンスが悪いだけでなく、期待した件数の結果が得られない原因にもなります。

This is a massive advantage of pgvector over dedicated vector databases: your metadata and vectors live together, enabling the query planner to create highly efficient, composite query plans.

これは、pgvectorが専門のベクトルデータベースに対して持つ大きな利点です。メタデータとベクトルが共存することで、クエリプランナは非常に効率的な複合クエリプランを作成できます。

この強力な機能を活用することで、pgvectorは単なるベクトル検索エンジンではなく、リレーショナルデータとベクトルデータをシームレスに統合した高度な検索システムの中核となり得るのです。

--------------------------------------------------------------------------------

6. 日本語RAGの精度は「チャンク設計」で決まる

RAG（Retrieval-Augmented Generation）システムの精度は、元となるドキュメントをどのように分割（チャンキング）するかで大きく左右されます。特に日本語のテキストを扱う場合、その言語的特性に合わせた設計が不可欠です。以下に、実運用で効果が確認されている実践的なパラメータを示します。

• チャンクサイズ (Chunk Size): 800～1,200文字
• チャンクオーバーラップ (Chunk Overlap): 120～200文字 (チャンクサイズの10-15%が目安)

これらの設定が日本語において有効な理由は、日本語が英語に比べて文字数に対するトークン数が多い傾向があるためです（ESTIMATED_TOKENS_PER_CHAR_JP = 1.5程度）。少し大きめのチャンクサイズで十分な文脈を確保する必要があるのです。また、適切なオーバーラップを設けることで、文章がチャンクの境界で分断された際に意味的なつながりが失われるのを防ぎます。

分割の際には、以下の区切り文字を優先順位の高い順に設定することで、文の構造を維持しやすくなります。

• 区切り文字 (Separators) の例: [ "\n\n", "。\n", "。", "\n", "、", " " ]

この設定により、まず段落（二重改行）、次に句点といった意味的な区切りを優先することで、チャンクの文脈的まとまりが保たれやすくなります。

--------------------------------------------------------------------------------

まとめ

pgvectorは間違いなく強力なツールですが、その真価を本番環境で引き出すためには、言語の特性、インデックスの内部メカニズム、そして継続的な運用保守といった、表面的なシンプルさの裏に隠された深いニュアンスを理解することが不可欠です