[レポート]PostgreSQL上の生成AIアプリでベクトル検索するためのベストプラクティス #DAT423 #AWSreInvent

AWSのPostgreSQLの Principal Product Manager - Technicalを務めるJonathan Katzさんによるセッション"DAT423 | Best practices for querying vector data for gen AI apps in PostgreSQL"をレポートします。

本セッションは、PostgreSQLをベクトルデータベース化する pgvector エクステンションを題材に、検索品質の評価では、再現率(recall)が何よりも大事といったベクトルデータベースのベストプラクティスが、具体的な実験結果とともに展開されました。

以下のスクリーンショットはYouTube動画からのものです。

セッション情報

• スピーカー
  • Jonathan Katz(Principal Product Manager - Technical, AWS)
• タイトル
  • DAT423 | Best practices for querying vector data for gen AI apps in PostgreSQL
• 概要
  • PostgreSQL makes it easier to store and query vector data for artificial intelligence and machine learning (AI/ML) use cases with the pgvector extension. Learning best practices for vector search will help you deliver a high-performance experience to your customers. In this session, learn how to store data from Amazon Bedrock in an Amazon Aurora PostgreSQL-Compatible Edition database and learn SQL queries and tuning parameters to optimize the performance of your application when working with AI/ML data, vector data types, exact and approximate nearest neighbor search algorithms, and vector-optimized indexing.
• 動画 : https://www.youtube.com/watch?v=L8fQqVwTT3Y
• スライド : TODO

セッションのハイライト

生成AIアプリでは、RAGを始めとしてモデルを利用したベクトル化(埋め込み)とベクトルを対象とした検索が求められます。

ベクトル検索では、ベクトルを元にベクトルの集合に対して検索します。
大量のベクトル同士を比較すると、計算量が膨れ上がるため、Approximate Nearest Neighbor(ANN) という近似アルゴリズムが用いられます。

このアルゴリズムはあくまでも近似のため、取りこぼしがあります。

正解10個のうち8個を当てられたら、再現率(recall)は80%です。

ベクトル検索を評価するときに

• 再現率
• インデックスの構築時間
• クエリーパフォーマンス(スループット、レイテンシー)

などが気になります。

Katzが言うには、 再現率が何よりも大事 、ということです(動画 9:09)。
いくらスループットが良くても、再現率が0%(空振っている)だと意味がありません。

pgvector のベクトル検索用インデックス

pgvector が実装している ANN はクラスターベースの IVFFlatと グラフベースの HNSW の2種類が、トレードオフの関係にあります。現在は、後から実装された HNSW のほうがうまくいくことが多く、主流になりつつあります

selectivity とインデックスの選択

ベクトル検索ならHNSW等ベクトル検索用インデックスを使うべしと思考停止してしまいがちですが、一部のデータにフィルタリングしてベクトル検索する場合、つまり、selectivity が高い場合、B-Treeなど、古典的なインデックスでフィルタリングして、ナイーブにベクトル同士を比較したほうが早いです。

pgvector HNSWは m が大事

以降では、pgvectorのHNSWインデックスを題材に様々な実験結果やトレードオフ関係が解説されます。

HNSWインデックスでは重要なパラメータが2つあります

• m
  • the max number of connections per layer
  • デフォルトは16
• ef_construction
  • the size of the dynamic candidate list for constructing the graph
  • デフォルトは64

例えば、動画28:55 では、Katzが最もお気に入りのスライドが紹介されています。

5つの埋込モデルで検索時間を評価すると、データ数がそれぞれ異なるにも関わらず、評価候補のベクトルの数が同程度に抑えられています。

m=16としているおかげです。

まとめ

セッションタイトルからはRAG のベストプラクティスのような内容を期待しますが、PostgreSQL を ベクトルデータベース 化する pgvector エクステンションの HNSW インデックス を題材にした、データベース、特に、インデックス周りを深掘った、密度の濃いセッションとなっています。

データベースに興味があるなら、視聴をおすすめします。

参考

• https://github.com/pgvector/pgvector/
• https://www.youtube.com/watch?v=L8fQqVwTT3Y