基準測試的透明度之戰：ClickHouse 反駁 Databricks Reyden 報告
ClickHouse Blog · 2026 年 6 月
今年稍早，Databricks 發布了一份名為 Reyden 的基準測試報告，宣稱 ClickHouse 在 1,200 至 1,500 QPS 時發生崩潰。這份報告未附上任何硬體規格、設定檔、快取狀態或成本資訊，卻在業界廣泛流傳。ClickHouse 工程團隊隨後自行重現測試，提出了系統性的反駁。
Databricks 揭露了什麼，又隱瞞了什麼
Reyden 報告確實指名了所用資料集：TPC-H SF1 與紐約市計程車資料（約 22,000 列）。然而這兩份資料集都小到可以放進一支 iPhone 的記憶體，本質上並不適合評估大規模生產環境的效能。報告裡找不到節點數量、CPU 核心數、記憶體大小、磁碟類型，更沒有任何可供外界重現的設定參數。ClickHouse 向 Databricks 申請訪問 Reyden 系統以進行直接比較，截至文章發布時申請仍未獲批准。
從 Databricks 宣稱的崩潰 QPS 範圍，ClickHouse 工程師反推出 Databricks 使用了大約 3 個節點、約 90 個 vCPU。缺乏公開硬體規格，使得任何效能數字都無法被獨立驗證或複製。業界對此類報告的接受程度，揭示了一個更深層的問題：行銷導向的基準測試往往比工程導向的基準測試更具傳播力。
ClickHouse 的重現實驗：單節點 30 vCPU 能跑多少
ClickHouse 採用 TPC-H SF1 Q6 作為測試查詢，在單一 30 vCPU 節點上執行壓力測試。結果顯示，該節點可持續維持約 420 QPS，且 P90 延遲維持在 1 秒以內，全程未出現任何崩潰。當並發查詢數接近系統預設上限 1,000 時，ClickHouse 以保護機制主動拒絕新查詢，而非崩潰——這是設計行為，不是缺陷。
若要達到 15,000 QPS 並維持相同的 P90 延遲，工程師計算出需要 30 至 40 個未經調優的節點，呈線性擴展。此外，測試刻意不啟用任何進階調優手段，包括 max_threads = 1（降低 CPU 競爭）、查詢快取（Databricks 環境預設啟用）、以及 Projection 功能。若啟用這些選項，效能數字可望大幅提升。
-- ClickHouse 重現所用查詢（TPC-H SF1 Q6）
SELECT
sum(l_extendedprice * l_discount) AS revenue
FROM lineitem
WHERE
l_shipdate >= toDate('1994-01-01')
AND l_shipdate < toDate('1994-01-01') + INTERVAL 1 YEAR
AND l_discount BETWEEN 0.06 - 0.01 AND 0.06 + 0.01
AND l_quantity < 24;可重現方法論的最低標準
這場爭論的核心不在於哪家資料庫更快，而在於基準測試必須提供足夠的資訊讓第三方獨立重現結果。一份有效的基準測試報告至少應包含：公開的查詢語句、資料集與規模、完整的硬體規格、系統設定檔，以及成本或雲端帳單資訊。缺少其中任何一項，讀者就無法判斷數字背後的條件假設。
| 項目 | Databricks Reyden 報告 | ClickHouse 重現報告 |
|---|---|---|
| 資料集 | 有（TPC-H SF1、NYC Taxi） | 有（TPC-H SF1 Q6） |
| 硬體規格 | 無 | 有（單節點 30 vCPU） |
| 系統設定 | 無 | 有（未調優基線） |
| 快取狀態 | 無 | 有（未啟用） |
| 可重現步驟 | 無 | 有 |
原始來源：ClickHouse Blog — Databricks Reyden Benchmark Transparency
AI Agent 厭惡摩擦：為 Agent 設計資料系統的早期觀察
ClickHouse Blog · 2026 年 6 月
隨著 AI Agent 開始被部署到生產環境，工程師發現一件令人意外的事：Agent 在遭遇反覆失敗後，會像人類一樣放棄任務，甚至主動尋找替代工具。這篇文章記錄了 ClickHouse 工程師在觀察 Agent 與資料系統互動時歸納出的摩擦模式，以及降低摩擦的設計原則。
Agent 如何在摩擦中失敗
觀察到的最常見失敗模式，是 Agent 在執行同一個目標時進行了超過 30 次的失敗嘗試，最終得出「此任務不可能完成」的結論並建議使用者改用其他方案。造成這種行為的根源往往不是 Agent 本身的能力不足，而是介面設計未考慮 Agent 的使用方式。錯誤訊息只說「不行，請重試」而不提供任何診斷線索，是最典型的例子——人類可以憑直覺推斷，Agent 卻必須多花幾個步驟才能收斂。
另一個常見問題是上下文視窗的消耗速度。即使模型提供了 100 萬 token 的上下文窗口，當累積的對話量超過約 15 萬 token 時，模型的推理品質會明顯下降。若 API 回應過於冗長、工具輸出未經壓縮，Agent 在任務中途就會開始出現判斷失誤。
衡量 Agent 體驗的六個維度
文章提出了「Agent 體驗（AX）」的概念，並列出可量化的評估維度：
- 完成步驟數：步驟越少代表介面可發現性越高；過多的錯誤重試是設計問題的訊號
- 自我修正能力：錯誤訊息是否提供可操作的修正方向，而非單純拒絕
- 行為一致性：相同目標在不同執行路徑下的結果變異程度
- 上下文效率：稀疏的說明文件可能減少 token 消耗，但也可能迫使 Agent 多花步驟探索
- Token 經濟性：回應的詳盡程度與步驟數之間的取捨
- 熟悉的模式：Agent 在訓練資料中見過的工具介面（如
kubectl、git、gh）能大幅降低學習成本
人類 DX 與 Agent AX 的根本差異
工程師最容易犯的錯誤，是假設「對人類友善的介面對 Agent 也友善」。這個等式在多數情況下並不成立。人類在使用 UI 時能利用視覺層次、顏色提示和文化慣例快速定向；Agent 只能依賴文字語義和結構一致性。一個設計精美、對人類直覺友善的 API，若錯誤訊息缺乏機器可解析的結構，對 Agent 來說反而是高摩擦介面。
LLM 的非確定性也放大了介面設計缺陷的影響。同樣的目標在不同執行中可能走完全不同的路徑，因此介面的容錯空間必須大於為人類設計時的預期。讓 Agent 能夠在出錯後優雅地自我修正，比讓 Agent 第一次就不出錯更加重要。