让企业知识图谱学会说"不知道"：引用优先的GraphRAG实践

每个工程师都经历过这样的时刻：准备修改一个服务，却不确定会影响哪些下游。答案可能藏在去年的Confluence页面、某个PR描述、或者会议记录里的一句随口之言——但没人能告诉你具体在哪。

直接套一个LLM来问答？这条路最危险的地方在于它的失败方式：悄无声息。问一个文档里没有答案的问题，你会得到一个流畅、合理、但完全站不住脚的段落。对于变更影响分析这类场景，一个自信的错误答案比没有答案更糟——它可能直接导致一次线上事故的审批通过。

ZEHN Core给自己定了一条铁律：每个答案都必须引用它来自的那句话；如果做不到，就回答"我不知道"。 这个项目构建在FalkorDB之上，参加了FalkorDB Graph Hacks黑客松，代码已开源。

为什么是图，为什么是FalkorDB

"如果我改X，什么会坏？"本质上是一个图问题——它需要沿着"X被Y使用，Y供给Z"的链条走。单纯的向量搜索只能找到提及X的段落，无法跨文档追踪依赖关系。

团队使用FalkorDB和其GraphRAG SDK，摄入了Confluence页面、GitHub PR、会议记录和邮件组成的语料。关键设计决策是把溯源信息变成图的形状本身，而不是事后贴上的元数据：

(Document)-[:PART_OF]->(Chunk)<-[:MENTIONED_IN]-(Entity)
(Entity)-[:RELATES {rel_type, fact, spans}]->(Entity)

每条关系都携带谓词、抽取出的"事实"以及源文本的字符跨度。从"origin-mapper影响indexer"回到那句话本身，只需要一跳Cypher查询。

在此之上还有两层保护：检索通过一组固定的、白名单化的命名查询执行，最多三跳，且由遍历策略决定哪些谓词可以被走；FalkorDB的多命名图功能则让抽取实验和试点在隔离图中运行，基线图不受干扰。

GraphRAG 是检索增强生成（RAG）的一种变体：传统 RAG 从向量库取回相似文本片段直接拼进提示词，而 GraphRAG 先从语料中抽取实体与关系构成知识图谱，检索时沿图的边遍历，从而能回答“A 依赖 B、B 又依赖 C”这类需要多跳推理的问题。它的代价是抽取阶段会引入噪声——LLM 判断出的关系未必真被原文支持，因此 GraphRAG 系统通常需要额外的证据校验层，这也正是本文反复强调溯源的原因。

FalkorDB 是一个基于稀疏矩阵（GraphBLAS）实现的低延迟图数据库，支持属性图模型与 openCypher 查询语言。它的一个差异化特性是多命名图：同一个实例内可以并存多张相互隔离的图，各自拥有独立的 schema 与数据，查询时显式指定图名即可。这让团队能在不影响生产基线图的前提下，为抽取策略实验单独开一张图做对照。其 GraphRAG SDK 则封装了从非结构化文档到实体关系图的抽取与查询流程。

阻止幻觉的三层机制，只有一层是提示词

作者坦诚地指出，单纯在提示词里写"禁止使用外部知识"是必要但远远不够的。真正的防线在另外两层：

引用验证。 模型写出的每个证据ID都会与工具实际返回的ID进行比对。只要有一个引用是编造的，整个答案就被拒绝。一个真实引用不能为另一个虚构引用背书。

强制弃权。 没有有效引用就没有答案——无论行文多么自信。

为了验证这套机制，测试套件故意喂给代理循环一个行为不端的模型：编造引用、无证据作答，然后断言答案确实被扣留。

引用验证（citation verification） 与常见的“要求模型标注来源”有本质区别：后者只是提示词层面的请求，模型仍可能编造一个格式合法但不存在的 ID；前者是程序化的后置校验——把模型输出中的每个证据标识与工具调用实际返回的结果集做集合比对，任一 ID 不在返回集中即判定整个回答无效。这是一种全有或全无的策略：只要出现一条虚构引用，就认为该回答的推理链条不可信，因为模型已经表现出拼接不存在证据的倾向，其余“真实”引用无法为它作担保。

强制弃权（forced abstention） 指系统在缺少有效证据时主动输出“我不知道”，而不是让模型自由发挥。它在工程上要求答案生成路径存在一个显式的“证据充分性”门控，且该门控由代码而非模型判断。二者结合意味着系统的默认状态是拒答，作答是需要被证据解锁的例外——这与多数 RAG 系统“默认作答、偶尔道歉”的默认值正好相反。

给图谱自己的断言打分

图中存在一条路径，不代表文档真的这么说了。LLM抽取是有噪声的：模型看到"发布流水线将发出v2索引"，就兴冲冲地写了一条AFFECTS边，尽管那句话描述的是一个计划，而非依赖关系。

因此对于返回的每条路径，系统都会把每一跳与它自己的源句子比对，并打上标签：

标签	含义
有源支撑	路径上每个谓词都被其句子支持
推断假设	路径存在，但至少有一跳未被其句子断言
证据不足	被否定、假设性表述，或实体绑定失败

在UI中，推断出的跳会画成虚线边并附警告标记。问及Redwood API时，图找到了十二条路径——其中十一条被标记为推断假设。一个想显得厉害的系统会展示十二条自信的依赖关系；ZEHN Core选择给自己的作业打分。

同样的原则适用于歧义。"Redwood Inference"在语料中同时是一个团队、一个服务和一个客户。系统没有把它们合并成一个更整洁的答案，而是展示全部三种身份然后停下。

实体绑定（entity binding / entity resolution） 是知识图谱抽取中最容易出错的一环：抽取器需要判断文本中提到的“Redwood”究竟指向哪个实体节点。当语料里存在同名但不同指称的对象（一个团队、一个服务、一个客户都叫 Redwood Inference），绑定错误会导致关系边挂到错误的节点上，进而让整条推理路径失真。本文提到约三分之一的关系绑定错误，主要来源正是这一类同名歧义与指代消解失败。常见缓解手段包括：为实体附加类型与上下文指纹、要求抽取时输出指向原文的字符跨度以便人工复核、以及在同一名称存在多候选时拒绝合并并并列展示。

五条来自实践的经验

1. 模型的"事实"不是引文。 图抽取会在每条边上存一个自然语言fact字段。团队实测发现：186条事实中，0条是逐字来自源文本的。它们读起来像引文，这正是危险之处。他们不再把fact渲染为引用，转而构建了存储原始句子的引用优先路径。

2. 审计你的边，而不只是答案。 人工审计发现，抽样的关系中大约三分之一绑定到了错误的实体目标。这个数字没有被藏起来——它作为可见的限制随每一次调查一起呈现。

3. 了解你的Schema的物理形态。 在这个图中，每条边物理上都是RELATES，语义类型存在r.rel_type里。查询:DEPENDS_ON会返回空——而空看起来和"没有依赖"一模一样。这教会了团队最重要的一条工程规则：失败绝不能看起来像一个空结果。 数据库错误和"没有任何东西依赖它"是两个不同的事实，UI对它们的渲染也不同。

4. 没有验证过的东西不要打开。 团队评估过让CALLS边可遍历。它产生了有趣的链条，但无法用证据支撑，所以生产环境中保持关闭——并且当前激活的策略会实时显示在UI上。如果有人启用了它，徽章会显示评估模式。

5. 说出你还没建好的东西。 语料是覆盖四种来源类型的30篇文档子集；没有工单来源，也没有陈旧度检测。UI的历史页面会写"此构建中历史记录未持久化"，而不是展示假数据行。一个点击后没有实际动作的控件，比没有控件更糟。

结果与启示

ZEHN Core以一个FastAPI后端加React前端交付，包含七个屏幕：带标签页证据检查器的变更影响雷达、实时流式展示工具调用的代理、交互式知识浏览器，以及把API健康和图健康作为独立事实汇报的观测台。项目由959个后端测试和63个前端测试支撑，其中包含断言"无法引用不存在的来源"的测试。

作者最后的总结与图或模型无关：可信度是一个看得见的产品功能——一条虚线边、一次拒绝、一条提前列出的限制。用户无法验证流畅度，但他们可以验证一句话。

这一思路对构建任何企业级RAG系统的团队都有参考价值：引用优先不是限制，而是一种可被用户感知的信任设计。