生产环境中的 RAG 实践与常见困境分析
RAG（Retrieval Augmented Generation，检索增强生成）是一种将大规模语言模型（LLM）与外部知识源检索相结合的工程框架，旨在改进问答能力。虽然概念上看似完美，但在实际应用中，RAG 往往面临'一看就会，一用就废'的困境，难以直接满足生产需求。本文将深入探讨 RAG 的核心原理、常见陷阱以及生产环境下的优化方案。
RAG 补充大模型能力
在使用 RAG 之前，需要理解 LLM 知识更新的局限性：
- 训练数据固定：LLM 的训练数据集是静态的，一旦训练完成，很难通过继续训练来更新知识。
- 微调成本高：参数量巨大，随时进行 Fine-tuning 消耗大量资源且耗时较长。
- 知识黑盒：知识编码在数百亿参数中，无法直接查询或编辑其中的知识图谱。
因此，LLM 具有静态、封闭和有限的特点。RAG 应运而生，赋予 LLM 持续学习和获取新知识的能力。
一般 RAG 的主要目的包括：
- 减少 LLM 的幻觉回答问题
- 将来源/参考关联到大模型生成的回答
- 消除使用元数据注释文档的需要
工作原理
RAG 本质上是通过工程化手段，解决 LLM 知识更新困难的问题。其核心是利用外挂于 LLM 的知识数据库（通常使用向量数据库）存储未在训练数据集中出现的新数据、领域数据等。RAG 将知识问答分成三个阶段：索引、知识检索和基于内容的问答。
第一阶段：知识索引
事先将文本数据进行处理，通过词嵌入等向量化技术，将文本映射到低维向量空间，并将向量存储到数据库中，构建起可检索的向量索引。此阶段涉及数据加载器、分割器、向量数据库、提示工程等组件。
第二阶段：知识检索
当输入一个问题时，RAG 会对知识库进行检索，找到与问题最相关的一批文档。这依赖于第一阶段建立的向量索引，根据向量间的相似性进行快速检索。
第三阶段：生成答案
RAG 把输入问题及相应的检索结果文档一起提供给 LLM，让 LLM 充分把这些外部知识融入上下文，并生成相应的答案。RAG 控制生成长度，避免生成无关内容。
这种设计既发挥了 LLM 强大的语言生成能力，又规避了其知识更新的困境，使之能更智能地回答各类问题，尤其是需要外部知识支持的问题。
RAG 的常见坑
在生产案例中，RAG 系统常遇到以下问题：
- 内容缺失：用户假设特定问题的答案存在于知识库中，但事实并非如此。系统没有回应'我不知道'，而是提供了一个看似合理但毫无意义的错误答案。
- 漏掉排名靠前的文档：检索器是小型搜索系统，简单的嵌入查找很少能达到目的。有时，检索器返回的前 K 个文档中不存在正确答案，导致失败。
- 不符合上下文：RAG 系统可能检索到太多文档，强制根据上下文分割并输入。这意味着对问题的回答不在上下文中，可能导致模型产生幻觉。
- 未提取到有用信息：当 LLM 无法从上下文中提取答案时，尤其是塞满上下文导致模型困惑时。不同大模型对背景信息的理解能力参差不齐。
- 格式错误：特定格式的输出不是 LLM 的开箱即用功能。这需要大量的系统提示和指令微调，以生成特定格式的信息。
- 不合适的回答：响应中返回答案，但不够具体或过于具体，无法满足用户需求。
- 不完整：不完整的答案是准确的，但缺少一些信息，即使这些信息存在于上下文中并且可用于提取。
为啥生产中会失败？
1. 系统太复杂
把 RAG 从实验室搬到生产线，就像是把一辆赛车从赛道开到市区。RAG 需要处理各种不可预测的负载，保证在高需求下也能稳定运行。复杂的链路增加了故障排查的难度。
2. 用户互动难以预测
用户的行为模式可能随时间而变化，RAG 系统必须能够适应这些变化，不断学习和优化。用户来自不同的背景，有着不同的知识水平和期望，这就要求 RAG 不仅要有广泛的知识储备，还要具备一定的推理和判断能力。
改进思路与优化方案
由于上述缺点的存在，直接使用基础框架实现的 RAG 几乎无法直接在生产中使用，需要进行大量的工程化优化。以下是关键的优化方向：
