SLS-Bench: A Benchmark for Incident Log Summarization with Synthetic Observability Data¶
会议: NeurIPS 2026
arXiv: 2610.16412
OpenReview: https://openreview.net/forum?id=764jkex4Xd
代码: https://github.com/dynatrace-research/sls-bench
领域: LLM 评测
关键词: 故障日志总结, 智能体评测, 可观测性基准, 合成数据生成, LLM-as-a-Judge
一句话总结¶
针对真实生产环境故障日志收集成本高且涉及隐私导致的评测缺失问题，本文提出基于真实事后分析报告（Postmortem）驱动的端到端故障日志总结基准 SLS-Bench，包含 90 个异构分布式系统故障任务及大规模合成日志流，并对 14 款主流前沿与开源大语言模型智能体进行了全方位评测与成本-质量 Pareto 分析。
研究背景与动机¶
现代 IT 系统结构高度分布式且复杂，在发生系统故障与停机事件时，运维人员需要面临持续产生的大规模海量日志流。诊断并处置故障要求工程师在成千上万行杂乱日志中快速过滤无关背景噪声、定位关键异常日志、重构跨微服务组件的故障传播链条，并将最终结论整理成条理清晰、具备因果证据支持的故障事后总结报告（Incident Summary / Postmortem）。这一工作是 AIOps 运维生命周期中最耗时、认知负荷最高的核心环节。尽管基于大语言模型（LLM）的智能体展现出端到端自动巡检与故障分析的潜力，但业界一直缺乏能够在真实规模和复杂环境下严谨评估此类智能体故障日志总结能力的基准测试。
这一评测真空的根本瓶颈在于真实生产故障数据的获取极其高昂且受限：真实微服务架构的运行日志通常包含商业机密与用户隐私数据，企业极少公开；同时生产环境中的极端故障样本稀疏，且缺少高水平系统架构师人工撰写的标准参考答案（Ground Truth）。现有日志分析基准普遍对任务维度进行了大幅度简化：Loghub-2.0 局限于日志模板解析；LogQA 与 NLPLog 仅关注单条日志的局部问答；LogSummary 与 LogEval 仅对 10 到 20 行短窗口日志提取关键词或三元组；而 RCAEval 与 OpenRCA 则将评测退化为候选故障根因服务的 top-k 分类或离散字段预测。现存基准无一能够评测智能体从包含数万行真实日志流中端到端推断系统架构、梳理多阶段故障演化并生成完整事故报告的能力。
面对真实日志难以大规模开源的困境，本文提出了基于真实事后分析报告锚定的合成数据生成思路。真实世界中存在大量由工程师在排障后公开发布的高质量事故报告，这些报告详尽记录了所涉及的服务拓扑、技术栈、故障触发动因、时序症状演变及最终根因。核心 idea：以公开发布的真实生产事故报告为事实锚点，通过 LLM 逆向构建形式化的结构化故障模型（Incident Model），进而驱动代码级日志仿真器确定性生成数万行逼真日志流与对应标准参考总结，构建覆盖 90 个异构真实故障场景的端到端日志总结基准 SLS-Bench。
方法详解¶
整体框架¶
SLS-Bench 的整体构建管线由数据源筛选、结构化建模、仿真日志生成、参考答案推导以及多维 LLM 裁判评测五个阶段闭环构成。首先，从公开收集的 343 份事故报告中经去重与严苛 LLM 过滤筛选出 90 份高质量报告；其次，将非结构化自然语言报告通过生成-验证循环（Generator–Verifier Loop）逆向建模为包含静态拓扑、日志模板和分阶段时序的 YAML 故障模型；接着，基于该模型自动生成确定性 Python 仿真器，合成出平均 56k 行的真实结构化 CSV 日志文件；同时从故障模型直接推导出仅包含日志可观测事实的高标准参考报告；最后，待测智能体通过带有状态的 Python 数据分析环境探索日志并提交总结报告，由校准后的双 LLM 裁判按照七大维度细粒度打分。
%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
A["真实事故报告集<br/>343份候选→去重过滤90份"] --> B["基于真实报告的结构化故障建模<br/>推断系统拓扑+日志模板+时序状态机"]
B --> C["生成-验证循环与K次连续验证机制<br/>代码Schema检查+LLM语义保真度双重校验"]
C --> D["确定性日志仿真与低层真实性控制<br/>生成Python仿真器→导出平均56k行日志CSV"]
C --> E["参考总结生成<br/>约束仅表达日志可观测事实"]
D --> F["待测智能体诊断探索<br/>ReAct循环+状态化Python/Pandas工具"]
E --> G["双评委校准与多维对齐评测协议<br/>GPT-5.2中+Sonnet 4.6低联合裁决"]
F --> G
G --> H["评测结果输出<br/>7维分项得分+成本/时延Pareto前沿"]关键设计¶
1. 基于真实报告的结构化故障建模：将高层叙述形式化为可执行模型
针对自然语言事故报告往往缺乏微观配置参数与底层日志格式这一痛点，本文设计了由系统描述（system_description）与动态场景（scenario）构成的 YAML 故障模型。系统描述构建了一个静态微服务有向图，定义各组件（服务、数据库、负载均衡器等）的交互协议以及所发射日志的抽象模板与变量域；动态场景则将事故时序划分为正常基线阶段（Normal）、诱发触发阶段（Trigger）和故障演变阶段（Progression）。为了精确模拟分布式交互，模型显式定义了三类日志发射机制：单次突发（Burst，模拟配置变更或崩溃风暴）、持续背景（Background，模拟周期性健康检查与基础流量）以及跨组件调用路径（Path，携带全局分布式 trace_id，按采样的一跳 \(p_{50}\) 与 \(p_{95}\) 延迟在多个组件间生成有序日志序列）。这种抽象确保了微观日志能够精准还原宏观故障演进。
2. 确定性日志仿真与低层真实性控制：保证日志微观统计特性与逻辑自洽
为将高层故障模型转化为数万行具体日志流，本文利用 LLM 针对每个故障模型生成独立的确定性 Python 仿真代码。仿真脚本将时序场景拆分为分段常数区间，在每个区间内动态调整请求吞吐量倍率（rate_multipliers）与延迟倍率（latency_multipliers），并严格控制模板槽位变量取值的上下文自洽性。例如在正常阶段 HTTP 状态码变量限定在 2xx 范围内，而在故障阶段自动漂移至 5xx/4xx；在同一条调用链（Trace）中，若前序跳步发生超时，后续组件绝不发射成功日志。统计分析表明，SLS-Bench 在日志消息长度、每模板变量数、变量基数等底层统计特征上与权威真实日志集 Loghub-2.0 展现出高度一致的重合度，同时克服了 Loghub 过于机械循环的缺陷，具备更符合分布式高并发特征的交织动态性。
3. 生成-验证循环与 K 次连续验证机制：消除幻觉并确保数据可靠性
所有合成制品（故障模型、Python 仿真器、参考报告）均在生成器-验证器反馈循环中生成，最多允许 20 轮迭代修正。验证层由两部分构成：确定性算法检查（校验 YAML 语法、拓扑连通性、引用完整性与 Python 运行正确性）以及强大的语义验证器（基于 GPT-5.2 high）。论文的核心实验发现，若采用单次验证通过策略（\(K=1\)），被接收的对象在后续二次抽检中复现失败率极高；而当设定连续通过阈值 \(K=10\) 时，模型生成的制品能够达到极其稳定的通过率，有效滤除了由于 LLM 验证器偶然松懈而漏过的约束违背。人工注入非平凡语法与逻辑错误测试表明，该验证器对缺陷的召回率高达 98%。
4. 双评委校准与多维对齐评测协议：平衡评判偏置并锚定可观测事实
评测采用 LLM-as-a-judge 方案。固定评测题目要求模型输出结构包括系统架构、分阶段时序还原、根本原因与因果链诊断、关键证据以及置信度。评委无需阅读数万行原始日志，而是将待评报告与权威参考报告在七大维度进行对照打分：报告结构（Structure）、系统拓扑重构（System reconstruction）、时序分期（Timeline structure）、动态演进（Timeline progression）、故障诊断（Diagnosis）、证据链支撑（Support alignment）以及不确定性表达（Uncertainty）。为消除单一模型偏置，系统构建了涵盖 5 档语义等级的校准集：GPT-5.2（medium）准确率达 90% 但对合理的细节扩充存在轻微苛刻偏置，而 Sonnet 4.6（low）表现出对补充信息的宽容度；两者平均分消除了家族偏置（Spearman 相关系数达 0.98），并将五档定性标签映射至 0.0 到 1.0 的连续综合评分。
一个完整示例：Buildkite 仪表板故障案例（0b9e6bdf）¶
以基准中代号为 0b9e6bdf 的真实事故为例，系统模拟了一个由负载均衡器（ELB）、Rails Web 仪表板集群、中心化 PgBouncer、PostgreSQL RDS 以及 Auto Scaling Group（ASG）构成的 CI/CD 服务：
1. 正常阶段（0-25 min）：用户登录流量以 120 rpm 穿过 ELB、Rails 与数据库，健康检查全部返回 200，日志呈现规律的低延迟请求完成。
2. 故障触发阶段（25-40 min）：RDS 遭遇高并发慢查询饱和，导致 Rails 仪表板应用针对数据库的健康检查连接超时（Healthcheck failed: database ping timeout）。ELB 标记目标实例异常并开始向外部用户返回 503 no_healthy_backends，同时 PagerDuty 报警触发。
3. 故障升级与恶性循环（40-48 min）：ASG 试图自动启动新机器替换不健康的实例，但由于部署脚本配置从故障的 Web 仪表板端点拉取最新代码版本（userdata fetch deploy revision failed），新实例初始化彻底失败并被反复销毁重试，陷入经典自锁环。同时旧实例分片报错 database shard missing shard=one。
4. 人工介入与缓解（48-50 min）：运维人员手动锁定 ASG 容量、切换 AMI 部署源为 S3 独立存储、升级 RDS 规格并将 PgBouncer 改为本地单机池化模式。随后 RDS 指标恢复正常，ELB 503 报错锐减。
待测智能体必须从 43,368 行日志中抽丝剥茧，不仅要识别出数据库负载过高，还必须准确定位 ASG 引导脚本的闭环依赖死锁，方可在诊断与证据链维度斩获高分。
实验关键数据¶
主实验¶
论文在 SLS-Bench 的 90 项基准任务上评估了包含 OpenAI、Anthropic 及主流开源权重（Open-Weight）在内的 14 款代表性大语言模型。智能体统一配备基于 ReAct 范式的状态化 Python/Pandas 代码解释器，单题最多允许 200 次工具调用。下表汇报了各模型的平均得分（得分 \(\in [0, 1]\)）、单题平均花费（美元）以及平均运行耗时（分钟）。
| 模型体系 | 模型名称与配置 | 综合得分（↑） | 单题成本 [$]（↓） | 单题耗时 [Min]（↓） | 效费比 Score/$ | 效率比 Score/Min |
|---|---|---|---|---|---|---|
| OpenAI | GPT-5.4 (high) | 0.73 ± 0.01 | 2.19 | 9.5 ± 1.6 | 0.33 | 0.08 |
| GPT-5.4 (medium)⋆ | 0.73 ± 0.01 | 1.56 | 6.9 ± 1.0 | 0.47 | 0.10 | |
| GPT-5.4 (low)⋆ | 0.67 ± 0.01 | 0.85 | 3.4 ± 0.5 | 0.79 | 0.19 | |
| GPT-5.4 Mini (high)⋆ | 0.61 ± 0.01 | 0.37 | 5.2 ± 1.3 | 1.65 | 0.11 | |
| GPT-5.4 Mini (medium)⋆ | 0.57 ± 0.01 | 0.21 | 3.0 ± 0.7 | 2.71 | 0.18 | |
| GPT-5.4 Mini (low)⋆ | 0.48 ± 0.01 | 0.06 | 0.9 ± 0.1 | 8.00 | 0.53 | |
| GPT-5.4 Nano (high) | 0.44 ± 0.01 | 0.10 | 7.0 ± 1.7 | 4.40 | 0.06 | |
| GPT-5.4 Nano (medium)⋆ | 0.39 ± 0.01 | 0.06 | 3.7 ± 0.9 | 6.50 | 0.09 | |
| GPT-5.4 Nano (low)⋆ | 0.28 ± 0.01 | 0.01 | 1.1 ± 0.2 | 28.00 | 0.22 | |
| Anthropic | Opus 4.6 (high) | 0.61 ± 0.01 | 1.91 | 9.9 ± 2.9 | 0.32 | 0.06 |
| Opus 4.6 (medium) | 0.59 ± 0.01 | 0.71 | 4.1 ± 0.8 | 0.83 | 0.13 | |
| Sonnet 4.6 (low) | 0.58 ± 0.01 | 0.47 | 5.0 ± 1.4 | 1.23 | 0.11 | |
| Sonnet 4.6 (medium) | 0.57 ± 0.01 | 1.02 | 11.1 ± 3.5 | 0.56 | 0.05 | |
| Opus 4.6 (low) | 0.53 ± 0.01 | 0.34 | 2.5 ± 0.5 | 1.56 | 0.21 | |
| Haiku 4.5 | 0.46 ± 0.01 | 0.16 | 2.4 ± 0.5 | 2.88 | 0.19 | |
| 开源权重 | GLM-5 (744B/40B) | 0.49 ± 0.01 | 0.59 | 7.9 ± 3.5 | 0.83 | 0.05 |
| MiniMax-M2 (230B/10B)⋆ | 0.29 ± 0.01 | 0.02 | 3.4 ± 1.1 | 14.50 | 0.06 | |
| Nemotron 3 Super (120B/12B) | 0.29 ± 0.02 | 0.02 | 7.8 ± 5.1 | 14.50 | 0.03 | |
| DeepSeek V3.2 (685B/37B) | 0.27 ± 0.02 | 0.25 | 11.8 ± 6.1 | 1.08 | 0.02 | |
| Mistral Large 3 (675B/41B) | 0.12 ± 0.01 | 0.02 | 0.8 ± 0.4 | 6.00 | 0.13 | |
| Ministral 3 (14B) | 0.12 ± 0.01 | 0.02 | 1.8 ± 1.1 | 6.00 | 0.05 | |
| Qwen3-Next (80B/3B) | 0.10 ± 0.01 | 0.02 | 3.7 ± 1.9 | 5.00 | 0.02 | |
| Nemotron 3 Nano (30B/3.5B) | 0.06 ± 0.01 | 0.02 | 5.1 ± 5.1 | 3.00 | 0.01 |
注：标 ⋆ 为成本-质量 Pareto 前沿最优配置。评判标准中 Good Match 对应分数为 0.75。
消融实验与敏感性分析¶
为了探究智能体工具调用预算对诊断质量的影响，作者在 30 道抽样题库上测试了不同调用预算（0、5、10、25、50 次）下的表现：
| 评估模型与推理配置 | 预算 0 次 | 预算 5 次 | 预算 10 次 | 预算 25 次 | 预算 50 次 | 实际使用调用数 (预算50) |
|---|---|---|---|---|---|---|
| Nemotron 3 Nano | 0.00 | 0.02 | 0.04 | 0.06 | 0.07 | 19.53 |
| DeepSeek V3.2 | 0.00 | 0.09 | 0.17 | 0.20 | 0.29 | 37.10 |
| GPT-5.4 Nano (medium) | 0.00 | 0.19 | 0.31 | 0.38 | 0.40 | 36.83 |
| Haiku 4.5 | 0.00 | 0.32 | 0.40 | 0.41 | 0.43 | 15.50 |
| Opus 4.6 (low) | 0.00 | 0.44 | 0.45 | 0.50 | 0.50 | 10.97 |
| GPT-5.4 (low) | 0.00 | 0.56 | 0.62 | 0.63 | 0.65 | 22.37 |
| GPT-5.4 (high) | 0.00 | 0.58 | 0.64 | 0.70 | 0.71 | 35.52 |
此外，针对评委鲁棒性（Judge Robustness）的语义扰动消融显示： - 保留语义但大幅改写结构（Meaning-preserving）：词重叠 Jaccard 仅为 0.56，GPT-5.2 评分为 0.98，Sonnet 4.6 评分为 0.99，平均达 0.99，证明评委不会因语言表达变异而误判。 - 保留结构与词汇但篡改事实核心（Meaning-altering）：词重叠高达 0.87，但评委评分锐减至 0.14（GPT-5.2）与 0.20（Sonnet 4.6），平均仅 0.17，证明评委对故障因果与事实缺陷极其敏感。
关键发现¶
- 闭源前沿模型主导 Pareto 前沿，开源模型差距悬殊：GPT-5.4 家族覆盖了绝大部分性价比前沿，GPT-5.4 (medium) 在 1.56 美元与 6.9 分钟内达到 0.73 的可靠重构水准（接近 Good Match 阈值 0.75）。开源模型中表现最好的 GLM-5 达到 0.49，而大多数开源模型由于在多轮长工具调用中发生指令遗忘或数据清洗失效，得分均低于 0.30。
- 宏观诊断与微观因果证据呈现能力割裂：细粒度 7 维雷达图显示，高水平模型在宏观因果诊断（Diagnosis）维度几乎接近满分 1.0，能够准确猜中故障类型；然而在时序演变推进（Timeline Progression）和证据支撑对齐（Support Alignment）上明显触顶于 0.7–0.8。模型经常遗漏或误读支撑高层结论的关键日志证据，存在"结论对但依据错"的幻觉风险。
- 探索轨迹存在巨大优化空间（预计算与并行化）：深入分析 GPT-5.4 的探索轨迹发现，21.0% 的 Python 工具输出属于完全可以在模型介入前静态预先计算的日志元数据（如日志总量、时间窗口、错误码直方图、服务拓扑概览等）；且前 29.9% 的探索步骤属于通用的模式探索前缀，后续排障过程完全可以拆解为互不依赖的并行分支（错误追踪、时序聚合、对照组采样），可大幅压缩端到端时延与 API 开销。
亮点与洞察¶
- 将真实报告形式化为合成数据生成器的范式闭环：避开了直接抓取脱敏生产日志的法律合规与稀缺性死结，又避免了无源纯合成数据导致的场景失真，为系统软件可观测性（Observability）领域的基准构建提供了可扩展蓝图。
- 连续 K 轮通过率的验证器工程智慧：实验发现 LLM 验证器在单次检验中极易受到提示词随机性影响而漏判隐蔽 Bug，强制要求通过 10 轮独立无死角验证有效将数据生成良率提升至工业级可用标准。
- 可复用的排障智能体加速策略：发现日志排障中 21% 的命令属于静态元数据侦察，在实际部署运维 Agent 时，可设计"预热缓存 + 并行证据检索"架构，使系统诊断响应速度提升数倍。
局限与展望¶
- 作者承认的局限性：基准规模当前受限于 90 篇公开报告；故障模型侧重于事故相关的最小必要子系统，背景生产噪声与无关干扰服务数量低于真实工业现场（真实场景模板数往往达数百种）；评委通过对比参考报告而非直接检索原始日志打分。
- 潜在改进方向：可进一步引入多模态遥测指标（如 Prometheus Metrics、OpenTelemetry Traces）实现多源遥测关联总结；将生成管线拓展至私有云生产事后报告库，实现企业专属运维基准的自动化定制。
相关工作与启发¶
- vs Loghub-2.0 / LogPAI 系列：后者专注于静态日志解析（Parsing）和局部单点异常检测（Anomaly Detection），输出为离散标记；SLS-Bench 则是端到端的高阶因果重构与长篇事故报告总结。
- vs RCAEval / OpenRCA：现有根因分析（RCA）基准大多将任务定义为分类预测题（预测出具体哪个微服务是根因）；SLS-Bench 要求生成包含背景、时序阶段、证据与置信度的全面工程师可用报告。
- vs AIOpsLab / Cloud-OpsBench：后者依赖在真实微服务靶场进行故障注入，环境部署极其厚重、可复现性易受运行环境抖动干扰；SLS-Bench 通过高保真确定性离线仿真，兼具了场景复杂性、评测轻量化与 100% 结果可复现性。
评分¶
- 新颖性: ⭐⭐⭐⭐⭐（开创性地利用真实事后报告逆向建模生成大规模合成日志流，填补了端到端日志总结基准的空白）
- 实验充分度: ⭐⭐⭐⭐⭐（横跨 14 款主流模型评测，配备细致的消融实验、评委校准与轨迹效率分析）
- 写作质量: ⭐⭐⭐⭐⭐（问题陈述清晰，数学符号与系统架构定义严密，实验报告层次分明）
- 价值: ⭐⭐⭐⭐⭐（代码与数据全部开源，对 LLM 智能体在云原生运维、AIOps 领域的实际落地具有关键评估指引价值）