← 概念解説に戻る

Concept Fable

pgvector

先に結論:pgvectorはPostgreSQLの拡張機能で、リレーショナルデータベースに直接ベクトル保存と類似度検索の能力を追加します。複数のインデックスタイプ(HNSW、IVFFlat)、複数の距離尺度(L2、内積、コサイン距離)、および正確/近似検索をサポートします。企業シナリオにおいて、pgvectorの最大の価値は、ベクトル検索と既存の業務データを同じトランザクション、権限、クエリ体系に置くことです——専用のベクトルDBと業務データベースの間で同期を維持することなく、1つのSQLでJOIN、WHEREフィルタ、ベクトル類似度ソートを同時に行えます。データ量が百万件以内で、チームがすでにPostgreSQLを深く使用しており、強い一貫性と低遅延のベクトルクエリが必要なシナリオに適しています。ベクトル量が千万件を超え、分散または純粋なベクトルワークロードが必要な場合は、専用のベクトルデータベースを検討すべきです。

pgvector · PostgreSQL vector extension

まず物語を読む。ここでは急いで定義を示さず、まず問題そのものを立ち上がらせる。

寓話

老いた経理係は古い総勘定元帳に新しい算木を一本つないだ

百年の票号には、何代も受け継がれてきた総勘定がある。顧客、取引、契約、担保、権限がすべて同じ帳櫃にあり、経理係たちは各照会経路に精通している。新しい店主はカウンターにもう一つ能力を加えたいと考えた。客が来たら、過去に最も似た数名の客を見つけ、彼らにどの手形が適しているかを見るのだ。

ある者は似た櫃をもう一つ買うことを提案した。その櫃は計算が速いが、総帳の資料を定期的に書き写さなければならない。一度目は、新規客が相似櫃に入るまで二時辰待った。二度目は、書き写す際に銀銭の小数を落とした。三度目は、櫃番の規則と総帳の規則が一致せず、店員が相似櫃の中で本来見てはならない記録を見られた。

老いた経理係は言った。別に一櫃を立てるのは新しく見えるが、実際には帳簿を写す川が一本増える。川のどの橋も漏れ、遅れ、権限を忘れる。彼は古い総帳に相似算木を一組加えることを勧めた。各客、各契約のそばに特徴珠を一串多く置き、帳簿を調べるときは依然として総帳櫃の中で完結するが、近さの度合いで並べる取り方が一つ増えるだけだ。

最初の試用は順調ではなかった。算木が少なすぎると、似た人を正確に見つけられない。算木が多すぎると、古い帳簿棚の引き出しが重くなり、番頭の帳簿めくりが遅くなる。老経理係は新しい算木を撤去せず、よく調べる帳目には木の棚を設け、あまり調べない帳目はゆっくり調べ、権限札は元の棚に掛けたままにした。

新しい算籌が接続された後、カウンターは同じ帳簿規則の下で問い合わせられる。この客に最も近い五人は誰か、彼らは何を買ったか、同じリスク分類に属するか、どの記録を現在の店員が閲覧する権限を持つか。帳簿を移す必要もなく、権限を別途書き直す必要もない。

もちろん、旧総勘定元帳は万能ではありません。珠の数が多すぎれば棚を占め、並べ替えが頻繁すぎれば経理係の作業が遅れ、索引の木棚も維持管理が必要です。もし全城の膨大な資料をすべて押し込めば、総勘定元帳が耐えられないかもしれません。

店主は最後に理解した。新しい能力は古い帳簿の骨組みの上に育つものであり、その価値は櫃を一つ節約することだけでなく、既存の資料、権限、照会の習慣を保つことにある。慣れ親しんだ総帳に類似検索を一つ追加できることが、この改修の本当に気楽な点なのである。

後に票号が常連客を接待するとき、店員は依然として古い帳規で身元、限度額、権限を確認でき、同じ櫃で似た人が誰かをもう一句尋ねるだけでした。新しい能力は古い体系を引き裂かず、むしろ古い体系から信頼を得ました。主人は、この改造が既に総帳が深く、別の規則を開きたくない場所に適していると知っていました。

明らかにする

この物語が語るのは:pgvector

pgvectorはPostgreSQLの拡張機能で、リレーショナルデータベースに直接ベクトル保存と類似度検索の能力を追加します。複数のインデックスタイプ(HNSW、IVFFlat)、複数の距離尺度(L2、内積、コサイン距離)、および正確/近似検索をサポートします。企業シナリオにおいて、pgvectorの最大の価値は、ベクトル検索と既存の業務データを同じトランザクション、権限、クエリ体系に置くことです——専用のベクトルDBと業務データベースの間で同期を維持することなく、1つのSQLでJOIN、WHEREフィルタ、ベクトル類似度ソートを同時に行えます。データ量が百万件以内で、チームがすでにPostgreSQLを深く使用しており、強い一貫性と低遅延のベクトルクエリが必要なシナリオに適しています。ベクトル量が千万件を超え、分散または純粋なベクトルワークロードが必要な場合は、専用のベクトルデータベースを検討すべきです。

重要なのは、それが単なる用語ではなく、実際のAI/Agentシステムで繰り返し現れる構造的な問題だという点だ。これを理解して初めて、いつモデルを足すべきか、いつプロセスを変えるべきか、いつガバナンスを補うべきかを判断できる。

メタファーのマッピング

  • 百年の総勘定元帳:企業が既に持つ PostgreSQL データベース。取引、権限、レポートのロジックを含む
  • 新しい検索櫃:専用ベクトルデータベース。機能は強力だが業務データベースから独立している
  • 定時同期ブリッジ:ETL / CDC 同期により、遅延、一貫性、権限の問題が生じる
  • 小数位の欠落:同期中のデータエラーであり、金融など強一貫性が求められる場面では受け入れられない
  • 古い総勘定に新しい算木を入れる:pgvector は PostgreSQL 拡張として、ベクトル検索をネイティブに組み込む
  • ORDER BY embedding <-> query_vector:SQL ネイティブのベクトル類似度ソート
  • 行レベルセキュリティポリシー:PostgreSQL に既存の RLS を利用してベクトルデータの権限制御を行う
  • 代償は拡張の上限:pgvector は PG の単一マシン拡張モデルに制約され、数百万レベルのベクトルに適する

Andy(任旭)判断

この概念の実戦的価値は、「賢く見えるAI機能」を納品可能、検収可能、ガバナンス可能な作業単位に分解する手助けをすることです。

PostgreSQLvector searchSQLembeddingsHNSWIVFFlat
京ICP备2026014272号