为什么你的 RAG 应用在生产环境中会失败（以及如何修复）

你构建了一个 RAG 应用。演示效果令人印象深刻。管理层非常满意。然后你上线了。

现实随之而来。

用户收到错误的答案。聊天机器人自信地给出错误信息。真实流量涌入时延迟飙升。向量搜索返回不相关的 Chunk。支持工单不断堆积。

你并不孤单。这是当前企业 AI 项目中最常见的轨迹。"在演示中可以运行"和"在生产环境中可以运行"之间的差距——正是大多数 RAG 项目走向失败的地方。

本文将拆解 RAG 最常见的 7 种失败模式，并提供每种模式的具体解决方案。

RAG 是什么，为什么它如此脆弱？

RAG 是 Retrieval-Augmented Generation（检索增强生成）的缩写。与其完全依赖 LLM 的训练数据，RAG 系统会从你自己的知识库中检索相关文档，并在模型回答之前将其注入 Prompt。

听起来很简单，但实际上并非如此。

从 Ingestion、Chunking、Embedding、Retrieval、Ranking、Prompting 到 Generation，Pipeline 中的每个步骤都可能以不可见的方式出错——直到真实用户出现时才会暴露。

失败模式一：Chunk 太大（或太小）

这是最常见的错误，也是最难调试的，因为表面上一切看起来都很正常。

在导入文档时，你需要在 Embedding 之前将其拆分成 Chunk。如果 Chunk 太大，Embedding 就会变成多个概念的模糊平均值——检索返回了正确的文档，但给出了错误的上下文。如果 Chunk 太小，使答案有意义的周围上下文就会丢失。

解决方案： 采用混合 Chunking 策略。从语义分割开始（按段落或章节边界拆分，而不是固定的 Token 数量）。然后使用父子架构：用小 Chunk 进行精确检索，但将较大的父 Chunk 返回给 LLM 作为上下文。LlamaIndex 等库可以让这个过程变得简单直接。

实用起点：256-512 Token 的 Chunk，10-15% 的重叠率，针对实际查询集进行评估。

失败模式二：你在测量错误的指标

大多数团队用他们确定在文档中的问题来测试 RAG。而生产环境中的用户会以你从未预料到的方式提问。

如果没有评估框架，你就是在盲飞。你不会知道模型更新、数据更新或 Prompt 更改是何时破坏了某些东西。

解决方案： 在上线前构建评估集。收集 50-100 个真实或贴近真实的查询。为每个查询定义预期答案和预期来源文档。然后衡量三件事：

Retrieval Recall（检索召回率） — 正确的 Chunk 有没有被检索回来？
Answer Faithfulness（答案忠实度） — LLM 是否严格依据检索到的内容回答？
Answer Relevance（答案相关性） — 答案是否真正回答了问题？

RAGAS、DeepEval 或简单的 LLM-as-judge 设置都可以自动化这个过程。每次部署都运行评估。

失败模式三：Embedding 与查询风格不匹配

Embedding 对语义意义进行编码——但 500 词技术文档 Chunk 的含义与 10 词用户查询的含义有本质区别。这种不匹配会悄无声息地破坏检索质量。

许多团队对所有内容都使用通用 Embedding 模型（如 text-embedding-ada-002）。在演示中效果不错，因为演示查询都是精心设计的。但当真实用户提出简短、模糊或特定领域的问题时，它就会失效。

解决方案： 使用专为非对称搜索训练的 Embedding 模型——即短查询检索长文档的场景。bge-large-en-v1.5 和 Cohere embed-v3 是不错的选择。更好的方案是：在你自己领域的查询-文档对上微调 Embedding 模型。几百个示例就可以显著提升检索精度。

同时测试：在查询前添加类似 "search query: " 的前缀是否能改善检索效果？某些模型的训练预期中包含这种前缀。

失败模式四：检索的 Chunk 太多（或太少）

大多数 RAG 教程的默认值是 top_k=3 或 top_k=5。在生产环境中，这个数字至关重要。

检索 Chunk 太少会错过关键上下文。检索太多会让 Prompt 充满噪声——LLM 感到困惑，延迟上升，成本增加。

解决方案： 让 top_k 动态化。对于狭义的事实查询，3 个 Chunk 就足够了。对于复杂的推理问题，可能需要 8-12 个。使用 Reranker（如 Cohere Rerank 或 Cross-encoder 模型）作为第二道筛选，在发送给 LLM 之前对检索到的 Chunk 进行相关性评分。这让你可以广泛检索，然后积极地筛选。

此外：设置相关性阈值。如果没有检索到的 Chunk 相似度分数超过 0.7，不要凭空捏造答案——告诉用户你没有这些信息。