AIOps实战14大模型做日志分析与RAG排障让经验不再锁在少数人脑子里我是老计。上一篇讲了大模型给运维带来的四样新能力。这一篇落到地上讲两个最成熟、最值得先做的落地场景用大模型做日志分析和排障、用 RAG 搭运维知识库。这两个场景恰好把大模型语义理解和知识整合两大强项用到了实处也是我做 K8sChat 时花心思最多的地方之一。一用大模型读日志把人从逐行看里解放先讲日志分析。前面日志那篇讲过传统方法这里讲大模型怎么增强它。先说个画面。过去排障运维盯着屏幕一行行翻日志从几千上万行里找那几行有用的报错眼睛都看花。这个又苦又低效的活恰恰是大模型的用武之地。大模型能做什么第一读懂并总结。把一段报错日志丢给它它能告诉你这段日志大概发生了什么、报的是什么错、可能是什么问题。运维从逐行读原始日志变成看一份它给的摘要效率天差地别。第二解释晦涩报错。很多报错信息晦涩难懂尤其是不熟悉的组件。大模型往往能解释这个报错是什么意思、常见原因是什么相当于一个随叫随到、什么都懂点的老师傅。第三关联和建议。它不仅能读懂当前日志还能结合它的知识给出可能的排查方向和建议。当然这些建议是参考得人来判断和验证。但要记住上一篇强调的融合思路不可能把海量日志全喂给大模型成本受不了。现实做法是传统方法模板化、聚类、频率分析先从海量日志里粗筛出可疑的一小撮再把这一小撮交给大模型精读、总结、解释。传统方法做漏斗、大模型做精读这是日志分析落地最务实的架构。举个具体的画面感受一下这套配合。某个服务半夜报警日志刷了几万行。传统方法先按频率一算发现某个错误模板在报警前后突然暴增了几十倍一下就把范围缩小到这几百条相关日志再把这几百条丢给大模型它读完告诉你这些错误集中指向某个下游依赖的连接超时建议先查那个依赖的健康状况。你看从几万行到一句可执行的判断传统方法负责快速缩小范围、大模型负责读懂并给结论各出一半力。要是没有前面的粗筛几万行全塞给大模型既贵又慢还容易超出它一次能处理的长度要是没有后面的大模型那几百条还是得人一行行看。两者缺一不可这就是融合的实际意义。二RAG让运维知识活起来第二个场景也是我认为对团队价值最大的用 RAG 搭运维知识库。先说清它要解决的痛点。运维知识有个大问题它是散的、锁死的。一部分在文档和 Wiki 里但常常过时、没人维护、搜不到一部分在历史的故障复盘和工单里但躺在角落没人翻还有很大一部分锁在几个老师傅的脑子里他一请假、一离职知识就断了。结果就是新人遇到问题两眼一抹黑同样的坑不同的人反复踩经验没法有效传承。这是我做运维多年见过的普遍痛点。RAG 就是来解这个的。前面讲框架和大模型时讲过 RAG 的原理这里讲它在运维的用法。核心思想把散落的运维知识文档、Wiki、历史故障、Runbook都收集起来、建成一个知识库当运维提问时先从知识库里检索出相关的内容再连同问题一起交给大模型让它基于这些真实的知识来回答。这样带来的改变是实实在在的新人遇到问题直接问这个报错以前遇到过吗、怎么处理系统从历史故障库里检索出类似案例和当时的解决办法给他答复。老师傅脑子里的、文档里的、历史记录里的经验第一次被盘活成一个随时可问的助手。经验不再锁在少数人脑子里、不再躺在没人看的文档里而是变成了全团队随时可调用的活知识。这个价值怎么说都不为过。三我做K8sChat的RAG体会这块我有实操分享几点做 K8sChat 时关于 RAG 的真实体会都是干货。第一检索质量决定一切。RAG 的效果七分在检索、三分在生成。如果检索这一步没找到真正相关的知识喂给大模型的就是无关内容它答得再流畅也是错的。我做 K8sChat 时在检索上花的功夫比在调大模型上多得多混合了多种检索方式来提高召回和相关性。别以为 RAG 就是把文档一塞、问题一问那么简单检索做不好整个 RAG 就是花架子。这里稍微展开一点我踩过的检索坑。一开始我以为用最常见的向量检索把文档和问题都转成向量、按相似度找就够了结果发现它对一些精确的关键词比如某个具体的错误码、某个特定的资源名反而不敏感明明知识库里有、却检索不出来。后来我把关键词检索和向量检索结合起来用两条腿走路召回率和准确性才明显上去。这个经历让我明白RAG 的检索不是一招鲜往往要针对运维数据的特点既有自然语言描述、又有大量精确的技术标识符做组合和调优。这些不起眼的检索细节才是决定 RAG 好不好用的关键远比换个更强的大模型重要。第二知识库质量是根基。喂进去的知识本身如果是过时的、错误的、混乱的那检索出来的也是垃圾。RAG 不会点石成金它只是把你已有的知识调出来知识本身烂结果一定烂。这又回到了数据治理知识库也要治理、要维护、要更新。第三让答复带出处。让大模型的回答标注它是基于哪些知识来的。这样运维能追溯、能核实而不是盲信一个不知从哪冒出来的答案。有出处的回答才敢用。这和前面反复讲的可解释、可追溯是一脉相承的。第四还是那句结论要人核实。大模型会幻觉即便有 RAG 兜底它也可能答错。尤其在指导操作时把它的答复当作有依据的参考最终判断和执行还得人把关。这也是我做 K8sChat 最深的体会花活好整把基本功做扎实才难、才值钱。RAG 做好了是运维知识管理的一次质变它把死的文档、散的经验变成了活的、可对话的智能。但做好它靠的不是大模型多强而是检索、知识库这些不起眼的基本功。小结这一篇讲了大模型在运维最成熟的两个落地场景一是日志分析大模型能读懂并总结日志、解释晦涩报错、给排查建议把运维从逐行看日志解放出来但要用传统方法粗筛加大模型精读的融合架构控成本。二是RAG运维知识库解决运维知识散落锁死、经验难传承的痛点把文档Wiki历史故障Runbook收成知识库提问时先检索相关知识再交大模型基于真实知识回答让经验从锁在少数人脑子里变成全团队可问的活助手。做RAG的真实体会检索质量决定一切(七分检索三分生成)、知识库质量是根基、让答复带出处、结论要人核实。基本功比花活值钱。下一篇是 LLM for Ops 的重头戏也是我做 K8sChat 的核心运维 Agent 与 Copilot讲怎么让大模型不只是问答而是能安全地执行运维操作。延伸阅读LangChain 官方文档RAG 检索增强生成python.langchain.comLlamaIndex 官方文档数据检索与索引docs.llamaindex.aiGrafana Loki 官方文档日志聚合与查询grafana.com/docs/loki检索增强生成综述可在 arXiv 检索 retrieval augmented generation surveyarxiv.org本文为技术经验分享旨在梳理大模型做日志分析与RAG运维知识库的方法。文中观点结合个人运维与K8sChat实践经验不构成具体产品或采购建议实际落地请结合自身环境评估。