<p>前沿人工智能模型在生成模板函數方面表現出色，但對其調試能力的新嚴格測試表明，它們距離處理生產故障仍然相去甚遠。</p>
<p>今天發佈的基準測試 OTelBench 測試了 14 個領先的大型語言模型在執行一項基本的站點可靠性工程（SRE）任務上的能力：使用行業標準 OpenTelemetry（OTel）為微服務添加分佈式追蹤。結果對人工智能 SRE 的炒作週期是一個嚴峻的現實檢查。</p>
<p>在涵蓋 11 種編程語言的 23 項任務中，整體通過率僅為 14%。即使是表現最好的模型，Anthropic 的 Claude Opus 4.5，成功率也僅為 29%，而 GPT 5.2 的成功率為 26%。</p>
<p>分佈式追蹤對於現代微服務架構至關重要。當用户點擊 “登錄” 時，這個單一的動作可能會跨越數十個服務。OTel 提供了必要的工具——添加到應用程序中的代碼——將這些分散的事件鏈接成一個單一的、連貫的時間線，使工程師能夠準確找出請求失敗的地方。</p>
<p>OTelBench 的研究人員，包括 Przemek Delewski 和 Jacek Migdał，設計了對人類 SRE 來説微不足道的任務，涉及約 300 行代碼的簡短、乾淨的微服務。如果模型無法處理這些，它們肯定無法應對現實世界中龐大且遺留系統。</p>
<h2>上下文差距與無聲故障</h2>
<p>基準測試識別出的最關鍵的故障模式不是編譯錯誤，而是缺乏商業上下文。</p>
<p>在一個例子中，模型被呈現出一個模擬兩種不同用户行為的網絡服務：一次成功的搜索和一次失敗的令牌檢索嘗試。人類工程師會立即將這兩者識別為兩個獨立的用户旅程，需要兩個具有不同 TraceID 的獨特追蹤。</p>
<p>大型語言模型在這個測試中表現不佳。它們沒有生成兩個獨立的追蹤，而是機械地對每個 HTTP 調用進行了工具化，並將兩個用户行為混淆為一個單一的、令人困惑的時間線。它們成功地對低級 HTTP 調用進行了工具化，但未能正確傳播上下文，將整個序列視為一個扁平的事件列表，而不是兩個層次分明的樹狀結構。</p>
<p>這一發現至關重要：許多模型生成的代碼雖然編譯正確，但產生了格式錯誤或無用的追蹤。對於 SRE 工作而言，“它構建成功” 遠遠不夠。格式錯誤的追蹤可以説比沒有追蹤更糟，因為它在故障期間提供了誤導性的數據。</p>
<p>現代系統的多語言特性也被證明是一個無法克服的障礙。基準測試要求模型跨越 11 種語言工作，反映了雲環境的現實。雖然 Go 和 C++ 取得了一定的成功，但模型在幾個關鍵語言上完全失敗。在 Java、Ruby 或 Swift 中，14 個模型沒有解決任何任務，常常在依賴管理和構建系統上掙扎——這些技能遠遠超出了簡單代碼生成的範疇。</p>
<p>研究人員指出，這需要多語言後端開發技能，包括對 C++ 的 CMake 或 Go 的模塊系統的瞭解，這些通常超出了訓練截止日期或當前人工智能開發的核心關注點。</p>
<p>### 成本與效率權衡</p>
<p>儘管整體表現較低，但基準測試確實揭示了成本效率的顯著差異。</p>
<p>表現最好的模型 Claude Opus 4.5 也是最昂貴的。然而，預算意識強的贏家是 Gemini 3 Flash。儘管其成本是 Claude Opus 4.5 的 11 倍便宜且速度是其兩倍，Gemini 3 Flash 的通過率達到了 19%，大幅超越了更昂貴的 Gemini 3 Pro，後者僅得到了 16%。這表明，對於低級 SRE 支持而言，速度和成本效率目前主導了在通用智能上的邊際收益。</p>
<p>OTelBench 的結果由 QuesmaOrg 發佈，確認了人工智能 SRE 的承諾在 2026 年初仍然主要是市場炒作。雖然大型語言模型可以協助編寫函數，但它們缺乏可靠地工具化和調試複雜分佈式系統所需的長遠推理和上下文意識。</p>
<p>結論很明確：在模型能夠可靠地區分不同用户旅程並處理多語言構建系統的複雜現實之前，工程師應當預期自己編寫和維護 OpenTelemetry 工具化。行業需要像 OTelBench 這樣的更好基準測試，以推動朝着真正可靠的人工智能輔助的進展。</p>

全球科技股指數 ETF - iShares

XDAT

北美科技軟件股指數 ETF - iShares

AGIX

雲計算 ETF - GlobalX

標普軟件與服務 ETF - SPDR

<p>一項新的基準測試 OTelBench 顯示，領先的 AI 模型在調試能力方面存在困難，而這些能力對站點可靠性工程（SRE）至關重要。在對 14 個模型進行的測試中，使用 OpenTelemetry 添加分佈式追蹤的整體通過率僅為 14%。表現最好的模型是 Anthropic 的 Claude Opus 4.5，成功率為 29%。主要失敗原因包括缺乏業務上下文和多語言系統的挑戰。儘管一些成本效益較高的模型表現更好，但結果表明，AI 在 SRE 中的作用仍然有限，強調了工程師在模型改進之前需要自行處理 OpenTelemetry 的儀器化</p>

<p>Frontier AI models have become excellent at generating boilerplate functions, but a new, rigorous test of their debugging capabilities suggests they are nowhere near ready to handle production outages.</p>
<div class="lb-trans"><p>前沿人工智能模型在生成模板函數方面表現出色，但對其調試能力的新嚴格測試表明，它們距離處理生產故障仍然相去甚遠。</p>
</div><p>A benchmark released today, OTelBench, tested 14 leading large language models on their ability to perform a fundamental Site Reliability Engineering (SRE) task: adding distributed tracing to microservices using the industry standard, OpenTelemetry (OTel). The results are a stark reality check for the AI SRE hype cycle.</p>
<div class="lb-trans"><p>今天發佈的基準測試 OTelBench 測試了 14 個領先的大型語言模型在執行一項基本的站點可靠性工程（SRE）任務上的能力：使用行業標準 OpenTelemetry（OTel）為微服務添加分佈式追蹤。結果對人工智能 SRE 的炒作週期是一個嚴峻的現實檢查。</p>
</div><p>The overall pass rate across 23 tasks spanning 11 programming languages was a dismal 14%. Even the best performing model, Anthropic’s Claude Opus 4.5, succeeded only 29% of the time, while GPT 5.2 managed 26%.</p>
<div class="lb-trans"><p>在涵蓋 11 種編程語言的 23 項任務中，整體通過率僅為 14%。即使是表現最好的模型，Anthropic 的 Claude Opus 4.5，成功率也僅為 29%，而 GPT 5.2 的成功率為 26%。</p>
</div><p>Distributed tracing is essential for modern microservices architectures. When a user clicks “Login,” that single action might hop across dozens of services. OTel provides the necessary instrumentation—code added to the application—to link these scattered events into a single, coherent timeline, allowing engineers to pinpoint where a request failed.</p>
<div class="lb-trans"><p>分佈式追蹤對於現代微服務架構至關重要。當用户點擊 “登錄” 時，這個單一的動作可能會跨越數十個服務。OTel 提供了必要的工具——添加到應用程序中的代碼——將這些分散的事件鏈接成一個單一的、連貫的時間線，使工程師能夠準確找出請求失敗的地方。</p>
</div><p>The OTelBench researchers, including Przemek Delewski and Jacek Migdał, designed tasks that would be trivial for a human SRE, involving short, clean microservices of around 300 lines of code. If the models cannot handle this, they certainly cannot handle the massive, legacy-ridden systems found in the real world.</p>
<div class="lb-trans"><p>OTelBench 的研究人員，包括 Przemek Delewski 和 Jacek Migdał，設計了對人類 SRE 來説微不足道的任務，涉及約 300 行代碼的簡短、乾淨的微服務。如果模型無法處理這些，它們肯定無法應對現實世界中龐大且遺留系統。</p>
</div><h2>The Context Gap and Silent Failures</h2>
<div class="lb-trans"><h2>上下文差距與無聲故障</h2>
</div><p>The most critical failure mode identified by the benchmark was not compilation errors, but a profound lack of business context.</p>
<div class="lb-trans"><p>基準測試識別出的最關鍵的故障模式不是編譯錯誤，而是缺乏商業上下文。</p>
</div><p>In one example, models were presented with a web service simulating two distinct user actions: a successful search and a failed token retrieval attempt. A human engineer would immediately recognize these as two separate user journeys, requiring two unique traces with different TraceIDs.</p>
<div class="lb-trans"><p>在一個例子中，模型被呈現出一個模擬兩種不同用户行為的網絡服務：一次成功的搜索和一次失敗的令牌檢索嘗試。人類工程師會立即將這兩者識別為兩個獨立的用户旅程，需要兩個具有不同 TraceID 的獨特追蹤。</p>
</div><p>The LLMs failed this test consistently. Instead of generating two distinct traces, they mechanically instrumented every HTTP call and conflated both user actions into a single, confusing timeline. They successfully instrumented the low-level HTTP calls but failed to propagate the context correctly, treating the entire sequence as one flat list of events rather than two hierarchical trees.</p>
<div class="lb-trans"><p>大型語言模型在這個測試中表現不佳。它們沒有生成兩個獨立的追蹤，而是機械地對每個 HTTP 調用進行了工具化，並將兩個用户行為混淆為一個單一的、令人困惑的時間線。它們成功地對低級 HTTP 調用進行了工具化，但未能正確傳播上下文，將整個序列視為一個扁平的事件列表，而不是兩個層次分明的樹狀結構。</p>
</div><p>This finding is crucial: many models produced code that compiled correctly but generated malformed or useless traces. For SRE work, “it builds” is not nearly enough. A malformed trace is arguably worse than no trace at all, as it provides misleading data during an outage.</p>
<div class="lb-trans"><p>這一發現至關重要：許多模型生成的代碼雖然編譯正確，但產生了格式錯誤或無用的追蹤。對於 SRE 工作而言，“它構建成功” 遠遠不夠。格式錯誤的追蹤可以説比沒有追蹤更糟，因為它在故障期間提供了誤導性的數據。</p>
</div><p>The polyglot nature of modern systems also proved to be an insurmountable hurdle. The benchmark required models to work across 11 languages, reflecting the reality of cloud environments. While Go and C++ saw moderate success, models failed completely on several key languages. None of the 14 models solved a single task in Java, Ruby, or Swift, often struggling with dependency management and build systems—skills that extend far beyond simple code generation.</p>
<div class="lb-trans"><p>現代系統的多語言特性也被證明是一個無法克服的障礙。基準測試要求模型跨越 11 種語言工作，反映了雲環境的現實。雖然 Go 和 C++ 取得了一定的成功，但模型在幾個關鍵語言上完全失敗。在 Java、Ruby 或 Swift 中，14 個模型沒有解決任何任務，常常在依賴管理和構建系統上掙扎——這些技能遠遠超出了簡單代碼生成的範疇。</p>
</div><p>The researchers note that this requires polyglot backend development skills, including knowledge of CMake for C++ or module systems for Go, which are often past the training cut-off dates or outside the core focus of current AI development.</p>
<div class="lb-trans"><p>研究人員指出，這需要多語言後端開發技能，包括對 C++ 的 CMake 或 Go 的模塊系統的瞭解，這些通常超出了訓練截止日期或當前人工智能開發的核心關注點。</p>
</div><p>### Cost and Efficiency Tradeoffs</p>
<div class="lb-trans"><p>### 成本與效率權衡</p>
</div><p>While performance was low across the board, the benchmark did reveal significant differences in cost efficiency.</p>
<div class="lb-trans"><p>儘管整體表現較低，但基準測試確實揭示了成本效率的顯著差異。</p>
</div><p>The best-performing model, Claude Opus 4.5, was also the most expensive. However, the budget-conscious winner was Gemini 3 Flash. Despite being 11 times cheaper and twice as fast as Claude Opus 4.5, Gemini 3 Flash achieved a 19% pass rate, substantially outperforming the more expensive Gemini 3 Pro, which scored only 16%. This suggests that for low-level SRE assistance, speed and cost efficiency currently dominate marginal gains in generalized intelligence.</p>
<div class="lb-trans"><p>表現最好的模型 Claude Opus 4.5 也是最昂貴的。然而，預算意識強的贏家是 Gemini 3 Flash。儘管其成本是 Claude Opus 4.5 的 11 倍便宜且速度是其兩倍，Gemini 3 Flash 的通過率達到了 19%，大幅超越了更昂貴的 Gemini 3 Pro，後者僅得到了 16%。這表明，對於低級 SRE 支持而言，速度和成本效率目前主導了在通用智能上的邊際收益。</p>
</div><p>The OTelBench results, released by QuesmaOrg, confirm that the promise of AI SRE remains largely marketing hype in early 2026. While LLMs can assist in writing functions, they lack the long-horizon reasoning and contextual awareness required to reliably instrument and debug complex distributed systems.</p>
<div class="lb-trans"><p>OTelBench 的結果由 QuesmaOrg 發佈，確認了人工智能 SRE 的承諾在 2026 年初仍然主要是市場炒作。雖然大型語言模型可以協助編寫函數，但它們缺乏可靠地工具化和調試複雜分佈式系統所需的長遠推理和上下文意識。</p>
</div><p>The verdict is clear: until models can reliably distinguish between separate user journeys and handle the messy reality of polyglot build systems, engineers should expect to write and maintain their own OpenTelemetry instrumentation. The industry needs better benchmarks like OTelBench to drive progress toward truly reliable AI assistance.</p>
<div class="lb-trans"><p>結論很明確：在模型能夠可靠地區分不同用户旅程並處理多語言構建系統的複雜現實之前，工程師應當預期自己編寫和維護 OpenTelemetry 工具化。行業需要像 OTelBench 這樣的更好基準測試，以推動朝着真正可靠的人工智能輔助的進展。</p>
</div>

AI OpenTelemetry 基準測試揭示了 LLM 調試的失敗