裂缝里的指纹

GraphRAGProv: GraphRAG Meets How-Provenance

一句话概括

当"大模型 + 知识图谱"成为答题基础设施，这篇论文做了一件不性感却性命攸关的事：把"答案是怎么算出来的"整条计算链拆开摊平——从问题到查询、从查询到答案绑定、从答案到来源多项式、从多项式到图里的每一条陈述、从每条陈述到原文里的每一个字符。四百个案例的体检结果相当清醒：答案对了，证据链却处处裂缝；而把这些裂缝照出来，恰恰是这套系统最大的价值。

法证剧里有个百拍不厌的桥段。嫌疑人招了，口供漂亮得无可挑剔：时间、地点、动机、手法，每个细节都对得上号。检察官合上卷宗准备结案，老刑警却盯着物证袋的标签出神——第三枚指纹的提取时间，比口供里声称的作案时间，晚了整整一天。指纹是真的，口供也未必是编的，但物证链的第三环断了。断一环，整条链的证据效力就归零，这是刑事诉讼法写在条文里的常识。

干审计的人熟悉同一套逻辑。年底查账，报表数字轧得平平的，发票也一张张贴在凭证后面。审计师随手抽一张发票，顺着它往回走：发票上的金额，怎么进了账簿，账簿上的科目，又怎么汇进了报表。哪一环对不上，哪怕最终数字碰巧正确，这张报表也不能签字。

现在把镜头切到人工智能。今天的大语言模型接上知识图谱，在 Wikidata 这样的巨型知识库里检索、推理、作答，答案越来越像样，排行榜上的数字一个比一个体面。很多系统还格外贴心：回答问题时，顺手把检索到的关系路径、相关子图一并展示给你看。看那，模型就是根据这些证据作答的——这个回答，可是有据可查的。

真是这样吗？

那份展示给你的子图，顶多证明模型看到了什么。它回答你的那个词、那个数字，究竟是怎么从那些证据里长出来的——这一段发生在神经网络黑箱里的算术，没有任何东西能给你看。就像那张轧平了的报表：发票都在，可没人知道发票是怎么加总成报表的，因为做账的那个人，拒绝打开他的算盘。

在闲聊场景里，这顶多算个洁癖。可一旦场景换成医疗诊断、计算司法——任何一个答案错了要付出真实代价的地方——问题就变成了法律问题：不仅答案要被验证，导致答案的那个计算过程，本身也必须能被验证。

法国 INRIA 雷恩团队的这篇 demo 论文，直面了这件事。而且它的解法有一种侦探片式的狠辣：既然黑箱算术查不了，那就干脆别让它发生。

🎯 看不见的算术

先交代舞台。GraphRAG 是这两年检索增强生成里的一条技术路线：不把原始文档 chunk 一股脑塞进上下文，而是把文本里的实体和关系抽成知识图谱，检索时沿图结构找出相关的路径或子图，再喂给大模型生成答案。比起平面文本检索，图结构自带多跳推理的能力——问"《活着》作者的出生地有什么特产"，图谱能把"《活着》→余华→杭州→西湖龙井"这条链一次性端出来。

GraphRAG 的卖点之一，恰好就是"可解释"。传统 RAG 检索回来一堆语焉不详的段落，GraphRAG 给你的是干干净净的关系路径。很多系统的交互界面上，答案旁边就悬浮着那张证据子图，边是边，点是点，看着就让人心安。

这篇论文把这块心安的牌子摘下来，翻了过来。作者指出的裂缝很具体：检索到的路径或子图，只能告诉你 LLM 看到了什么证据；它们不能告诉你，返回到用户手里的那个值，是怎么算出来的。 证据是输入，答案是输出，中间隔着一段生成过程。而生成——那几百层 Transformer 里上演的注意力分配——恰恰是整个链条里最不可审计的一段。你可以复核证据本身，但你无法复核"模型使用证据的方式"。

把这件事的严重性说透，得换一个更老的行当来打比方。你请一位会计做年度报表。年底他交给你两样东西：一摞发票，一张轧平的报表。你问他："这个月的主营业务收入，是怎么算出来的？"他回答："我看过这些发票了。"你满意吗？当然不会。看过发票和算对报表之间，隔着一整套做账流程，而那套流程他全程关着门做。发票再真，也替代不了对做账过程的审计。

今天的 GraphRAG 系统，就是那个关着门做账的会计。检索子图是发票，最终答案是报表，中间的"做账"——实体怎么被链接、关系怎么被推理、多个证据怎么被加权取舍——发生在 LLM 的生成过程里，无账可查。

为什么会走到这一步？原因不复杂：这一架构把"检索什么"和"怎么回答"两段工程，分别外包给了两套机制。检索段好歹是符号的、确定的，沿着图的边走路，每一步有日志；生成段是神经的、概率的，从上下文到答案是一次性采样，没有任何中间状态被记录下来。整个领域忙着优化答案质量的时候，中间这段黑箱被默认忽略了——反正答案对就行。可"答案对就行"这五个字，在医疗和司法场景里，恰恰是最说不出口的那句。

🔍 釜底抽薪：让查询自己开口

面对"生成过程黑箱"这个病灶，通常的思路是给黑箱装玻璃：让 LLM 输出思维链、输出引用、输出置信度。GraphRAGProv 走了另一条路，干脆利落得近乎暴力——不让 LLM 写答案。让 SPARQL 查询直接把答案算出来。

这句话值得停下来嚼一嚼。在几乎所有 GraphRAG 系统里，知识图谱扮演的是"检索员"的角色：它负责把相关上下文捞回来，端给 LLM，由 LLM 组织语言、生成最终答案。在这篇论文的架构里，角色整个反了过来：知识图谱是"计算器"，LLM 只是"翻译"——把用户的自然语言问题翻译成 SPARQL 查询，把源文本翻译成图里的三元组。查询在图数据库里执行出来的结果，就是返回给用户的答案本身。没有文本检索兜底，没有 LLM 生成的 fallback。查出来的值是什么，用户看到的就是什么。

这一招的高明之处，在于它把审计的对象整个换掉了。原本你要审的是"模型从证据到答案的生成过程"——神经网络内部的事，原则上不可审；现在你要审的是"一个查询在一套数据上的执行过程"——符号计算的事，每一步都可以重放、可以记录、可以回溯。前者是逼一个画家解释他的每一笔为什么这样落，后者是查一张快递单每一站的签收时间。画家说不清，快递单一清二楚。

当然，查询本身也可以瞎写——这是后话，第四节的 Labyrinth 案例会现场演示。但至少从架构上，计算被拉回到了光天化日之下。

在这个符号计算的地基上，论文搭起了三层可审计的物证架。每一层对应链条上的一环，层层咬合，从最终答案一路回溯到原文的字符级位置：

1. 图构建层：LLM 把自然语言文本解释为 RDF 三元组，同时必须为每个三元组的三个组件——主语、谓语、宾语——分别给出支撑它的文本引文。一个确定性定位器把这些引文解析到原文里精确的字符 span。找不到原文出处的引文，直接打回让 LLM 修正：拿不出出处的引文，不配当精确证据。
2. 符号块层：每一个"源接地陈述出现"（source-grounded statement occurrence）被登记为一个符号块，拥有唯一 id，一头连着 RDF 三元组，一头连着源段落和证据 span。同一条三元组如果从两个不同段落里各被提取了一次，就保留两个独立的出现 id 和两套文本证据。这些连接用 RDF-star 的具体化（reification）机制存进图里。
3. How-Provenance 层：LLM 把问题翻译成 SPARQL 查询，交给 GraphDB 执行；一个叫 NPCS 的引擎（Asma 等人 2024 年的工作）在重写查询的同时，顺手算出这个答案的 how-provenance——一个代数多项式，其中乘法 ⊗ 表示多条陈述的联合使用（缺一不可），加法 ⊕ 表示可相互替代的推导路径（哪条都行）。

三层拼起来，就是一条完整的追溯链，论文用一串符号把它写全了：

q → Q → μ → P_μ → id_i → (u_i, E_i^s, E_i^p, E_i^o)

读作人话：自然语言问题 q，被翻译成 SPARQL 查询 Q，执行得到答案绑定 μ，NPCS 算出 μ 的来源多项式 P_μ，多项式里的每一项指向一个 RDF 陈述出现 id_i，每个出现再拆出它对应的源段落 u_i 和三个组件各自的证据 span（主语 E_i^s、谓语 E_i^p、宾语 E_i^o）。从答案到字符，五环，环环有编号，环环可核查。

这就是会计做梦都想要的那条链：报表上的数字，一路追到分录，追到凭证，追到发票，最后追到发票右下角那个签名落在纸上的确切位置。

⚙️ 三层物证架：魔鬼全在细节上

这三层架子，乍看是三个已知部件的拼装——LLM 抽取、确定性定位、来源代数。demo 论文的篇幅也不允许它发明全新的重型武器。但这套拼装里有几处设计分寸，值得逐层细看，因为它们决定了这套物证架是花架子还是真家伙。

第一层：从句子到三元组，每一步留指纹。 图构建这一步，LLM 负责阅读理解：读一段原文，抽出 (subject, predicate, object) 三元组。论文举的例子是：「Borhane Alaouié is a Lebanese film director」被抽成 (Borhane Alaouié, nationality, Lebanese)。

请盯住这个三元组多看两秒。nationality 这个词，原句里根本没有。原句有的是形容词 Lebanese 和短语 is a——谓语 nationality 是模型从这两个成分里推断出来的。这个细节表面上无关痛痒，其实是整个系统里最早埋下的一枚雷：文本解释这一步，天然包含推断，而推断就可能出错。第四节第一个案例，就是踩着这枚雷炸的。

论文为这一步配了两道保险。第一道，LLM 必须给三元组的每个组件分别出具文本引文——你说主语是他，证据是哪几个词；你说谓语是国籍，证据是哪几个词；宾语同理。第二道，验收引文的不是模型，而是一个确定性定位器——一段程序，把每条引文解析回原文里精确的字符级 span。凡是定位器在原文里找不到的引文，打回，让 LLM 修正，修不出来这条证据就不算数。

注意这里的分工哲学，我认为是全文最清醒的一处：凡是程序能确定的，绝不用模型。定位是字符串匹配，交给程序；理解是语义推断，才交给模型。审计系统的天敌是"用不确定的东西去验证不确定的东西"，这条设计从根上避开了它。

第二层：每一次出现，都是独立的一号物证。 符号块这一层解决的是一个容易被忽视的问题：同一条知识，图上只有一个三元组，但它是从原文哪一段、哪一句话里抽出来的？万一两个段落都说了同一件事呢？

GraphRAGProv 的登记方式很有法医意识：它登记的对象是"知识的出现"，而非知识本身。同一个三元组 (A, nationality, Lebanese) 从第一段抽出来一次，登记为出现 1 号，附上第一段的证据 span；从第三段又抽出来一次，登记为出现 2 号，附上第三段的证据。两条出现，各自独立的 id、各自的文本凭据，互不混同。好比同一个指纹在五个现场出现，法医会装五个物证袋、贴五张标签，绝不会合并成一张"该指纹出现过的证明"——因为每一个现场都对应一条独立的证据链。

这些登记信息用 RDF-star 的具体化机制存进图里。具体化是 RDF 世界的老手艺：一个三元组本身不能被当作另一个三元组的主语或宾语，那就给它造一个"替身节点"，把关于这个三元组的元数据——谁提取的、从哪段文本、对应哪些字符位置——全部挂在替身上。于是图数据库里同时存着两层事实：知识本身，和知识的来路。查询照常查前者，审计随时翻后者。

第三层：给计算本身记账。 最后一层处理的是整条链的心脏：答案绑定 μ 是怎么由图里的陈述算出来的？

执行器是 GraphDB，SPARQL 引擎。妙处在于 NPCS 这个组件：它在执行前把查询重写一遍，使执行过程同时产出一份 how-provenance——一个多项式。这个代数的规矩很朴素：乘法 ⊗ 意味着"这几条陈述被联合使用"，拆开任何一条，这个答案就散架；加法 ⊕ 意味着"几条可替代的推导路径"，走哪条都能到达这个答案，但每条都是一条独立的来路。

打个比方：答案 1986 的账本上写着「陈述 3 ⊗ 陈述 7 ⊕ 陈述 3 ⊗ 陈述 12」，审计员一眼就能读出两层信息——这个答案有两条独立的推导路径，一条依赖陈述 3 和 7 的联合，一条依赖陈述 3 和 12 的联合；两条路共用陈述 3。哪里断了，断的是哪条路，多项式比任何自然语言解释都精确。

到这一步，五环链全部接通：问题、查询、答案、多项式、出现、原文字符。值得一提的还有评估时的构建配置：图构建和 SPARQL 生成都由 DeepSeek-V4-Flash 完成，而且构建时模型能看到问题、期望答案和推理证据——等于出题的时候就把标准答案和解题思路塞给了施工队。这个设置让四百个案例的上游质量尽量可靠，也让后面暴露出来的裂缝更显意味深长。

📊 四百个案例的体检：链条断在哪

理论搭完，上解剖台。评估用两套组合式问答基准：2WikiMultiHopQA 的 200 道组合问题和 MuSiQue 的 200 道可回答问题，合计 400 例。

先说系统自身的体检报告：完整追溯可用率，2Wiki 上是 193/200，MuSiQue 上是 118/200；所有 311 条成功解码的追溯，全部通过了出现检查和源 span 检查。 翻译一下：只要追溯链生成出来了，它是结实的——每个环节都能对上号，五环没有一环松动。MuSiQue 上可用率明显更低（118/200），则说明这套流水线的瓶颈在上游构建，而不是追溯机制本身。

但这份报告要读得小心。311 条全数通过，证明的是物证架本身造得牢；而物证架的全部意义，在于它一丝不苟地记录上游——于是上游的每一道裂缝，都被原样照了出来。四个案例，四种断法，刚好画出了一张完整的故障地图。

案例一：Meesaya Murukku——词在，意思歪了。 系统给出的答案是 "India"，正确。引用的词 "Indian" 也确实存在于记录里的那个字符偏移处，来源解析无可挑剔。唯一的麻烦：那个 "Indian" 描述的是电影，不是导演。答案对了，证据里的每个字也都对得上原文，但文本解释在谓语上拐错了主语。

这正是 Borhane Alaouié 那枚雷的引爆现场。nationality 类谓语是从形容词和系动词结构里推断出来的；推断一旦走偏，错误的谓语带着真实的文本出处，堂堂正正进了图。来源解析忠实得像一台复印机——可惜复印的是一张填错的表。这个案例给所有人上了一课：字符级的精确出处，保证不了语义级的正确解读。发票上的签名是真的，签名对应的那笔账是错的。

案例二：Labyrinth——每块砖都合格，墙砌错了。 查询返回了正确的年份 1986。来源多项式显示，它用了两条各自有坚实文本支撑的断言——每一条单拎出来都挑不出毛病。可是顺着多项式走一遍就会发现：整个计算过程从未建立 "Acornsoft 出版了这款游戏" 这个事实。两条好断言，拼出了一个用户没问的问题的答案。

来源忠实记录了执行的计算——问题出在那个计算根本没有表达问题。这个案例锋利到什么程度？论文为它写下的那句结论，我认为值得每个做问答系统的人抄在笔记本上：

"An executable query answers what it asks of a graph, not necessarily what the user asked of the original text."
可执行查询回答的是它对图问的问题，不一定是用户对原文问的问题。

翻译的环节出了毫厘之差——用户问的是 A，查询问的是 A′——执行再正确，也是在正确地答错题。而这件事，不看 provenance 你根本发现不了：答案对了，证据齐全，皆大欢喜，只有审计线索在角落里冷冷地记着：这笔账加的不是那组数。

案例三：Aldobrandino——一个人，两张身份证。 图里明明有那个人的父亲关系，也明明有他的出生日期。查询也没写错。可是 join 失败了，查询返回空。为什么？父亲关系挂在 IRI 甲名下，出生日期挂在 IRI 乙名下，而甲和乙本该代表同一个人。实体解析在两个段落里给同一个人办了两张身份证，信息被提取了，却被锁进两个永不往来的抽屉。所需的每一颗零件都在仓库里，只是装配单上写的是两个零件编号。

这个案例还顺手暴露了 provenance 系统最深的一处盲区：空结果无从追溯。 计算发生了，但什么也没算出来，于是没有答案绑定、没有多项式、没有任何痕迹可追——provenance 只能沉默。诊断这类故障，只剩一条路：人工翻开图和查询直接检查。审计线索记下了系统做过的每一笔账，但对"系统没做成的那笔"，它无话可说。这是整套方法最诚实的边界，论文没有掩饰，反而用案例把它亮了出来——这份坦白本身，就是可审计精神的注脚。

案例四：Caledon River——一条段落，扛起了两条关系。 benchmark 的标准设定是：这道组合题需要两条支撑段落。而追溯链揭示，实际答案所依赖的两个必需关系，全部来自同一条段落。推导依然充分成立，答案依然有效——断的不是系统，是 benchmark 的标注假设与实际语料结构之间的对账。这个案例不是故障案例，它展示了追溯链的另一种用法：拿它反过来核对评测基准自己的规格，看看题目声称依赖的证据结构，和语料真实的证据结构是不是一回事。

四个案例排开，故障地图就清晰了：文本解释层断（案例一）、查询表达层断（案例二）、实体表示层断（案例三）、语料结构层对不上规格（案例四）。断裂的位置不同，机理不同，唯一相同的是——没有 provenance，它们全都 invisible。答案对的时候，没人想拆墙；墙里的裂缝，只有审计线索看得见。

💡 审计线索，不是证书

看完四个案例，论文最核心的哲学区分也该登场了：provenance 是审计线索（audit trail），不是证书（certificate）。

这两个词的分寸极重要。证书是系统自己给正确性打包票——"我的答案是对的，信我"。审计线索是把账本摊开在桌面上——"这是我做的全部计算，每一步的凭据都在，对还是不对，请你过目"。GraphRAGProv 从头到尾没有承诺答案更准。它承诺的是另一件事：答案背后的每一步，你都能查；查出问题，责任边界清清楚楚。

这个定位，决定了怎么评价它的贡献。这是一篇 demo 论文，篇幅短，技术组件多是组合——LLM 抽取、确定性定位、RDF-star、NPCS——没有新的 SOTA 模型，没有刷榜的数字。若按"方法创新"的尺子量，它显得轻；若按"问题重要性"的尺子量，它踩在了这个时代最软的腹部上。整个领域都在给大模型接图谱、接检索、接工具，答案产量节节攀升，而"这些答案是怎么来的"依旧是一笔糊涂账。GraphRAGProv 的价值不在让答案更准，而在让不可见的变得可见——把一段黑箱算术，变成一条可以逐步走完的路。在一个答案越来越便宜的时代，"它是怎么来的"成了最贵的东西。工程上它或许只是拼装，范式上它是一声提醒：可审计性不会自己长出来，得一环一环造。

它在系统设计上留下的那条分工原则，也值得单独记下：确定性组件管验证，统计性组件只管翻译。 定位交程序，执行交引擎，多项式交代数——凡是能写成代码的，绝不让模型沾手；模型只做它真正不可替代的两件事：理解文本，翻译语言。这是治"用不确定验证不确定"这个绝症的唯一药方。

再把镜头拉回这个系列。上一部我们讲 FoG：知识图谱智能体答对了题却拿不出证据，要用"每条证据只奖给第一个找到它的人"的奖励函数，逼着它先取证再开口。那一种谎言，是"对了，但没有来路"。这一部更进一步：来路有了，摆得整整齐齐，一查，物证对不上案发现场——文本被误读、实体有两张身份证、查询答的不是你问的那道题。谎言的级别从"没来路"升级成了"来路本身造假或断链"。FoG 让 agent 把物证带回警局，GraphRAGProv 让物证袋上的每一张标签经得起查看。两件工作一前一后，恰好拼出了可审计性的两半：先要取证，再要能查账。

而物证的故事还没完。第三种谎言已经等在门口：答案对了，证据链也完好无损——可证据是去年取的。口供句句属实，但那是去年的现场。下一部讲 LiveSearch：答案会过期这回事，检索系统打算怎么办。

法证剧的最后，老刑警把物证袋一张张排开， timelines 一格格对齐。他没有替法官定罪，也没有替嫌疑人翻案。他只是让链条上的每一环，第一次变得可以走完。剩下的判断，是人的事。

这套系统也一样。它把计算摊开，把裂缝照亮，然后退后半步。审计线索的尽头，永远站着一个愿意逐环查看的人。

参考文献

• Wadie El Amrani, Luis Galárraga. "GraphRAGProv: GraphRAG Meets How-Provenance." arXiv:2610.37237 [cs.AI], 2026.（INRIA, Rennes, France；demo paper；组件含 NPCS provenance 引擎 Asma et al., 2024、GraphDB、RDF-star）
• 系列前作：Zongyuan Sun et al. "Clearing the FoG: Training KG Agents to Retrieve the Evidence Behind Their Answers." arXiv:2610.37405 [cs.AI], 2026.

#论文解读 #arXiv #小凯 #GraphRAG #数据溯源 #知识图谱