拥有六个极的引擎——十行代码的神话

深入调查六个部分，探讨您购买的文档聊天机器人持续“编造”信息的根本原因，以及在2026年初，有人开始探索的另一条发展方向。

深入调查六个部分，探讨您购买的文档聊天机器人持续“编造”信息的根本原因，以及在2026年初，有人开始探索的另一条发展方向。

引言——拥有八个极的引擎（但实际上只有六个）

2026年3月，米兰。一位经理打开了公司内部的聊天机器人，这是IT部门怀着极大的热情和一丝不信任“在两周内”搭建的。他提出了一个非常简单的问题：“CMP40M 引擎有多少个极？” 聊天机器人用大型语言模型惯有的十足的自信回答道：“CMP40M 引擎有八个极。”

错误。它有六个。正确的答案不在那个422页的目录中，那是有人几个月前充满信心地倾倒到一个向量数据库中，认为从那时起，系统“就会知道一切”。那个数据根本不在目录里。它在一个PDF文件中，附在SEW技术人员的电子邮件中，存放在一个没有人费心去索引的文件夹里。

这个场景，在不同的行业和语境下，在数百家意大利办公室重演。承诺很简单且诱人：将所有公司文件提供给你的AI助手，它就能回答关于这些文件的任何问题。现实却更加平淡：聊天机器人会阅读但无法理解，会搜索但找不到，而且当它找不到时——它不会告诉你——它会编造。它会流畅地编造，语法完美，数字合理。这比不回答更糟糕。

在2024年末到2026年初，我们花费了几个月的时间来剖析这些失败。不是为了煽动争议，而是为了理解一件事：为什么一个如此线性的想法——“给他文件，然后问他问题”——在离开演示舞台，进入真实服务器房间时会变得如此困难。

这篇分为六个章节的调查讲述了我们发现的内容：静默的错误会删除整个目录，云端重新排序器拥有错误的分数，并非由模型而是由几年前受污染的数据产生的幻觉，每条查询都比其价值更昂贵的传出账单，以及那些承诺用十行代码就能完成一切的“流行”框架，前提是不要对它们要求太多。在最后一章中，我们讲述了从 2026 年初开始，有人悄悄开始采取的不同方向——一种搜索策略不再是代码，而是任何公司员工都可以阅读和修改的文档的架构。

每个章节都可以独立阅读。如果你想从 342 张消失的表的故事开始，或者从那个说谎的重新排序器的故事开始，你可以自由地这样做。但整个故事的寓意只有在最后才会显现：企业级的 RAG——这个技术首字母缩略词代表 Retrieval-Augmented Generation，即“基于检索到的文档生成答案”——还不是一个成品。它是一片前沿。正如所有前沿一样，到目前为止，它主要由销售人员讲述。是时候倾听那些真正体验过它的人了。

第一章 — 十行代码的神话

从2023年起，每一场关于人工智能的会议上的幻灯片都是一样的：“您的企业文档助手，只需10行代码。” 标题下方是一个用柔和色彩呈现的Python代码块，展示了一个开源库——通常是那些著名的美国库，其名称让人联想到树链或藏族喇嘛——它加载PDF文件，将其分割成块，将其粘贴到向量数据库中，并使用语言模型对其进行查询。 五分钟，你就有了一个聊天机器人。 五分钟，掌声雷动。 五分钟，一家意大利中型企业就相信问题已经解决，并且他们的IT部门可以在两周内完成。

问题——幻灯片上没有说明的是——演示是使用三个格式良好的PDF文件构建的，一个专门定制的问题以匹配内容，一个没有实际延迟的舞台，以及一个在登上讲台前已经练习了二十七次的演示者。 在现实中，企业文档是一场地质灾难：扫描的扫描，表格覆盖在文本上，脚注插入段落，像“RH1M”这样的字母数字代码被分块器切成两半，误以为是单词，图像包含70%的有用信息，但没有人真正提取，以及需要考古学家而不是解析器的创意布局。

RAG——这是其核心理念——是一个绝妙的想法。获取用户的提问，在您的档案中搜索最相关的文档，将其传递给语言模型，并获得基于这些文档的答案。从理论上讲，它巧妙地解决了幻觉问题：模型不再需要“知道”答案，它只需要“阅读”您提供的片段即可。但在实践中，链条中的每一个环节——分块、嵌入、检索、重新排序、最终生成——都有其失效的方式，而且失效很少表现为可见的错误。它表现为略微错误的答案。然后是完全错误的答案。然后是经理质疑为什么他要为一个比实习生知识还少的东西付费。

使 RAG 流行起来的开源框架是为了演示，而不是为了生产。它们是由优雅的抽象层层堆叠而成的，每一层都隐藏着一个未言明的假设：你的 PDF 具有像样的 OCR，你的照片已经被描述过，你的表格遵循某种约定，嵌入模型真正理解你的语言（剧透：很多模型只擅长英语），你的档案已经清理了重复数据。当这些假设中的一个失效时——至少有一个总是会失效，几乎总是三个——系统并不会停止工作。更糟糕的是，它停止良好地工作，但仍然会给出答案。流畅、自信，但往往与事实脱节的答案。

在构建这些系统的人群中流传着一句话，你永远不会在教程中看到：“RAG 很容易做，但很难做好。” 从第一个演示到生产服务之间存在着鸿沟，而增加 GPU 或更改模型无法弥补这一鸿沟。弥补鸿沟的关键在于理解一个令人不安的事实：当你构建企业级 RAG 时，你不是在编写代码。你是在为你的文档设计一个小型、顽固的定制搜索引擎，这其中包含所有编辑选择——什么是噪音，什么是信号，什么需要索引两次，什么应该丢弃。只是在十行代码的教程中，这些选择已经被别人代替你做了一次，而且这个人从未见过你的文档。而且这些选择几乎总是对你的情况错误的。