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

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

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

pgvector的索引選型

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

IVFFlat（倒置文件索引）：構建快、記憶體佔用低，適合初期數據量在10萬條以內的場景。查詢時通過探測一定數量的聚類中心近似搜尋，準確率略低於精確搜尋，但速度顯著更快。

HNSW（層次化導航小世界圖）：在大數據量下召回率更高，但索引構建時間長、記憶體佔用顯著增加。建議在100萬條向量以上才評估切換，初期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並以+8時區（AT TIME ZONE 'Asia/Hong_Kong'）存儲。若混用UTC與本地時間，基於時間的向量過濾查詢（如「最近7天的記憶」）將在邊界時段出現難以察覺的錯誤。HKSoka記憶系統的架構設計，可參閱AI長期記憶系統：HKSoka的架構設計與工程細節。

小結

Neon + pgvector適合中小規模RAG系統的快速上線。四個關鍵生產決策：連接池必須正確配置；冷啟動策略根據使用模式選定；索引類型初期選IVFFlat；所有時間戳統一+8時區。這四點在設計之初確定的成本，遠低於上線後修復的代價。