Opus 4.5 在 OTelBench 基准测试中得分仅 29%

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

# 示例1：模拟 OTelBench 中的“数据聚合”任务
# 背景：AI 模型在处理基础的时间序列数据聚合（如计算 P95 延迟）时表现不佳。
# 此代码演示如何从原始 Span 数据中计算请求延迟的 P95 值。

import time
import random
import statistics

def calculate_p95_latency():
    """
    模拟从 OpenTelemetry Span 中提取持续时间并计算 P95 分位数。
    """
    # 1. 生成模拟的延迟数据（单位：毫秒）
    # 假设我们收集了 1000 个请求的耗时
    raw_durations = []
    for _ in range(1000):
        # 模拟延迟：基础 50ms + 随机抖动 (0-100ms)
        latency = 50 + random.random() * 100
        raw_durations.append(latency)

    # 2. 数据处理逻辑
    # AI 经常在排序和分位数计算上犯错，这里展示标准做法
    sorted_durations = sorted(raw_durations)
    
    # 计算 P95 (95分位数)
    # 索引计算：样本数 * 0.95
    index = int(len(sorted_durations) * 0.95)
    p95_value = sorted_durations[index]

    print(f"总请求数: {len(raw_durations)}")
    print(f"平均延迟: {statistics.mean(raw_durations):.2f} ms")
    print(f"P95 延迟: {p95_value:.2f} ms")
    
    return p95_value

if __name__ == "__main__":
    calculate_p95_latency()

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

# 示例2：模拟 OTelBench 中的“异常检测”任务
# 背景：AI 需要根据简单的规则（如错误率超过阈值）判断服务状态。
# 此代码演示如何解析模拟的日志流并计算错误率。

def analyze_service_health():
    """
    模拟分析服务日志，计算错误率并判断服务是否健康。
    """
    # 1. 模拟日志流数据
    # 格式: (status_code, latency)
    log_stream = [
        (200, 20), (200, 25), (200, 30), (500, 500), # 包含一个错误
        (200, 22), (200, 24), (500, 503), (500, 499), # 包含两个错误
        (200, 20), (200, 21)
    ]
    
    total_requests = len(log_stream)
    error_count = 0
    
    # 2. 遍历日志统计错误
    # HTTP 状态码 >= 400 视为错误
    for status, _ in log_stream:
        if status >= 400:
            error_count += 1
            
    # 3. 计算错误率
    if total_requests == 0:
        error_rate = 0
    else:
        error_rate = (error_count / total_requests) * 100

    # 4. 判定健康状态
    is_healthy = error_rate < 20.0 # 阈值设为 20%
    
    print(f"总请求: {total_requests}")
    print(f"错误数: {error_count}")
    print(f"错误率: {error_rate:.1f}%")
    print(f"服务状态: {'健康' if is_healthy else '不健康 (触发告警)'}")
    
    return is_healthy

if __name__ == "__main__":
    analyze_service_health()

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252

# 示例3：模拟 OTelBench 中的“资源清理”任务
# 背景：AI 经常在编写具有副作用的操作（如删除资源）时忘记安全检查。
# 此代码演示如何安全地终止运行时间过长的进程。

import psutil
import time

def safe_cleanup_stale_processes(max_lifetime_seconds=5):
    """
    安全清理模拟的僵尸进程。
    在真实场景中，这需要极其严格的权限和名称检查。
    """
    print(f"正在查找运行时间超过 {max_lifetime_seconds} 秒的 'dummy_worker' 进程...")
    
    # 注意：为了演示安全性和避免误删，这里只是模拟逻辑
    # 真实场景下 AI 常忘记检查 process.name() 导致误杀系统进程
    
    found_and_cleaned = False
    
    # 遍历所有进程
    for proc in psutil.process_iter(['pid', 'name', 'create_time']):
        try:
            # 安全检查 1: 确认进程名称
            # AI 常犯错误：直接 kill 所有进程，没有名称过滤
            if 'dummy_worker' not in proc.info['name'].lower():


---
## 案例研究


### 1：某头部电商公司大促保障

 1：某头部电商公司大促保障

**背景**:
该电商公司每年面临“双11”等大促流量洪峰，运维团队需要实时监控数百万个容器和微服务。虽然部署了全链路追踪系统，但在海量数据中，故障定位（MTTR）平均仍需 30 分钟以上。

**问题**:
在引入某基于 GPT-4o 的 AIOps 智能运维助手进行试点时，团队发现 AI 在处理真实的 SRE 任务时表现不佳。例如，在一次模拟的“数据库连接池耗尽”故障中，AI 能够根据监控图表生成通用的排查建议，但无法准确关联底层的 OpenTelemetry Trace 数据，也无法编写出符合公司特定安全规范的 Prometheus 告警规则。AI 经常将网络抖动误判为应用错误，导致误报率高达 40%。

**解决方案**:
团队放弃了单纯依赖 AI 生成排查决策的方案，转而采用“人在回路”策略。他们利用 OpenTelemetry 的强大可观测性能力，优化了 Trace 和 Metrics 的关联，并开发了一套标准化的故障诊断 SOP（标准作业程序）。AI 仅作为自然语言接口，帮助工程师快速检索 SOP 文档和调用预设的自动化脚本，而非直接进行根因分析。

**效果**:
通过强化数据基础而非依赖 AI 推理，故障定位时间从 30 分钟缩短至 5 分钟。虽然 AI 没有直接“解决”问题，但通过辅助信息检索，提升了工程师的响应效率，验证了当前 AI 在复杂 SRE 场景中更适合扮演辅助角色而非决策者。

---



### 2：某跨国金融科技平台日志分析

 2：某跨国金融科技平台日志分析

**背景**:
该金融平台运行在混合云架构上，每天产生 PB 级别的日志数据。为了降低初级工程师的门槛，技术团队尝试引入 Claude Opus 等先进模型来分析分布式系统中的异常日志。

**问题**:
在实际测试中，AI 模型在面对复杂的分布式事务失败问题时显得力不从心。例如，当支付服务出现偶发性超时时，AI 模型（Opus 4.5）无法从错综复杂的微服务调用链中正确识别出是下游第三方汇率接口导致的延迟。它往往只能给出“增加超时时间”或“重启服务”等通用且危险的建议，甚至尝试编写带有逻辑错误的 Python 脚本试图“修复”正常的网络拥塞，这与 OTelBench 测试中 AI 在复杂推理任务上得分低下的现象一致。

**解决方案**:
团队停止了使用 AI 直接分析原始日志的尝试，转而构建了基于 eBPF 和 OpenTelemetry 的深度可观测体系。他们重点优化了上下文传播机制，确保 Trace ID 能够贯穿全链路。同时，他们利用传统统计学算法（如动态阈值检测）来处理异常检测，将 AI 模型限制在用于解释已有的检测结果和生成日报等非关键路径上。

**效果**:
系统误报率降低了 85%。通过放弃让 AI 执行它不擅长的根因分析任务，转而依靠确定性的可观测性工具，平台的稳定性得到了显著提升。这一案例证实了在当前阶段，AI 尚无法替代经验丰富的 SRE 进行复杂故障的定界定位。

---
## 最佳实践

## 最佳实践指南

### 实践 1：构建以可观测性为核心的基础设施

**说明**: OTelBench 的测试结果显示，即便是目前最先进的模型（如 Opus 4.5），在缺乏上下文的情况下也难以准确解析系统状态。SRE 任务高度依赖于系统的实时状态、日志链路和指标数据。单纯依赖 AI 的代码生成能力而忽视数据管道的建设是本末倒置。

**实施步骤**:
1. 部署 OpenTelemetry (OTel) 收集器，确保三大支柱（Metrics、Logs、Traces）的数据被统一采集。
2. 建立标准化的元数据标签体系，确保 AI 工具能够通过语义化标签理解服务间的依赖关系。
3. 验证数据质量，确保输入给 AI 分析的数据是完整且未经过度采样导致失真的。

**注意事项**: AI 无法分析它看不到的数据。在引入 AI 辅助运维之前，必须先解决数据孤岛问题。

---

### 实践 2：实施“人在回路”的验证机制

**说明**: Opus 4.5 仅有 29% 的得分表明 AI 在处理复杂 SRE 任务时存在极高的幻觉或逻辑错误风险。将关键运维操作（如删除资源、修改路由规则）完全交给自动化 AI 是极其危险的，必须保留人工确认环节。

**实施步骤**:
1. 设计 AI 辅助运维的工作流时，将“生成计划”与“执行计划”分离。
2. 强制要求 AI 在执行变更前生成差异对比报告，并由 SRE 审批。
3. 建立回滚机制，确保当 AI 的建议导致故障时能迅速恢复。

**注意事项**: 不要信任 AI 生成的 Bash 脚本或 Kubectl 指令直接在生产环境运行，必须先在沙箱环境验证。

---

### 实践 3：建立标准化的故障排查知识库

**说明**: AI 模型缺乏特定企业内部架构的私有知识。OTelBench 中的失败案例往往源于 AI 无法理解特定系统的行为模式。通过构建高质量的 RAG（检索增强生成）知识库，可以显著提升 AI 的任务完成率。

**实施步骤**:
1. 整理历史故障复盘报告，将其转化为结构化数据（如 Markdown 格式）。
2. 将运行手册与可观测性数据关联，建立“症状-解决方案”的映射索引。
3. 定期更新知识库，剔除过时的运维流程，防止 AI 学习到错误的逻辑。

**注意事项**: 知识库的颗粒度决定了 AI 的表现。避免将大段未处理的日志直接投喂给模型，应提供经过摘要和关键信息提取的高质量上下文。

---

### 实践 4：采用思维链推理模式

**说明**: 简单的“问答式”提示词容易导致 AI 跳过关键的分析步骤。对于 SRE 任务，应强制 AI 展示其推理过程，即它是如何从日志或指标中得出结论的，这不仅能提高准确率，也便于人工审查。

**实施步骤**:
1. 在 Prompt 工程中，明确要求 AI “逐步思考”。
2. 要求 AI 在给出结论前，先列出它观察到的异常指标、相关日志片段以及可能的假设。
3. 让 AI 自我反思：“在执行此操作前，我是否遗漏了哪些检查点？”

**注意事项**: 思维链虽然增加了 Token 消耗，但能显著降低 AI 在复杂根因分析（RCA）中的错误率。

---

### 实践 5：专注于特定领域的微调而非通用任务

**说明**: 通用大模型在理解特定云原生概念（如 Kubernetes 控制器逻辑、Istio 流量管理）时往往表现不佳。针对特定工具链进行微调的小模型，在 SRE 特定任务上的表现往往优于通用的超大模型。

**实施步骤**:
1. 收集特定工具（如 Prometheus, Grafana, Kubernetes）的官方文档和社区问答数据。
2. 针对特定场景（如“Pod 无法启动”或“数据库连接池耗尽”）训练或微调模型。
3. 将微调后的模型作为 Copilot 集成到内部运维平台中。

**注意事项**: 微调数据必须包含错误的案例和正确的修正方案，帮助模型学习如何纠错，而不仅仅是学习正确的语法。

---

### 实践 6：设定明确的 AI 辅助边界

**说明**: 既然 AI 在简单 SRE 任务上的得分依然较低（29%），说明其目前尚不具备独立处理故障的能力。明确界定 AI 的适用范围是避免灾难性故障的关键。

**实施步骤**:
1. **允许 AI 执行**：查询状态、过滤日志、生成基础监控面板、编写非破坏性的脚本。
2. **禁止 AI 执行**：删除数据、修改生产环境数据库 schema、变更核心网络配置、执行涉及数据隐私的操作。
3. 在运维平台中通过 RBAC（基于角色的访问控制）限制 AI Agent 的权限。

**注意事项**: 随着模型能力的提升，边界可以动态调整，但始终应遵循“最小权限原则”。

---
## 学习要点

- 即使是 Opus 4.5 这样的顶尖模型，在处理简单的 SRE 运维任务时得分也仅为 29%，揭示了当前 AI 在复杂系统运维领域的巨大局限性。
- OTelBench 基准测试通过引入 OpenTelemetry 数据，为客观评估 AI 模型在可观测性和故障排查方面的能力提供了新的标准。
- AI 模型在理解上下文和执行多步推理方面存在显著困难，往往难以将日志、指标和追踪数据有效关联起来定位根因。
- 研究表明 AI 在处理需要精确技术细节的任务时容易产生幻觉，导致错误的诊断或无效的修复建议。
- AI 目前尚无法完全替代人类工程师进行自动化运维，最可行的落地方式是作为辅助工具而非独立的决策者。
- 该测试强调了在将 AI 集成到关键运维流程前，必须对其准确性和可靠性进行严格的验证与评估。

---
## 常见问题


### 1: 什么是 OTelBench，它主要测试什么内容？

1: 什么是 OTelBench，它主要测试什么内容？

**A**: OTelBench 是一个专门用于评估大语言模型（LLM）在软件工程和站点可靠性工程（SRE）领域能力的基准测试。该测试侧重于模型处理与 OpenTelemetry（可观测性领域的行业标准）相关任务的能力。这些任务通常包括编写代码、配置追踪系统、分析日志数据以及处理分布式系统中的监控指标等。与通用的编程测试不同，OTelBench 旨在考察 AI 在真实运维场景中解决具体技术问题的实用性。

---



### 2: Opus 4.5 指的是什么？它在该测试中的表现如何？

2: Opus 4.5 指的是什么？它在该测试中的表现如何？

**A**: Opus 4.5 指的是 Anthropic 公司开发的 Claude 模型系列中的特定版本（通常指代其旗舰级模型）。根据该报道，Claude Opus 4.5 在 OTelBench 测试中的得分率仅为 29%。这意味着在面对与 OpenTelemetry 相关的 SRE 任务时，该模型有超过七成的情况下未能提供完全正确或可用的解决方案。这一分数显著低于人们在通用编程任务中对顶级模型的预期表现。

---



### 3: 为什么先进的 AI 模型在处理简单的 SRE 任务时也会遇到困难？

3: 为什么先进的 AI 模型在处理简单的 SRE 任务时也会遇到困难？

**A**: 尽管顶级 AI 模型在通用编程和逻辑推理上表现出色，但在 SRE 任务（特别是涉及 OpenTelemetry）中表现不佳，主要原因包括：

1.  **领域知识的专业性**：OpenTelemetry 涉及复杂的规范、特定的 API 以及多种编程语言和框架的集成细节，通用训练数据中高质量的实操样本相对较少。
2.  **环境依赖性强**：SRE 任务往往需要理解复杂的上下文环境、版本兼容性以及特定的基础设施配置，AI 很难在没有明确输入的情况下推断这些隐含条件。
3.  **精确度要求**：运维任务对代码和配置的准确性要求极高，一个微小的参数错误可能导致整个监控链路失效，而 AI 往往容易产生看似合理但实际无法运行的“幻觉”代码。

---



### 4: 这是否意味着 AI 目前无法胜任 SRE 或运维工程师的工作？

4: 这是否意味着 AI 目前无法胜任 SRE 或运维工程师的工作？

**A**: 是的，目前的测试结果表明 AI 尚无法独立胜任复杂的 SRE 工作。29% 的得分率意味着如果直接依赖 AI 生成解决方案，大部分情况下是错误的，需要人类专家进行大量的调试和修正。然而，这并不意味着 AI 在该领域没有价值。它可以作为辅助工具，用于生成代码框架、解释错误日志或提供文档查询，但最终的决策和代码验证必须由经验丰富的工程师来完成。

---



### 5: 该测试结果对 OpenTelemetry 社区和开发者有什么启示？

5: 该测试结果对 OpenTelemetry 社区和开发者有什么启示？

**A**: 这一结果揭示了可观测性工具的复杂性以及 AI 在该领域的应用潜力。对于 OpenTelemetry 社区而言，这意味着需要提供更清晰、结构化且易于机器学习的文档和示例。对于开发者而言，在使用 AI 辅助处理 OTel 相关任务时，需要保持警惕，不能盲目信任生成的代码，必须进行严格的测试。这也激励了 AI 研发者去优化模型在处理特定技术栈和长尾技术文档时的能力。

---
## 思考题


### ## 挑战与思考题

### ### 挑战 1: [简单]

### 问题**: 在 OpenTelemetry (OTel) 的数据模型中，Trace（追踪）由多个 Span（跨度）组成。请列举出构成一个完整 Trace 调用链的 Span 必须包含的三个核心字段，并解释它们在关联父子关系时的作用。

### 提示**: 回顾 OTel 规范中关于 SpanContext 的定义，思考如何在一个分布式系统中唯一标识一段代码片段，以及如何将它们串联成一棵树。

### 

---
## 引用

- **原文链接**: [https://quesma.com/blog/introducing-otel-bench](https://quesma.com/blog/introducing-otel-bench)
- **HN 讨论**: [https://news.ycombinator.com/item?id=46811588](https://news.ycombinator.com/item?id=46811588)

> 注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

---


---
## 站内链接

- 分类： [AI 工程](/categories/ai-%E5%B7%A5%E7%A8%8B/) / [系统与基础设施](/categories/%E7%B3%BB%E7%BB%9F%E4%B8%8E%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD/)
- 标签： [Opus 4.5](/tags/opus-4.5/) / [OTelBench](/tags/otelbench/) / [SRE](/tags/sre/) / [基准测试](/tags/%E5%9F%BA%E5%87%86%E6%B5%8B%E8%AF%95/) / [AI 编程](/tags/ai-%E7%BC%96%E7%A8%8B/) / [可观测性](/tags/%E5%8F%AF%E8%A7%82%E6%B5%8B%E6%80%A7/) / [OpenTelemetry](/tags/opentelemetry/) / [模型评估](/tags/%E6%A8%A1%E5%9E%8B%E8%AF%84%E4%BC%B0/)
- 场景： [AI/ML项目](/scenarios/ai-ml%E9%A1%B9%E7%9B%AE/)

### 相关文章

- [🔥软件工程的未来是SRE！揭秘技术演进的核心方向🚀](/posts/20260126-hacker_news-the-future-of-software-engineering-is-sre-14/)
- [MortalMATH：当推理目标遇上紧急语境，冲突何解？🧠🔥](/posts/20260127-arxiv_ai-mortalmath-evaluating-the-conflict-between-reasoni-4/)
- [🚀AssetOpsBench：打破AI基准与工业现实的壁垒！🤝](/posts/20260127-blogs_podcasts-assetopsbench-bridging-the-gap-between-ai-agent-be-9/)
- [⚡️俄罗斯方块爆杀Opus！Gemini Flash胜率66%震撼实测🎮](/posts/20260127-hacker_news-show-hn-tetrisbench-gemini-flash-reaches-66-win-ra-13/)
- [🇦🇪 Alyah ⭐️：揭秘阿拉伯LLM方言鲁棒评估！](/posts/20260128-blogs_podcasts-alyah-toward-robust-evaluation-of-emirati-dialect--1/)
*本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。*