RAG 是什么
RAG（Retrieval-Augmented Generation，检索增强生成）在生成回答之前先从外部知识库检索相关片段，再把片段作为上下文交给大模型作答。它把知识从模型参数里搬到可随时更新的索引里：知识变更只需重建索引，回答还能标注出处。该范式由 Lewis 等人于 2020 年提出，现在已是企业知识库问答、客服助手与文档助手的基础架构。
基本信息
| 英文名 | Retrieval-Augmented Generation |
|---|---|
| 提出 | Lewis et al., NeurIPS 2020 |
| 基本组成 | 离线索引链路 + 在线检索链路 |
| 核心价值 | 知识可更新、回答可溯源、不必重训模型 |
| 典型场景 | 企业知识库问答、客服助手、文档检索与摘要 |
| 主要局限 | 不保证消除幻觉，需配套引用校验与评估 |
两条链路
| 链路 | 典型环节 |
|---|---|
| 离线索引 | 文档解析 → 清洗 → 切分 → Embedding → 写入向量库（带元数据） |
| 在线检索 | 问题改写 → 向量化 → 召回 → 重排 → 上下文组装 → LLM 生成 → 引用标注 |
典型使用场景
- 企业内部制度与流程问答：把制度文件入库，员工用口语提问即可定位条款
- 产品手册与技术支持：型号、错误码类问题靠检索精确命中，再由模型组织成可读答案
- 客服坐席辅助：检索历史工单与话术，实时给出建议答复并标注来源
- 法务与合规查询：要求逐条注明出处，便于人工复核
- 文档站与帮助中心问答：降低用户翻文档的成本，回答带原文链接
- 研发知识检索：把接口文档、变更记录、事故复盘统一入库，替代散落的搜索
链路示意
链路示意
用户问题 → 检索（向量 + 关键词）→ 候选片段 → 重排 → 拼进提示词 → LLM → 带引用的回答各环节主要矛盾
| 环节 | 主要矛盾 | 失控后的后果 |
|---|---|---|
| 解析 | 表格、公式、扫描件能否还原 | 切片内容缺失，答案永远缺一块 |
| 切分 | 粒度大则语境全、小则定位准 | 太粗语义被稀释，太细答案拼不全 |
| 向量化 | 检索效果与部署成本 | 模型与语料不匹配，整体召回偏低 |
| 检索 | 召回率与响应延迟 | 漏召回时后续环节无法补救 |
| 重排 | 排序精度与响应时间 | 全量重排让响应从毫秒进入秒级 |
| 生成 | 忠实原文与语言流畅 | 无约束时模型补充训练记忆里的内容 |
落地顺序建议
- 先把解析与切分调对，用向量库取回切片人工抽查
- 搭最小可用的向量检索链路，建立 question（问题）与 gold（标准答案）的评测集
- 按评测短板依次引入混合检索、查询改写、重排
- 补上引用标注与忠实度校验，再开放给真实用户
- 把评测脚本接入日常流程，避免改一处参数就整体退化
RAG 不保证消除幻觉：检索不到答案时，模型很可能用训练记忆里的旧知识冒充原文，必须用「上下文不足就拒答」的指令与评测兜底。
RAG 的效果上限由索引质量决定：解析错、切分乱、向量模型与语料不匹配时，换更强的生成模型也无法弥补。
常见误区
- 把 RAG 当成搜索引擎的替代品：它交付的是带出处的答案，需要对答案的忠实度负责，而不只是给出链接列表
- 把希望全押在向量检索上：型号、错误码、专有名词类问题仍需关键词一路补齐
- 以为入库一次长期有效：文档改版、embedding 模型升级都会让旧索引失效，必须重建
- 跳过评测集建设直接调参数：没有固定问题集与标准答案，任何优化都无法证明收益
评测集建议按业务场景分层：制度类看条款定位是否准确，操作类看步骤是否完整，故障类看是否引用到正确版本。分层统计才能判断是检索退化还是生成退化。