4.3 知识图谱与外部系统集成
4.3 知识图谱与外部系统集成
本节摘要：对话系统要"办事"，就得接外部资源。本节讲清两类集成：知识图谱（结构化的知识查询）与外部系统（API 调用），以及"对话系统不是孤岛"的核心理解。
上手前先明确
阅读完本节，你应当能够：
- 理解知识图谱的作用
- 集成外部系统 API
- 设计知识查询
- 处理调用失败
- 让对话系统"会办事"
一、问题与直觉
"查航班、下订单、看余额"——这些靠对话系统自己做不到，要接外部系统。对话系统不是孤岛：NLU 听懂需求，DM 决定动作，外部系统完成动作。集成能力，决定对话系统"能办多少事"。
二、核心原理
2.1 两类外部资源
| 资源 | 是什么 | 用途 |
|---|---|---|
| 知识图谱 | 实体与关系网络 | 结构化知识查询 |
| 外部 API | 业务系统接口 | 执行任务 |
2.2 集成流程
💡 关键直觉：外部系统是 DM 的"执行之手"——DM 负责"决定干什么"，外部系统负责"真的干成"。集成层要处理"成功、失败、超时"三种结果。
三、工程实践要点
3.1 集成设计要点
| 要点 | 说明 |
|---|---|
| 接口封装 | 外部调用封装成服务 |
| 超时控制 | 防卡死 |
| 错误兜底 | 失败给替代答案 |
| 权限校验 | 安全边界 |
⚠️ 常见坑：外部调用失败让对话"卡死"或"编造"。查询失败时要么重试、要么明确说"暂时查不到"——别让系统假装查到了。
3.2 知识图谱的用法
图谱存：实体、关系、属性 问答：把问题映射成图查询 示例：北京 → 有哪些景点 → 图谱查询
3.3 集成清单
接口文档清楚吗 超时与失败处理了吗 结果能结构化返回吗 权限与安全做了吗
核心回顾
- 要点一：知识图谱管查询，外部 API 管执行
- 要点二：对话系统不是孤岛
- 要点三：外部系统是 DM 的执行之手
- 要点四：集成三结果——成功、失败、超时
- 要点五：失败要兜底，别编造
- 要点六：权限与安全是集成红线
资源接好了，最后一节选模型——对话管理模型。
深度扩展：图谱问答与 API 封装的落地细节
"知识图谱管查询、外部 API 管执行"——这里把两类集成的实现细节各展开一层，并给出外部调用失败时的处理模板。
图谱问答（KGQA）：知识图谱存的是"实体-关系-实体"三元组。对话系统拿到用户问题后，需要把自然语言映射成图查询。例如用户问"北京有哪些景点"，映射思路是：
实体识别：北京（景点实体） 关系识别：有哪些 → has_attraction 图查询：MATCH (c:City {name:"北京"}) -[:HAS]-> (a:Attraction) RETURN a.name 结果回填：用查询结果组织回复
工程要点：实体要先对齐到图谱里的标准实体（用户说"首都"要映射到"北京"）；关系要和图谱 schema 对得上，对不上就查不出；查询结果要为空的情况提前准备兜底话术。
API 封装的要点：外部系统（订单、航班、余额）都以接口形式暴露。集成层要做的四件事——参数校验（把槽位值转成接口要求的格式与字段）、超时控制（设定超时并决定重试策略）、错误映射（把外部错误码映射成用户能听懂的话术）、安全边界（鉴权与敏感信息脱敏）。一个失败处理的模板：
try: 调用查询接口(带超时) 结果成功 → 格式化返回给 NLG 超时/失败 → 重试 1 次 仍失败 → 明确告知用户 "暂时查不到，请稍后再试" （绝不编造结果）
编造是集成层的红线：查询失败时系统回答"查到有 3 个航班"就是编造，后果比"查不到"严重得多。所有外部结果都要标来源状态，无结果、失败、成功三种状态分开走话术。集成清单最后自检：接口文档是否清楚、超时与重试是否配置、结果是否结构化返回、权限与脱敏是否落实——四关全过，外部集成才算合格。
动手练习：给集成失败设计三种话术
设计"查询失败"场景的完整处理链。场景：用户问航班，外部接口超时。请写出三条话术分别对应：重试一次后仍失败（明确告知查不到，并给替代方案）、结果为空（当天确实无航班）、部分成功（查到部分信息，需说明缺失部分）。写完后检查：三条话术有没有一种情况是"编造结果"——只要系统说了它没查到的数据就算编造，一律禁止。再补一条设计：把失败日志记下来（接口名、参数、错误码、耗时），作为后续排查与外部系统沟通的依据。把这个"三话术 + 一条日志"的模板套用到你熟悉的任何外部调用上，集成层的工程规范就建立起来了。