背景
云观秋毫是一家在可观测性领域帮助用户落地IT故障根因分析的初创企业。产品最开始使用传统的规则引擎来实现分析规则的执行,但是存在可解释性和定制化差等问题,所以2024年我们探索引入了大语言模型,不仅取得了效果上的提升,同时也获得了更好的解释性和可扩展性。2025年,云观秋毫将会把实践经验融入到平台中,研发可观测性智能体编排平台,让用户也能够快速构建可观测性领域的智能体,覆盖更多可观测性数据分析垂直场景。
早在2024年11月,通过多方位实验和测试,团队就已经选型DeepSeek作为智能体背后默认的大语言模型,当时我们已经发现DeepSeek在性能和成本上的优势,但没有料到DeepSeek会如此火爆,下图是我们在社区中介绍功能的聊天记录:
实践效果
先上结论,我们基于大语言模型实现了一个可持续演进的故障定位智能体,该智能体能够执行告警分析和故障定位的能力,该智能体在使用DeepSeek时综合表现优于其他模型(2025年2月结论)。DeepSeek在理解和处理可观测性的各类数据上有着较高的准确率,能够较好地理解专家规则并按照规则分析数据,且具有高性价比的价格,尽管偶尔出现数据幻觉,但经过设计能够达到较高的准确率。
该智能体分析问题的整体流程为:以告警通知作为智能体分析的入口,以告警和异常检测事件作为数据基础,让大模型利用预设的思维链规则分析拓扑和事件数据,以此识别疑似根因节点,最终通过北极星指标确认根因。
使用该智能体,能够显著提高用户在复杂服务依赖场景中进行故障定位的效率,同时智能体在分析问题时提供了更好的解释性和可扩展性。
下图是该智能体分析问题的真实案例:
这里不再赘述细节,如果大家对该智能体感兴趣,欢迎关注和试用“云观秋毫”的“APO”产品,我们在官网提供了更多详细信息。此外,我们正在研发可观测性智能体编排平台,未来用户能够方便地在平台上构建自己的智能体,覆盖除了根因分析以外的更多场景。
为什么选择DeepSeek
大模型选型的考量
在当今的可观测性领域中,运维人员在处理异常问题时,常常需要处理海量的数据进行查询、分析和处理任务。排障过程通常具有流程化、规范化以及经验化的特性,这意味着对于经验不足的运维人员而言,这一过程既耗时又费力。因此,利用大模型的推理能力来简化这一过程显得尤为重要——只需提供自然语言描述的规则和数据,大模型便能像专家一样快速识别问题所在。
1.JSON格式数据的理解
由于大模型存在上下文Token限制,为了确保其能够有效理解可观测性数据,首先必须解决的是数据输入格式的问题。
JSON作为一种结构化数据格式,因其便于从原始数据中提取信息,并结合提示工程(描述JSON数据格式键值对含义)易于被大模型解析而成为首选。
如微服务场景下,服务调用的上下游关系复杂且数据量庞大,通过精简数据并使用嵌套的JSON格式记录这些关系,可以大大简化层级结构,帮助大模型更好地理解和分析数据。
然而,并非所有大模型都能完美解析这种数据形式。经过实际验证发现,如文言一心和参数低于14b的模型等在理解JSON数据时存在障碍,容易出现逻辑错误,如无法正确理解上下游调用关系,或着将调用关系弄反。而豆包、智谱GLM-4 Plus、Qwen2.5-32B及以上版本和DeepSeek则表现出了良好的理解能力。
模型 | 理解JSON数据 |
---|---|
文言一心 | 否 |
参数14b以下的模型 | 否 |
豆包1.5-Pro-256K | 是 |
智谱GLM-4-Plus | 是 |
Qwen2.5-32b及以上 | 是 |
DeepSeek | 是 |
2.自然语言规则执行效果
当大模型能够准确理解可观测性数据后,其还需要具备根据用户提供的自然语言规则进行推理的能力,以定位可能的故障点。然而,部分大模型在执行规则时可能会出现偏离指令的情况。
例如,在APO平台节点中,业务拓扑需通过服务名和端点组合唯一标识,但某些模型在处理过程中会忽略端点数据,造成业务拓扑服务名称不完整导致结果偏差。推理结果中,不同的模型对规则的执行准确率也不同。
对比不同模型的表现,DeepSeek在规则执行准确性方面达到了100%,显著优于其他选项如豆包1.5-Pro-256k(70%)、智谱GLM-4 Plus(90%)以及Qwen的不同版本。
模型 | 规则执行准确率 |
---|---|
豆包1.5-Pro-256K | 70% |
智谱GLM-4-Plus | 90% |
Qwen2.5-32b | 70% |
Qwen2.5-72b | 90% |
DeepSeek | 100% |
3.大模型使用成本
除了考虑模型的推理能力和准确性外,实际业务场景中的使用成本也是不可忽视的因素之一。
尽管像Qwen2.5-72B和智谱GLM-4 Plus这样的模型在推理效果上表现出色,但它们的调用费用相对较高。相比之下,DeepSeek不仅在性能上领先,而且其调用成本相比其他旗舰级模型低至十分之一乃至百分之一(尤其是当命中缓存时),提供了更高的性价比。
虽然像豆包1.5-Pro-256k这样的低价替代品看似经济实惠,但其较低的推理准确率也意味着潜在的效率损失。
每千 Token价格 (输入) | 每千 Token价格 (输出) | |
---|---|---|
Qwen2.5-32b | 0.002 | 0.006 |
Qwen2.5-72b | 0.004 | 0.012 |
智普GLM-4-Plus | 0.05 | 0.05 |
豆包1.5-Pro-256k | 0.005 | 0.009 |
DeepSeek | 0.0005(命中缓存)/0.002(未命中缓存) | 0.008 |
大模型选型的结论
- 从准确率的角度考虑,需要大模型能正确识别JSON数据,同时按照用户指令来执行自然语言的规则。国内符合条件且效果较好的大模型有DeepSeek, Qwen2.5-72b, GLM4-Plus等。
- 同时还需要考虑调用成本,DeepSeek费用远低于其他大模型且缓存机制使得成本进一步下降。
DeepSeek存在的缺陷
尽管DeepSeek在处理可观测性数据、执行自然语言规则方面展现了极高的准确率和卓越的性价比,但它也并非毫无瑕疵。与所有大模型一样,DeepSeek面临着一个较为突出的问题——模型幻觉现象(hallucination)。
这种现象在分析微服务拓扑结构时尤为明显,例如在基于“train-ticket”场景的测试中,简化了复杂的微服务调用关系,仅保留最基本的业务节点进行测试,DeepSeek有时仍会输出一些如“ts-payment-service”这样实际上并不存在于真实数据中的服务名,但这些名称又似乎与“train-ticket”有关。
如何克服这些缺陷
- 调整大模型参数:通过精细调节DeepSeek的生成参数,比如top_p(核采样)和temperature(温度),可以有效控制输出内容的多样性和稳定性。降低temperature值可以让模型倾向于选择概率更高的词汇,从而减少输出的随机性;而适当调整top_p值,则有助于限制词汇的选择范围,进一步确保输出内容的精确度和一致性。
- 优化数据组织方式:为了避免大模型由于数据相似性而产生联想,导致出现不准确的服务名,可以通过改进数据的组织形式来缓解这一问题。具体而言,APO平台使用服务名加端点的方式代替单纯使用服务名标识节点的方法,不仅可以增加数据的独特性,还能显著降低模型因混淆不同数据而产生错误的可能性。
采取上述措施,可以在一定程度上缓解DeepSeek及其他大模型中存在的幻觉问题,提升其在实际应用中的可靠性和准确性。不过值得注意的是,完全消除此类问题可能需要持续的技术进步和对模型架构的深入优化。
展望未来
目前我们实现的智能体主要解决基于拓扑的故障定位场景,在该场景下已经取得了不错的效果。在实践过程中,我们积累了大量开发大语言模型应用的经验,特别是在可观测性领域中如何分析大量异构数据。我们希望这些经验不止停留在团队内部,而是能够与业界一起讨论交流,一同推动大语言模型在可观测性领域的落地。
基于上述实践和经验,我们已经意识到AI Agent可能给可观测性领域带来的颠覆性改变,为了能够让这些经验能够惠及更多人和企业,我们正在研发可观测性智能体编排平台,并将会作为开源项目开源。在该平台中,所有人都能够方便地构建自己的可观测性智能体,覆盖可观测性领域中的更多场景,最终释放人的时间,让智能体替人工作。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。