Steven Renwick, 联合创始人兼CEO，Tilores Steven Renwick 联合创始人兼CEO，Tilores

实体解析正在成为AI基础设施，而不仅仅是数据清理

一段时间前，我看到一个AI代理给出了一个自信但错误的答案，原因很简单。一个企业有两个记录，指向同一个公司客户。一个记录包含旧的交易名称和财务联系人，另一个记录包含新的法律名称和不同的账单地址。代理被问了一个简单的问题：这个账户是否正常？它找到一个记录，看到没有逾期发票，并说是的。但是，逾期发票被记录在另一个名称下。没有任何虚构的内容。模型在给定的数据上进行了清晰的推理。数据只是碰巧描述了两个客户，而在现实世界中只有一个。错误不在于语言模型，而在于连接。我已经开始认为这是企业AI中最被低估的风险之一，也是讨论最少的。我们不断谈论模型准确性、提示设计和治理。我们很少谈论系统是否真正知道它正在处理哪个现实世界的客户、供应商或账户。这个问题有一个名字，叫做实体解析。在过去60年里，它一直在背景中，现在它正在悄悄地变成一部分活跃的基础设施。问题的时态发生了变化在其工作生涯的大部分时间里，“这些两个记录是否是同一个实体？”是一个清理问题。你在批处理中运行它，按计划运行，位于主数据管理程序、仓库或分析管道的某个地方。它从来没有完美，但它是可以忍受的，因为输出是一个报告，下周有人会阅读它。如果两个记录没有合并，支出数字会略微错误，分析师会注意到，并在下一次运行中纠正。系统中有松弛。时间吸收了错误。AI代理消除了这种松弛。它将问题的时态从“最终”变为“现在”。当代理即将批准退款、路由案例、更新配置文件或回答合规性问题时，解析的实体不再是下周的报告。它正在为行动提供信息。错误连接的成本从一个稍微不正确的数字变为一个在世界上立即发生的事件，通常没有人工干预来捕获它。这是值得深思的转变。根本问题是旧的，众所周知的。新的方面是，我们已经将其直接连接到自己的系统中。20世纪60年代的统计问题实体解析并不是随着大型语言模型而出现的。它出现在打孔卡中。1959年，H. B. Newcombe和他的同事在《科学》杂志上发表了一篇关于自动链接重要记录的论文，描述了计算机如何决定出生记录和婚姻记录是否指的是同一个人。十年后，Ivan Fellegi和Alan Sunter给这个想法提供了正式的数学理论，定义了任何匹配系统今天仍然产生的三个结果：链接、非链接和需要人工审查的可能链接。在这段历史中，有一个细节值得注意，因为人们经常错误地理解它。记录链接从来不是仅仅基于电子邮件地址或共享ID的精确匹配。从一开始，它就是基于概率的。它根据两个记录在姓氏、日期、地点等方面的匹配程度进行加权，生成一个分数，因为人工输入的数据是混乱的，精确的键经常失败。现代实体解析仍然以这种方式工作。它结合了确定性的规则（共享的稳定标识符是决定性的）和基于机器学习的模糊匹配，以处理拼写错误、昵称、字段颠倒、缩写等人类数据中的小问题。一个好的领域调查追溯了从20世纪50年代的重要记录到现在使用的聚类和机器学习方法的完整线索。真正发生变化的是我们需要答案的时间。研究人员在当前AI浪潮之前就已经写过关于实时解析实体的内容，而不仅仅是在预处理中。以前这是一个有趣的优化问题。现在它更接近于一个要求。为什么代理将其转化为基础设施大多数企业AI系统不会从模型的记忆中回答问题。它们检索。流行的检索增强生成模式使代理在问题时刻检索相关上下文并对其进行推理。这总体上是一个好事情。它使答案基于您的数据，而不是模型的训练。但是，它带来了一个容易忽略的后果。代理继承了检索步骤提供的任何内容。如果检索返回一个分裂的客户，三个从未连接的部分记录，代理将推理三个客户。如果检索返回一个错误合并的记录，两个不同的公司合并为一个配置文件，代理将推理一个。源系统中已经存在的模糊性直接传递给模型并呈现为已解决的事实。模型无法知道连接是错误的，就像您在阅读一份您从未见过的记录的整洁摘要时一样。因此，解析不能是一个每季度运行一次并写入单独表格的附加步骤。实体必须在数据摄取时组装，并且当前解析视图必须能够在代理询问时立即检索。这种运行时依赖性更像数据库或身份验证服务，而不是周期性的数据清理项目，并且必须像对待任何其他应用程序实时调用的系统一样设计、监控和信任。没有人准确命名的准备差距该行业已经感觉到这里有些东西不对劲。思科的AI准备度指数2025发现，83%的组织计划部署自主代理，而只有大约三分之一的组织觉得他们的基础设施真正准备好了，并且只有大约四分之一的组织觉得自己有能力控制和管理这些代理实际做什么。麦肯锡最近的AI状况调查从另一个方向描述了类似的差距：大约88%的组织现在在至少一个功能中使用AI，但大多数组织尚未在整个企业中扩大AI。当人们解释这个差距时，他们倾向于使用两个词：数据质量和治理。两个都是重要的，两个都不可以省略。但是，有一个更具体的问题隐藏在它们之下，即使干净、有序的数据也无法自行回答这个问题。系统能否确定给定记录指的是哪个现实世界实体，跨越所有记录存在的位置，马上？您可以在每个单独的系统中持有高质量的数据，但仍然无法通过这个测试，因为失败不在任何一个系统中，而是在它们之间的空间中，相同的客户在不同的系统中呈现出三种略微不同的面貌。在让代理采取行动之前要检查的内容如果您将实体解析视为活跃的基础设施，您可以像检查基础设施一样检查它。操作失败模式是具体的和可测试的：应该是单个实体的分裂身份，应该保持分开的记录的错误合并，过时的生存规则继续推广已过时的地址，缺少持久的标识符，以及代理继承源系统的模糊性，并将其视为已解决的事实。实际的准备测试不需要新的模型或新类别的供应商。收集一组您真正理解的实体。将其通过代理使用的相同检索路径运行，而不是为演示构建一个单独的干净副本。然后测量决定结果的内容：错误合并和错误拆分的数量，系统处理真正模糊性的方式，置信度阈值的位置，何时升级到人工而不是猜测，以及如何清晰地将其移交给现有的主数据和治理控制。如果团队无法回答这些问题，代理正在根据无法验证的身份采取行动，并且对其输出的信心是错误的。这并不能取代主数据管理、治理、客户数据平台或仓库。这些回答了不同的问题，并且仍然是必要的。治理决定了代理可以做什么。实体解析决定了它对谁或什么采取行动。前者在大多数大型组织中已经成熟。后者是许多组织即将发现他们需要在实时中与之并存的层，正是当他们让代理采取行动而不是建议时。我观察到的代理不需要更聪明的模型。它需要在被允许发出自信的声音之前知道两个名称是同一个客户。随着我们将这些系统赋予真正的行动权，这个安静的60年纪律不再只是清理工作，而是变得至关重要。