1 为什么要引入DeepSeek故障定位

在讨论这个话题之前，需要先聊一聊传统的基于专家经验的故障定位的思路

这里存在的难点有如下2个：

在各种大模型比如DeepSeek的智能推理出现后，上述2个难点问题就迎来了新的转机

所以是时候重新需要思考下：在大模型的加持下，故障定位到底该如何改进了

2 引入DeepSeek的方案探讨

引入DeepSeek后最初步的设想是：大模型承担更多智能化工作，我们只需要提供数据源即可

整体定位架构就变得非常简单，如下所示：

就是把智能化的工作交给大模型去处理，我们的重点就在于将我们的数据体系向大模型描述清楚，举个例子：

比如从Trace中抽取出了http接口的指标信息，如下所示：

这里就是我们需要把我们的指标体系提供给大模型，让大模型理解这个指标是干什么的，有哪些tags和fields，同理Tracing等其他数据也是类似

思路的本质：我们是需要将故障定位这个问题向大模型描述清楚，同时并不限制大模型的分析思路。因为一旦限制大模型的分析思路，那么我们的限制将成为定位的瓶颈，大模型也失去了智能化的意义，变成了一个执行器而已

这看起来才是一个智能化的架构，不过是一个非常理想的架构，存在哪些痛点呢？

以上述service.http指标为例，各种维度组合下，最近10分钟的Metric，这个数据都可能有几M的大小

基于以上痛点，业内也有基于DeepSeek的故障定位业的实践者，他们的主要思路如下

那在这种方案下，大模型接手的是处理过后大数据，数据量大大减少，确实解决了这个痛点，但是也会有副作用，大模型演变成了一个工作流执行器，失去了智能化的威力

有没有更好的方案：既能解决token的限制，也能充分发挥大模型的智能化呢？

该方案的本质：将基础数据分析这种脏活累活交给Agent，不仅大大降低了大模型的token数，还加快了分析速度，同时又能充分发挥大模型的智力

3 落地方案

落地方案如下所示：

4 实际效果

提前告诉大模型对应的数据体系，以及数据体系中的数据关联和约束

然后当出现告警时，让大模型给出下一步的分析命令

上述大模型给出了要分析的数据，Agent能够从数据源中获取该数据进行初步分析，然后将分析结果发给大模型

大模型针对Agent的响应，综合性分析给出下一步的分析指令

就这样如此往复，最终大模型会给出结束指令

然后让大模型综合分析结论，给出故障树

5 后续展望

这个方案有3个核心关键点：

第一个关键点是我们需要努力的，合理并且简单的数据体系更容易被理解

第二三个关键点是大模型需要进一步优化的。目前的大模型还是存在幻觉和推理不严谨的问题，还需要加一些约束机制，以及在数据体系上花费大功夫来解释到位

不过大模型还在飞速进步，这些工作也会逐步废弃

更多信息请关注 RootTalk故障定位专场 公众号