Google 本週發布了一份預印本,介紹 Auto-Diagnose,一個基於 LLM 的系統,它讀取整合測試的日誌,告訴工程師測試為什麼失敗。動機來自 Google 內部調查:38.4% 的整合測試失敗診斷需要超過一小時,8.9% 需要超過一天。單元測試幾乎瞬時就能分診,因為失敗面就是一個函式;而整合測試橫跨服務、資料中心和執行時層,所以根因分析變成了一項日誌考古工作。Auto-Diagnose 用前沿模型上的提示工程來自動化這項考古,而不是用微調模型。
模型是 Gemini 2.5 Flash,溫度 0.1,top-p 0.8,沒有在 Google 測試語料上做過微調。流水線收集測試驅動日誌和跨資料中心的元件日誌,將它們按時間順序拼成單一流,然後整體提交給模型。每次執行的平均負載:110,617 個輸入 token 和 5,962 個輸出 token。延遲 p50 為 56 秒,p90 為 346 秒。提示引導模型通過明確的階段:掃描日誌段、讀取脈絡、定位失敗、總結錯誤,然後給出結論。關鍵的工程選擇是一個嚴格的反幻覺約束,強制模型在證據不足時拒絕回答而不是猜測。正是這種拒絕行為,讓準確率在一個「自信地答錯會浪費工程師數小時」的領域裡維持在 90% 以上。
2025 年 5 月以來的生產資料:評估了 224,782 次測試執行,診斷了 52,635 個不同的失敗測試。在 39 個團隊的 71 個真實世界失敗上的人工評估:根因準確率 90.14%。開發者回饋:評審員 84.3% 的「please fix」、開發者回應中的有用度比例 62.96%、在 370 個內部 Critique 工具中按有用度排名第 14(前 3.78%)。值得注意的是缺失的部分:沒有微調、沒有 RAG 層、沒有客製模型。只有 Gemini 2.5 Flash 加上用心的提示設計和一條拒絕-於-歧義規則。系統也受益於 Google 極端集中的日誌基礎設施,所以你不能簡單地把同一個提示發到 AWS CloudWatch 就期待同樣的數字,因為提示假設日誌已經跨服務按時間順序拼好了。
如果你在執行任何形式的多服務 CI,這裡的方法論可複製,但不便宜。模型成本微不足道(Gemini 2.5 Flash 每次分診約 116k token,成本幾分錢),所以真正的投入在日誌管道:在 LLM 看到任何東西之前,先收集、標準化並跨服務拼接。拒絕-於-歧義這個模式是最可遷移的單一想法。大多數 CI 裡的 LLM 流水線沒有調好拒絕,結果會幻覺出看起來合理的原因,這比沉默更糟,因為它會把工程師引向錯誤修復。如果你在給測試套件接 LLM 分診,先複製這個模式,再去操心模型。第二個教訓是,現成的前沿模型加上用心的提示,在專門任務上已經能和微調方案競爭,前提是你把輸入塑造好。這提高了小團隊不搞 ML 基礎設施也能做出的東西的上限。