泥泞中的 RAG

业内有一句玩笑话“做个 RAG 的 Demo 只要几十行代码但把 RAG 推向生产环境需要一支十几人的工程团队至少踩半年的坑。”如果学术界是论文中的 RAG那么产业界面对的则是泥泞中的 RAG。根据工业级项目的实战我总结了八个 RAG 在企业真实落地时遇到的难题。一、数据质量是最大瓶颈绝大多数 RAG 项目的失败的原因不是模型不好而是低估了文档处理的复杂性。很多企业认为自己拥有高质量的数据积累了十几年、格式五花八门、质量参差不齐、不成体系的文档是巨大的金矿。但是人类可读 ≠ 机器可读对于 AI 而言这些文档其实是鸡肋。Word、PDF、PPT 等文档都是为人类视觉阅读设计的。人类可以通过版式、加粗、字号大小、缩进甚至是一个不规则的图文混排瞬间脑补出文章的层级结构和上下文。但 AI 和解析工具是线性瞎子它们只能读取底层的字符流。PDF等格式在底层甚至没有段落的概念只有某个字符在屏幕的X/Y坐标。这就导致人类眼里的完美文档在机器眼里是碎片化的乱码。另外缺乏统一的数据治理和元数据Metadata体系更是历史遗留的沉重包袱。因此无数看上去高大上的 AI 项目其核心工作实际上是在整理垃圾数据。二、表格处理难题表格是人类发明的一种极其高效的二维、甚至多维的信息表达方式它的意义不仅在于单元格里的内容更在于行表头和列表头的交叉映射关系。大量企业知识隐藏在各式各样、互相关联的表格中处理不好表格数据的价值就丢掉了一大块。传统 RAG pipeline 在处理时往往把表格按行或按列展平变成一维的纯文本。这种降维处理直接摧毁了表格的空间拓扑结构导致大量高价值的结构化信息丢失。例如有一份包含“iPhone 13、14、15”和“屏幕尺寸、电池、价格”的参数对比表。被RAG拍扁成纯文本后变成了“iPhone13 iPhone14 iPhone15 屏幕 电池...”。当用户问“iPhone 14的电池容量是多少”大模型大概率会把 iPhone 13 或 15 的电池容量张冠李戴回答出来因为表格的三维映射关系在转换成文本的一瞬间就崩溃了。三、分块困境分块Chunking是 RAG 工程中最基础、最棘手的环节之一。采用 100-256 Token 的小块虽然语义聚焦但丢失上下文。采用 1000-2000 Token 的大块希望能把上下文全包进去但又引入噪声影响匹配精度。更麻烦的是法律法规、技术手册、会议纪要等企业文档结构、体裁各不相同需要不同的分块策略。其根本原因是人类语言的弹性上下文依赖与 Embedding 模型固定的数学降维逻辑之间的矛盾。为什么大块不行因为维度是固定的如果把一整页纸压缩进1024个数字里特定细节的特征就会被严重稀释导致检索不到。为什么小块不行语言是高度依赖上下文的如代词“他”、“这个项目”等。切得太小失去了上下文这句话的向量就变成了无意义的孤儿。四、相关 ≠ 有用用户期望得到能直接解决问题的答案而向量模型只能衡量语义距离不懂逻辑、不懂因果、更不懂意图。这种现象在客服、技术支持等场景尤为突出。因为Embedding 模型是通过海量语料训练出来的它只能理解词语和句子的分布相似度或主题相近度。例如“汽车发动机无法启动”和“汽车发动机工作原理”因为词汇高度重合在向量空间里可能距离极近。但用户遇到故障时需要的是排除故障的步骤因果与逻辑而不是工作原理相关概念。五、多跳推理与长链条问答用户的真实问题往往需要综合多个文档、多个段落的信息才能回答传统的检索-生成单次流水线难以处理这类需要推理的场景。例如用户问“审批去年的‘光伏采购项目’的部门负责人是谁”系统需要先找“光伏采购项目属于哪个部门”假设是新能源部再去查“新能源部的负责人是谁”假设是张三。传统 RAG 会直接拿着原问题去向量库里搜根本找不到同时包含这三个关键词的句子。最终大模型只能回答“文中未说明光伏采购项目的负责人”。因为RAG 为了检索第一步就是把文档切碎相当于人为制造了信息孤岛切断了知识之间的关联链路。多跳推理要求先找 A根据 A 找 B再找 C。每一次检索都是一次概率匹配假设每次准确率80%如果是三跳推理准确率就变成了 80%×80%×80%51.2%。传统向量库缺乏知识图谱那种显式的节点导航能力导致检索链条越长噪声干扰越大最终迷失在向量空间里。六、知识更新企业知识是动态的。如果不能及时更新就会出现前朝的剑斩本朝的官的情况。例如公司昨天发布了新规报销额度从500降到200。IT 部门往知识库里传了新文档但由于没有删除老文档的向量索引。用户问“现在报销额度是多少”检索系统会同时把“500”和“200”两个版本的规定都捞出来扔给大模型。大模型困惑了可能会回答“报销额度是500也有可能是200”或者强行编造一个“350”。这在合规和法律场景下是极其致命的。其根本原因是主流向量数据库建库容易修改极难。它们为了追求毫秒级的检索速度在底层构建了极其复杂的图索引结构如近似最近邻算法ANN等。当你想要删除或更新一条过期的知识时不仅要删掉节点还要重新编织复杂的图拓扑结构。涉及到分布式系统下原子性、一致性等复杂的工程问题。因此增量更新在底层架构上本身就是成本高昂且脆弱的操作。七、评估困难RAG 系统经常测试集高分实操拉垮或者发生回归灾难。根源是生成式大模型的非确定性与真实用户意图的无限发散之间的矛盾。具体表现是按下了葫芦浮起了瓢优化变成了一门玄学。例如开发人员用100个标准测试题测出来准确率95%。结果上线后真实用户提问不用书面语而是发语音转文字“那个啥报销单填错了咋整啊”RAG 系统瞬间瘫痪无法理解准确率跌破30%。又如为了修复用户 A 抱怨的“查不到最新政策”的问题工程师微调了分块大小和 Prompt 。结果用户 A 满意了但第二天用户 B、C、D 跑来投诉“怎么以前能查到的产品手册今天全查不到了”缺乏系统的量化评估导致没人知道一次代码提交会带来什么连锁反应。因为传统软件工程的评估是确定性的输入11必须输出2否则就是Bug。而 RAG 系统是概率性的。同一个问题大模型每次生成的表述可能不同。面对真实用户口语化、带错别字、表述不清等等千奇百怪的提问方式。在缺乏绝对且唯一的标准答案的情况下传统的自动化测试脚本完全失效。评估从对比代码变成了高成本的语义核对导致无法像传统软件那样做到快速迭代和量化指标。八、生产环境的工程挑战经常出现 Demo 阶段惊艳一上线就卡死或泄密。向客户一个人演示时系统1秒出结果。全公司几百人同时提问带有权限过滤的向量检索大模型生成直接导致系统资源耗尽每个人都要等1分钟以上才能看到答案一个字一个字地蹦出来。因为很多 RAG 框架最初是由算法研究员写的默认场景是单机、单用户、所有数据全量开放。而在企业里权限ACL是底线。张三和李四搜同一个问题底层向量库必须在几百万个向量中先剔除他们无权查看的向量再计算相似度。这种带有极强业务逻辑的过滤规则与向量库底层的纯数学并发计算存在严重的资源冲突极大地拖慢了吞吐量和响应延迟。高并发下的资源竞争、权限管控、审计日志、多租户隔离、延迟与吞吐的平衡等不性感但重要的工程问题在概念验证阶段容易被忽略却在生产上线时成为拦路虎。实践中客户更在乎系统的可靠性和响应速度而不是模型的复杂度。这八个难题之所以在企业级 RAG 项目中普遍存在其根本原因在于原本面向人类的信息系统与当前 AI 的底层架构之间存在巨大的错位。解决这些难题已经不再是调调 Prompt 就能做到的而是需要从多模态解析、知识图谱、混合检索架构等更底层的维度去进行架构重构。