AI 运维知识库从 0 搭建：90 天，都踩过哪些坑？- 大数跨境

首页

AI 运维知识库从 0 搭建：90 天，都踩过哪些坑？

BizDevOps软件工厂

2026-09-07

导读：至少不会在第 30 天就崩

★ 点击名片，关注我们不迷路 ★

AI 运维知识库这两年热度不低。多数团队（包括我接触过的几个）结局都差不多——前期冲 RAG 选型，后期没人用。

问题出在哪？

不是模型不够强，也不是向量库选错。是前 30 天就开始追技术新词，把”治理”这件脏活累活跳过了。等到第 90 天发现回答全是幻觉、没人愿意维护、最后归档。

下面这条 30 / 60 / 90 路径，是观察多个团队落地后总结出来的——按这个节奏走，至少不会在第 30 天就崩。

阶段一：0-30 天，救命

这个阶段目标只有一个：让知识库先能用。

技术选型？暂缓。先做三件事。

盘点存量。 把 Confluence、Notion、Word、飞书文档里和运维相关的内容全翻一遍，按”高频 SOP / 低频参考 / 已过期”分类。高频 SOP 通常就 20-30 篇，但能解决 80% 的日常问题。
重写核心 SOP。 不是”复制粘贴 + AI 润色”，而是按统一模板重写。多门店 IT 运维有个真实案例，3 个月靠这一招从 0 做到 213 篇可用 SOP。模板长这样：

SOP 标题：[系统名]-[故障现象]-[操作类型] 适用版本：v1.2.3+（写稿时） 前置条件：需要 X 权限 / 必须在 Y 状态执行 操作步骤：   1. ...（每步带预期输出）     2. ... 回滚步骤：... 关联告警：alert_id_xxx 关联 Runbook：wiki/xxx 最后更新：2026-XX-XX（责任人）

注意模板里强制写版本、强制写回滚、强制写责任人。这三项是后面能复盘的命根子。

3. 停止以”文档数量”考核。 这条违反很多管理者的本能，但经验上看是必要的——一旦把数量当 KPI，团队会疯狂产出没人看的复制品，反而把搜索命中率拖垮。急救期的北极星指标应该是搜索命中率（搜索 → 打开 → 解决），0-2 个月先稳住 15%+ 这个基线，3-6 月再推到 25%-50%。

这三件事做完，30 天就过去了。不需要任何 AI。

阶段二：31-60 天，联动

这个阶段目标：让知识库长在流程里，而不是孤岛。

核心动作有两条。

告警卡片嵌 Runbook 短链。 监控告警一弹出，自动带一个”对应 SOP”按钮。值班的人不用切换工具就能点开，路径从”凭记忆找文档”缩短到”告警即入口”。
故障复盘必须更新 Runbook。 这条要写进故障复盘模板里，没有”Runbook 已更新”这一项，复盘报告不算完成。

这两条都依赖事件驱动而不是自觉驱动。自觉驱动在第 30 天就会失效，事件驱动能跑到第 90 天。

还有一条容易忽略：SOP 入口靠近。多门店那个案例提到——原来 SOP 放在 Wiki 三级菜单，值班时根本想不起来；后来放在企业微信群置顶 / 工单系统推荐位，命中率直接翻倍。

阶段三：61-90 天，才到 RAG

到第 60 天，如果前两阶段动作到位——内容质量稳了、流程接上了、有人持续维护了——这时候才适合上 RAG。

RAG 选型的常见误区是盯着 Embedding 模型比来比去。实际上生产环境的检索准确率，70% 以上由 ingestion 阶段决定——chunking、metadata、deduplication 这三件事做好了，用 OpenAI text-embedding-3 还是 BGE，差距不到 5%。

运维场景的 RAG 切片推荐配置：

# 运维 RAG 的典型分块配置（写稿时 v1.0）CHUNK_SIZE = 300    # 字符，运维 SOP 知识点密度高CHUNK_OVERLAP = 50  # 字符，避免切断步骤SEPARATORS = ["\n## ", "\n### ", "\n步骤", "。"]  # 按结构切，不按句切METADATA_FIELDS = [         "system",            # 业务系统    "alert_id",          # 关联告警    "severity",          # P0/P1/P2    "last_verified_at",  # 最后核实时间    "owner_team",        # 责任人]

几个反直觉点：

运维文档别按句切。SOP 里”步骤 1 → 步骤 2”如果被切断，召回时找不到完整操作。
父子分片比单层分片精度高一档 — 子分片（128-256 字符）做向量检索，父分片（512-1024 字符）喂给 LLM。
元数据必须有 severity 和 alert_id。值班场景下，搜”P0 数据库挂”应该只召回 P0 级别的 SOP，不是所有数据库文档。

评估闭环：90% 团队跳过的部分

RAG 上线后第一个月，大多数团队就停止迭代了——因为没有评估指标。

RAGAS 是目前行业里比较成熟的评估工具，指标分三层：

实操建议：

建一个 Golden Question Set（50-100 道高频问题 + 标准答案），每次改完 chunking 或 prompt 跑一遍，对比指标变化。
每周抽 10 个失败 query，人工标注失败原因（检索失败 / 答案生成失败 / 元数据缺失），按原因分布驱动下一轮优化。
幻觉率是底线指标。具体阈值因业务而定（金融 / 医疗会比通用场景更严），但如果幻觉 query 占比稳定在 5% 以下才算能上生产的最低线。

没有这套闭环的 RAG 系统，三个月内一定退化为没人用的摆设。

边界与反方

这套 30 / 60 / 90 路径有几个前提：

团队规模 50 人以上。10 人以下小团队不需要这么重，30 天治理 + 简单 RAG 就够。
有明确运维负责人。没人推动 SOP 重写和事件驱动流程，90 天也会拖成 180 天。
不是”AI 问答替代 wiki”派。这条路短期看快，但 hallucination 风险、长期维护成本、团队知识沉淀能力被弱化三个问题，会在 6 个月后集中爆发。

如果你正准备动手，建议先做一件事：列出团队最近一个月被问最多的 20 个问题，看看现有 wiki 能回答几个。能回答 < 5 个，先别上 AI，把 SOP 补齐再说。

还不过瘾？想了解更多 AI Agent 在运维、SRE 稳定性上的应用实践？1016GOPS2026・上海站，扫码享 9 折优惠👇