AI 圈子有個很有意思的現象。
一邊是科技公司瘋狂給大型語言模型裝上「手和腳」，讓它代替人類操作各種軟體；另一邊，真正需要 AI 的企業客戶卻在搖頭。
慕尼黑工業大學、達姆施塔特工業大學、麻省理工學院等機構的一群研究者，在他們最新的論文裡戳破了這層窗戶紙。
企業裡的 AI 落地問題，根本不是模型不夠聰明，而是資料太亂。
當頂尖的大型語言模型智慧體（Agent）在模擬企業環境中掙扎，正確率慘淡到 0% 時，一個叫 RUBICON 的新架構，靠著一套簡單直白的查詢語言，把正確率拉到了 100%。而且用的還是更小、更便宜的模型。
企業資料散落在各個孤立的系統裡。今天的智慧體 AI 總想讓大型語言模型當大腦，去理解並操作一切，結果就是混亂、昂貴、不可靠。
RUBICON 走了另一條路。它把操作權交還給使用者，讓使用者透過一種叫做 AQL 的極簡查詢語言，明確告訴系統去哪個資料來源找什麼東西，大型語言模型只負責在精確劃定的範圍內執行任務。
所有中間步驟透明可見，使用者隨時可以介入。這套方法用結構化的確定性，取代了端到端推理的機率性。
聰明大腦配不上混亂資料
過去幾年，把大型語言模型做成智慧體（Agent）成了主流思路。
大家覺得，大型語言模型推理能力強，應該讓它當總指揮，自己決定什麼時候查什麼資料庫，什麼時候調用什麼工具，最後合成一個答案。
這種以大型語言模型為中心的架構，看起來很美好。
但現實世界裡的企業，可不是實驗室裡那幾個乾淨的測試集。
論文毫不客氣地指出，企業在 AI 上碰的釘子，幾乎全是資料整合問題，而不是推理赤字。
關鍵資訊分散在資料庫、文件系統、郵件服務、外部網頁這些完全不同的系統裡。
每個系統有自己的查詢語言、資料結構、存取權限。
這些系統是架構嚴謹、對效能要求極度嚴苛的資料堡壘，而大型語言模型是個玩文字遊戲的機率高手。讓後者去管前者，就像讓一位詩人去調度一支航空母艦戰鬥群。
為什麼現在流行的 Text-to-SQL 在企業裡玩不轉？
論文點出了四個要命的差異。
公開的學術測試集，資料量小，對大型語言模型來說不過是一小撮資料。
但企業的資料倉儲動輒儲存著海量資料，完全不在一個量級。
學術測試集追求乾淨的單一模式，企業裡為了加速存取，到處是冗餘視圖和物化視圖，同一個問題有無數種查法，大型語言模型一看就暈。
企業資料裡充滿了內部行話，某個簡稱可能代表一個複雜專案，某段編碼背後是一整套業務流程，靠大型語言模型去猜，完全不切實際。
真實的業務查詢也比測試集複雜得多。
當這些差異疊加，論文觀察到大型語言模型在真實企業資料倉儲上的準確率，相比基準測試有超過 50% 的斷崖式下跌。這直接從可用掉到了不可用。
查什麼、從哪查，你說了算
既然此路不通，RUBICON 的解決之道很淳樸。
它不再死磕讓機器理解一切，而是把方向盤還給了人類駕駛員。
架構核心是一套叫 AQL（Agentic Query Language，智慧體查詢語言）的查詢代數。
這套語言極其精簡，就三個核心指令：FIND（找什麼）、FROM（從哪裡找）、WHERE（條件是什麼）。
條件部分用自然語言寫，其他部分使用者明確指定。
舉個例子，你想知道大學裡哪個研究實驗室的教授拿過圖靈獎或諾貝爾獎。對 RUBICON 來說，一個可能的 AQL 指令長這樣：
看到了嗎，使用者必須清楚地說出，要從維基百科和大學資料倉儲這兩個具體來源取數，並指明欄位。
大型語言模型的工作被壓縮到了一個極窄的範圍：它只負責理解 WHERE 後面的自然語言條件，把它翻譯成各個資料來源能執行的指令。
它不用再瞎猜去哪裡找資料，不用再操心怎麼把資料連起來。這個翻譯工作，由連接不同資料來源的包裝器（Wrapper）完成。
每個包裝器負責把一個資料來源（哪怕是郵件系統、影片庫），轉換成一個規範的關聯式表格視圖。
這讓所有的資料，看起來都像資料庫裡的行和列，下游操作變得極其明確。
這種設計直接把大型語言模型那套不透明的鏈式呼叫，變成了顯式的、可檢查的關聯操作流水線。
RUBICON 有兩種執行模式。
互動模式下，使用者執行完一條 AQL 指令，得到一個可視的、類似電子試算表的中間結果。
使用者可以停下來檢查，發現不對立刻糾正，然後把結果存起來，發給下一條指令用。每一步都實實在在，可追溯，可重現。
如果你想重複一個任務，編譯模式會把整個指令序列打包，像一個傳統資料庫查詢計畫一樣，讓最佳化器找到最高效的執行路徑，成本比反覆呼叫大型語言模型低得多。
0% 對陣 100%
口說無憑，團隊為 RUBICON 和目前的智慧體 AI 方案做了一個有意思的微型對打。
他們模擬了一個典型的企業資訊雜亂環境，包括維基百科、一個擁有 97 張表的匿名化大學資料倉儲、一個大學研究實驗室網站、Gmail 郵件系統，還有大型語言模型自己的預訓練知識庫。
他們精心設計了 7 個問題。每個問題都必須恰恰好跨 2 個資料來源才能回答，其他 3 個源全是干擾項。
表 1：七個基準查詢的真實資料來源相關性。綠色表示必須的資料來源（R），黃色表示可選資料來源（O），灰色表示無關資料來源（-）。
模型是 OpenAI 的 GPT-5-mini、Google 的 Gemini-3-flash-preview 和 Anthropic 的 Claude-Sonnet-4.6。
它們以兩種姿態迎戰：一種是不帶任何工具的普通聊天模式（Vanilla LLM），另一種是配備全套資料來源存取權、採用當前最流行的 ReAct 推理-行動循環的 LangChain 智慧體。
結果是一場令人驚訝的完勝。
所有 Vanilla LLM 和 LangChain 智慧體配置，準確率全部是 0%。一個正確的都沒有。
失敗的原因不是模型說胡話，而是系統性協調失靈。
模型要麼忘記去查某個必要的源頭，查到一半就停了，要麼沒能把不同源的結果正確關聯起來。
就拿剛才那個教授獲獎的問題來說，LangChain 智慧體經常只是去維基百科扒了個獲獎名單，卻沒去資料倉儲核實這些人是不是學校的教授，最後列出來一堆外人。
給了工具，模型自己卻沒管住手。論文裡形容，給模型更大的自主權和更強的推理設置，得到的是更廣的失敗面和更高的成本。
反觀 RUBICON，準確率 100%。這 7 個問題對它來說只是按部就班的 AQL 指令組合，不存在漏查或忘聯的可能。
管住手腳反而更省錢
效率上的對比同樣殘酷。來看看表 3 彙總的成本和延遲資料。
表 3：所有查詢的平均效率指標彙總。k̄ 是每個查詢的平均工具調用次數（Vanilla 模式為 0）。
Vanilla 模式很安靜，不調用任何工具，輸入 token 數不到 80，成本極低。
一旦變成 ReAct 智慧體，情況立刻失控。它們為了那可憐的 0% 正確率，開始瘋狂地嘗試。
GPT 智慧體平均每次查詢輸入 token 數飆到 2 萬到 4.6 萬。
Gemini 智慧體更誇張，自然語言模式下輸入超過 27 萬 token，AQL 模式下衝到近 47 萬 token，調用了高達 22.71 次工具，一次查詢的金錢成本是 0.28 美元，首次回應時間要等超過 4 分鐘。
Claude 的情況也很類似，昂貴的按 token 計價，加上大面積探索，導致一次查詢可能超過 0.5 美元。
這些模型用越來越多的推理、越來越長的上下文、越來越頻繁的工具調用，換來的卻是越來越穩固的 0 分。
RUBICON 用的是 GPT-5-mini，成本穩定在極低水準，每次查詢正好調用 2 次工具（對應 2 個必須的資料來源），不瞎逛，不多想。
RUBICON 把資料去哪找這類關鍵的決策權交還給使用者，這確保了結果正確，還天然繞開了一個智慧體 AI 自己很難處理的大坑：查詢計畫的選擇。
論文用同一個教授獲獎的問題舉了個例子。
使用者想達到目的，可以寫兩種不同的 AQL 指令。
計畫 A 是「先找獲獎者，再找人」，先從維基百科找出所有圖靈獎和諾獎得主（這個名單不長），然後再去大學資料倉儲裡，核對哪些人是教授。
計畫 B 是「先找人，再找獎」，先拉出所有教授（可能很多），然後為每一個教授去維基百科翻他的頁面，看有沒有得獎記錄。
這兩個計畫邏輯上都正確，但成本天差地別。計畫 B 會讓系統對每一位教授執行一次維基百科查找操作，開銷隨教授數量線性增長。計畫 A 則利用了一個高選擇性的過濾條件，大幅減少了後續的查找次數。
在智慧體 AI 中，這直接意味著更多或更少的工具調用、Token 消耗和等待時間。
大型語言模型自己選擇哪條路，有很強的隨機性，選得不好，成本能爆掉，速度能慢到無法接受。
RUBICON 把選擇權交給了使用者，也可以用一個經典的基於成本的查詢最佳化器，自動挑出最高效的那條路。這都是當前大型語言模型智慧體根本做不到的。
研究結尾引用了 MIT 一個追蹤了超 300 個企業 AI 專案的報告。報告發現，少於 5% 的自訂 AI 專案取得了可量化的回報。
模型越來越強，自主能力越開越大，但幻覺和遺漏帶來的失敗模式，沒什麼本質改變。
研究者給這股熱潮送上了一套古老的軟體工程智慧。
先理清資料，管好介面，再說智慧的事。這個看似「笨拙」的架構，反而更接近企業真正需要的 AI。
參考資料：
https://arxiv.org/pdf/2604.21413
END