检索增强生成（RAG, Retrieval Augmented Generation）是一种将大规模语言模型（LLM）与外部知识源检索相结合的工程框架，旨在改进问答能力。虽然概念上看似完美，但在实际生产应用中，RAG 常面临'一看就会，一用就废'的困境。本文将深入探讨 RAG 的工作原理、常见坑点及生产环境的优化策略。
RAG 补充大模型能力
在理解 RAG 之前，需明确 LLM 的知识更新存在天然局限：
- 训练数据固定：LLM 训练完成后，知识库难以通过常规方式更新。
- 微调成本高：参数量巨大，持续 Fine-tuning 消耗资源且耗时。
- 知识不可直接编辑：知识编码在数百亿参数中，无法像数据库一样直接查询或修改。
因此，LLM 具有静态、封闭的特点。RAG 应运而生，通过外挂知识库赋予 LLM 获取新知识的能力。其主要目的包括：
- 减少 LLM 幻觉，提高回答准确性。
- 将来源/参考关联到大模型生成的回答，增强可解释性。
- 消除使用元数据注释文档的繁琐需求。
工作原理
RAG 本质上是利用工程化手段解决 LLM 知识更新困难的问题。核心是利用向量数据库存储未在训练数据中出现的新数据。通常分为三个阶段：
1. 知识索引
事先对文本数据进行清洗和分块，通过词嵌入（Embedding）等向量化技术，将文本映射到低维向量空间，并存储到向量数据库中构建可检索的索引。此阶段涉及数据加载器、分割器、向量数据库及提示工程等组件。
2. 知识检索
当用户输入问题时，RAG 系统基于向量索引进行相似度检索，找到与问题最相关的一组文档。这依赖于第一阶段建立的索引质量。
3. 生成答案
系统将输入问题及检索到的文档上下文一同提供给 LLM，让模型结合外部知识生成答案。同时控制生成长度，避免无关内容。
这种设计既发挥了 LLM 的语言生成能力，又规避了知识更新的困境，使其能更智能地回答依赖外部知识的问题。
RAG 的常见坑
在生产实践中，RAG 系统常遇到以下问题：
- 内容缺失：用户假设答案存在于知识库中，但系统未返回'我不知道'，而是编造看似合理实则错误的'幻觉'答案。
- 检索排名不佳：简单的嵌入查找往往不够精准。有时正确答案不在前 K 个检索结果中，导致后续生成失败。
- 上下文不符：检索到的文档过多或分割不当，关键信息被稀释，模型无法从上下文中提取有效答案。
- 信息提取困难：不同大模型对长上下文的理解能力参差不齐，塞满上下文可能导致模型困惑。
- 格式错误：LLM 默认输出格式可能不符合业务需求（如特定 JSON 结构），需要复杂的 Prompt 工程或指令微调。
- 回答不匹配：响应过于笼统或过于具体，无法满足特定场景（如教育、客服）的期望。
- 答案不完整：准确但缺失关键信息，即使这些信息存在于上下文中。
为啥生产中会失败？
1. 系统复杂性
将 RAG 从实验室迁移到生产线，如同赛车进入市区。系统需处理不可预测的负载、高并发请求及网络延迟，保证稳定性极具挑战。
2. 用户互动难以预测
用户背景多样，提问方式千变万化。RAG 系统需具备持续的监控和适应能力，以应对不断变化的用户行为模式。
改进思路与优化实践
直接使用基础框架（如 LangChain 默认配置）实现的 RAG 往往难以满足生产要求，需进行深度工程化优化：
1. 数据预处理与分块策略
- 清洗输入数据：去除噪声、HTML 标签及无关字符。
- 优化分块大小：根据文档类型调整 Chunk Size，避免语义割裂。可采用重叠滑动窗口（Overlap）保持上下文连贯性。
- 元数据过滤：利用文档元数据（如时间、作者、分类）进行预过滤，缩小检索范围。
