本文整理自 IvorySQL 2025 生態大會暨 PostgreSQL 高峯論壇的演講分享，演講嘉賓：Florents Tselai。

引言

從 SQL 到 AI，從數據庫操作到大模型推理，技術在不斷進化。本文將探討如何在保持穩定性的前提下，利用 SQL 與 AI 接口實現高效、可靠的數據處理。

關於作者

Florents Tselai 擁有數據分析與數據工程背景，早年就讀於商學院，隨後逐步轉向數據工程領域，專注於 PostgreSQL 擴展開發與 AI 數據處理。

曾為歐洲及美國多家企業提供數據諮詢服務，目前擔任 希臘政府 AI 孵化計劃的技術顧問。其研究方向涵蓋 PostgreSQL 可擴展性、ETL 工具設計與 AI 數據接口優化。

代表作品：

• PostgreSQL 擴展
• 統計類：pgxicor, vasco
• ETL 工具：pgPDE, pgJQ

創新項目：

• spat：讓 PostgreSQL 像 Redis 一樣使用共享內存的高性能存儲擴展
• pghaicker：基於 AI 的 pgsql-hackers 郵件摘要工具

背景：從複雜中迴歸極簡

極簡主義 = 經驗 + 麻煩。

複雜的運維流程與多系統環境常使開發過程面臨協作障礙與效率損耗。長期的項目實踐與問題積累，逐漸催生出一種“極簡主義”技術理念——在複雜中求簡，以最少且最可靠的工具應對最多的場景。

SQL、Bash 與 Python 成為跨環境開發的核心支撐，體現了高穩定性、高效率與強可移植性的技術哲學。

接口的演進：從 SQL 到 AI

在軟件開發與數據分析中，接口（Interface）是核心概念。

SQL：可靠的數據接口

SQL 是數據操作中最穩定、最可靠的核心工具，自 1970 年代以來，它通過標準化方式將人類需求轉化為數據庫執行計劃，實現從查詢到報表的完整流程。

SQL 的接口特性：

• 描述“想要什麼”，而非“如何實現”。
• 數據表提供直觀可視化表示。
• 標準化操作（盡力而為）。
• 從查詢到報表完整流程。
• 隱藏底層複雜性。
• EXPLAIN PLAN 提供有限洞察。

AI：自然語言與推理的新接口

AI 接口是 SQL 接口理念的延伸與升級。與 SQL 類似，AI 將人類意圖轉化為可執行操作，但能夠理解自然語言，進一步降低操作門檻。

AI 的接口特性：

• 理解自然語言描述：可生成查詢或執行計劃，實現直觀的人機交互。
• 執行與智能推理：除了生成執行計劃，還可處理複雜數據和邏輯推理。
• 延續 SQL 接口哲學：只需描述需求，系統負責實現，但方式更自然、更智能。

從 SQL 到 AI，這一演進體現了接口的核心理念：讓人類與系統交互更直觀、高效，同時隱藏底層複雜性。AI 接口不僅延伸了 SQL 的能力，也為未來的數據分析與應用開發提供了新的可能。

核心轉變：從執行計劃到推理計劃

在高級用户操作 AI 的實踐中，可以觀察到執行計劃與推理計劃的一一對應關係。用户通過一個提示詞得到結果，再將結果組合或優化，這本質上是在編排推理邏輯，而不僅是執行操作。這些結果可以作為緩衝或中間狀態，實現更高效的任務管理。

現狀批判：LLM 框架的陷阱

複雜的生態與過度抽象

• 對普通用户而言，AI 操作像魔法，簡化了複雜任務。
• 對數據工程師或開發者而言，部署和操作仍然複雜，需要理解系統底層邏輯。

這一差異反映了用户體驗的便利性與開發者實際操作複雜性之間的落差。

當前大模型生態尚未穩定，技術迭代速度過快，主要表現為：

• 行業仍缺乏統一標準與穩定範式。
• 經驗方法更新頻率高，難以長期複用。
• HOW-TO 類資料常因工具與版本更新而被替代。
• 各模型都聲稱性能領先，但實際效果依賴具體場景。
• 不同 LLM 框架試圖定義自己的標準路徑，卻往往引入更高的複雜度和學習成本。

歷史的押韻：LLM Frameworks = ORMs

LLM 框架類似 80 年代的 ORM（對象關係映射）：

• ORM 雖提供了 SQL 的抽象封裝，但底層執行原理仍需掌握。
• LLM 框架提供抽象化接口，但早期依賴可能掩蓋底層邏輯。
• 當前框架過度封裝、複雜化流程，使開發者容易迷失。

LLM 框架雖便利，但存在顯著問題：

• 過度自信與複雜化 —— 框架自認為萬能，卻增加不必要的複雜性；
• 死板抽象 —— 多層封裝讓問題難以理解；
• Java 式設計泛化 —— 流程被強制框架化，增加學習成本；
• “想要香蕉？先建宇宙” —— 為完成簡單任務，需要經歷冗長複雜步驟；
• 強制流程 —— 框架規定操作步驟，限制靈活性；
• 阻礙學習 —— 用户依賴框架而非理解底層邏輯；
• 產生挫敗感 —— 框架讓用户覺得無法掌控，體驗不佳。

整體結論：LLM 框架目前仍是輔助工具，開發者不應盲目依賴，應理解底層原理並培養核心技能。

SQL 依然是最穩定的答案

面對快速發展的 AI 技術生態，開發者常常需要尋找穩定可靠的解決方案。儘管出現了各種新興工具和框架，SQL 依然被證明是數據訪問和處理的核心接口。

SQL 自誕生以來數十年，始終保持其核心價值。儘管有人宣稱 SQL 已過時，每隔十年總有新論斷出現，但 SQL 的基礎地位從未動搖，其聲明式語法和標準化特性使其在複雜系統中長期可靠。

SQL 不僅僅是查詢語言，更可以視作系統的編排者。在處理複雜數據流程時，SQL 能將不同任務和操作整合為清晰的執行計劃，從而簡化系統協調和資源管理的複雜性。

在 AI 應用中，模型的推理流程與 SQL 的執行計劃存在對應關係。通過 SQL 的結構化操作，可以對 AI 推理過程進行有效映射與管理，使數據處理和推理邏輯保持一致性。

迴歸本質：AI 即相似度搜索

當前大模型（LLM）及各類 AI 應用，從底層機制來看，核心都可以歸結為“相似度搜索”。其基本流程是：

1. 將輸入文本切分成 tokens；
2. 通過向量化模型生成向量表達；
3. 存儲的數據向量進行相似度比對，
4. 最終根據得分返回結果。

這一過程並不神秘，模型能力的差異主要取決於數據規模與訓練質量。

在實際應用中，系統會在數據庫內存儲多種信息片段，並不斷圍繞“向量—相似度—檢索”循環工作。從業務角度看，AI 的執行流程更像是“聲明—比對—迭代”的模式：給定輸入，不斷檢索最接近語義結果，再多輪迭代優化。

核心機制

當前 AI 技術生態中最常見的術語如 tokens、vectors、documents，均圍繞相似度檢索機制展開。

• tokens：文本最小單元
• vectors：語義向量表示
• documents：文檔或數據片段

Postgres 早已具備的能力

儘管今天的向量檢索聽起來前沿，但對於數據庫從業者而言，這一思想並非全新。PostgreSQL 在十餘年前就已經通過全文檢索（Full Text Search）實現了類似能力。例如：

SELECT 'a fat cat sat on a mat'::tsvector @@ 'cat & rat'::tsquery;

全文檢索的流程同樣依賴文本分詞、構建詞典、生成向量化表示，並在查詢時根據詞項匹配進行判定。不同之處僅在於：

• 過去依賴的是本地語料構建的詞典與向量；
• 現在依託的是規模更大的語言模型語料與向量空間。

從技術原理上看，這兩者在語義表達與匹配流程上的一致性非常明顯。因此，LLM 並不是完全改變數據庫世界的“新物種”，而是將“相似度檢索”做到規模更大、語義更豐富、泛化能力更強。

AI 實戰：上下文即一切

多層封裝的體系結構

現代 AI 應用普遍構建在大模型框架之上，外層工具與平台不斷疊加新的包裝與接口，形成“套娃式”的技術結構。絕大多數產品並非從零實現，而是圍繞底層模型進行 API 封裝、功能抽象與產品化組合。

底層核心：llama.cpp

在這些封裝層的最底部，llama.cpp 等核心實現承擔模型推理的基礎執行職責。其高性能、輕量化與良好兼容性，使其成為大量應用的實際運行基礎。圍繞相關代碼庫，社區生態與開源許可問題也構成技術討論的重點。

上下文的重要性

在實際使用中，影響模型效果的關鍵因素依然是上下文處理能力。上下文長度決定了模型能夠加載的數據量，也直接影響推理結果的完整性與連續性。在早期上下文窗口有限的階段，複雜的數據裁剪與拼接流程不可避免；而隨着上下文上限不斷提升，數據組織方式與調用策略也隨之調整。

構建提示詞 = 數據連接的藝術

在大模型應用中，上下文構建已成為決定模型效果的核心環節。模型能夠輸出高質量結果的前提，是輸入數據經過精確篩選、裁剪與組織。實際業務中，這一過程本質上是數據 Join 的組合工程。

在客户服務、電商等常見場景中，約 80% 的工作是從數據庫中挑選關鍵字段，包括商品描述、用户屬性、業務要點等，並剔除無關內容。通過將這些信息壓縮為清晰的文本表示後，即可形成模型的輸入上下文。該過程強調數據組織能力，而非複雜算法。

基於字符串的模板化構建方式

上下文的構建主要依賴字符串拼接與模板化處理。SQL 的格式化函數、標準的字符串模板引擎等工具即可完成大部分處理需求。相比構建複雜腳本或 Notebook 環境，這種方式更直接、更高效，並滿足絕大多數生產實踐場景。

將複雜度交給模型處理

在設計提示詞或業務流時，不必在應用層堆疊大量邏輯判斷或格式規約。大模型具備強大的推理與補全能力，適合承擔複雜推斷工作。應用層應主要聚焦於準備精簡、準確的輸入數據，將複雜度交由模型處理，從而提升系統整體效率與可維護性。

Everything in PostgreSQL：減少鏈路

通過 PostgreSQL 的擴展生態，可以將多種形態的數據處理直接集成到數據庫內部，從而減少跨系統的數據搬運、降低額外的同步壓力，並提升整體系統穩定性。

解析 PDF：非結構化數據提取

藉助 pgPDF 擴展，PostgreSQL 能夠直接讀取本地或遠端 PDF 文件並將其解析為文本。示例如下：

github.com/Florents-Tselai/pgPDF

CREATE EXTENSION pgpdf;

SELECT '/path/to/my.pdf'::pdf;

執行 HTTP 請求：獲取外部數據

利用 http 擴展，可以在 PostgreSQL 內直接發起 API 請求，例如：

CREATE EXTENSION http;

SELECT http_post('http://myprovider');

這一能力使數據庫能夠直接完成部分外部數據的獲取流程，從而減少應用端的多次 I/O 往返，降低數據鏈路的複雜性。需要注意的是，HTTP 請求存在阻塞和失敗的可能，因此更適合在非核心業務節點或離線庫中使用。

將文本解析、外部 API 請求等操作整合到數據庫內部，可以減少：

• 數據在系統間傳輸帶來的延遲
• 應用層的額外邏輯與依賴
• 由於鏈路增長導致的失敗點

從而提升整個數據鏈路的可靠性與可維護性。

Unix 哲學在現代數據處理中的價值

Unix Philosophy

Unix 哲學強調以最小單元構建工具，通過清晰的接口協同完成複雜任務。這一思想在當下依然具有實踐意義，特別是在數據密集型場景中。

“Do One Thing Well” 與文本接口

Unix 哲學的核心原則包括：

• 工具專注於單一功能
• 文本作為通用接口

在 LLM 與數據庫協作的場景中，文本仍然是最穩定、最易組合的接口形式。這也使得傳統工具鏈在新的技術背景下依然適用。

管道化的工具組合

遵循 Unix 的方式，小工具之間通過管道組合，能夠以極低的複雜度完成高效的數據處理流程。

常見工具組合方式

在實際工程中，以下工具鏈可以覆蓋大量數據拉取、處理與寫入場景：

• curl：用於獲取本地或遠程 API 數據
• jq：處理 JSON 結構
• xargs（含並行執行）：用於批量或並行處理
• psql：直接與 PostgreSQL 交互

這些工具組合後，可以在極少代碼量的前提下實現高效的流水線式處理。

示例：真實項目示例

以下示例來自實際項目，通過 Makefile 驅動整套數據處理流程：

1. 生成時間區間；
2. 拉取與分組數據；
3. 構建 JSON 數據；
4. 向量化處理（如使用某 embedding 模型）；
5. 將結果寫回 PostgreSQL。

整個流程以 JSON 作為中間格式，以 PostgreSQL 作為狀態與結果的統一存儲，避免了額外的數據搬移與邏輯分散。

示例：命令行操作 PostgreSQL 實現數據流水線

在實際項目中，通過命令行工具直接操作 PostgreSQL，實現數據處理自動化：

1. 使用 % 通配符靈活查詢數據。
2. 本地 LLM 對數據進行處理，如生成每日聚合結果。
3. 為每一天生成獨立 PostgreSQL 數據庫，將結果寫入數據庫。
4. 利用命令行管道直接寫回數據庫，實現數據流閉環，無需額外搬移。

示例：LLM 結合的處理邏輯

本地 LLM 對文本、集合或結構化數據進行處理和聚合，生成有用信息並向量化，結果直接寫入 PostgreSQL。利用數據庫索引和聚合能力完成優化，實現從數據處理到存儲的自動化閉環。

結語

SQL 與 AI 的結合展示了簡化複雜、提升效率的價值。理解底層原理併合理運用工具，才能在快速變化的技術生態中保持掌控與高效。