MCP Toolbox 串接 Gemini 嵌入模型,把 Agent 文字寫進 ClickHouse 向量索引
ClickHouse Blog · 2026-09-07
ClickHouse 官方部落格在 2026 年 9 月 7 日發布文章,示範如何用 Google 的 MCP Toolbox 把 AI Agent 送出的原始文字自動轉成向量,寫入並查詢 ClickHouse 的向量索引。文章以 MCP Toolbox 1.9.0 搭配 ClickHouse Cloud 26.4.1 實測,說明 Agent 端只需宣告工具設定檔,不必自行呼叫嵌入 API 或手寫向量搜尋 SQL。
背景
MCP Toolbox 是 Google 開源(Apache 2.0 授權)的 Model Context Protocol 伺服器,做為 AI Agent 與資料庫之間的中介層。Agent 透過 MCP 標準協定呼叫「工具」(tool),而不是直接下 SQL 或呼叫資料庫驅動程式,Toolbox 負責把工具呼叫轉譯成對應資料庫的實際操作。目前支援的後端除了 ClickHouse,還包括 PostgreSQL、MySQL 等,ClickHouse 是這篇文章示範新加入的向量儲存後端。這類串接常見於檢索增強生成(RAG)場景:Agent 需要把使用者輸入或待索引的文件先轉成向量,再拿去資料庫裡做相似度搜尋,過去這段轉換多半得由應用程式自己寫程式碼呼叫嵌入 API,這篇文章示範的做法是把這段邏輯整個下放給 Toolbox 處理。
核心改動/實作細節
關鍵機制是工具設定裡的 embeddedBy 參數註記。當某個參數標上 embeddedBy: gemini-embedder,Toolbox 會在把請求送進 ClickHouse 之前,先呼叫 Google 的 gemini-embedding-001 模型把該段文字轉成向量,再把向量綁定到 SQL 的參數位置。目前 1.9.0 版只支援 Gemini 這一種嵌入供應商,認證可用 Google AI Studio API key,或 Vertex AI 的 Application Default Credentials。模型預設輸出 768 維向量,維度可調整,但必須與資料表欄位宣告一致。
寫入端與查詢端各對應一支工具設定,寫入時把使用者傳入的 content 複製一份標成待嵌入參數:
kind: tool
name: insert_doc
type: clickhouse-sql
statement: |
INSERT INTO vectors.documents (content, embedding) VALUES (?, ?)
parameters:
- name: content
type: string
- name: text_to_embed
type: string
valueFromParam: content
embeddedBy: gemini-embedder查詢工具則是把使用者輸入的問題句同樣標上 embeddedBy,轉成向量後代入 cosineDistance() 排序取前幾筆:
kind: tool
name: search_docs
type: clickhouse-sql
statement: |
SELECT content, cosineDistance(embedding, ?) AS distance
FROM vectors.documents
ORDER BY distance ASC
LIMIT 5
parameters:
- name: query
type: string
embeddedBy: gemini-embedderClickHouse 這端的資料表把向量存成 Array(Float32) 欄位,並在該欄位上建立向量索引:
CREATE TABLE vectors.documents (
id UUID DEFAULT generateUUIDv4(),
content String,
embedding Array(Float32),
INDEX idx_embedding embedding TYPE vector_similarity('hnsw', 'cosineDistance', 768)
)
ENGINE = MergeTree ORDER BY (id);vector_similarity 索引採用 HNSW(Hierarchical Navigable Small World)演算法做近似最近鄰搜尋,距離函式固定用 cosineDistance,索引宣告時的維度數字必須對齊嵌入模型實際輸出的向量長度,這裡是 768。
影響範圍
這個組合把「文字轉向量」這件事從 Agent 應用程式碼裡搬進資料庫中介層,開發者不需要自己維護嵌入呼叫、錯誤重試或向量格式轉換邏輯,只要在工具設定檔裡宣告 embeddedBy 對應哪個嵌入器即可。對 ClickHouse 而言,這篇文章示範它能在部分場景下取代專用向量資料庫,靠既有的 MergeTree 引擎加上 vector_similarity 索引提供近似最近鄰搜尋,不需要額外部署獨立的向量儲存系統。對已經用 MCP 協定接資料庫的團隊來說,ClickHouse 現在是 Toolbox 支援矩陣裡多一個可直接宣告使用的後端。
原始來源:ClickHouse Blog
十一年後重看《Dataflow Model》:作者自認窗口與觸發器想多了
VLDB (PVLDB Vol. 19) · 2026-09-07
《The Dataflow Model Revisited》發表於 PVLDB 第 19 卷,作者是 Tyler Akidau、Rafael Fernández-Moctezuma、Reuven Lax 與 Daniel Mills,四人正是 2015 年那篇拿下 VLDB Test of Time 獎的原始 Dataflow Model 論文作者。這篇回顧文章重新檢視十一年前提出的串流處理模型,指出哪些論點禁得起時間考驗、哪些方向其實走偏了。
背景
2015 年那篇《The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing》定義了現代串流系統慣用的一整套詞彙:用 watermark 追蹤事件時間(event time)的進度、用 windowing 把無界資料切成有限區段、以及用 trigger 決定何時輸出結果。這套模型後來直接催生了 Apache Beam,也影響了 Apache Flink、Apache Spark 的串流語意設計。該論文後來在 VLDB 會議上獲頒 Test of Time 獎,這個獎項頒給發表滿十年、且經證實對後續研究與產業產生長遠影響的論文。這篇 2026 年的續作,就是原班作者拿到獎項後,對自己十一年前主張逐條重新檢討,寫成的自我評論式論文。
核心論點
作者認為留下來的部分經得起考驗:把「無界、可能亂序的資料才是常態」當成設計前提是對的,堅持以 event time(而非 processing time)為核心、並要求強一致性,這兩個立場至今仍是正確方向。但他們也點名三個判斷失準之處:第一,論文把 windowing 和 triggering 講得太重,佔據了論文與後續實作太多篇幅與心力;第二,trigger 機制本身被過度工程化,想用一套複雜的觸發規則去解決本該更簡單處理的問題;第三,整篇論文站在「一切都是串流」的角度思考,但後來證明「串流與資料表其實是同一份物件的兩種呈現方式」才是更準確的框架。
作者提到,真正把串流複雜度降下來的,不是發明更精巧的串流專屬機制,而是拉回資料庫的老傳統:SQL、incremental view maintenance(增量視圖維護),以及帶有新鮮度保證的 materialized view。文中舉了以增量視圖維護為核心的 Materialize 引擎為例,說明串流計算最終被重新表述成「對資料表做增量更新」,而不是原論文設想的獨立串流運算模型。
影響範圍
這篇回顧等於是原作者對 Apache Beam 程式設計模型的一次公開反省,對還在用 windowing/trigger API 的團隊,等於官方承認這套 API 的複雜度可能超過實際需要。對資料庫與串流引擎的發展方向來說,這也呼應了近年 Flink SQL、Materialize 等產品把「串流即資料表」當成主軸的選擇——把串流查詢寫成標準 SQL,由引擎在背後做增量視圖維護,而不是要求開發者手動組裝 window 和 trigger。
原始來源:VLDB paper page、PDF