定义
RAG（Retrieval-Augmented Generation，检索增强生成）是一种 AI 架构模式：在大语言模型生成回答之前，先从外部知识库检索相关文档，将其作为上下文注入提示词，使模型基于检索到的事实生成回答，而非仅依赖训练记忆。
这个概念最早由 Facebook AI Research 在 2020 年的论文中提出（Lewis et al., NeurIPS 2020）。到 2025 年，RAG 已成为企业 AI 应用的主流架构——据 Databricks 统计，约 60% 的企业 LLM 应用已在使用 RAG 技术。
RAG 的运行流程可以概括为三步：
- 检索（Retrieval）：用户提问后，系统先在企业知识库中搜索相关文档片段
- 增强（Augmentation）：将检索到的内容作为上下文，与用户问题一起组成增强提示词
- 生成（Generation）：大语言模型基于增强提示词生成回答
为什么企业需要 RAG
大语言模型有三个固有限制，恰好是 RAG 解决的核心问题：
知识截止：模型的训练数据有截止日期。一个 2024 年训练的模型不知道 2025 年的公司政策、产品手册或行业法规变更。RAG 通过实时检索，让模型访问最新文档。
幻觉：模型有时会生成看似合理但完全错误的信息。RAG 把相关事实放在模型的「眼前」，让它基于事实回答，从架构层面减少幻觉风险。
私有数据不可达：标准大模型无法访问企业内部的合同、报告、知识库、工单系统。RAG 在查询时动态连接这些数据源，不需要把企业数据放进模型训练集。
RAG 不是什么
RAG ≠ 微调替代品
这是一个常见误解。RAG 和微调解决不同的问题：
- 微调改变模型的行为——语气、格式、领域术语理解。适合让模型「说话像我们的人」。
- RAG 提供实时事实——让模型「知道我们最新的政策和数据」。
成熟的部署同时使用两者：微调负责风格一致性，RAG 负责事实准确性和可追溯性。
RAG ≠ 万能方案
RAG 有明确的适用边界：
- 结构化数据查询（如「上季度各区域平均客单价」）——需要 SQL 查询，不是向量检索
- 实时数据（如库存、定价、系统状态）——标准 RAG 从静态索引检索，需要配合 Function Calling
- 跨长文档推理（如理解一份 50 页合同的完整脉络）——分块会丢失全局上下文
企业级 RAG 的关键决策
一个能稳定运行的 RAG 系统不只是「把文档放进向量数据库」。核心架构分为五层：
- 文档摄入：解析 PDF、Word、HTML 等格式，提取文本和元数据
- 分块（Chunking）：将长文档切分为检索单元。语义分块（按段落/章节切分）优于固定长度切分
- 向量化（Embedding）：将文本块转换为高维向量，用于语义相似度搜索
- 检索：混合搜索（语义向量 + 关键词 BM25）通常优于单一方法。重排序（cross-encoder re-rank）可进一步提升精度
- 生成：将检索到的上下文注入提示词，指示模型仅基于上下文回答
大部分质量问题出在前四层，而非 LLM 本身。 如果检索不到正确的文档，再强的模型也无法生成正确回答。
评估
生产级 RAG 系统需要量化评估。业界常用 RAGAS 框架的四个指标：
- Faithfulness（忠实度）：回答是否由检索到的上下文支撑（目标 > 0.90）
- Answer Relevancy（回答相关性）：回答是否切中问题（目标 > 0.85）
- Context Precision（上下文精度）：检索到的文档是否相关
- Context Recall（上下文召回）：需要的信息是否都被检索到
RAG 的企业价值：可追溯性
RAG 区别于其他 AI 方案的核心优势是可追溯性：每个回答可以链接到源文档的具体位置。
在法律、金融、医疗等受监管行业，「这个回答从哪里来？」不是一个可选功能，而是合规硬性要求。RAG 从架构层面提供了这种能力——回答基于检索到的文档，文档有元数据（来源、日期、作者），可以审计和回溯。
与 LangChat 平台的关联
LangChat 平台在架构决策（ADR-001）中将 RAG 列为四类一等公民能力之一（RAG / Workflow / Agent / Tool Use）。这意味着：
- RAG 是平台层的核心构造块，不是某个产品功能的附属
- LangChat AI Knowledge（企业 AI 知识库）以 RAG 为核心架构
- RAG 可以与 Workflow、Agent、Tool Use 组合使用，形成更复杂的企业 AI 应用
以上 Capability 映射基于 LangChat 自身的产品模型，不是行业通用的 RAG 定义。