Neon Postgres與pgvector：生產RAG資料庫設計要點

連接池、冷啟動、索引類型、混合搜尋——四個在設計時確定代價最低的決策

pgvector為Postgres引入原生向量存儲與相似度搜尋能力，Neon則提供Serverless託管的Postgres服務。兩者結合是目前中小規模RAG系統最具成本效益的選擇之一。本文聚焦生產環境中容易忽略的配置細節。

pgvector的索引選型

pgvector支援兩種索引類型，選擇錯誤會顯著影響查詢性能：

IVFFlat（倒置文件索引）：相比HNSW，通常構建較快、記憶體佔用較低。透過探測指定數量的向量聚類進行近似最近鄰搜尋。召回率及查詢延遲取決於索引配置與實際工作負載，應透過效能測試評估適用性，避免使用固定數據量作為選型門檻。

HNSW（層次化導航小世界圖）：通常能提供比IVFFlat更佳的查詢速度與召回率平衡，但一般需要更多記憶體及較長的索引構建時間。應根據實際查詢、召回率要求、延遲及資源成本比較兩種索引，避免使用固定向量數量作為切換門檻。

Serverless環境的連接池管理

Neon的Serverless特性帶來一個生產關鍵問題：Lambda函數或Vercel Edge Function的每個實例都可能嘗試建立獨立的Postgres連接。在高流量時，數據庫連接數迅速耗盡（Postgres默認100-200個連接上限）。

解決方案：使用Neon提供的連接池端點（pool mode），或自行配置PgBouncer。Neon Serverless Driver（@neondatabase/serverless）使用WebSocket協議替代傳統TCP，可在不支援長連接的環境（如Cloudflare Workers）中正常運作，同時避開連接池問題。

冷啟動延遲的處理策略

Neon在不活躍期間暫停計算資源（Autosuspend），首次查詢的冷啟動延遲可達1至5秒，對即時向量搜尋路徑而言不可接受。

應對策略：對延遲敏感的向量搜尋端點設置最短活躍期（Neon Scale計劃支援），或維持一個常開的向量搜尋連接，僅允許關係型查詢端點自動暫停。監控冷啟動頻率並寫入日誌，以判斷是否需要升級計劃。

混合搜尋的設計

純向量搜尋有時遺漏精確關鍵詞匹配的結果，尤其是產品代號、人名、法規條文編號等專有名詞。生產系統常採用混合搜尋：向量相似度結果 + Postgres全文搜尋結果，以加權方式合併排名。

Postgres全文搜尋原生對中文支援有限，pg_trgm可處理部分場景。正式中文全文搜尋建議使用zhparser擴展或在應用層預處理分詞。混合搜尋的權重比例應以業務數據集的召回率作為調參依據，而非憑感覺設定。

時區標準化

向量記錄的時間戳字段應統一使用TIMESTAMPTZ，其內部以UTC表示時間。顯示或解讀本地日期時，可使用Asia/Hong_Kong等適當時區。若混用帶時區與不帶時區的時間戳，基於時間的向量過濾查詢（如「最近7天的記憶」）可能出現邊界錯誤。HKSoka記憶系統的架構設計，可參閱AI長期記憶系統：HKSoka的架構設計與工程細節。

小結

Neon + pgvector適合中小規模RAG系統的快速上線。四個關鍵生產決策：連接池必須正確配置；冷啟動策略根據使用模式選定；索引類型透過實際工作負載測試選擇；時間戳統一使用TIMESTAMPTZ並保持時區處理一致。這四點在設計之初確定的成本，遠低於上線後修復的代價。