从 100 万份文档构建知识图谱，如何验证它是否可信？

从一百万份文档构建知识图谱成本高昂。这并不特别令人意外。一旦在前面加上“一百万”，大多数事情都会变得昂贵。但还有一个较少受到关注的问题：

构建好图谱之后，你怎么知道它实际上是正确的？

这个问题是在我们读到 Corvic AI 联合创始人 Gurbinder Gill 的一篇近期 LinkedIn 帖子后出现的，该帖子探讨了在超大规模文档语料库上构建知识图谱的成本。他的例子是一百万页。他的帖子提出了一个有用的观点：如果你想要的一些信息已经存在于文档结构中，你大概不应该把每份文档的每个词都送进昂贵的 LLM。

页面有顺序。章节包含段落。表格属于页面。块跟随其他块。你不需要 LLM 来发现第 12 页在第 11 页之后。

不过，在讨论过程中的某个地方，我们在 Memgraph 的平台工程负责人 Toni Lastre 注意到了有趣的事情。帖子在其一个表格中提到了“结构图谱构建”。但在其他地方，包括标题，它谈论的是构建知识图谱。这两者可以重叠。它们并不自动是同一回事。

那篇 LinkedIn 帖子的作者显然理解知识图谱。他的其他文章正确地描述了语义抽取、类型化实体和关系，以及跨文档去重。所以这其实并不是要抓某人用错了词。

它提出了一个更有趣的工程问题：

当我们在文档之上构建图谱时，我们到底在构建什么，困难的部分从哪里开始？

于是我们当然在内部展开了一场辩论。

文档之上的图谱不一定是知识图谱

正如 Toni 所解释的，假设你有一份描述一家公司及其产品的文档。你把它拆分成块，并像这样表示结构：

文档 → 页面 → 块 1 → 块 2 → 块 3。

那是一个图谱。它也可以是一个非常有用的图谱。你保留了关于源材料如何组织的信息：哪个块属于哪份文档，它前面或后面是什么，也许还有哪些文档相互链接。这些块仍然可以有嵌入并参与向量搜索。事实上，结构图谱可以通过给向量检索提供除相似性之外可跟随的关系来丰富它。

但这个图谱仍然主要是在描述文档。

知识图谱试图描述的是文档所谈论的事物。所以，取而代之，你可能有：

公司 → 制造 → 产品 x
公司 → 制造 → 产品 y

而在某个其他地方，在一份完全不同的文档中，你可能有：

客户 A → 使用 → 产品 x

现在我们面临一个不同的挑战。这两份文档可能根本不相互链接。图谱连接它们是因为产品 x 在两个地方含义相同。

正如 Toni 所说：

“把文档的块放在一个图谱中，其中一个块指向下一个块，与表示该文档中的知识不是一回事。”

这种区别很重要，因为第二个系统必须推断事物。

而推断正是事情开始变得有趣的地方。

我们指的是昂贵。

结构还算便宜，语义则不然

文档已经免费给了你相当多东西：页面顺序、标题、章节、表格、段落边界，有时还有元数据。

你可以在不询问 LLM 它认为任何事物意味着什么的情况下保留其中大部分内容。

语义知识图谱的工作则更为艰巨。

它可能会发现，例如，“Acme Widget Platform”、“the Widget product”、“AWP”和“our flagship platform”都指向同一个事物。

然后它需要确定那个事物是什么，哪家公司拥有它，哪些客户使用它，它依赖什么，以及分散在数千或数百万个块中的事实如何相互关联。

现在你正在做的是实体提取、关系提取、身份解析、去重以及模式或本体对齐之类的事情。根据架构的不同，LLM 可能正在完成其中很大一部分工作。

这就是成本飙升的地方。

Toni 使用了一个故意粗略的例子。想象一下一百万份文档。每份文档有 50 页。每页大约有 2,000 个字符。

那就是 Gill 的一百万页，乘以五十倍。这样你就得到了大约 1000 亿个字符的文本。在你开始担心输出、重试、多次提取过程，或者有人决定模式应该稍有不同之前，输入 token 数就已经达到数百亿了。

确切的美元数字并不太有用，因为它取决于模型选择、缓存、批处理、分词和管道设计。

更有用的观点是：

一旦你要求模型理解文本的含义，每一页都变成了推理工作。

请注意，还有一个小问题：时间。

一百万份文档意味着大量的模型调用。你会遇到速率限制。你需要等待。你进行批处理。你重试失败的调用。有人发现昨天的提取任务在凌晨 3:14 悄悄停止了。

某处的笔记本电脑风扇开始发出令人担忧的声音。

不过，最终，假设你完成了。图谱存在了，恭喜！

现在尴尬的部分来了。

它到底对不对？！

正如原始讨论中的一条评论所说：

“当然，它又大又快，但生成的图谱好吗？”

确实如此。

因为在某些时候，计数不再等同于评估。

一个管道可以告诉你它创建了 8,000 个实体和 12,000 个关系。这是有用的信息。它证明了，除其他事项外，该管道一直非常忙碌。

它并没有告诉你这些实体和关系是否正确。

假设系统 A 提取的实体数量是系统 B 的两倍。哪一个构建了更好的知识图谱？

仅凭计数无法回答这个问题。

也许系统 A 发现了明显更有用的知识。

太好了。

或者也许它热情地创建了同一家公司的四个版本，并将两个完全不同的 John Smith 合并成了一个异常多才多艺的人。

不太妙。

一旦你开始构建语义图谱，“好”的含义就开始不同了。

我们提取的事物中有多少实际上是正确的？我们错过了多少重要信息？我们是否正确地识别出两个提及指向同一个现实世界实体，还是因为名称相似而意外合并了两个不同的实体？

这条边是否真的代表了源文本所说的内容？

与计数节点不同，这些问题没有特别方便的答案。

计算机非常擅长计数。它们也非常乐意计算错误的东西。而且语料库越大，你自己检查结果就越不切实际。

有十份文档时，你可以查看。

有一百个的话，你或许还能检查足够多的内容，说服自己没发生什么灾难性的事情。

但面对一百万份文档，“我们看了几个，看起来没问题”就开始不像质量保证，而更像是一种带着抽样策略的乐观主义。

这就引出了更棘手的问题。

十份文档看起来很棒。然后我们处理了其余 999,990 份

想象你构建了一个抽取流水线。你在一个小的随机样本上测试它。一切看起来都很好。一切都能说得通。太棒了。

确切的样本量其实不是重点。你仍然只是在验证即将成为一个庞大数据语料库的极小一部分。

于是你在剩余的文档上运行这个流水线。

在某个时刻，大约在第 643,817 份文档附近，模型出错了。也许它抽取了一个源文本从未陈述的关系。也许它认定产品 x 收购了公司 y，这对双方来说肯定都是新闻。

现在难的部分来了。

Toni 的担忧并不仅仅是 LLM 会产生幻觉。这一点我们早就知道。他担忧的是之后会发生什么。

你可以对输出进行抽样。你可以让领域专家审查图谱中的随机部分。你还可以叠加其他验证方法。

这些都很有用。

但假设你知道在数百万个自动生成的关系中，某处有一个是错的。

你怎么找到它？

而一旦你找到了它，同一次抽取运行还产生了什么别的东西？其他事实是否依赖于它？你应该删除这条边吗？重新处理这份文档？

这不再是抽取问题。这是一个恢复问题。而当在图谱变得庞大之前没有人为此做过设计时，恢复往往会变得相当有趣。

质量变成了一个运营问题

我们很擅长度量基础设施。延迟、吞吐量、token 用量、内存、成本。

计算机喜欢这些数字。它们是表现良好的数字。你问某件事花了多少毫秒，你就会得到一个毫秒数。

“这个关系真的成立吗？”是另一种问题。

这很重要，因为知识图谱通常不是为装饰目的而构建的。没有人会花几个月抽取实体和关系，只为了让所有人都能站在那里赞叹边的密度。

总会有东西要用它。

应用程序查询它。GraphRAG 系统从中检索。智能体在其上推理。分析在其上运行。

而一旦其他系统开始把图谱当作知识，一个错误的关系就不再仅仅是一条不幸的边，而是开始有了一份职业。

它出现在检索结果中。它与其他事实结合。它成为上下文。有东西在其上推理。不久之后，一个自信地错误的关系就有了依赖者。

毕竟，快速给出的错误答案仍然是错误答案。它们只是来得更早而已。

这意味着图谱质量不是一个学术问题。它变成了应用质量。

构建图谱可能是简单的部分

这一切都不是在主张放弃知识图谱、默认转向向量搜索。尽管可以理解的是，有时情况确实如此。

但这两种方法解决的是不同的问题。如果答案取决于事物之间的关系，而不仅仅是找到与问题相似的文本，那么避开图谱并不会让关系问题消失。它只是意味着你决定不去对它建模。

更有用的方向是，首先让构建图谱这件事变得不那么令人生畏。

困难的部分是真实存在的。

它们同时也是工程问题。

而工程问题有一种恼人的倾向：一旦有足够多的工程师被它们烦到，它们就会变得更容易。

然而，在以下两者之间仍然存在一个惊人的巨大鸿沟：

我们成功生成了千万条关系。

以及：

我们拥有千万条我们信任的关系。

第一句话相对容易证明。它们有一千万条。你可以数一数。数据库会帮忙。

第二句话往往会引发一场更长的会议。

让原始来源与提取出的知识保持足够近的距离

你可以审查样本。你可以改进提取。你可以让原始来源与提取出的知识保持足够近的距离，这样当某些东西看起来可疑时，你有一个合理的起点去挖掘。

回答这个问题最便宜的时间是在你构建图谱之前。之后，它就会变得昂贵。再之后，它就变成考古了。

每一条提取出的关系都应该带有一个指回其来源块的指针，外加一条产生它的运行记录：模型、提示词版本、日期。这不会让一条关系变成真的，但会让它变得可核查。当有人在第 643,817 号文档中发现一条坏边时，你可以调出它背后的那句话，找出同一次运行中产生的所有其他边，然后决定下一步怎么做。

所有这些都有帮助。

你所没有的，是一个大大的绿色按钮，上面写着：VALIDATE KNOWLEDGE GRAPH

至少，没有一个我们会信任的。

所以，也许大规模知识图谱构建中最难的问题，不是你能处理多少页、能提取多少实体，甚至也不是整件事要花多少钱。

而是六个月后，当有人指着几百万条关系中的某一条问：

“为什么图谱认为这是真的？”

如果你能回答这个问题，你就算有所进展了。

如果你回答不了，你可能仍然拥有一个非常令人印象深刻的图谱。

只不过，你还拥有一个谜。