我們的文字轉查詢 Agent 從前沿模型的 45 秒，縮短到 GLM 5.3 Flash 的 2 秒，在相同準確度下，成本僅為原本的二十分之一。
Conversion 近期大部分的 AI 工作都集中在通用行銷情報上。
行銷自動化團隊在跨系統執行廣泛的工作：研究帳戶、建立受眾、規劃活動、撰寫內容，以及根據成效數據採取行動。我們一直在建立能夠推理這些工作流程，並使用與熟練行銷人員相同工具的 Agent。
這些系統受益於功能強大、用途廣泛的模型。這項工作是開放式的，良好的判斷力通常比快速完成任務更重要。
但我們也積累了一些較小、更聚焦的 AI 功能。其中之一是自然語言篩選器：讓使用者用白話英文描述受眾，並將該描述轉換成他們可以在 Conversion 現有陳述式建構器中檢查和編輯的篩選器。（在 Conversion 中，篩選器稱為陳述式。）
起初，這看起來像是一個直接的結構化生成任務。給模型可用的欄位，描述輸出格式，然後要求它產生 JSON。結果發現，這比想像中困難得多。
使用 GLM 5.3 Flash 在 5 秒內生成的複合陳述式。
以以下範例來說：
尋找在過去 30 天內至少提交過一次示範表單，並且任職於一家有超過 50,000 美元開放商機的軟體公司的聯絡人。
這需要系統能夠：
- 找出使用者所指的特定「示範表單」
- 判斷哪個欄位代表公司的產業
- 了解該工作區如何表示「軟體」，這意味著要查看該欄位中實際儲存的值，而不是猜測
- 從聯絡人遍歷到其公司，再到該公司的商機
- 確保「開放」和「超過 50,000 美元」適用於同一個商機
- 應用相對事件時間範圍
它還需要足夠快地完成所有這些操作，以至於感覺像是一個篩選器介面，而不是一個研究 Agent。
一個看似簡單的提示工程任務，變成了一個受限的文字轉查詢問題。解決它需要一個使用工具的 Agent、一個中間表示法（IR）、一個確定性編譯器和一個語意基準測試。
我們在最終的基準測試 Statement Bench 上運行了八個模型，包括 Claude Opus 5、Kimi K3、GLM 5.3 Flash 以及今天早上發布的 Gemini 3.8 Flash。結果如下。
為 Agent 提供工具
回答上述請求所需的大部分資訊都是客戶環境特有的。一個工作區可以容納數億個歷史欄位值，以及其資產和物件。顯而易見地，我們無法將所有這些都放入一個提示中。
我們第一個有用的架構決策是停止將問題視為普通的結構化生成。取而代之的是，模型會收到一組小型工具。它可以搜尋欄位、檢查歷史值，以及解析特定於業務的資產，例如表單、活動、電子郵件和受眾。它僅在請求需要時才使用這些工具。
這些搜尋基礎設施大部分來自我們最近的 Global Search 工作，該工作提供對 Conversion 中所有記錄的文字和語意搜尋。我們計劃很快分享更多相關資訊！
基本流程如下所示：
1自然語言請求2 |3 v4 使用工具的 Agent <-----------------+5 / | \ |6欄位 資產 關係 | 附帶原因的拒絕7 \ | / |8 v |9 受限的 IR |10 | |11 v |12 驗證器和編譯器 -----------------------+13 |14 v15 生產環境的陳述式
這使得初始上下文保持較小。它也讓失敗更容易理解。如果一個陳述式是錯誤的，我們可以判斷 Agent 是否找到了錯誤的資產、選擇了錯誤的欄位、誤解了關係、以錯誤的方式表示了正確的想法，或者暴露了編譯器中的一個錯誤。這個區別後來對我們的評估循環變得非常重要。
創造一個更小的語言
工具使用解決了上下文問題，但沒有解決延遲問題。
從早期回饋中學到的一課是：使用者對專用介面中的延遲容忍度遠低於聊天介面。
這指向一個更廣泛的矛盾。我們根據任務對我們自己來說感覺有多困難來設定延遲期望，而不是根據系統的實際難度。撰寫內容感覺困難，因為我們能看到工作本身。描述一個篩選器感覺簡單，因為我們的大腦會默默地解析上下文、實體、關係和意圖。對模型來說，重建這些隱藏的假設就是任務本身。使用者感知到的工作越少，他們給系統完成工作的時間就越少。
根據早期回饋，我們設定了兩個目標：對於常見查詢，準確率超過 95%，回應時間約為 5 秒。
Conversion 擁有一種表達力豐富的內部查詢語言。在我們的早期測試中，直接使用生產格式時，只有像 Claude Opus 這樣最大的模型才能可靠地生成它。即使是一個簡單的陳述式也需要大約 45 秒。
視覺化的陳述式建構器只暴露了完整語言的一個子集。我們為該子集創建了一個更小、對 Agent 友好的中間表示法。較小的模型可以使用更少的 token 來生成它，而一個確定性編譯器則處理完整的生產格式。
考慮以下陳述式：
職稱包含「Director」。
原始的生產陳述式如下所示：
1{2 "type": "LOGICAL",3 "version": 1,4 "logical": {5 "operator": "OR",6 "operands": [7 {8 "type": "LOGICAL",9 "version": 1,10 "logical": {11 "operator": "AND",12 "operands": [13 {14 "type": "VARIABLE",15 "version": 1,16 "variable": {17 "variableSchemaId": "550e8400-e29b-41d4-a716-446655440000",18 "where": {19 "type": "LOGICAL",20 "version": 1,21 "logical": {22 "operator": "AND",23 "operands": [24 {25 "type": "LOGICAL",26 "version": 1,27 "logical": {28 "operator": "CONTAINS",29 "operands": [30 {31 "type": "ATTRIBUTE",32 "version": 1,33 "attribute": {34 "name": "value"35 }36 },37 {38 "type": "CONSTANT",39 "version": 1,40 "constant": {41 "value": "Director"42 }43 }44 ]45 }46 }47 ]48 }49 }50 }51 }52 ]53 }54 }55 ]56 }57}
同一個篩選器面向模型的表示法是：
1{2 "field": "550e8400-e29b-41d4-a716-446655440000",3 "op": "contains",4 "value": "Director"5}
IR 已經經歷了幾代演進，最新的版本是透過觀察小型模型在早期版本上失敗而塑造出來的。一個重大的改進是引入了更好的同記錄語意（這是 schema 驗證無法捕捉到的）：
1{2 "related": "OPPORTUNITY",3 "all": [4 { "field": "<stage uuid>", "op": "equals", "value": "Closed Won" },5 { "field": "<amount uuid>", "op": "gt", "value": 100000 }6 ]7}
這種模型與程式碼的分離給了我們一些有用的特性：
- 不支援的陳述式難以表達
- 同記錄關係語意是可見的
- 欄位和關係引用可以被驗證
- 編譯器可以獨立於模型進行測試
- 生成的陳述式在現有 UI 中仍然可以編輯
IR 最終簡化了模型的工作：Agent 解析使用者的意圖並產生一個受限的計畫；程式碼則處理生產格式。
建立一個語意基準測試
一個輸出可能完全有效，但仍然是錯誤的。以這個請求為例：
在擁有價值超過 100,000 美元已贏得商機的公司中的聯絡人。
一個聯絡人屬於一家公司，而一家公司可以有多個商機。匹配這個篩選器意味著遍歷關係（聯絡人到公司，公司到商機），並沿途檢查兩個條件：交易已贏得，且交易價值超過 100,000 美元。
困難之處在於這些條件必須適用於同一個商機。如果它們被獨立檢查，那麼一家公司同時擁有一個已贏得的 20,000 美元交易和一個開放的 150,000 美元交易，就能滿足這兩個條件：每個條件分別匹配一個交易。Schema 驗證永遠不會捕捉到這一點。
一旦幾個這樣的例子通過了，編輯提示就有可能使它們回歸。我們需要一種方法來檢查意義，而不僅僅是有效性，並且在每次有變動時都進行檢查。
我們圍繞產品的行為建立了 Statement Bench，這些行為源自客戶先前建立的匿名受眾模式。該測試套件現在包含 100 個案例，涵蓋十五個類別，例如純欄位條件、事件、相對和日曆時間範圍、關係以及複合查詢。
每個案例都在一個逼真的工作區沙盒中運行。Agent 接收與生產環境中相同的資料和工具。
評估器會檢查幾個層面：
- Agent 是否回傳了一個陳述式？
- IR 是否滿足其 schema？
- 引用的欄位和關係是否存在？
- 陳述式能否編譯並通過生產驗證？
- 它是否代表了請求的意義？
- 它需要多少模型步驟、工具呼叫、token 和被拒絕的提交？
第五點是最有趣的，因為有效性並不能保證語意等價。
語意檢查會讀取編譯後的陳述式，斷言諸如「一個商機條件同時承載了階段和金額」、「一個電子郵件事件的類型是點擊，而非開啟」或「一個網路研討會條件，而非自訂活動條件」等事項。
運行評估驅動的最佳化循環
基準測試改變了我們繼續開發此功能的方式。我們不再要求一個編碼 Agent「改進提示」或「實作一個新的 IR」，而是可以給它一個可執行的改進定義。
這個循環看起來像這樣：
- 運行基準測試
- 根據根本原因對失敗進行分組
- 檢查 Agent 的工具軌跡和提交的 IR
- 更改提示、工具、驗證器或編譯器
- 再次運行完整的基準測試
- 僅在改進系統且不引入回歸的情況下保留更改
編碼 Agent 可以使用基準測試來比較模型、實驗 IR、改進工具描述，以及自主地優化提示。每次更改後運行完整的測試套件也防止了我們過度擬合於個別失敗，我們還保留了另外 50 個案例來確認這一點。
一些更改對結果的改善最大：
- 將路徑、類型和結構移入編譯器。 我們的第一個 IR 讓模型明確寫出所有關係：聯絡人到公司，公司到商機。欄位的元資料已經隱含了該路徑，因此編譯器現在會推斷它。我們對日期、型別轉換、否定放置和群組巢狀也做了同樣的處理。將規則移入編譯器簡化了 IR 並減少了 schema 失敗。
- 附帶解釋和修正的拒絕。 每個 schema 和編譯器拒絕都會說明應該改寫什麼（如果有的話）：「此欄位上的 gt 無法被否定；請使用 lte」、「從 campaign_list 複製 id」。小型模型在一兩次重試後就能收斂，而生產模型在每百個請求中只會被拒絕幾次。
- 為小型模型結構化提示。 重新組織提示並沒有改變準確率，但它將重試次數減半，這直接改善了延遲。這項靈感來自 Anthropic 的 提示最佳實踐。
- 使用範例勝過文字說明。 在我們的格式參考中增加兩個範例，解決了一類文字說明段落未能解決的遺漏問題，將被拒絕的提交大致減少了一半。
- 提供完整的上下文，否則就不提供。 模型在呼叫工具之前會先使用上下文中的內容。當上下文包含一組不完整或未標記的欄位時，模型會使用最接近的一個，而不是進行搜尋，從而產生語意不正確的陳述式。透過減少部分上下文並鼓勵工具呼叫，我們提高了建構率並將輸入 token 減少了五分之一。
最終的生產配置 GLM 5.3 Flash，以 2.3 秒 的中位數延遲和 7.1 秒的 95 百分位數延遲完成了所有 100 個基準測試案例。而且，100 個中有 97 個 在語意上是正確的。與原始的生產格式方法相比，簡單的篩選器從大約 45 秒減少到略多於 1 秒，成本僅為原來的二十分之一。
在 Statement Bench 上比較模型
基準測試也為我們提供了一種在實際任務上比較模型的方法。
在 2026 年 9 月 2 日，我們在八個模型上運行了相同的 100 個案例。每個模型都收到了相同的提示、工具、IR、編譯器和 30 秒的請求超時時間。
供應商路由、提示快取和臨時推理負載都會影響延遲。
模型
有效建構
語意正確
P50 延遲
P95 延遲
快取讀取
工具呼叫
被拒絕的提交
每 1,000 次請求的估計成本
Claude Opus 5
100/100 (100%)
100/100 (100%)
3.16 秒
8.53 秒
91.1%
162
0
$27.51
GLM 5.2
100/100 (100%)
100/100 (100%)
4.38 秒
13.02 秒
93.5%
201
5
$14.94
Kimi K3
100/100 (100%)
100/100 (100%)
5.17 秒
11.84 秒
34.3%
157
0
$48.51
GLM 5.3 Flash
100/100 (100%)
97/100 (97%)
2.34 秒
7.07 秒
92.8%
163
2
$1.33
DeepSeek V4 Pro
96/100 (96%)
96/96 (100%)
5.53 秒
24.31 秒
47.8%
172
1
$12.00
Gemini 3.7 Flash
77/100 (77%)
77/77 (100%)
15.14 秒
30.01 秒
26.5%
228
1
$18.24
Gemini 3.8 Flash
76/100 (76%)
76/76 (100%)
14.29 秒
30.01 秒
35.4%
266
1
$27.44
DeepSeek V4 Flash
56/100 (56%)
55/56 (98%)
6.79 秒
30.00 秒
41.5%
100
1
$0.56
估計成本是根據觀察到的輸入、快取輸入和輸出 token，以及各供應商在 2026 年 9 月 2 日列出的非促銷費率計算的每 1,000 次嘗試請求的成本。快取輸入按供應商公佈的快取讀取費率計費，若供應商未公佈，則按完整輸入費率計費。
圖 1. 正確性與成本對比。GLM 5.3 Flash 以約為 Claude Opus 5 二十分之一的成本達到了 97% 的正確率。
圖 2. 延遲分佈，中位數和 95 百分位數，按 P95 排序。
有幾個發現值得注意。
模型大小和價格都無法預測延遲。 最快的模型是最小且最便宜的。第二快的則是最大且最貴的。
失敗已從錯誤答案轉變為緩慢答案。 八個模型中有六個在它們完成的每個陳述式上都是語意正確的；它們之間的差異幾乎完全在於有多少請求在超時時間內完成。在 IR 和提示的早期迭代中，大多數較小的模型在建構步驟就以低於 50% 的語意準確率失敗了。
推理 token 的開銷超過了工具呼叫。 Gemini 3.8 Flash 在其 192,000 個輸出 token 中花費了 180,000 個用於推理，並進行了 266 次工具呼叫；Claude Opus 5 花費了 813 個 token 用於推理，進行了 162 次呼叫，並完成了每個案例。我們的 Global Search 工作將每次工具查找時間縮短到毫秒級別，因此剩餘的成本是模型在它們之間的輪次。
結論
模型擅長解析歧義，程式碼擅長強制執行精確性，而我們早期的大部分失敗來自於要求模型同時做到這兩點。建立這個 Agent 的工作，就是決定兩者各自應該負責哪一部分。我們認為，對於文字轉 SQL 和大多數其他自然語言介面來說，情況也是如此。
如果你對這些問題中的任何一個感興趣，歡迎聯繫我們！我們正在招聘。
