對於許多剛接觸 AI 應用的工程師來說，最直覺的反應可能是「我需要一個向量資料庫（Vector Database）」來實現 RAG（檢索增強生成）。但實際上，在企業級的生產環境中，AI Agent 需要的不僅是語義相似度，更多的是對結構化數據的精準控制與可靠的狀態管理。
這篇文章將分享如何利用 PostgreSQL 的多模態能力，將其從單純的關聯式資料庫，轉化為 AI Agent 的核心基礎設施。
從基礎數據到 AI 上下文
LLM（大語言模型）的強大程度取決於你提供給它的上下文（Context）。上下文通常分為三類：對話歷史（Previous Messages）、環境資訊（Environment，如使用者位置、時間）以及當前操作的相關數據（Current Activity，如編輯中的程式碼檔案）。
要將這些數據餵給 LLM，目前主流有兩種模式：
第一種是 RAG（Retrieval-Augmented Generation）。開發者預先定義好檢索邏輯，找出相關數據並放入 Prompt 中。這是一種由開發者掌控的「推播」模式。
第二種是 Agentic 模式。開發者不直接提供數據，而是提供一組工具（Tools/Functions），讓 LLM 根據需求自行決定何時調用哪個工具來獲取數據。這是一種由模型掌控的「拉取」模式。
實務建議：在嘗試 Agentic 模式前，你必須先能用 RAG 模式手動跑通流程。如果你自己都不知道該檢索什麼數據才能得到正確答案，你無法設計出有效的工具給 Agent 使用。
利用關聯式查詢強化 RAG
很多人誤以為 RAG 等同於向量搜尋，但事實上，最精準的上下文往往來自傳統的 SQL 查詢。
以 AI 輔助的 Issue 優先級判定為例，單靠向量搜尋「相似的 Ticket」是不夠的。LLM 需要知道：該專案目前的 P0 Ticket 數量、受影響的客戶數、該 Ticket 的開單時間以及依賴鏈條。
這些數據透過 SQL 的 Join、Count 和 Window Function 就能高效獲取。PostgreSQL 的強大之處在於它能處理多模態數據： JSONB：用於儲存半結構化的 Payload，且支持高效索引。 全文檢索（Full Text Search）：用於精確的關鍵字匹配。 地理空間數據（PostGIS）：用於處理位置相關的上下文。
此外，建議直接利用 Postgres 的 JSON 構建能力，在資料庫端就將結果格式化為 JSON，減少應用層的記憶體開銷與處理時間。
深入向量搜尋與 HNSW 索引
當需要處理「語義相似度」（例如：找出與目前問題性質相似的歷史案例）時，向量嵌入（Embeddings）就派上用場。
在 PostgreSQL 中，透過 pgvector 擴展可以實現向量儲存與查詢。但在數據量達到數千條以上時，全表掃描（Exact Nearest Neighbor）會變得極慢。這時需要使用近似最近鄰（ANN）算法。
推薦使用 HNSW（Hierarchical Navigable Small World）索引。它透過建立多層圖結構，讓搜尋過程像在金字塔中由粗到細地過濾，大幅提升查詢速度。
針對向量搜尋的實務優化技巧：
量化（Quantization）：將 32 位元的浮點數壓縮為 8 位元或 16 位元。這能減少 75% 的記憶體與磁碟空間，並將查詢速度提升約 4 倍，而召回率（Recall）的損失通常在業務可接受範圍內。
理解過濾機制：HNSW 索引的過濾與 B-tree 不同。它會先找 N 個最近鄰，再進行條件過濾。如果過濾掉太多，它必須反覆迭代搜尋，因此增加過濾條件反而可能讓向量查詢變慢。
驗證召回率：不要過度信任算法。建議定期在沒有索引的副本上跑一次全量比對，確認 HNSW 返回的結果與真實最接近的結果一致性（例如 90% 以上）。
構建 Agent 的工具與記憶體
當我們將 Postgres 視為 Agent 的後端時，應關注兩件事：工具化與狀態管理。
工具化（Tooling）： 將 SQL 查詢封裝成高階函數（如 get_similar_tickets），而非直接給 Agent 執行 SQL 的權限。這樣可以增加安全性，且方便在不更動模型 Prompt 的情況下優化底層實作。目前業界趨勢是採用 MCP（Model Context Protocol），讓 Agent 能透過標準協議調用外部伺服器的工具。
記憶體與併發控制（Memory & Concurrency）： Agent 在執行任務時需要記錄筆記或狀態。由於 Postgres 支持 ACID 事務與 MVCC（多版本併發控制），你可以利用 SELECT ... FOR UPDATE 或簡單的鎖定機制，將 Postgres 當作一個可靠的任務隊列（Work Queue），防止多個 Agent 同時修改同一個實體導致數據覆蓋。
總結：為什麼選擇 PostgreSQL？
對於生產環境的 AI 應用，PostgreSQL 提供了一個極低風險的起點： 可靠性：經過數十年驗證，比許多新興的向量資料庫更穩定。 多模態：在同一個系統中結合關聯查詢、JSON 處理與向量搜尋，避免維護複雜的數據同步管線（Data Pipeline）。 安全性：支持行級安全控制（Row-Level Security），能精確限制 Agent 可讀寫的數據範圍。
來源：infoq.com - Postgres for Production Agents: Your Relational Foundation for Enterprise AI
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。