LLM 能工作，但你的產品可能不行

近日，OpenAI 報告稱，GPT-5.6 Sol 在官方控制框架下僅取得 13.3% 的 ARC-AGI-3 得分。然而，在啓用保留推理和上下文壓縮後，同一模型得分躍升至 38.3%，同時輸出令牌數減少六倍。

同樣的模型，同樣的基準，不同的控制框架——這一結果應徹底改變我們解讀 AI 基準測試的方式。ChatGPT、Claude Code 或 Codex 絕非僅僅是 API 背後的模型。它們是模型、上下文管理、工具、記憶、權限和執行循環的整合體。

這個整體才是真正的產品。

然而，數以千計的 SaaS 產品聲稱使用 GPT 或 Claude，彷彿接入模型就意味着獲得了這些產品所展示的能力。事實並非如此。

每家使用 LLM 的公司都在構建自己的控制框架，無論其是否意識到這一點。一個薄弱的框架能讓優秀的模型顯得愚蠢；而一個強大的框架則能讓完全相同的模型顯得聰明得多。

我曾在實驗小型開源模型時親身體驗到這一點。在我們的初始應用中，有些模型幾乎毫無用處。但在根據其優勢調整上下文、指令和工具循環後，它們變得切實有用。

基準測試即護城河

公開的基準測試只能告訴你一個模型加控制框架在某類任務上的表現，卻幾乎無法説明你的產品是否能完成實際工作。

一個客服代理可以承諾退款卻不實際生成；一個編程代理可以解釋正確的修復方案卻讓測試失敗；一個研究代理能產出令人信服的報告，但依據的是過時或虛構的信息源。

2025 年，Replit 的 CEO 承認其代理刪除了生產數據庫中的數據，並稱之為“不可接受”。有趣之處不在於 AI 犯了錯，而在於整個系統竟允許這個錯誤變成生產動作。

因此，任何價值實質性依賴 LLM 的 SaaS 都需要自己的內部基準測試。它應重現真實的輸入、工具、權限和故障模式，並評估完整的部署系統：模型、提示、上下文策略和執行循環。

更重要的是，它應測試最終狀態，而非模型聽起來有多可信。退款是否實際創建？測試是否通過？信息源是否真實？操作是否獲得授權？

如果代碼能驗證結果，就用代碼。LLM 可以生成多種可能的解決方案，但確定性檢查應驗證權限、計算、工具結果和最終狀態。

如今，一個令人印象深刻的 AI 原型可以在幾天內構建完成。但要確保其可靠運行，仍可能需要數月時間。嚴肅的評估需要代表性案例、專家標籤、重複運行、對抗性輸入和持續維護。

每次更換模型都應觸發基準測試。但更換提示、工具描述、檢索策略或上下文策略時也應如此，因為每次變更都會創建一個略有不同的系統。

沒有內部基準測試，團隊無法知道自己是在改進產品，還是在改變其行為。

真正的產品並非 API 背後的模型，而是模型、控制框架以及證明它們協同工作的證據。沒有這些證據，AI SaaS 就不能算是經過測試的產品——它只是一個在生產環境中運行的演示。

模型正成為商品，而基準測試才是護城河。