AIOps探索：做运维领域的RAG，如何做数据清洗

推荐语

探索AIOps运维RAG的关键：数据清洗是90%效果的保障，掌握7步流程让数据真正发挥价值。

核心内容：
1. 运维RAG中有效数据的5大类型与筛选标准
2. 数据清洗的完整7步流程与关键操作
3. 实战避坑指南：从去重降噪到结构化处理的典型场景解析

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

研究Aiops有一段时间了，目前手里有不少可落地的方案了，接下来会把这些方案全部整理到我的大模型课程里。同时，欢迎大家把你遇到的场景在评论区留言。我会在能力范围内给你提供思路和建议。

上一篇文章说了，做AIOps，不要忽略做运维RAG，但是做RAG的关键在于如何搞到高质量的数据。而数据无外乎来自于各种各样的文档、邮件、工单、故障复盘、IM聊天记录等等。

很多人做 RAG，一上来就研究模型、Embedding、向量库，最后效果却很差。其实90% 的问题，其实出在数据上。

在运维场景里，数据问题更加敏感：

• 告警日志是碎的

• 工单描述是口语化的

• Wiki 文档多年没人维护

• 事故复盘格式五花八门

如果不做数据清洗，RAG 基本等于“高级全文检索”。下面我从真实运维数据类型出发，一步一步拆解：RAG 前，数据到底该怎么清洗？

一、先明确：运维 RAG 的“有效数据”长什么样

在动手清洗之前，先统一一个共识：RAG 不是喂所有数据，而是喂“能回答问题的数据”。

在运维场景里，真正有价值的数据一般是这 5 类：

1. 故障处理记录

• 工单

• 故障单

• 事故复盘（Postmortem）

• 标准化文档

• Runbook

• SOP

• 应急预案

• 配置 & 架构说明

• 架构设计文档

• 服务依赖关系说明

• 高价值日志

• 关键错误日志样例

• 已确认根因的日志片段

• FAQ / 经验总结

• 运维群沉淀

• FAQ 文档

不是所有日志都要进 RAG。原始全量日志，99% 是噪声。

二、数据清洗总流程

我建议把清洗流程拆成 7 个步骤：

 → 数据收集 → 去重 & 降噪 → 结构化 → 语义补全 → 颗粒度切分 → 打标签 → 抽样验收

三、第一步：数据收集要“宁少勿杂”

1️⃣ 常见错误

很多团队一上来就是：

• 全量日志

• 全量工单

• 全量 Wiki

结果是：

• 向量库巨大

• 检索命中率低

• 回答东拼西凑

2️⃣ 正确做法

只收“可复用经验型数据”

数据源	是否建议
事故复盘	✅ 强烈建议
Runbook	✅ 必须
已关闭工单	✅
原始实时日志	❌
临时聊天记录	❌（需整理后）

原则：“这个内容，人能不能照着再处理一次问题？”不能的，先别进 RAG。

四、第二步：去重 & 降噪（这是最容易被忽略的一步）

1️⃣ 去重不只是“完全一样”

运维数据里，高度相似 比完全重复更多：

【故障】kafka 消费延迟【故障】Kafka 消费延迟问题【问题】Kafka 延迟过高

解决方案：

• SimHash / MinHash 做相似度去重

• 相似度 > 0.9 的只保留一条

2️⃣ 必须删除的噪声

清洗时，下面这些直接干掉：

• 时间戳（保留一份即可）

• TraceId / RequestId

• UUID

• IP（除非是网络问题）

• 无意义字段（OK / success / done）

否则会严重干扰向量相似度。

五、第三步：结构化（让模型“看懂”运维经验）

RAG 最怕的不是数据少，而是语义散。

1️⃣ 把“故事”变成“结构”

清洗前（典型工单）：

昨天晚上流量上来后接口开始变慢，后来发现是 Redis 连接数满了，扩容后恢复。

清洗后（结构化）：

问题现象: 接口响应变慢影响范围: 线上核心接口触发条件: 流量突增根因: Redis 连接数耗尽解决方案: Redis 扩容验证方式: 接口延迟恢复

2️⃣ 建议的最小结构

每条数据至少包含：

• 问题现象

• 根因

• 解决方案

没有这三项，不适合进 RAG。

六、第四步：语义补全（非常关键，但很多人不做）

运维文档有个通病：写给“懂的人”看的。

1️⃣ 问题在哪里？

很多文档长这样：

重启服务即可

但 RAG 面对的是：

• 新人

• 模型

• 不知道上下文的用户

2️⃣ 正确补全方式

把隐含信息补全成可检索语义：

原文：

重启服务

补全后：

通过 systemctl 重启 xxx 服务，释放异常连接，恢复服务正常运行

核心原则：让“搜索的人”和“写文档的人”不是同一个人，也能看懂。

七、第五步：切分颗粒度（不要盲目 500 字一段）

很多教程说：

每 300～500 字切一段

在运维场景，这很容易翻车。

1️⃣ 正确切分标准

以“一个完整运维动作”为最小单位

比如：

• 一个故障 + 一个根因 + 一个解决方案

• 一个告警 + 一个处理流程

不要跨问题切分。

2️⃣ 推荐做法

• 事故复盘：按「问题」切

• Runbook：按「步骤」切

• FAQ：一问一答一段

八、第六步：打标签（让 RAG 更“聪明”）

标签不是给人看的，是给检索阶段用的。

1️⃣ 必打标签

• 业务系统（kafka / redis / mysql）

• 故障类型（性能 / 可用性 / 配置）

• 影响级别（P0 / P1 / P2）

• 操作风险（是否可自动化）

2️⃣ 示例

{  "system": "Redis",  "fault_type": "性能",  "level": "P1",  "auto_fix": false}

有标签的 RAG，命中率可以直接翻倍。

九、第七步：抽样验收（别让模型背锅）

最后一步一定要做人工验收。

1️⃣ 验收方式

随机抽 50 条数据，问 3 个问题：

1. 人能不能看懂？

2. 单独拿出来有没有歧义？

3. 如果我是新人，能不能照着做？

2️⃣ 一个硬指标

如果你自己都不想搜这条数据，那模型也不该用它回答。

十、总结一句话

运维 RAG 的本质，不是“让模型更聪明”，而是“逼运维把经验写清楚”。

只要你把：

• 噪声清掉

• 经验结构化

• 语义补完整

• 颗粒度切对

模型、Embedding、向量库，反而都是次要的。