企业官网建设流程全解析

“大模型运维准确率不到 50%”这个结论，我们团队内部争论了两周。有人说模型不行，有人说是提示词没写好，还有人说评测口径本身就有问题。与其在群里吵，不如直接把 DeepSeek V4 拉上线，把运维里面最常见的 5 类场景各抽 100 个真实样本，统一跑一遍。结果出来之后，数据确实出人意料——不是简单的好或者不好，而是不同场景之间的差距大到离谱。这篇就把我们的评测方法、跑分结果、踩过的坑一次性说清楚。

我先把结论放最前面：在严格判分口径下，5 大场景综合准确率只有 56.4%；但换成宽松口径，直接跳到 72%。这 15.6 个百分点的差距说明什么？说明模型能力没我们想的那么不堪，但也没到能直接放生产环境当自动处置引擎的水平。真正决定“能不能用”的，不是模型本身，而是你怎么定义任务、怎么给上下文、怎么解析输出。下面的内容更适合正在规划 AIOps 落地、或者想搞清楚“大模型到底能在运维里干什么”的团队参考。

1. 先说清楚：为什么很多团队测下来准确率不到 50%

不少团队一上来就拿着大模型去干“故障自愈”这种大而全的活儿，让模型看完日志后直接给出最终处置动作，还要求它把根因、影响范围、恢复步骤一口气全说对。这种任务，模型的回答看着很完整，但细拆下来，每一步错的概率叠加之后，最终准确率很容易掉到 50% 以下。

我见过最典型的例子，是让模型“根据告警信息判断问题原因并给出重启命令”。模型确实给出了一个看起来很专业的命令，但告警里根本没提具体服务名，模型自己脑补了一个，命令就跑不通。这类问题不是模型笨，而是任务边界太宽，信息不足，任何模型都只能“猜”。

还有一个反复出现的坑：评估口径不统一。有的团队把“模型提的思路沾边就算对”，有的团队要求“关键动作完全正确才算对”，两种口径下同一个模型可能一个 70 分一个 30 分。我们这次刻意用两套口径打分，就是为了让结果不被口径绑架。

另外，上下文污染问题特别严重。真实业务日志里往往夹杂着大量无关信息、重复打印、过期的历史告警，直接全部塞给模型，它会抓不住重点。这也是为什么评测时不能随便拿一段日志就开跑，必须做数据清洗和裁剪。

2. 评测设计与场景选取：我们为什么只选了这 5 个场景

很多评测贴上来就列了一大堆场景，但每个场景只有 10 来条测试样本，数据没有可信度。我们这次反着来，每个场景 100 条样本，全部来自过去 6 个月的脱敏生产数据，共 500 条。数据来源包括真实工单、真实的告警事件记录、线上日志片段、已有的监控指标数据。标注由 3 名经验不同的运维工程师独立完成，有争议的样本走仲裁流程，最终保留的都是共识样本。

5 个场景的选取依据就一条：运维日常工作中重复性最高、花费人力最多的场景。不追求覆盖所有运维工作，但求每个场景的用例都足够真实。

具体包括：

每个场景都要严格保持输入只包含“一个任务 + 必要的上下文信息”，系统提示词统一、评测脚本统一。这样做的好处是：任何一条样本结果差，都能追溯到是模型能力问题、还是提示词问题、还是数据问题，不会互相干扰。

这里必须强调一句：我们不是把大模型当搜索引擎用。所有场景都不允许模型联网检索，只能依赖输入上下文。因为生产环境的真实故障往往不在公开网络上，联网检索反而会引入错误信息。这条原则也是后续所有实验结果的前提，如果模型靠检索外部资料才答对，那就不是它在支撑运维。

3. 核心评测过程：从样本构造到判分口径的完整链路

3.1 样本构造与脱敏处理

原始日志里有 IP、主机名、账号信息，直接喂给模型不合适。我们写了一个脱敏脚本，把所有 IP 替换成 10.10.x.x 的保留网段，主机名替换成 node-01、node-02 这种格式，数据库账密、Token 全部替换成占位符。脱敏之后的日志语义不能变，否则评测就没意义。这一步看起来简单，但很考验经验，比如有的日志里 IP 藏在 URL 参数中，有的用户 ID 是纯数字长串，单纯按正则替换会漏掉，得人工抽样核对。

每条样本的格式统一为 JSON 结构：

{ "time": "2025-03-12 14:32:08", "node": "node-07", "level": "ERROR", "content": "connection pool exhausted, waiting for 30000ms, active=50, max=50" }

字段少了，模型分析时上下文不够；字段多了，模型容易被无关字段带偏。经验证，标题、节点、级别、内容这四个字段在多数场景下信息量最大、噪声最小。额外信息有需要时再在任务描述中单独给。

3.2 提示词模板的设计思路

我们尝试过三种提示词风格：

• 短指令式：“请分析以下日志是否异常。”
• 角色扮演式：“你是一名资深 SRE，请分析以下日志。”
• 约束式：“请分析以下日志。如果存在异常，请指出异常类型和可能根因；如果没有异常，请回答正常。不要编造日志中未出现的信息。”

实测下来，第三种效果最稳定。角色扮演式在小样本上略有帮助，但在 500 条全量评测中提升不明显，反而有时会让模型用过于主观的口吻回答。约束式的优势在于它明确告诉模型“不要编造未出现的信息”，这句话直接过滤掉了很多幻觉回答。

我们的提示词模板大致长这样：

你是负责系统稳定性的一线运维工程师。请根据给定的日志片段，判断系统是否出现异常，并给出结论。 要求： 1. 只根据给定信息判断，不要推断日志中未出现的现象。 2. 输出格式严格如下： {"status": "normal|abnormal", "reason": "简短的判断依据", "root_cause": "可能的根因，没有则写无"}

特别注意几个细节：

• 输出格式说明放在提示词后半部分，模型对越靠近末尾的格式约束越敏感。
• 不让模型输出长篇大论，强制用 JSON 结构化，方便后续自动化判分。
• 给到一个明确的状态枚举，省掉一堆概率性描述。模型一旦给出“可能也许大概”这类表述，判断价值会大打折扣。

3.3 参数设置与评测脚本

模型推理参数我们统一固定为：temperature 0.1、top_p 0.9、max_tokens 800、禁用联网搜索。temperature 不设成 0 是留一点采样空间，避免连续多次调用结果完全一致导致判分失真；0.1 的数值在后面的重复实验中也比较稳定。

评测脚本核心思路：逐条读取样本，拼接提示词，调用模型 API，解析输出，判分，记录日志。判分环节用的是独立规则脚本，不依赖模型自身。处理流程如下：

import json, time from openai import OpenAI client = OpenAI(base_url="...", api_key="...") def eval_one(sample, template): prompt = build_prompt(template, sample) resp = client.chat.completions.create( model="deepseek-v4", messages=[{"role": "user", "content": prompt}], temperature=0.1, top_p=0.9, max_tokens=800 ) content = resp.choices[0].message.content return content, parse_to_json(content) results = [] for s in samples: out_text, out_json = eval_one(s, template) correct_strict = strict_check(out_json, s.answer) correct_loose = loose_check(out_json, s.answer) results.append((s.id, correct_strict, correct_loose, out_text)) time.sleep(0.5) # 避免触发限流

判分规则我们做了两套。严格规则要求状态判断正确且根因关键实体一致，比如参考答案是“数据库连接池耗尽”，模型必须命中“连接池”相关关键词才算对，只说“数据库异常”不算；宽松规则只要根因方向性描述一致就算对，比如“资源耗尽导致连接失败”也接受。两个口径一起跑，能同时看出模型的精确能力和语义理解能力。

实测发现，模型偶尔会输出合法的 JSON 但格式错乱，比如字段名变了、大小写不一致、多了引号。我们在解析层做了归一化，先尝试 json.loads，失败则去掉首尾噪声再尝试，都不行就记为解析失败。解析失败的次数本身也是一条很有价值的信息，能反映出格式控制能力。

4. 五大场景实测结果与对比分析

4.1 总览数据

整轮评测跑完后，我们拿到了全套数据。综合下来，500 条样本中严格正确 282 条、宽松正确 360 条，综合准确率分别为 56.4% 和 72%。

按场景拆分的结果很能说明问题：

之前网上流传很广的“准确率不到 50%”说法，如果单看告警归因分析严格口径，确实成立。但如果看工单分类这种任务，准确率接近 80%。把不同场景混在一起谈准确率，是很多结论互相打架的根本原因。

4.2 日志异常检测：超出预期

这是唯一一个让我们感受到模型有“经验感”的场景。给到一段日志，比如“connection pool exhausted, waiting for 30000ms, active=50, max=50”，模型能准确判断出连接池耗尽，并指出可能是慢查询拖垮了连接池。严格准确率 68%、宽松准确率 82% 的成绩，我认为很大程度归功于日志本身的异常特征明显，且领域知识是公开通用的。

失败的 18 条样本也很典型，一类是日志本身非常隐晦，比如只有一条 WARN 级别的“retry times exceed threshold”，没有任何其他信息，人类工程师也无法精准定位根因；另一类是模型把“大量重试”误判为“网络抖动”，但实际上日志中出现过“connection refused”的线索，模型没有串联起来。

这个场景的结论是：大模型适合做日志异常的第一道筛子，能比较准确地圈出“有问题”的日志，但根因定位需要给它更多上下文才能进一步提升。

4.3 告警归因分析：最大的滑铁卢

34% 的严格准确率确实非常难看，但拆开看之后会发现，不是模型完全不行，而是它太容易在根因上“深度跑偏”。

我们给模型输入的是关联告警事件，包含一段时间内多个节点的告警级别、告警类型、发生时间。参考答案中，告警 A 和告警 B 之间有互相触发的因果关系，模型却经常把它们解释为并列关系，给出的根因往往是“磁盘故障”或“网络波动”等笼统结论。很多回答逻辑链条看着顺，但关键节点错了，严格判分直接不给过。

更让人头疼的是，模型缺乏领域语境的常识。比如一条“MySQL slave IO thread stopped”告警和一条“slave SQL thread running”告警同时出现，人类工程师会立刻联想到主从复制中断，但模型会把它解读为主从两边都出了问题，甚至给出“建议检查双机负载均衡”这种完全偏了的结论。

这让我意识到，告警归因本质上不是一个“语言理解”问题，而是一个“因果推理”问题，模型缺的是对特定系统架构的理解。想提升这个场景的准确率，光靠换模型不够，得把系统的依赖关系图、历史故障模式作为附加知识提前注入。

4.4 Shell 命令生成：看得见、用不上

Shell 命令生成这个场景，表面正确率 61%，看起来还凑合。但我逐条检查后，发现一个严重问题：很多命令“人类一看就知道是 AI 写的”——花哨、考虑周全、喜欢加各种管道和变量，但实际执行时会有小时级的问题。

比如让模型“找出最近一小时内修改过的文件并压缩”，它给出了：

find /var/log -type f -mmin -60 | xargs tar -czf /tmp/log_backup.tar.gz

看着没毛病，但实际执行时如果文件过多，xargs 会把命令分成多次执行，导致压缩包损坏。资深运维会加上-I {}或者用tar -czf - $(...)，模型不会自动考虑这些边界情况。

还有一类常见错误是编造不存在的命令参数。比如生成journalctl --since "1 hour ago" --until "now" --no-pager时，模型认为--until和--no-pager是 GNU coreutils 的标准参数，但部分发行版的老版本实际上不支持。输出里命令格式完全正确，实际一跑就报错。

这个场景最后浮出的结论是：Shell 命令生成适合做“初稿生成器”，但不到能直接无人值守落地的程度。想提高可用率，得在输出端接一个命令语法检查器，甚至做 dry-run 验证。

4.5 指标趋势与阈值建议：数学能力暴露短板

指标趋势与阈值建议严格准确率只有 42%，核心问题在于模型的“数值感觉”很差。

我们给模型一组 CPU 使用率时序数据，比如过去 30 分钟每隔 5 分钟一个数据点，模型在描述趋势上基本没问题，能看出“使用率整体上升”，但让它给出具体阈值建议时，它给的值非常离谱。有一次 CPU 使用率数据在 20% 到 45% 之间波动，模型建议把告警阈值设为 8%，这在任何真实环境里都会导致告警风暴。

后来分析原因，模型对数值的分布不敏感，它更多是在“猜一个看合理的数”，而不是基于数据的标准差、均值、峰值进行计算。这个场景里，我怀疑无论换哪个通用聊天模型，都不会有本质改善。除非把数值计算能力外置，比如先让脚本计算分位数再交给模型做结论。

4.6 工单分类与处置建议：稳定性最高的场景

工单分类与处置建议是 5 个场景里最稳的，严格准确率 77%、宽松准确率 89%。这很符合大模型的能力边界——它对“内容分类、意图识别、信息抽取”这类任务天生擅长。

用户工单描述往往有明确的意图，比如“服务器响应很慢，重启后依旧如此”，模型能准确分类到“性能问题”，建议先查负载、再查慢查询、再查磁盘 IO。这类任务对上下文依赖小，答案形式也相对固定，大模型的优势完全发挥出来了。

5. 踩坑实录与排查技巧：这些问题不解决，跑分都是虚的

5.1 模型会编造日志里不存在的内容

日志异常检测场景第一次跑分特别低，后来定位到原因：模型常把日志原文里没有的报错码补出来。比如日志里只有“failed to connect”，模型在根因里写“connect() to 10.10.2.31:3306 failed: Connection refused”，参考答案里可没有这个报错细节。虽然实际环境中可能确实如此，但按我们的严格口径，新增信息就是错误。

解决办法是在提示词里加了一条硬约束：“严禁补充输入中未出现的 IP、端口、报错码，根因描述必须围绕已有信息展开。” 加完之后，幻觉类错误下降了大概 60%。

5.2 输出格式不稳定的连锁反应

跑评测的时候 500 条样本中有 31 条输出无法直接解析成 JSON，占比 6.2%。不是模型乱写，而是它偶尔会在 JSON 前后加解释性文字，比如“根据日志分析，结果如下：{...}”。输出解析一失败，整体准确率直接被拖低。

我们最终的做法是加一层后处理：先把输出内容里第一个{到最后一个}之间的部分截取出来，再尝试解析；解析失败再调用一次模型“请修正以上输出为合法 JSON”，并把 800 的 max_tokens 提到 1200。加了这层之后，解析成功率回到 100%，但需要注意，重试的时间成本和 token 成本都会增加。

5.3 时间感知缺失与日志顺序颠倒

告警归因场景里，模型经常把时间先后关系搞反，比如先出现的网络告警被认为是后一个数据库告警触发的。模型没有“时间先后意味着因果方向”这种常识，它只是在做语义关联。

后来我们在提示词里明确写入“请先按时间从早到晚梳理事件链，再判断因果方向，最终根因必须是最早的、最能解释其他告警的事件。”这个改动让严格准确率从 34% 提升到 41%，但依旧不够理想。说明这类问题需要依赖外部知识或推理增强，单靠提示词修补有上限。

5.4 大量重复日志误导判断

生产环境日志经常每秒刷几十条相同错误，模型一看到大量重复的 ERROR 日志，就会把问题判得很严重，但实际情况往往只是一个小小的运行超时在反复重试。处理方法是输入前先做日志压缩，把完全相同的连续日志合并成一条，并注明重复次数。比如“这条日志在 20 秒内重复出现 150 次”，模型读起来就有概念了，不会再被刷屏式日志带偏。

5.5 上下文长度与滑动窗口

日志异常检测中我们遇到过长日志，单一请求塞不下，直接截断又丢失了关键信息。我们的处理方案是采用滑动窗口切片：按 200 行一个窗口、50 行重叠，先让模型对每个窗口给出局部结论，再把这些结论拼接成“事件汇总”输入给第二层模型做最终判断。这本质上是用两个阶段来模拟人工排查的过程，虽然耗时增加，但长日志场景下的准确率高了不少。

处理方式汇总如下：

5.6 数据安全与隐私是底线

整个评测过程我们坚持在本地脱敏后再调 API，不在线上直接传原始日志。运维日志里往往有真实的账号名、内部 IP、业务数据，这些属于高敏信息，评测阶段就要养成脱敏的习惯。后期如果要私有化部署，建议考虑本地化推理方案，彻底避免数据出域。

6. 我们总结出的经验：怎么把大模型真正用进运维

既然数字都摆出来了，直接说我们服不服：服一半，不服一半。服的是大模型在日志异常检测和工单分类场景下确实已经具备实用价值，尤其是工单分类 89% 的宽松准确率，配合人工复核真的是可以落地的。不服的是告警归因和阈值建议这两个场景，模型明显达到了能力边界，需要靠外部系统补足，单靠换更强的模型也未必能解决。

我的建议是，团队在落地时不要一上来就追求“全自动自愈”，而是把大模型当作“信息压缩器 + 建议生成器”。它的核心价值在于把大量杂乱的日志、告警、工单快速整理成可读的结论，让运维人员能更快定位问题，而不是替代运维人员的判断。

具体来说，可以先把大模型接到以下三个环节：

• 告警聚合后的“首轮解释”：自动生成告警的描述性摘要，给值班人员看一眼就能决定要不要马上介入。
• 工单自动预分类与定级：结合标签体系和历史处置记录，自动给出建议分派对象和优先级，人工确认后执行。
• 日志异常的初筛与聚类：把海量日志先分成“疑似故障”和“正常”两拨，再让运维重点看前者。

想进一步降低人工压力，可以做一个小工具链：模型输出结论 -> 调用命令语法检查器或规则引擎校验 -> 再进入执行队列。这样就发挥了模型的语言理解能力，同时让确定性系统兜底，避免模型幻觉变成线上事故。

最后分享一个我们在工程实现上的感觉：评测不只是为了看一个分数，更是为了搞清楚每个场景的失败边界在哪里。建议每个团队都按“场景 + 样本 + 判分口径”这套方式搭建自己的评测集，跑出来的数字才有参考意义。哪怕只是 50 条样本，也比随口一句“这模型不错”靠谱得多。