企业AI决策图谱：让每个AI结论可追溯可审计

从RAG到决策图：企业AI的可审计性挑战

当企业Agent给出"建议暂停向供应商A下单，当前履约风险过高"这样的结论时，最危险的不是答错，而是无法回答三个关键问题：这个结论依据哪几份合同和质检报告？哪些数据已过期？三个月后如何复原判断过程？

传统RAG擅长从文档中检索相似文本，却无法天然回答这些问题。当AI从生成内容走向影响采购、财务审核、客服升级等真实业务动作时，企业需要的不只是任务图，更需要一张决策图谱——连接事实、证据、规则、责任人与结果的可查询网络。

RAG与决策系统的五层差异

传统RAG的工作流程简单高效：文档切块、转向量、召回语义相近片段、组织答案。这适合回答"差旅报销标准是什么"这类事实性问题，但当问题变成"该不该做某事"时，复杂度陡增。

五层对比维度揭示了核心差异：

1. 检索来源：RAG找相似文本，决策系统需区分事实与推测
2. 关系处理：RAG弱关联，决策系统需完整因果链
3. 规则应用：RAG依赖模型理解，决策系统需确定性规则引擎
4. 结果归因：RAG提供参考段落，决策系统需明确责任主体
5. 时间维度：RAG静态快照，决策系统需时态追溯

真正可审计的AI系统，不是让模型生成一段"因为A所以B"的自我解释，而是系统完整保存可复现的输入、规则、证据、版本和执行结果。

Semantica：把决策变成图中的一等对象

Sematica开源项目提供了一个参考设计，其核心不是构建复杂的实体关系网络，而是让每个结论能够沿关系回溯。以制造企业供应商续约为例，最小决策图应包含以下节点类型：

• 供应商A
• 合同2025-017（约定交付SLA、质量条款）
• 交付批次记录（延迟3次）
• 质检报告（2次不合格）
• 整改函（状态未关闭）
• 续约建议（引用上述证据）
• 供应商管理规则
• 采购负责人决策

关键能力

Sematica将决策作为可被记录、查询和追溯的对象，提供recorded_decision结构记录决策类别、场景、结论、置信度和元数据。通过add_causal_relationship连接上游原因、下游影响和历史先例，支持trace_decision_chain、find_similar_decisions、analyze_decision_impact等接口。

这种设计强迫团队回答五个工程问题：

1. 什么算作可被引用的事实？来自哪个系统？谁在何时抽取？
2. 冲突信息出现时是覆盖、并存还是升级人工？
3. 哪些规则属于硬门槛，哪些只是风险提示？
4. 模型建议与人的批准如何明确区分？
5. 决策产生了什么后续影响？

系统级可解释性的四个关键层次

需要明确边界：Semantica提供的是系统级可解释性，而非还原模型内部推理过程。它能记录输入了哪些资料、检索到哪些事实、应用了哪些规则、模型给出什么建议、系统最终执行什么动作，但不证明模型在每个token间"如何思考"。

第一层：冲突不被静默覆盖

同一供应商在CRM、ERP和邮件中可能有不同状态。普通知识库容易将它们混合存储，把判断交给模型。Semantica的做法是标记冲突事实并进入处理流程——不保证自动找出真相，但避免新数据悄悄覆盖旧事实而无人知晓。

第二层：规则推理与模型生成分层

项目支持Prolog、Datalog、SPARQL等确定性推理引擎，以及SHACL约束、OWL本体管理。用业务语言表达：如果整改未关闭且质检不合格次数≥2，则续约建议不得自动批准，必须升级人工复核。这个门槛应由可测试、可版本化的规则控制，而不是依赖模型"每次都能理解公司制度"。

第三层：事实带着时间行走

企业数据不是静态百科。昨天有效的价格、供应商评级、组织权限今天可能已变更。Semantica提供时间快照和双时态事实能力，目标是让团队回看"当时系统知道什么"，而非用今天的数据解释三个月前的决策。对风控、财务、采购来说，这种时间边界比模型回答流畅更重要。

第四层：图、向量与存储可替换

Sematica并非反对向量检索，而是把向量召回、RDF三元组存储、属性图存储放进可替换的存储层，支持Faiss、Qdrant、Milvus、Neo4j等后端。正确理解不是"图谱淘汰RAG"，而是语义召回、图遍历、规则校验各司其职。

工程落地：从最小决策图开始

Sematica能力全面，但容易演变成宏大而迟迟不上线的工程。建议第一步只选满足三个条件的任务：

1. 有明确动作：升级、审批、分派、拦截、推荐，而非单纯FAQ
2. 有多元证据：至少涉及两个系统或文档来源
3. 需要事后解释：答案不能只是一段模型文本

适合起步的场景

• 销售报价异常折扣审核
• 售后投诉升级判定
• 供应商准入与续约复核
• 合同条款风险分级
• IT权限申请和例外审批

投诉升级最小实现

第一步：只建6类节点

客户、工单、产品、政策条款、证据附件、升级决策。

第二步：定义5条关键关系

• 客户提出工单
• 工单涉及产品
• 工单引用附件
• 政策条款约束工单
• 升级决策引用证据

第三步：加2条硬规则

• 涉及人身安全→自动升级人工
• 证据来源冲突→禁止自动关闭工单

这个版本跑通后，再逐步增加实体抽取、相似先例检索、影响分析和更多Agent能力。

决策表：何时需要决策图

场景类型	推荐方案	理由
员工查制度、找手册	普通RAG	维护好文档版本和引用来源即可
从资料提取字段生成周报	结构化工作流+人工抽检	不急着上图谱
Agent推荐、审批、拦截动作	事实-证据-规则-决策最小图	需要明确归因和责任主体
金融、医疗、法律、政府场景	图+规则+溯源+审计	从第一版就进架构，而非事后补丁
数据质量不稳定	暂缓	图谱会放大混乱，不会自动修复

上下文不只是向量，决策不只是日志

过去一段时间，Agent、Loop、Graph容易被讲成不断叠加的新概念。现在应该回到具体的事：Agent帮我们做事，Loop帮我们检查和改进，任务图让多人协作不乱，决策图则让企业知道为什么这样做、出问题能回到哪里。

Sematica未必是每家公司现在就该部署的答案，但它指出了重要方向：当AI从生成内容走向参与业务动作时，上下文不应只是一堆向量，决策也不应只是一条日志。真正的Graph Engineering下一层，是让每个影响业务的AI结论都能追溯到证据、规则、版本和责任主体。