1.什么是 AI 知识工程

知识工程的概念出现很久了，但在 AI 这个大背景下再次被提及，主要是因为知识工程所服务的对象发生了变化，即从人变成了 AI 系统。

1.1 人和 AI 使用知识的方式不同

人和 AI 系统使用知识的方式截然不同，主要体现在：

• 知识组织和使用方式不同：在人的认知里，知识是以"语义网络"的形式呈现的，即基于知识所描述的主体，主体之间的关系对知识进行组织和使用，使用时通过都会通过因为…所以这样的逻辑来以理解优先的方式来记忆。AI 则是将知识以“高维向量空间”的形式呈现，靠“数学距离”连接。AI 把“苹果”变成一个坐标点，它离“水果”近，离“橘子”也近。它的连接基于语料库中的共现频率，没有“理解”，只有位置关系的计算。
• 知识运用的幻觉：AI 在很多对结果质量要求很高的行业无法落地的根本原因就是无法承担 AI 幻觉带来的严重后果，这跟 AI 对知识的组织和使用方式有关，即只有知识语义相似性，缺乏人类的逻辑，即使在人类看来一本正经胡说八道的结果，AI 却无法识别。
• 知识的运用上限不同：在 AI 的世界里，只会基于现有的内容进行形式上的重构，而无法基于现有内容无中生有。举个例子，质能方程不是从现有文本里统计出来的，而这正是 AI 的上限。

1.2 AI 知识工程的必要性

正是 AI 和人对于知识的组织、使用方式的本质不同，AI 幻觉等问题，AI 知识工程才是破局关键，通过在大模型之上引入人的本体认知、推理逻辑最终消灭幻觉，让其在行业内落地生根。

2.知识工程的实施路径

2.1 确认本体论的基本路线

知识的背后都有一个隐藏的目标主体，这个主体通常在对话或阅读时不会刻意强调，但这是信息传递时的背景信息，这个背景信息来自信息交换双方对行业的深刻理解。但对于 AI 来说这个背景信息完全是确实的，正是这样的缺失导致基于语义搜索的结果，可能跟用户想要的差十万八千里。

本体论就是给 AI 建立知识的基本世界观，基于这个世界观再来理解用户的输入和对输出进行校准。这种思路下，AI 的输出不再只是一味追求模型参数的数量规模，当本体概念使用得当的情况下，中小模型一样可以发挥出超乎想象的效果。

2.2. 构建基于知识本体的索引

当我们将全部文档向量化并录入到向量知识库之后，这个时候我们就可以开始 RAG 检索了，但此时我们的检索准确率和效率其实是一个概率函数，这个函数还是呈正态分布的。

这里面的破局之策就是搜索之前先进行用户搜索意图识别和搜索词改写，然后先搜索索引，最后再面执行 RAG 搜索，最后一步将 RAG 返回的内容，基于知识本体的约束进行校验。

2.3. 索引和向量一体化管理

这一步本质是最后一步的技术实现，通常的做法是用关系数据库管理知识索引，用向量数据库管理向量化之后的向量数据。国内的数据库厂商，像 OceanBase 数据库提出了一体化管理知识索引和向量数据的思路，即在一张表里面管理知识索引和向量数据，这样的好处：

• 检索效率更高，关系数据和向量数据无需在二者之上建立一个融合处理层，少了这种关联处理逻辑（至少也是在一体化数据库内部处理）
• 一致性维护成本更低，无需担心索引数据和向量数据的更新时不一致问题，即无需通过事务来管理二者的更新状态
• 资源成本更低，两套数据管理机制不同，导致运维管理技术路线不同，而一体化管理之后，只需要一套运维管理技术工具即可

3. 知识图谱的表示方式

3.1. 符号表示法

• RDF（资源描述框架）三元组，这种方式将所有知识被拆解成一张巨大的有向图。它对AI很“硬核”，适合进行严格的图查询（如SPARQL语言）和逻辑校验，
• OWL（网络本体语言）：在 RDF 基础上增加了丰富的数学逻辑（如传递性、对称性、类的不相交性）。它允许AI进行自动分类和一致性检查。例如，定义“父亲”是“男性”且“有孩子”，AI就能自动推断出“张三的父亲”必须是男性。优点是推理能力强，缺点是表达复杂，对大规模动态数据不太友好。

3.2. 向量表示法（深度学习时代的主流）

图神经网络嵌入（如GCN, GraphSAGE）：不仅利用三元组信息，还利用节点的邻域结构来生成表示。每个节点的向量都聚合了邻居的信息，这对AI理解上下文非常关键，在节点分类和链接预测任务上效果极佳。

3.3. 混合表示法（当前的前沿趋势）

为了同时满足“逻辑推理”和“语义理解”，现在的AI系统倾向于将上述两种方法结合。

符号-神经混合表示：典型做法是将符号三元组（如（姚明， 职业， 篮球运动员））输入LLM，生成带有上下文语义的密集向量；同时保留图结构，用于执行多跳路径搜索。AI可以先用向量表示找“语义相似”的候选，再用符号表示做“精确校验”。

超关系/嵌套表示：为了表达复杂事件（如“姚明在2002年以状元身份加入火箭队”），不仅包含主谓宾，还附带了时间、条件等上下文。这种表示通常采用RDF*（RDF星） 或嵌套三元组，配合特定的向量化模型（如GraphRE），让AI能区分“事实”和“关于事实的陈述”。

4. Agent 如何实现推理

4.1. 推理规则

把策略写成AI能“理解意图”的结构化声明，而不是AI需要“执行”的代码逻辑。最友好的表示方法是“意图驱动的策略模板（Intent-Driven Policy Template）”，它本质上是一种受控自然语言 + 结构化参数的混合体。

策略ID: impact_analysis
意图描述: "分析某个节点故障时，会影响到哪些上游依赖方"
触发条件: "用户提问包含'影响范围'、'波及'、'会影响到谁'等关键词"
调用模板:
  图算法: BFS（广度优先搜索）
  起始节点: ${llm_extracted.node_name}   # 由LLM从问题中提取
  搜索方向: inbound                      # 固定值，指向依赖方
  深度限制: 3                             # 默认值，可由LLM调整
  过滤条件: "状态 != '已下线'"           # 固定业务规则
结果期望: "返回受影响节点列表，按业务重要性降序排列"
异常处理: "若深度超过5，提醒用户结果过多，建议加筛选条件"

实际使用流程：
用户问：“支付服务挂了会影响到谁？”
AI读取策略impact_analysis，识别意图匹配。
AI从问题中提取{node_name: “支付服务”}，填入模板。
AI将填好的模板参数传给底层图引擎执行。
引擎返回结果后，AI按“结果期望”格式化输出。

4.2. AIOps 中的实践

在实际AIOps系统中，最成熟的方案是把策略模板库（意图驱动模板）存放在外部配置中心，然后在运行时动态注入到AI的System Prompt中。

具体做法：
策略库：维护一个策略模板目录（如上面的YAML文件），每种推理场景一个模板。

检索注入：当用户提问时，AI先用向量检索或关键词匹配，从策略库中拉取最相关的Top-3模板。

上下文增强：将这些模板以结构化文本形式注入到当前对话的Prompt中，让AI“带装上阵”。

执行闭环：AI根据模板填入参数，调用底层图引擎，拿到结果后格式化反馈。

这种方式的好处是：

策略变更无需改代码，只需更新模板库。
AI只负责“填参数+解读结果”，不负责“实现算法”，各司其职。
新增策略时，只需添加一个新模板，AI自动就能识别和使用（前提是意图描述写清楚）。

策略ID: root_cause_trace
名称: 根因追溯
意图描述: "当某个服务或设备发生告警时，沿依赖关系反向查找导致故障的源头节点"
触发样例:
  - "为什么数据库连不上了"
  - "支付超时的根因是什么"
  - "帮我查一下告警的源头"
调用配置:
  图算法: 反向深度优先搜索（Reverse DFS）
  起始节点: ${llm_extracted.alarm_node}
  搜索方向: outbound（沿DEPENDS_ON反向，即被依赖方）
  深度限制: 5（硬上限）
  剪枝条件: "若当前节点状态为'正常'且其所有子节点均正常，则停止该分支"
  时间窗口: "仅考虑最近1小时内的状态变化"
结果期望: |
  返回根因路径树，每个节点附带：
  - 节点名称、类型、IP
  - 当前状态（正常/告警/故障）
  - 该节点的告警时间（如有）
  - 按时间先后顺序排列路径
异常处理: |
  若深度达到5仍未找到根因，返回已遍历的最深层节点，并提示“可能涉及外部依赖或未建模设备”

4.3. CMDB 数据跟知识图谱映射

将CMDB中的配置项（CI）和关系，通过“映射规范”转化为图数据库中的节点和边，再通过“数据增强”补齐知识语义，最终形成一个可推理、可视化的运维知识图谱。

数据获取模块：这是源头。除了从CMDB的资源管理平台接口导入静态数据，还需要整合历史告警/故障数据、调用链及网络拓扑等动态链路信息。这解决了CMDB数据静态、依赖人工录入的痛点。

CMDB关联拓扑梳理模块：这是核心加工环节。它不仅提取显式关系，还通过聚类分析、日志解析、文本聚类等技术，从海量历史数据中识别新的对象和关系，实现CMDB关联关系的自动发现和补全。

运维知识图谱构建模块：这是具体的“映射施工”环节。它通过模式设计、本体构建、数据清洗、实体识别、关系识别、数据融合、知识推理等一系列技术，将加工后的数据转化为图数据库中的知识图谱。

CMDB管理应用模块：这是价值的出口。构建好的图谱最终要服务于资源对象快速检索、风暴告警关联展示及收敛、故障关联分析及定位等上层运维场景。

在融合过程中，AI技术本身也在被用来解决映射的自动化难题：

实体与关系提取：使用BERT实体识别模型和依存句法分析，可以自动从CMDB和日志中提取设备实体（服务器、交换机）、逻辑组件（微服务）及静态依赖关系（如“服务器A承载服务B”），极大减少人工建模的工作量。

动态关联生成：结合Prometheus监控数据，AI还能生成动态关联关系（如“服务调用延迟与数据库查询量正相关”），让图谱不再是静态的“死图”。

5. 建立推理可观测机制

5.1. 技术层：记录性能与成功率

技术层聚焦于每个推理步骤的元数据（耗时、成功率、Token消耗），目的是做性能监控和成本分析。

统一的数据采集模型（基于OpenTelemetry增强）
推荐在OpenTelemetry的Span（追踪跨度）基础上，扩展自定义属性来记录AI特有的元数据。每个推理步骤（如一次工具调用、一次LLM请求）都是一个独立的Span。

{
  "trace_id": "abc-123-def-456",          // 全链路追踪ID，跨服务唯一
  "span_id": "step-003",                  // 当前步骤ID
  "parent_span_id": "step-002",           // 父步骤ID，构建调用树
  "span_name": "llm_reasoning",           // 步骤类型：llm_reasoning / tool_call / graph_query
  "start_time": "2026-08-15T14:23:01.123Z",
  "end_time": "2026-08-15T14:23:03.456Z",
  "duration_ms": 2333,                    // 核心指标：耗时
  "status": "success",                    // success / failure / timeout
  "error_code": null,                     // 失败时记录错误码，如"RATE_LIMIT"
  "metadata": {
    // AI特有字段
    "model_name": "gpt-4o",
    "input_tokens": 1250,
    "output_tokens": 380,
    "total_tokens": 1630,
    "token_cost_usd": 0.0123,
    "retry_count": 1,                     // 重试次数
    "temperature": 0.7,
    // 运维场景特有
    "target_node_id": "server_web_01",    // 本次推理涉及的目标节点
    "query_depth": 3                      // 图查询深度
  }
}

5.2. 业务层：记录输入输出与溯源

业务层记录的是推理的“内容”，即每一步“想了什么、输入了什么、产出了什么”。这层数据用于后续的人工审计、样本标注、模型优化。

1. 核心设计原则
   可还原：仅凭记录，能完整重放一次推理会话的全过程。

可溯源：每个结论都能追溯到其依赖的原始数据（如CMDB节点ID、文档片段）。

可评估：能方便地提取“输入-输出”对，用于离线评估或人工标注。

2. 数据结构设计（存入Elasticsearch或关系型数据库）
   每条业务记录以步骤（Step）为单位，关联到同一session_id下。

{
  "session_id": "chat_20260815_142301",           // 一次对话会话
  "step_index": 3,                                // 步骤序号
  "step_type": "graph_query",                     // 步骤类型
  "timestamp": "2026-08-15T14:23:02.456Z",
  
  // 核心：输入与输出（业务关键）
  "input": {
    "query_intent": "影响范围分析",               // LLM解析后的意图
    "extracted_entities": {
      "node_name": "支付服务",
      "node_type": "Application",
      "time_range": "last_1h"
    },
    "context": {                                   // 上下文（含历史步骤）
      "previous_nodes": ["nginx_01", "网关服务"],
      "user_question": "支付服务挂了会影响哪些业务？"
    }
  },
  "output": {
    "result_nodes": [                              // 推理结果（结构化）
      {"id": "order_srv", "type": "Application", "risk_level": "high"},
      {"id": "user_srv", "type": "Application", "risk_level": "medium"}
    ],
    "reasoning_path": [                            // 推理路径（用于溯源）
      "支付服务 -> 订单服务 (DEPENDS_ON)",
      "订单服务 -> 用户服务 (DEPENDS_ON)"
    ],
    "confidence": 0.92,                            // 置信度
    "attribution": {                               // **溯源关键**
      "source_docs": ["doc_cmdb_123", "doc_拓扑_456"],
      "graph_subgraph_id": "subgraph_abc",         // 引用的图子集ID
      "query_cypher": "MATCH ... RETURN ..."       // 实际执行的查询语句
    }
  },
  
  // 关联技术层数据（通过trace_id关联）
  "trace_id": "abc-123-def-456",
  "duration_ms": 340,
  "status": "success"
}