3.1 数据基础设施领域的 RAG
运维 智能体 背景
在数据基础设施领域，有很多运维 SRE，每天会接收到大量的告警，因此很多时间来需要响应应急事件，进而进行故障诊断，然后故障复盘，进而进行经验沉淀。另外一部分时间又需要响应用户咨询，需要他们用他们的知识以及三方平台工具使用经验进行答疑。
因此我们希望通过打造一个数据基础设施的通用智能体来解决告警诊断，答疑的这些问题。
严谨专业的 RAG
传统的 RAG + Agent 技术可以解决通用的，确定性没那么高的，单步任务场景。但是面对数据基础设施领域的专业场景，整个检索过程必须是确定，专业和真实的，并且是需要一步一步推理的。
右边是一个通过 NativeRAG 的一个泛泛而谈的总结，可能对于一个普通的用户，对专业的领域知识没那么了解时，可能是有用的信息，但是这部分对于数据基础设施领域的专业人士，就没有什么意义了。因此我们比较了通用的智能体和数据基础设施智能体在 RAG 上面的区别：
- 通用的智能体：传统的 RAG 对知识的严谨和专业性要求没那么高，适用于客服，旅游，平台答疑机器人这样的一些业务场景。
- 数据基础设施智能体：RAG 流程是严谨和专业的，需要专属的 RAG 工作流程，上下文包括 (DB 告警 -> 根因定位 ->应急止血 ->故障恢复)，并且需要对专家沉淀的问答和应急经验，进行结构化的抽取，建立层次关系。因此我们选择知识图谱来作为数据承载。
知识处理
基于数据基础设施的确定性和特殊性，我们选择通过结合知识图谱来作为诊断应急经验的知识承载。我们通过 SRE 沉淀下来的应急排查事件知识经验 结合应急复盘流程，建立了 DB 应急事件驱动的知识图谱，我们以 DB 抖动为例，影响 DB 抖动的几个事件，包括慢 SQL 问题，容量问题，我们在各个应急事件间建立了层级关系。
最后通过我们通过规范化应急事件规则，一步一步地建立了多源的知识 -> 知识结构化抽取 -> 应急关系抽取 -> 专家审核 -> 知识存储的一套标准化的知识加工体系。
知识检索
在智能体检索阶段，我们使用 GraphRAG 作为静态知识检索的承载，因此识别到 DB 抖动异常后，找到了与 DB 抖动异常节点相关的节点作为我们分析依据，由于在知识抽取阶段每一个节点还保留了每个事件的一些元数据信息，包括事件名，事件描述，相关工具，工具参数等等，
因此我们可以通过执行工具的执行生命周期链路来获取返回结果拿到动态数据来作为应急诊断的排查依据。通过这种动静结合的混合召回的方式比纯朴素的 RAG 召回，保障了数据基础设施智能体执行的确定性，专业性和严谨性。
AWEL + Agent
最后通过社区 AWEL+AGENT 技术，通过 AGENT 编排的范式，打造了从意图专家 -> 应急诊断专家 -> 诊断根因分析专家。
每个 Agent 的职能都是不一样的，意图专家负责识别解析用户的意图和识别告警信息诊断专家需要通过 GraphRAG 定位到需要分析的根因节点，以及获取具体的根因信息。分析专家需要结合各个根因节点的数据 + 历史分析复盘报告生成诊断分析报告。
三、总结
建议围绕各自领域构建属于自己的领域资产库包括，知识资产，工具资产以及知识图谱资产
- 领域资产: 领域资产包括了领域知识库，领域 API，工具脚本，领域知识图谱。
- 资产处理，整个资产数据链路涉及了领域资产加工，领域资产检索和领域资产评估。
- 非结构化 -> 结构化：有条理地归类，正确地组织知识信息。
- 提取更加丰富的语义信息。
- 资产检索：
- 希望是有层级，优先级的检索而并非单一的检索
- 后置过滤很重要，最好能通过业务语义一些规则进行过滤。
