文本、表格、知识图谱三方打架，这篇论文把它做成了可检测的问题

如果你做过基于 Wikipedia 的 RAG，或者拿 Wikidata 做知识增强，大概率遇到过这个场景：同一件事，正文里写的是 A，信息框里写的是 B，去 Wikidata 查又变成 C。该信谁？

这种情况其实很常见。Wikipedia 和 Wikidata 的知识深度互联，但分散在文本、表格和知识图谱三种模态里，彼此之间根本没有自动对账机制。Fanfu Wei、Thibault Ehrhart 和 Raphaël Troncy 近期上传的一篇论文，就把这个问题拎出来系统化地研究了。

论文标题很直白——「Detecting Knowledge Inconsistencies Across Text, Tables, and Knowledge Graphs」，核心就一件事：当三种模态的知识不一致时，怎么自动发现并解释这种冲突？

不止是矛盾，还有遗漏和时空差

作者先给冲突分了类。不一致不全是「错误」——实际跑出来的情况比单纯的对错要复杂。他们归纳了四种类型：

• 信息颗粒度差异：一种模态讲得细，另一种只提了一嘴，没有直接冲突但信息量不等。
• 直接矛盾：A 说东，B 说西，典型的知识冲突。
• 时序变化：旧版本和新版本之间对不上——比如人口数据，表格是 2010 年的，文本用的是 2020 年数据。
• 知识图谱不完备：Wikidata 压根没收录某个属性，导致表里有而 KG 里空着，看起来像冲突，实际上是缺失。

这种分类本身就有用——跑报警的人最怕的就是不分青红皂白全标成「错误」，然后一个个手工看。颗粒度差异和时序变化在很多场景里可以自动标记，不必每次都炸 human-in-the-loop。

Kontrast：让机器自己审自己

为了解决这个问题，他们搭了一个框架叫 Kontrast。流程大致是这样：用 Table-QA 数据集里的表格问题作为起点，先跑 Text-to-SPARQL 把自然语言问题转成 Wikidata 查询，拿到 KG 里的答案，然后把表里的答案和 KG 答案送到 LLM 那里做对比，最后归类冲突类型。

流程是让大模型当裁判，拿表格数据去 Wikidata 对账，再把对不上的地方分门别类。

实验跑在各种 Table-QA 数据集上，结果不意外——跨模态不一致非常普遍，而且这些不一致不只暴露了真正的知识冲突，还顺手揪出了 KG 结构缺失和时序不匹配。换句话说，这个框架在找 A 和 B 哪个错了的同时，还能指出「B 根本没这个字段」或者「A 和 B 的数据年份不一样」。

当然也有边界问题。Text-to-SPARQL 本身会引入错误，LLM 推理也有噪声。作者的定位很清醒——Kontrast 定位是「大规模知识审计」的实用工具，顺带给后续研究搭了个 benchmark。

代码和数据已开源：github.com/ECLADATTA/KONTRAST。

为什么这件事值得关注

只是用 Wikipedia 读文章的话，三种模态打架影响不大。但在做三件事中的任何一件时——LLM 预训练、检索增强生成、知识图谱构建——这个不一致问题就直接变成生产质量问题了。

一个典型的场景：搭了一个 RAG pipeline，检索 Wikipedia 文本当上下文，同时从 Wikidata 拉结构化数据做验证。两条线的信息如果对不上，LLM 生成出来的东西就是内部自相矛盾的。这个问题在目前的 eval 体系里很少被专门测试到。这篇论文至少给了一个检查工具箱和一个分类法，让人知道自己系统里哪些知识在打架。

跑 Table-QA 只是起步。更实际的应用可能是把这个流程接进数据管道，定期扫描自己的知识库。Kontrast 用的 Text-to-SPARQL + LLM 判断这条链路，框架本身不挑数据源，换一套 KG 和表格也能跑。

论文最后也没把问题说死——Text-to-SPARQL 的质量仍然是瓶颈，LLM 做冲突判断的准确率还有空间。但方向是对的：把知识一致性问题从「遇到了再手工修」推到「自动化检测 + 分类」的阶段。对做数据基建的人来说，这比又多一个 benchmark 刷榜有用得多。