OTelBench评测：Opus 4.5在简单SRE任务中得分仅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
38
39
40
41
42
43
44
45

# 示例1：基于阈值的简单告警逻辑
# 模拟 Opus 4.5 在测试中表现不佳的基础规则匹配任务

def check_service_health(cpu_usage, memory_usage, error_rate):
    """
    根据预设的阈值判断服务健康状态。
    这是一个典型的 SRE 规则引擎任务，AI 模型在处理此类明确的逻辑时，
    如果不能严格遵循指令，容易产生幻觉或逻辑错误。
    """
    # 阈值定义
    CPU_THRESHOLD = 80.0    # CPU 使用率阈值
    MEM_THRESHOLD = 85.0    # 内存使用率阈值
    ERR_THRESHOLD = 0.05    # 错误率阈值 (5%)

    is_healthy = True
    alerts = []

    # 检查 CPU
    if cpu_usage > CPU_THRESHOLD:
        is_healthy = False
        alerts.append(f"ALERT: High CPU usage detected: {cpu_usage}%")

    # 检查内存
    if memory_usage > MEM_THRESHOLD:
        is_healthy = False
        alerts.append(f"ALERT: High Memory usage detected: {memory_usage}%")

    # 检查错误率
    if error_rate > ERR_THRESHOLD:
        is_healthy = False
        alerts.append(f"CRITICAL: High error rate detected: {error_rate * 100}%")

    return is_healthy, alerts

# 测试用例
if __name__ == "__main__":
    # 模拟一个高负载场景
    status, messages = check_service_health(cpu_usage=85.5, memory_usage=40.0, error_rate=0.01)
    
    if not status:
        print("Service is UNHEALTHY:")
        for msg in messages:
            print(f" - {msg}")
    else:
        print("Service is healthy.")

 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

# 示例2：解析 Prometheus 格式的文本指标
# 模拟 AI 在处理结构化文本提取时的常见困难

import re

def parse_prometheus_metric(metric_text):
    """
    从 Prometheus 文本格式的指标中提取名称、值和帮助信息。
    AI 经常在正则表达式构建或字符串解析的边界条件上出错。
    """
    # 正则表达式匹配 HELP 行
    help_pattern = re.compile(r'# HELP (\w+) (.+)')
    # 正则表达式匹配 指标行 (名称 数值)
    metric_pattern = re.compile(r'(\w+) ([\d\.]+)')

    result = {
        "name": None,
        "help": None,
        "value": None
    }

    lines = metric_text.strip().split('\n')
    
    for line in lines:
        # 尝试匹配 HELP
        help_match = help_pattern.match(line)
        if help_match:
            result["name"] = help_match.group(1)
            result["help"] = help_match.group(2)
            continue
        
        # 尝试匹配指标数值
        metric_match = metric_pattern.match(line)
        if metric_match:
            # 如果之前没有通过 HELP 获取名称，这里也可以获取
            if not result["name"]:
                result["name"] = metric_match.group(1)
            result["value"] = float(metric_match.group(2))

    return result

# 测试用例
if __name__ == "__main__":
    raw_data = """
    # HELP http_requests_total The total number of HTTP requests.
    http_requests_total 1024.5
    """
    
    parsed = parse_prometheus_metric(raw_data)
    print(f"解析结果: {parsed}")
    
    # 验证解析是否正确
    assert parsed["value"] == 1024.5, "数值解析失败"
    assert "total number" in parsed["help"], "Help 信息解析失败"

  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
253
254
255
256

# 示例3：计算服务可用性 (SLA) 与错误预算
# 模拟 AI 在进行时间窗口计算和百分比转换时的准确性问题

from datetime import datetime, timedelta

def calculate_sla(downtime_events, total_period_hours=720):
    """
    根据停机事件列表计算 SLA 和剩余错误预算。
    
    参数:
    - downtime_events: 停机时长列表（单位：分钟）
    - total_period_hours: 统计总时长（单位：小时，默认720小时=30天）
    
    返回:
    - availability_percentage: 可用性百分比
    - error_budget_remaining: 剩余错误预算百分比
    """
    # 1. 计算总停机时间（分钟 -> 小时）
    total_downtime_minutes = sum(downtime_events)
    total_downtime_hours = total_downtime_minutes / 60.0

    # 2. 计算可用性
    # 公式: (总时间 - 停机时间) / 总时间


---
## 案例研究


### 1：某大型金融科技公司

 1：某大型金融科技公司

**背景**:
该公司拥有复杂的微服务架构，运行在 Kubernetes 集群之上。随着业务迭代速度加快，SRE 团队面临海量监控指标和日志数据，急需利用 AI（如 Opus 4.5 等大模型）辅助进行故障根因分析（RCA），以缩短平均修复时间（MTTR）。

**问题**:
在实际测试中，当生产环境出现延迟飙升时，SRE 团队尝试让 AI 分析 OpenTelemetry 收集的 Trace 数据。然而，AI 模型在面对复杂的 Span 上下文和异常堆栈信息时表现不佳。它无法准确区分“由上游依赖导致的延迟”与“自身服务代码问题”，甚至编造了不存在的服务依赖关系。正如 OTelBench 测试所示，AI 在处理这种需要精确理解系统拓扑和状态的任务时，准确率极低（约 29%），导致工程师不得不花费额外时间去验证 AI 的错误结论。

**解决方案**:
团队放弃了完全依赖 AI 进行自动化故障定性的尝试，转而采用“AI 辅助 + 确定性规则”的混合方案。利用 OpenTelemetry 的标准语义约定，编写了基于 Prometheus 的确定性告警规则（如根据 Error Rate 和 P99 Latency 的简单布尔逻辑）。同时，仅将 AI 用于生成查询语言（如 PromQL 或 SQL）的草稿，并由人工审核后执行。

**效果**:
通过回归到基于规则的 SRE 实践，误报率降低了 90% 以上。虽然 AI 未能直接解决根因分析问题，但将其作为“查询助手”而非“决策者”，使得工程师排查问题的效率提升了约 30%，避免了因 AI 幻觉导致的故障误判风险。

---



### 2：某电商平台 SRE 团队

 2：某电商平台 SRE 团队

**背景**:
在大促活动期间，该平台的流量呈十倍级增长，系统压力巨大。SRE 团队引入了先进的 AIOps 平台，试图利用 LLM（大语言模型）自动解读混沌工程测试中的异常指标，并生成修复建议。

**问题**:
在模拟的“数据库连接池耗尽”故障演练中，AI 模型未能正确识别应用日志中的 `TimeoutException` 和 `PoolExhaustedError` 之间的因果关系。相反，它给出了诸如“增加 Pod 数量”或“重启服务”等通用且无效的建议，这反映了当前 AI 在处理需要深层技术背景和逻辑推理的 SRE 任务时的局限性（与 Opus 4.5 得分 29% 的现象一致）。AI 难以理解简单的分布式系统约束，差点导致了错误的扩容操作，进一步加剧了数据库负载。

**解决方案**:
团队意识到当前 AI 尚不具备独立处理复杂 SRE 场景的能力，转而专注于优化可观测性数据本身。他们使用 OpenTelemetry 对全链路进行标准化埋点，确保 Trace、Metrics 和 Logs 的关联性。对于故障诊断，团队建立了标准化的“Runbook（运行手册）”知识库，并利用传统算法（如动态基线检测）来触发阈值告警，而非依赖 AI 的实时推理。

**效果**:
标准化的 OpenTelemetry 数据使得排查路径清晰可见，结合人工查阅 Runbook，故障定位时间从平均 45 分钟缩短至 15 分钟。这一案例证明，在当前 AI 技术条件下，完善的数据采集标准和确定性流程比依赖不成熟的 AI 推理更具实际价值。

---
## 最佳实践

## 最佳实践指南

### 实践 1：实施“人机协同”的工作流验证机制

**说明**: 鉴于 Opus 4.5 在 SRE 任务中仅获得 29% 的分数，表明当前 AI 模型在独立处理复杂运维任务时存在极高的失败率。企业不应将 AI 视为全自动化的解决方案，而应将其作为辅助工具。必须建立严格的人工审核流程，确保 AI 生成的配置、脚本或诊断结果必须经过经验丰富的工程师验证后方可执行。

**实施步骤**:
1. 建立 AI 生成内容的代码审查或变更审查制度。
2. 对于生产环境的操作，要求必须由高级 SRE 进行“双人复核”。
3. 记录 AI 产生的错误案例，用于后续提示词优化或作为负面样本训练。

**注意事项**: 即使面对自信度极高的 AI 回复，也要保持怀疑态度，重点检查逻辑漏洞和幻觉。

---

### 实践 2：构建高覆盖率的测试沙箱

**说明**: AI 在处理 SRE 任务时可能会产生看似正确但实际存在逻辑错误的配置。为了防止这些错误直接影响生产环境，必须建立与生产环境高度一致的隔离沙箱。AI 生成的所有变更脚本、监控查询或修复指令，必须先在沙箱中通过全量测试。

**实施步骤**:
1. 利用 IaC（基础设施即代码）工具快速搭建与生产环境拓扑一致的测试环境。
2. 编写自动化测试脚本，验证 AI 生成的操作是否达到了预期的状态（如服务恢复、指标下降）。
3. 只有在沙箱验证通过后，才允许将 AI 方案应用到预发布或生产环境。

**注意事项**: 沙箱数据应进行脱敏处理，但需保留数据结构和分布特征，以避免 AI 在“过于干净”的数据上产生误判。

---

### 实践 3：引入基于 RAG 的知识库增强

**说明**: 通用大模型（如 Opus）缺乏特定企业内部架构、历史故障和特定运维规范的知识。通过检索增强生成（RAG）技术，将企业内部的运维文档、过往工单、Runbook 和监控指标定义注入到 AI 上下文中，可以显著提高 AI 在特定 SRE 任务中的准确率。

**实施步骤**:
1. 整理并结构化存储企业的运维文档、历史故障处理报告和 API 文档。
2. 搭建向量数据库，并建立 AI 与私有知识库的检索接口。
3. 在提示词中强制 AI 仅依据检索到的知识库内容回答，并标注引用来源。

**注意事项**: 知识库必须定期更新，剔除过时的文档，防止 AI 引用错误的旧版配置信息。

---

### 实践 4：采用“分而治之”的任务拆解策略

**说明**: AI 在面对端到端的复杂 SRE 任务时（如“定位并修复内存泄漏”），容易在长链条推理中迷失方向。最佳实践是将复杂的运维目标拆解为微小的、可独立验证的原子任务（如“获取 Pod 列表”、“查询特定 Pod 的 CPU 使用率”），由 AI 逐个执行。

**实施步骤**:
1. 设计一个编排层，负责将高级别的 SRE 目标拆解为工作流。
2. 针对工作流中的每个步骤调用 AI 模型，并获取中间结果。
3. 每完成一个步骤，立即进行状态检查，若失败则回滚或重试，而不是让 AI 继续执行后续步骤。

**注意事项**: 拆解粒度要适中，过细会导致上下文丢失，过粗则无法降低 AI 的出错概率。

---

### 实践 5：建立可观测性工具的语义映射层

**说明**: SRE 任务高度依赖可观测性数据（指标、日志、链路追踪）。AI 往往难以直接理解复杂的 PromQL 或 SQL 查询语法。构建一个语义层，将自然语言需求映射为具体的查询语句，或者将底层数据转化为 AI 易于理解的文本摘要，是提高 AI 诊断能力的关键。

**实施步骤**:
1. 为核心监控指标和日志建立清晰的元数据标签和自然语言描述。
2. 开发中间件，将 AI 生成的自然语言查询转换为数据库或监控系统可执行的代码。
3. 将查询结果以结构化摘要（如“过去 10 分钟错误率上升了 50%”）的形式反馈给 AI，而非直接抛出海量原始数据。

**注意事项**: 确保语义层的权限控制严格，防止 AI 生成越权查询导致敏感数据泄露。

---

### 实践 6：定义安全的操作边界与熔断机制

**说明**: 由于 AI 存在幻觉风险，其在执行破坏性操作（如删除数据库、修改 K8s 核心配置）时极其危险。必须通过技术手段限制 AI 的操作权限，并设置硬性的熔断机制，确保 AI 的失误不会演变成灾难性事故。

**实施步骤**:
1. 实施最小权限原则（RBAC），限制 AI 使用的 Token 或 API Key 仅具有读取或有限写入权限。
2. 在自动化脚本中设置“预检”

---
## 学习要点

- 即使是目前最先进的 AI 模型（Opus 4.5）在处理基础 SRE 运维任务时也表现不佳，准确率仅为 29%，证明 AI 尚无法有效替代人工进行故障排查。
- AI 在涉及复杂逻辑推理和多步骤决策的“根因分析”环节尤其薄弱，这是其导致整体任务失败的主要原因。
- 现有的 AI 缺乏对现代可观测性工具（如 OpenTelemetry）数据的深度理解能力，难以有效利用日志和指标来定位问题。
- 该研究通过 OTelBench 基准测试揭示了 AI 的“幻觉”问题，即模型会自信地生成错误的诊断结论，这在生产环境中极具风险。
- AI 模型在处理简单的信息检索任务时表现尚可，但在需要执行具体操作或编写复杂修复代码的场景下能力急剧下降。
- 该测试结果为业界设定了现实的预期基准，表明当前 AI 技术更适合作为 SRE 的辅助工具，而非独立的自动化解决方案。

---
## 常见问题


### 1: Opus 4.5 具体是指什么模型？它在测试中的表现如何？

1: Opus 4.5 具体是指什么模型？它在测试中的表现如何？

**A**: Opus 4.5 指的是 Anthropic 公司发布的 Claude Opus 4.5 模型。根据 OTelBench 的基准测试结果，该模型在处理简单的站点可靠性工程（SRE）任务时表现不佳，得分仅为 29%。这意味着在面对诸如系统监控、故障排查或日志分析等实际运维场景时，即使是目前最先进的 AI 模型之一，也难以达到人类工程师的准确率和可靠性，距离真正替代人类工作仍有很大差距。

---



### 2: 什么是 OTelBench？它主要用来测试什么？

2: 什么是 OTelBench？它主要用来测试什么？

**A**: OTelBench 是一个专门针对可观测性和 SRE 任务设计的基准测试平台。它主要用来评估大型语言模型（LLM）在处理与 OpenTelemetry 相关的运维任务时的能力。测试内容通常涵盖从日志和指标中提取信息、识别系统异常、分析分布式追踪数据以及进行简单的故障根因分析（RCA）。该基准测试旨在通过标准化的数据集，客观衡量 AI 在实际工程环境中的问题解决能力。

---



### 3: 为什么 AI 模型在处理 SRE 任务时会如此困难？

3: 为什么 AI 模型在处理 SRE 任务时会如此困难？

**A**: AI 模型在 SRE 任务中面临困难主要有以下几个原因：
1.  **上下文窗口限制**：SRE 任务通常涉及大量的日志、配置文件和系统指标，往往超出了模型的单次处理能力。
2.  **逻辑推理与幻觉**：SRE 工作需要严谨的因果推理，而 LLM 本质上是基于概率预测的生成模型，容易产生“幻觉”，即编造不存在的错误信息或给出看似合理但错误的解决方案。
3.  **缺乏实时环境感知**：模型通常是基于静态数据集进行训练和测试的，缺乏对动态变化的复杂生产环境的实时感知能力。

---



### 4: 这个测试结果（29% 的得分）对 AI 辅助运维意味着什么？

4: 这个测试结果（29% 的得分）对 AI 辅助运维意味着什么？

**A**: 这一结果意味着虽然 AI 在编程辅助方面取得了显著进展，但在自主运维领域仍处于早期阶段。29% 的低得分表明，目前的企业还不能放心地将核心 SRE 任务完全交给 AI 自动化处理。它强调了“人机协同”的重要性：AI 可以作为辅助工具帮助工程师快速筛选信息或提供建议，但最终的决策和复杂的故障处理仍必须由经验丰富的工程师来把关。

---



### 5: OTelBench 的测试标准是否过于严苛或不切实际？

5: OTelBench 的测试标准是否过于严苛或不切实际？

**A**: 根据 OTelBench 的相关讨论，其测试任务被定义为“简单的 SRE 任务”，旨在测试模型的基础能力，而非极端复杂的边缘情况。因此，29% 的得分并非因为测试标准过高，而是反映了当前 AI 模型在理解系统架构、处理非结构化数据以及执行精确的技术操作方面存在固有的短板。这也暴露了通用大语言模型在面对特定垂直领域（如可观测性）时的局限性。

---



### 6: 除了 Opus 4.5，其他模型在 OTelBench 上的表现如何？

6: 除了 Opus 4.5，其他模型在 OTelBench 上的表现如何？

**A**: 虽然 OTelBench 的头条新闻聚焦于 Opus 4.5 的 29% 得分，但这通常反映了该领域的一个普遍现象。在类似的 SRE 和运维基准测试中，大多数主流的闭源和开源模型（如 GPT-4 或其他 Llama 变体）往往也面临挑战，得分通常难以达到可直接商用的水平（通常认为需要 80% 以上）。这表明整个行业在提升 AI 的逻辑推理和系统可靠性分析能力方面，还有很长的路要走。

---
## 思考题


### ## 挑战与思考题

### ### 挑战 1: 日志解析与统计

### 问题**：假设有一个包含数千行日志的文件，其中混杂了 JSON、纯文本及带时间戳等不同格式的日志。请编写一个提示词，指导大语言模型从这些非结构化日志中提取特定的错误代码（如 "Error 500"）并统计其出现次数。

### 提示**：在提示词中需明确定义“错误代码”的匹配规则，并指导模型处理格式不一致的情况。同时，必须规定模型的输出格式（例如 JSON），以便于后续程序自动化处理统计结果。

### 

---
## 引用

- **原文链接**: [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/)
- 标签： [LLM](/tags/llm/) / [SRE](/tags/sre/) / [Opus 4.5](/tags/opus-4.5/) / [OTelBench](/tags/otelbench/) / [AI评测](/tags/ai%E8%AF%84%E6%B5%8B/) / [基础设施](/tags/%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD/) / [DevOps](/tags/devops/) / [可观测性](/tags/%E5%8F%AF%E8%A7%82%E6%B5%8B%E6%80%A7/)
- 场景： [大语言模型](/scenarios/%E5%A4%A7%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B/) / [AI/ML项目](/scenarios/ai-ml%E9%A1%B9%E7%9B%AE/) / [DevOps/运维](/scenarios/devops-%E8%BF%90%E7%BB%B4/)

### 相关文章

- [OTelBench基准测试：Opus 4.5在简单SRE任务中得分仅29%](/posts/20260129-hacker_news-otelbench-ai-struggles-with-simple-sre-tasks-opus--5/)
- [Opus 4.5 在 OTelBench 基准测试中得分仅 29%](/posts/20260129-hacker_news-otelbench-ai-struggles-with-simple-sre-tasks-opus--1/)
- [🔥软件工程的未来是SRE！揭秘技术演进的核心方向🚀](/posts/20260126-hacker_news-the-future-of-software-engineering-is-sre-14/)
- [中国开源AI生态的架构选择：超越DeepSeek的构建路径](/posts/20260129-blogs_podcasts-architectural-choices-in-chinas-open-source-ai-eco-8/)
- [AI代码审查泡沫来了？🫧 揭秘背后的真相！🤯](/posts/20260127-hacker_news-there-is-an-ai-code-review-bubble-16/)
*本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。*