业内流传着一句玩笑：“搭建一个 RAG 的演示 Demo 只需要几十行代码，但要把 RAG 真正投入生产环境，往往需要一支十几人的工程团队，花费至少半年的时间去踩坑。”如果学术界谈论的是论文中的 RAG，那么产业界实际面对的，则是深陷泥泞的 RAG。结合多个工业级项目的真实经验，我总结出企业级 RAG 落地过程中常见的八大难题。

一、数据质量成为最大瓶颈

事实上，绝大多数 RAG 项目失败的根源，并不在于模型能力不足，而在于文档处理这一步就已经被绊倒。许多企业自认为拥有海量优质数据——十几年积累下来的文档，格式五花八门，质量参差不齐，这些不成体系的内容被视作一座巨大的金矿。但问题在于：人类可读 ≠ 机器可读。对于 AI 而言，这些文档其实形同鸡肋。

Word、PDF、PPT 等文档都是为人类的视觉阅读而设计的。人类可以通过版式、加粗、字号大小、缩进，甚至一个不规则的图文混排，瞬间脑补出文章的层级结构和上下文关联。然而，AI 和解析工具实际上是“线性瞎子”，它们只能读取底层的字符流。PDF 等格式在底层甚至没有“段落”的概念，只有某个字符在屏幕上的 X/Y 坐标。这就导致人类眼中完美的文档，在机器眼里变成了碎片化的乱码。再加上缺乏统一的数据治理和元数据（Metadata）体系，这更是历史遗留的沉重包袱。因此，无数看上去高大上的 AI 项目，其核心工作实际上是在整理垃圾数据。

二、表格处理成为棘手难题

表格是人类发明的一种极其高效的二维甚至多维信息表达方式。它的意义不仅在于单元格里的内容，更在于行表头与列表头形成的交叉映射关系。大量企业知识就隐藏在各式各样、互相关联的表格之中，如果处理不好表格，数据的价值便会大幅缩水。

传统 RAG 流程在处理表格时，往往将其按行或按列展平，转成一维纯文本。这种降维处理直接摧毁了表格的空间拓扑结构，导致大量高价值的结构化信息丢失。举个例子：有一份包含“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 系统是概率性的：同一个问题，大模型每次生成的表述可能不同。面对真实用户口语化、带错别字、表述不清等千奇百怪的提问方式，在缺乏绝对且唯一的标准答案的情况下，传统的自动化测试脚本完全失效。评估从对比代码变成了高成本的语义核对，导致无法像传统软件那样做到快速迭代和量化指标。

八、生产环境面临工程挑战

经常出现演示阶段惊艳，一上线就卡死或泄密的情况。向客户一个人演示时系统 1 秒出结果，全公司几百人同时提问，带有权限过滤的向量检索加上大模型生成，直接导致系统资源耗尽，每个人要等 1 分钟以上才能看到答案一个字一个字地蹦出来。

因为很多 RAG 框架最初是由算法研究员编写的，默认场景是单机、单用户、所有数据全量开放。而在企业环境中，权限（ACL）是底线。张三和李四搜索同一个问题，底层向量库必须在几百万个向量中先剔除他们无权查看的向量，再计算相似度。这种带有极强业务逻辑的过滤规则，与向量库底层的纯数学并发计算存在严重的资源冲突，极大拖慢了吞吐量和响应延迟。

高并发下的资源竞争、权限管控、审计日志、多租户隔离、延迟与吞吐的平衡等“不性感但重要”的工程问题，在概念验证阶段容易被忽略，却在生产上线时成为拦路虎。实践中，客户更在乎系统的可靠性和响应速度，而不是模型的复杂度。

这八大难题之所以在企业级 RAG 项目中普遍存在，其根本原因在于原本面向人类的信息系统与当前 AI 的底层架构之间存在巨大的错位。解决这些难题，已经不再是微调 Prompt 就能做到的，而是需要从多模态解析、知识图谱、混合检索架构等更底层的维度去进行架构重构。