泥泞里的 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 跑来投诉：“怎么以前能查到的产品手册，今天全查不到了？”

缺乏系统的量化评估，导致没人知道一次代码提交会带来什么连锁反应。

因为，传统软件工程的评估是确定性的，输入1 1，必须输出2，否则就是Bug。

而 RAG 系统是概率性的。

同一个问题，大模型每次生成的表述可能不同。

面对真实用户口语化、带错别字、表述不清等等，千奇百怪的提问方式。

在缺乏绝对且唯一的标准答案的情况下，传统的自动化测试脚本完全失效。

评估从对比代码，变成了高成本的语义核对，导致无法像传统软件那样做到快速迭代和量化指标。

八、生产环境的工程挑战

经常出现 Demo 阶段惊艳，一上线就卡死或泄密。

向客户一个人演示时，系统1秒出结果。

全公司几百人同时提问，带有权限过滤的向量检索 大模型生成，直接导致系统资源耗尽，每个人都要等1分钟以上才能看到答案一个字一个字地蹦出来。

因为，很多 RAG 框架最初是由算法研究员写的，默认场景是单机、单用户、所有数据全量开放。

而在企业里，权限（ACL）是底线。

张三和李四搜同一个问题，底层向量库必须在几百万个向量中，先剔除他们无权查看的向量，再计算相似度。

这种带有极强业务逻辑的过滤规则，与向量库底层的纯数学并发计算存在严重的资源冲突，极大地拖慢了吞吐量和响应延迟。

高并发下的资源竞争、权限管控、审计日志、多租户隔离、延迟与吞吐的平衡等不性感但重要的工程问题，在概念验证阶段容易被忽略，却在生产上线时成为拦路虎。

实践中，客户更在乎系统的可靠性和响应速度，而不是模型的复杂度。

这八个难题之所以在企业级 RAG 项目中普遍存在，其根本原因在于原本面向人类的信息系统与当前 AI 的底层架构之间存在巨大的错位。

解决这些难题，已经不再是调调 Prompt 就能做到的，而是需要从多模态解析、知识图谱、混合检索架构等更底层的维度去进行架构重构。

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2026-03-04，如有侵权请联系[email protected] 删除