Postgres 能處理你的 RAG 管線嗎？

• LLM 一次只能「看到」有限的文字量，也就是上下文視窗。這適用於小型任務，但當知識庫涵蓋數千頁內容時，就難以應付。即使上下文視窗足夠，效能仍可能因「大海撈針」問題而下降。

• RAG（「檢索增強生成」）已成為非常常見的模式：維護一套知識庫（文件、Wiki、政策、逐字稿等），利用嵌入向量對使用者查詢執行語意搜尋，找出最相關的片段，再將這些文字區塊連同問題一起提供給 LLM。這會縮小模型的上下文範圍；若方法得當，便能提升答案品質並減少幻覺。

• pgai 是開放原始碼的 Postgres 擴充套件（另有配套工具），可協助你在廣受信賴的開源資料庫 PostgreSQL 上建構「AI 檢索」工作流程。

• 核心概念是將標準 RAG 管線的更多環節下放至資料庫層（擷取 → 分塊 → 嵌入 → 維持嵌入向量同步），而非將資料庫只當成嵌入向量的「儲存空間」。

• 初步看來很有潛力，但只要 RAG 管線稍微複雜一些，尤其採用較複雜的分塊方法，就不太適合。不過，我們仍會密切關注這個專案。

建構 RAG 的方法很多。如需深入瞭解不同做法，請閱讀《客製化 RAG 解決方案實例》。一旦開始重視品質，設計空間會比想像中更深；常見的「預設」做法通常如下：

1. 準備一批文件。

2. 將文件切成區塊。做法有很多種，例如依段落或語意群組分塊。

3. 將每個區塊轉換成嵌入向量。

4. 將嵌入向量儲存在向量資料庫（如 Pinecone、Milvus）中，或透過 pgvector 儲存在 Postgres 中。

5. 收到查詢時，搜尋最接近的區塊，`並將其傳入 LLM（同樣地……這也有許多做法）。

在許多技術架構中，步驟 (1)–(3) 會透過應用程式碼或資料管線在資料庫外執行，而資料庫主要用於：

• 儲存嵌入向量

• 搜尋嵌入向量

pgai 是一款 Postgres 擴充套件（開放原始碼，由 Timescale 開發），試圖模糊這條界線。

pgai 不讓應用程式自行管理嵌入向量，而是將其變成資料庫功能：

• 你可以指定要進行嵌入的資料表或文件。

• 你可以指定嵌入模型與分塊策略。

• 其餘工作交由 pgai 管理，包括在來源資料變更時持續更新嵌入向量。

這項願景相當吸引人：

• 減少需要維護的客製化黏合程式碼。

• 底層來源文件變更時，應能更輕鬆地讓嵌入向量保持「最新」。

• Postgres/pgai 會管理重試、速率限制與失敗的工作等事項。

讀者注意：pgai 已內含 pgvector（另一款非常熱門的 RAG Postgres 擴充套件）。pgvector 為 Postgres 加入向量儲存和相似度搜尋功能；pgai 則以此為基礎，將分塊、嵌入及持續更新嵌入向量等 RAG 管線步驟自動化。

1) 啟動執行相當容易。

一切順利時，流程相當簡單：

• 提取 Timescale Docker 映像檔（資料庫與工作程序）。

• 提供嵌入服務供應商的 API 金鑰。

• 執行少量 SQL 來宣告向量化器，基本上就是指定要嵌入什麼內容、如何分塊，以及使用哪個模型。

之後，pgai 會安排向量化器工作程序以獨立程序執行，並非同步產生嵌入向量，例如每 5 分鐘執行一次，或依你想要的頻率執行。

2) 整條管線都能在資料庫「附近」執行，相當方便。

pgai 可以從資料表擷取內容，也能從 S3 等位置載入文件，再進行剖析、分塊與嵌入。它也能處理 PDF、Markdown 等不同的文字文件格式。

1) 會失去大量控制權，而 RAG 有時正需要這種控制。

若以答案品質衡量，高效能 RAG 系統通常需要客製化管線，例如：

• 客製化分塊規則（依標題、頁面、說話者輪次等）

• 能感知中繼資料的分塊（保留章節標題、時間戳記、作者、文件類型）

• 針對各種文件類型採用不同的嵌入策略

pgai 在上述方面的彈性較低。

目前主要有兩種分塊策略：字元文字分割器與遞迴字元文字分割器，另可選擇不分塊。這對某些使用情境或許已經足夠，但許多正式環境中的 RAG 系統需要更高程度的客製化。

如果 Timescale 能納入 Chonkie 等程式庫中更精密的分塊策略，並支援 Anthropic 的情境式檢索等進階設計，將會非常出色。

2) 以文字為主，而非多模態。

許多有趣的 RAG 問題已不再侷限於純文字：

• 含有圖表的 PDF

• 螢幕擷取畫面／影像

• 錄音

• 影片片段

即使可以從這些來源「擷取文字」，也不等同於真正的多模態嵌入管線。

如果 pgai 最終能提供端對端的多模態模型支援，包括載入、分塊及嵌入儲存在 S3 中的大型影像、音訊與影片，並可靠地保持同步，將會很有吸引力；但目前它仍是文字嵌入工作流程。

3) 如果只需要嵌入向量，你可能不需要 pgai。

如果擷取管線已經客製化，或本來就需要客製化，那麼「嵌入文字區塊」並不是 RAG 最困難的部分。在這種情況下，pgai 解決的是問題中最容易的部分。

此外，如果知識庫不常更新，自動同步嵌入向量的價值也沒那麼高。

pgai 有一種特別實用的用法，就是在資料庫上部署文字轉 SQL 介面。使用 pgai 提供的 semantic_catalog 模組，就能相當輕鬆地做到。只要依照以下方式設定：

1OPENAI_API_KEY="your-OpenAPI-key-goes-here"2TARGET_DB="postgres://user:password@host:port/database"3CATALOG_DB="postgres://user:password@host:port/database"

然後執行 pgai semantic-catalog create，讓語意目錄擷取資料字典。這會從資料存放區產生大致如下的上下文：

1---2schema: postgres_air3name: aircraft4type: table5description: Lists aircraft models with performance characteristics and unique codes.6columns:7- name: model8  description: Commercial name of the aircraft model.9- name: range10  description: Maximum flight range in kilometers.11- name: class12  description: Airframe class category or configuration indicator.13- name: velocity14  description: Cruising speed of the aircraft.15- name: code16  description: Three-character aircraft code serving as the primary key.17...

現在，pgai 能以多種方式使用這些上下文：

透過語意搜尋：

此查詢會傳回可能與自然語言查詢相關的資料表、函式及其他物件：

1pgai semantic-catalog search -p "Your natural language question goes here!"

取得原始上下文：

這會呈現與自然語言查詢相關的原始 YAML 上下文：

1pgai semantic-catalog search -p "Your natural language question goes here!" --render

產生 SQL：

或者，你也可以直接產生回答查詢所需的原始 SQL。上一個步驟的上下文會傳送至 LLM，由其產生回應：

1pgai semantic-catalog generate-sql -p "Your natural language question goes here!"

如果你正在建構相對簡單的 RAG 系統，並有以下需求，pgai 值得一試：

• 以 Postgres 作為記錄系統，

• 盡量減少黏合程式碼，

• 嵌入向量自動保持同步，

• 快速將文字轉 SQL 功能套用至資料庫，

• 試用新的 RAG 工具與 Postgres 擴充套件。

如果你的 RAG 管線有以下任何需求，或許應該先觀望 pgai：

• 大量客製化的擷取或分塊邏輯

• 大量具有不同剖析需求的文件類型

• 多模態嵌入

最後，pgvector 顯然已獲得廣泛採用；但 pgai 是否會獲得同等程度的關注與支援，目前仍不明朗，儘管它問世至今僅約 18 個月。

pgai 是一種有趣的 RAG 實作方式，讓資料庫承擔更多例行維運工作，從而簡化應用程式碼。

現階段，它：

• 可實際用於簡單的 RAG 設定，而且使用體驗確實很好

• 對較客製化的管線而言彈性不足，尤其是多模態管線

它展現出發展潛力，絕對值得持續關注後續進展。