16  RAG、语义层还是知识图谱

本章产出： 一棵按问题类型选择结构化查询、RAG、语义层与知识图谱的决策树，以及可分阶段演进的组合架构。

企业讨论 AI 数据架构时，常把几个概念放在同一场竞赛中：有人认为把文档接入 RAG 就足够，有人主张所有问答都必须经过语义层，也有人相信知识图谱才能解决幻觉。争论之所以难有结论，是因为它们解决的不是同一类问题。

RAG 擅长从文本证据中找到与问题相关的内容；语义层擅长把业务指标、实体和口径映射为确定计算；知识图谱擅长表达与遍历复杂关系；结构化 API 则适合返回当前事实和执行业务规则。企业问题通常横跨多种形态，正确选择不是押注单一路线，而是识别每一步需要什么确定性、关系和解释。

16.1 先问问题，不先问技术

架构决策从问题的“答案形状”开始：

  • 答案是一段制度、说明、案例或操作方法吗；
  • 答案是一个当前数值、状态、日期或计算指标吗；
  • 答案需要沿多个实体关系进行影响分析吗；
  • 需要严格复现计算口径吗；
  • 数据变化速度和历史版本要求如何；
  • 错误答案的代价与解释要求多高；
  • 用户是探索信息，还是准备执行动作。

如果问题是“维修手册怎样解释 E37”，文本检索是自然入口；“当前可用库存是多少”应查询权威服务；“过去一季度某区域首次修复率”应使用语义指标层；“某零件批次影响哪些客户、设备、手册和未结工单”适合关系遍历。一个售后诊断任务可能依次使用四者。

16.2 RAG 的边界

RAG 通过检索外部证据约束生成，能提高企业知识问答的时效和可引用性。它适合长文本、经验案例、自然语言改写和无法预先穷举的问题。文档更新后重建局部索引，通常比重新训练模型灵活。

但 RAG 不等于事实数据库。向量相似说明表达接近，不说明业务条件相同；文本块可能来自旧版本、错误型号或无权范围；Top-K 召回无法保证全部必要条件都出现；生成模型即使看到正确证据，也可能外推。RAG 的可靠性依赖文档版本、适用元数据、混合检索、权限过滤、引用校验和拒答。

适合 RAG 的条件包括：主要知识存在于文档和案例；答案需要解释而非精确计算；可通过引用让用户核查；错误时能够拒答或人工确认。若任务需要交易一致性、精确聚合或复杂多跳关系，RAG 应与其他服务组合。

16.3 语义层的价值

语义层把物理表转换为业务能够理解的实体、维度、指标和关系。它让“收入”“活跃客户”“首次修复率”等概念拥有统一公式、粒度、时间窗口、过滤和负责人。Agent 不必猜哪张表、怎样连接，也不能随意编造计算口径。

对于自然语言分析，语义层提供受控查询空间：模型负责理解用户意图并生成语义请求，确定性引擎负责执行。返回结果附指标定义、时间范围和版本。相比开放式 Text-to-SQL，它降低物理模式耦合和越权风险。

语义层的成本是建模和治理。不是所有临时问题都值得提前建模，复杂领域也可能存在多个合法口径。应从高价值、反复使用、需要一致解释的指标与实体开始。语义层若只服务 BI 而不通过 API 或工具向 Agent 开放，也无法形成上下文能力。

16.4 知识图谱的价值

知识图谱显式表达实体与关系，可以回答多跳、路径和影响问题。它适合关系密集、别名众多、连接跨系统且路径本身需要解释的场景。例如从某供应商批次沿零件、物料清单、设备、客户和工单分析影响范围。

图谱还可帮助实体解析和检索过滤：用户提到产品俗称时映射到正式型号，沿“适用”关系限制手册，沿组织关系判定客户范围。图检索与向量检索可以结合，先用语义找到候选实体，再沿可信关系扩展证据。

图谱的主要成本不在图数据库，而在关系建模、来源、时间和维护。现实关系会变化，边要有有效期、置信度和所有者。若问题只需单文档解释，建设全域图谱可能得不偿失。图谱应由真实问题和可持续数据源驱动，而不是为了拥有一张漂亮关系图。

16.5 结构化查询与业务 API 是底座

讨论三种技术时容易遗漏最朴素的答案：很多事实应由业务 API 或结构化查询提供。权限、库存、订单状态、当前配置、价格和审批结果需要权威、及时、确定。把它们转为文本再检索，只会增加延迟和歧义。

结构化工具应返回字段、单位、时间、来源和错误状态；高风险规则由确定性代码执行。生成模型可以解释结果，但不能重新计算或覆盖。对于分析指标，使用语义层；对于单实体当前事实，使用业务 API；对于历史大规模明细，使用受控查询。

16.6 决策矩阵

维度 RAG 语义层 知识图谱 结构化服务
主要数据 文档、案例 表、指标、维度 实体与关系 当前事实、规则
核心问题 解释与经验 聚合与统一口径 多跳与影响 精确查询与行动
确定性 中，需引用校验 高，计算可复现 取决于关系质量 高
更新 重建块与索引 模型与计算版本 节点边增量 随业务服务
解释 引用原文 公式与口径 路径 字段与规则结果
主要成本 解析、检索评测 领域建模 关系治理 接口产品化

决策树可以概括为：

flowchart TD
    A[问题需要什么答案] --> B{精确状态或动作?}
    B -->|是| C[结构化 API / 工具]
    B -->|否| D{统一指标计算?}
    D -->|是| E[语义层]
    D -->|否| F{多跳关系是核心?}
    F -->|是| G[知识图谱 / 关系服务]
    F -->|否| H[混合检索 RAG]
    C --> I[组合证据与生成]
    E --> I
    G --> I
    H --> I

真实流程允许并行分支，最终由 Agent 根据任务组合，而不是强制每个问题只走一条。

16.7 组合架构

组合架构可以分为五个层次：

  1. 统一身份与策略决定用户在当前目的下能访问什么；
  2. 上下文层提供实体、术语、产品、血缘、质量和可用工具；
  3. 查询规划识别问题类型，拆解为事实、文本、指标和关系子问题；
  4. 专用引擎分别执行结构化服务、语义查询、混合检索和图遍历；
  5. 证据融合与行动门禁处理冲突、引用、拒答和审批。

多种引擎必须共享实体标识、时间语义和权限。否则文本检索中的“设备 A”与图中的节点、API 的资产标识无法连接，组合只会制造新冲突。上下文层是它们的公共地图。

结果融合不能简单把所有输出拼进提示。应对每项结果标注来源、时间、适用范围和质量，检测冲突，并为确定性事实设置优先级。语言模型负责生成符合用户语境的表达，不负责投票决定哪套权威规则有效。

16.8 分阶段演进

第一阶段从最小组合开始。山城精工可使用结构化设备与库存 API，加经过版本过滤的混合 RAG，解决售后诊断。无需先建设完整语义层或知识图谱。

第二阶段，当指标查询重复出现，建设维修指标语义层；当设备、零件、手册之间的适用关系成为主要失败源，建立轻量实体关系。此时数据源和责任已经由首期产品验证。

第三阶段，当多个场景复用客户、设备、产品、供应商等关系，扩展图谱与上下文服务；当更多自然语言分析进入生产，扩大语义模型。每一步都以失败样本、复用价值和运维能力为依据。

不要把 PoC 架构直接宣布为终局，也不要用终局想象拖慢首期。架构决策记录应写明当前选择、未选择方案、触发复审的条件。例如：当超过百分之某类问题需要三跳以上关系且现有检索失败达到门槛时，评估图谱；当同一指标出现多个口径争议时，优先语义层治理。

16.9 评估不同层

组合系统要分层评估。RAG 看召回、排序、引用与无答案；语义层看意图映射、口径、维度和执行结果；图谱看实体解析、关系准确、多跳路径和时间；API 看事实、延迟、权限和稳定性；最终任务看证据融合、业务结果和风险。

若最终答案错误，先判断问题出在规划、某个引擎还是融合。只调整提示词可能暂时遮掩根因。每次变更保留版本和评测，避免一个分支提升却破坏另一个问题类型。

16.10 山城精工示例

用户问：“渝北客户这台 M7 设备为什么反复出现 E37，能否今天带备件解决？”

系统可以：

  1. 从当前工单取得设备标识，调用 API 查询配置、固件和最近告警；
  2. 用型号、版本和日期过滤后，混合检索正式手册与已确认案例；
  3. 沿设备—部件—替代件关系找到候选零件；
  4. 调用库存服务查询当前状态，不把缓存当承诺；
  5. 用规则工具判断保修与安全限制；
  6. 检查证据是否足够，生成带引用的建议；
  7. 只创建工单草稿，库存预留仍需工程师确认。

这里没有任何单一技术独立完成答案。可靠性来自每一类事实进入最适合的引擎，并在统一身份、语义和证据链下组合。

16.11 本章交付物：架构选择 ADR

决策记录至少说明：

  • 目标问题、用户、数据形态和风险；
  • 对精确计算、关系、解释、时效和行动的要求；
  • RAG、语义层、图谱、结构化服务各自承担什么；
  • 统一身份、实体、时间、权限和质量如何贯穿；
  • 未选方案及原因；
  • 建设与运营成本、团队能力和供应商依赖；
  • 分层评测、降级和失败处理；
  • 触发扩展、替换或退役的复审条件。

成熟架构不是选择名词最多的方案，而是让每种技术只承担它擅长的责任。RAG 让文档可引用，语义层让指标可复现，知识图谱让关系可遍历，结构化服务让事实和动作可确定。它们共享上下文与治理，才共同构成企业的 AI Ready 知识访问能力。

对高级数据产品经理和架构师而言，真正需要展示的也不是熟悉多少流行名词，而是能够从问题形态推导技术边界，说明错误发生时由哪一层负责，并用可复审条件控制演进。这样的决策既允许首期快速落地，也为未来复杂度保留了入口。