不存在的表格

第二章 — 不存在的表格

一位来自东北部一家机械公司的技术人员在喝意式浓缩咖啡时告诉我们，带着威尼托人特有的平静，预示着一场灾难：“我们的聊天机器人了解所有关于发动机的信息，除了发动机的数据。” 然后他解释说。他们的内部人工智能助手可以描述产品系列、使用场景、品牌历史、竞争优势。在叙事层面上，这真是太棒了。但是当客户询问 CMP50L 型号的额定扭矩时——也就是人们打开目录查找的技术数据，购买发动机的关键数字——聊天机器人会含糊其辞，有时听起来合理，有时则不然。经过五个月的开发，运营主管越来越困惑，没有人知道原因。

诊断是偶然发现的，几乎是出于无聊，在又一次没有结论的会议后手动检查数据库时。PDF 目录包含 342 张技术表格。数据库中收到的表格为零。不是少数：零。没有一张。提取表格的 PDF 代码将数据保存到名为 columns 和 data 的字段中，而随后对其进行索引的代码则期望字段名为 headers 和 rows。一个未被尊重的“同义词”。一个在被遗忘的重构中跳过的一个内部约定。结果是，在五个月的沉默中：整个目录的数值智能——配对、功率、直径、重量、订购代码、电源电压——从水龙头流出，却从未倒入杯中。三百四十二张表格，以一种礼仪般的沉默，一张接一张地丢失。

这是一种不会发出声音的错误。它不会引发异常，不会导致崩溃，也不会出现在任何日志中。仅仅是，世界的某个部分对你的系统来说停止存在，并且没有人注意到，直到一个用户——通常是一个愤怒的用户——提出足够多的坚持不懈的问题，才显示出这个漏洞。这象征着一个比字段名称更大的问题：通用的 RAG 框架针对当前文本进行了优化——文章、网页、叙事段落——并且在处理表格时将表格视为二等公民。但意大利的企业文档是表格。技术目录、价目表、产品规格、安全数据表、订单公告：对于查阅这些文档的人来说，有价值的部分是表格部分。这是最先出现故障并且没有人注意的部分。

这个教训不是“注意字段名称”。它更麻烦：在严肃的 RAG（检索增强生成）系统中，每种类型的内容——表格、图像、字母数字代码、段落标题、脚注——都需要专门的、设计好的、经过测试的处理。而功能测试不是“聊天机器人回答简单的问题”——即使是损坏的系统也能回答这些问题，因为有足够的数据来构建一些看似合理的东西。真正的测试是“聊天机器人回答的问题迫使它接触管道的每一个部分”。具体、数字、可验证的问题。存在正确且唯一答案的问题，如果系统出错，你立刻就能知道。

如果你没有进行这个测试，你就不知道你的 RAG 是否有效。你只知道它没有抱怨。而“没有抱怨”对于人们将用于做出决策的系统来说，是一个非常低的质量标准。