主導覽

Postgres 能否處理你的 RAG 管道？

我們測試了 pgai 以資料庫為先的方法，了解它可在哪些方面簡化 RAG 操作，以及複雜工作負載為何仍需更大彈性。

內容摘要

  • LLM 每次只能「看到」有限的文字量（即上下文視窗）。這種方式適合小型任務，但當知識庫涵蓋數千頁內容時便難以應付。即使上下文視窗容量充足，效能仍可能因「大海撈針」問題而下降。

  • RAG（「檢索增強生成」）已成為非常普遍的模式：先建立並維護知識庫（文件、Wiki、政策、文字記錄等），再利用嵌入向量對用戶查詢進行語義搜尋，擷取最相關的內容片段，然後連同問題一起輸入 LLM。這可收窄模型的上下文範圍；如運用得當，還能提升答案質素並減少幻覺。

  • pgai 是開源 Postgres 擴充功能（另有配套工具），可協助你在可信賴的開源資料庫 PostgreSQL 上建立「AI 檢索」工作流程。

  • 其核心理念是將標準 RAG 流程的更多環節推進資料庫層（擷取 → 分塊 → 嵌入 → 保持嵌入向量同步），而非只把資料庫視為嵌入向量的「儲存空間」。

  • 我們的初步看法是，這項技術頗具潛力，但只要 RAG 流程稍為複雜，尤其涉及分塊方法，便不太適用。儘管如此，我們仍會密切留意這個項目。

RAG 模式

建立 RAG 的方法很多。如想深入了解不同的 RAG 方法，請參閱自訂 RAG 解決方案實例。一旦重視輸出質素，其設計空間會比想像中更複雜，而常見的「預設」方法大致如下：

  1. 準備一批文件。

  2. 將文件分成多個區塊。分塊方法有很多，例如按段落或語義分組。

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

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

  5. 收到查詢時，搜尋最接近的區塊，`然後將它們輸入 LLM（同樣，這一步也有很多做法）。

在許多技術架構中，步驟 (1) 至 (3) 都是在資料庫以外的應用程式碼或資料管道中進行，而資料庫主要用於：

  • 儲存嵌入向量

  • 搜尋嵌入向量

pgai 的用途

pgai 是一項 Postgres 擴充功能（開源並由 Timescale 開發），旨在模糊上述界線。

pgai 不再把嵌入向量視為需由應用程式手動管理的項目，而是將其變成資料庫功能：

  • 你指定要嵌入向量化的資料表或文件。

  • 你指定嵌入模型和分塊策略。

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

這項技術的願景相當吸引：

  • 減少需要維護的特製銜接程式碼。

  • 底層來源文件變更時，應更容易令嵌入向量保持「最新」。

  • 重試、速率限制和失敗作業等均由 Postgres／pgai 管理。

讀者注意：pgai 已內置 pgvector（另一項非常流行的 Postgres RAG 擴充功能）。pgvector 為 Postgres 加入向量儲存和相似度搜尋功能；pgai 則以此為基礎，自動執行分塊、嵌入和持續更新嵌入向量等 RAG 流程步驟。

對 pgai 的初步看法

我們欣賞之處

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 解決的只是問題中最容易的部分。

此外，如果知識庫不常更新，自動同步嵌入向量的價值也會較低。

文字轉 SQL 層

pgai 一項特別合適的用途，是在資料庫上部署文字轉 SQL 介面。使用 pgai 提供的 semantic_catalog 模組即可輕鬆實現。只需按以下方式設定：

Bash

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

然後透過 pgai semantic-catalog create，讓語義目錄擷取資料字典。這會根據資料儲存區生成上下文，大致如下：

Plain Text

---schema: postgres_airname: aircrafttype: tabledescription: Lists aircraft models with performance characteristics and unique codes.columns:- name: model  description: Commercial name of the aircraft model.- name: range  description: Maximum flight range in kilometers.- name: class  description: Airframe class category or configuration indicator.- name: velocity  description: Cruising speed of the aircraft.- name: code  description: Three-character aircraft code serving as the primary key....

pgai 現在可透過多種方式使用此上下文：

透過語義搜尋：

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

Bash

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

取得原始上下文：

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

Bash

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

生成 SQL：

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

Bash

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

目前如何使用 pgai

如果你正在建立較簡單的 RAG 系統，並有以下需要，pgai 值得一試：

  • 以 Postgres 作為記錄系統，

  • 盡量減少銜接程式碼，

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

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

  • 試用新的 RAG 工具和 Postgres 擴充功能。

需要審慎之處

如果你的 RAG 管道有以下任何需要，現階段可能值得暫緩採用 pgai：

  • 大量自訂擷取或分塊邏輯

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

  • 多模態嵌入向量

最後，pgvector 顯然已獲廣泛採用，但 pgai 能否引起同等程度的興趣並獲得相應支援，仍未可知，儘管它面世至今只有約 18 個月。

GitHub 星標歷史圖表，顯示 Timescale 的 pgai 採用情況隨時間增長。

總結

pgai 為 RAG 提供了一種有趣的方法，讓資料庫承擔更多日常營運工作，從而簡化應用程式碼。

目前，它：

  • 適用於簡單的 RAG 配置，而且使用體驗確實良好

  • 彈性不足以應付較特製的管道，尤其是多模態管道

它展現出發展潛力，絕對值得持續留意其進展。

作者

Andrew Liubinas