外观
RAG：检索增强生成
RAG（Retrieval-Augmented Generation，检索增强生成）是一种"先检索外部知识、再把检索结果拼入上下文、最后让大模型生成答案"的架构模式。它把大模型从"闭卷考试"变成"开卷考试"：模型不需要记住所有事实，只需要学会"基于给定的材料作答"。RAG 是当前企业落地大模型的第一选择，也是缓解 幻觉：成因与缓解 最有效、最可落地的方案。
一、动机：大模型的四个短板
| 短板 | 表现 | RAG 的解法 |
|---|---|---|
| 知识截止 | 不知道训练之后的新事件、新知识 | 从外部知识库实时检索 |
| 幻觉 | 一本正经编造事实 | 用检索到的真实材料约束生成 |
| 私有数据 | 公司文档、数据库不对公众可见 | 检索企业私有知识库 |
| 不可溯源 | 回答没有依据，无法核对 | 答案可链接回原文片段 |
RAG 背后的判断是："模型是否知道"和"模型能否基于材料作答"是两件事。前者靠预训练（昂贵、静态），后者靠上下文（廉价、可更新）——RAG 选择后者。
RAG 的本质
RAG 把"知识"从模型权重中剥离出来，放进可索引、可更新、可审计的外部存储。代价是每次回答都要多做一次检索；收益是知识永远不过期、永远可溯源、私有数据永不进模型。
二、三阶段流程：索引 → 检索 → 生成
┌────────────────────────────────────────────────────┐
│ ① 索引阶段（离线，一次性） │
│ 文档 → 解析/清洗 → 分块(chunking) → 向量化 → 向量库 │
├────────────────────────────────────────────────────┤
│ ② 检索阶段（在线，每次提问） │
│ 问题 → 向量化 → 相似度 top-k → (重排序) → 候选片段 │
├────────────────────────────────────────────────────┤
│ ③ 生成阶段（在线，每次回答） │
│ [系统提示 + 检索片段 + 问题] → LLM → 带引用答案 │
└────────────────────────────────────────────────────┘1. 索引阶段
- 解析清洗：PDF/Word/网页 → 纯文本，去页眉页脚、目录、噪声；
- 分块（chunking）：把长文切成检索单元，见下文；
- 向量化：用 embedding 模型（如 bge、E5、text-embedding 系列）把每个 chunk 编码成向量；
- 存储：写入向量库（FAISS、Milvus、pgvector、Qdrant 等），同时保留原始文本（供引用与重排序）。
2. 检索阶段
把用户问题编码成向量，与库内向量做相似度检索（余弦/内积），取 top-k；高质量系统还会再做一次重排序，把最相关的片段顶到前面。
3. 生成阶段
把检索片段拼接进提示词：
系统: 你是一位客服助手，只能依据"知识库资料"回答，资料中没有的请明确说明。
资料:
[1] 退货政策：签收后 7 天内可无理由退货……
[2] 退款时效：退货审核通过后 3~5 个工作日到账……
用户: 我昨天退货了，什么时候能收到退款？
回答: 根据资料[2]，退货审核通过后 3~5 个工作日到账……4. 为什么索引质量决定上限
RAG 有一个"水桶效应"：整个系统的上限由最弱环节决定，而多数项目的短板在索引。文档解析的错误（表格被拆乱、扫描件识别错字）会原样污染检索；chunk 切得不合理会让语义断裂；向量化的质量决定"语义相近"能不能被召回。反过来说，索引环节的投入产出比极高：一份干净、合理分块、带元数据的索引，常常比换一个更强的生成模型带来更明显的质量提升。这也是为什么生产级 RAG 团队会把大部分时间花在文档治理与索引迭代上，而不是调模型。索引、检索、生成三阶段的工程细节见 RAG 实战。
5. 一个最小可行的 RAG 原型
不要被工具链吓住，一个最小原型只需要四样东西：一个 embedding 模型（bge 或 OpenAI 的 embedding API）、一个向量库（FAISS 或内存实现即可）、一段检索代码、一段拼接提示词。用 50 条文档跑通"提问→检索→拼接→生成→引用"，再逐步加上重排、混合检索与评测。先跑通再优化，是 RAG 项目避免过度工程的第一原则。
三、检索器与 chunking：RAG 质量的两块基石
1. 三类检索器
| 检索器 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| 稀疏检索 BM25 | 词法匹配 + TF-IDF 加权 | 无需训练、精确词匹配、可解释 | 语义不通、同义改写召回差 |
| 密集检索 | 双塔 embedding 余弦相似度 | 语义匹配、跨语言 | 依赖 embedding 质量、需训练数据 |
| 混合检索 | BM25 + 密集 加权融合（RRF） | 兼顾精确与语义，最稳 | 多一层工程 |
重排序（Rerank）通常用 cross-encoder：把 query 与每个候选片段拼起来整体编码打分，比双塔的"分别编码再比相似度"更精确（但更慢，所以只对 top-k 精排）。
检索质量不好时，所有下游优化（提示、模型）都是在"错误信息上精雕细琢"。这就是为什么专业团队会把检索评估（Recall@k、MRR、nDCG）单独做成流水线：先让检索达标，再谈生成。一个实用的经验阈值：top-5 召回率低于 70% 时，先优化索引与检索，不要急于调生成端。评估工具与流程见 评估实战。
2. Chunk 策略对比
| 策略 | 做法 | 适用 |
|---|---|---|
| 固定大小 | 按 256/512 token 切，带重叠（overlap） | 通用、简单 |
| 递归字符 | 按段落/句/词逐级回退切分 | 结构复杂文档 |
| 语义分块 | 用 embedding 相似度找天然边界 | 长文档、主题切换明显 |
| 结构感知 | 按 Markdown/HTML 标题、表格行切 | 手册、网页、表格 |
经验法则：chunk 太小丢失上下文、太大检索噪声多；一般 200~800 token 区间实验调参。更细的工程细节见 RAG 实战。
四、演进路线：Naive → Advanced → Modular
1. Naive RAG（2020–2023 早期）
原始论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》（Lewis et al., 2020，Facebook AI Research）用 DPR 检索 + BART 生成，在开放域问答（Natural Questions 等）上取得当时 SOTA。早期实践的"朴素版"就是最直接的"向量检索 + 拼接生成"。问题很典型：检索质量差、噪声片段污染答案、无重排序、无查询理解——检索错了，生成再强也白搭。
2. Advanced RAG（2023）
对三个环节分别打补丁：
| 环节 | 优化手段 |
|---|---|
| 查询侧 | 查询改写（rewriting）、多查询扩展、HyDE（让模型先生成假设答案再检索） |
| 索引侧 | 更好的 chunking、元数据过滤、父子分块 |
| 检索侧 | 混合检索 + 重排序 + 上下文压缩（只保留相关片段） |
代表作：HyDE（2022，用"生成式伪文档"改善零样本检索）、RAG-Fusion（多查询 RRF）。
3. Modular RAG（2023 底–2024）
把 RAG 拆成可编排的模块（查询规划、路由、记忆、反思、重写），允许检索循环多次，甚至让模型自我评估检索结果：
- Self-RAG（2023）：模型生成"反思 token"，自行判断"是否需要检索、检索结果是否相关、回答是否被证据支持"；
- CRAG（Corrective RAG）（2024）：对检索结果质量打分，差则触发"查询重写再检索"，避免带病作答。
Modular RAG 已经是今天企业级 RAG 的事实形态：RAG 不再是固定流水线，而是可编程的检索-生成环路。
RAG 演进的主线其实是"认知复杂度"的提升：Naive 阶段是"固定流水线"（一次检索一次生成），Advanced 阶段是"可控流水线"（每环节可优化），Modular 阶段是"可编程流水线"（模块自由编排）。这条主线与 Agent 的发展高度同构——事实上，Modular RAG 已经与 基于 LLM 的 Agent 深度融合：检索、重排、改写、反思都可以是 Agent 的工具与决策。未来 RAG 与 Agent 的边界会越来越模糊，理解这个趋势有助于选择技术方向。
Naive RAG 的三大翻车现场
① 检索到无关片段 → 答案被带偏；② 片段太多塞爆上下文 → 关键信息被淹没；③ 知识库更新了但向量库没重建 → 旧数据作答。凡是"RAG 效果差"，先排查这三处，别急着换模型。
五、RAG vs 微调 vs 长上下文
| 维度 | RAG | 微调 | 长上下文 |
|---|---|---|---|
| 知识来源 | 外部检索（可实时更新） | 写入权重（静态） | 上下文内给全文 |
| 知识截止问题 | 更新索引即可 | 需重新训练 | 需把新文档全塞进去 |
| 幻觉缓解 | 强（有依据） | 弱（仍会编造） | 中（长文仍会"中间迷失"） |
| 可溯源 | 可引用原文 | 不可 | 不可 |
| 成本 | 检索开销 + 每次带上文 | 一次性训练成本 | 长文本推理成本高（O(n²) 注意力） |
| 延迟 | 中（多一次检索） | 低 | 高（长输入编码） |
| 适用 | 事实类、知识库问答、实时数据 | 风格/格式/领域行为 | 单文档深度分析、代码库上下文 |
| 组合使用 | ✓ 最常见组合：RAG 给知识 + 微调给风格 |
选型口诀：知识类问题 → RAG；行为类问题 → 微调；单篇超长文档深度分析 → 长上下文。三者不是互斥而是叠加——详见 微调：SFT 与参数高效微调 与 上下文与长文本。
三者的组合还有一个更精细的视角：它们解决的是不同层次的问题。RAG 解决"知识从哪来"（事实来源），微调解决"行为长什么样"（风格与格式），长上下文解决"单次能看多少"（信息带宽）。一个常见的最优解是：用 RAG 接入最新与私有知识，用长上下文承载单篇大文档（如合同、论文），再用微调或提示固化输出风格。决策顺序建议是：先 RAG，再长上下文（按需），最后微调（有明确行为诉求时）——这个顺序也符合"先便宜后昂贵、先可逆后不可逆"的工程原则。
还有一个值得单独强调的对比维度：更新成本。微调一次的成本以万元级起、需要数天；长上下文每次都要把全文送进模型（token 费用高）；而 RAG 的更新只需重建索引（分钟到小时级、成本低）。在"知识会频繁变化"的场景（政策、价格、库存），RAG 几乎是唯一现实的选择；在"知识稳定且格式要求高"的场景，微调可能更合适。把这个"更新频率"维度加入决策，是很多团队选型出错的原因。
为什么长上下文没有"杀死"RAG？
长上下文解决"能不能读长"，但解决不了"知识从哪来"：企业文档每天更新，不可能每篇都塞进 128K 上下文，而且越长越贵、越长越容易"中间迷失"。RAG 用"只带相关片段"的方式，同时解决了成本与精准度。
六、RAG 评估：检索、生成、端到端三层
| 层 | 指标 | 说明 |
|---|---|---|
| 检索 | Recall@k、MRR、nDCG | 相关片段是否被召回、排序是否靠前 |
| 生成 | 忠实度（faithfulness）、答案相关（answer relevance） | 答案是否严格基于检索片段、是否答非所问 |
| 端到端 | RAGAS 综合分、人工评测、A/B | 用户可感知的整体质量 |
RAG 评估有三个常见误区。其一，只看端到端分数——端到端分数高不代表检索好，可能是生成模型"猜"对了，掩盖了检索缺陷；要同时看检索层指标（Recall@k、MRR）。其二，评测集与生产分布脱节——用论文的公开问答集测自己的知识库，结论基本无意义；评测集必须从真实用户问题抽样。其三，忽略"负样本"——只测"库里有的答案"会高估系统，要测"库里没有的问题"，看模型是否诚实说不知道（而不是编造）。这三点对应 RAG 评估体系的"分层、真实、覆盖"三原则，详细方法见 评估实战 与 评测与基准。
RAGAS 是 2023 年提出的框架化评估（论文见参考资料），把 RAG 质量拆成"忠实度 + 答案相关 + 上下文相关"三指标，可低成本自动化打分。评估集必须自建：从真实用户问题抽样，标注"期望片段 + 期望答案"，见 评估实战。
七、代表系统
| 系统 | 时间 | 亮点 |
|---|---|---|
| 微软必应 Chat（New Bing） | 2023.2 | 搜索引擎 + 生成式回答的首次大规模融合，问答带来源链接 |
| Google Bard / Gemini | 2023.3 起 | 搜索增强生成，逐步演进 |
| Perplexity AI | 2023 起 | 纯 RAG 式 AI 搜索引擎，回答全程引用来源 |
| Bespoke-Minerva | 2023.12 | Arcee 开源"RAG 专用微调模型"（基于 Llama），展示"检索 + 微调"结合 |
| 企业级平台 | 2023 起 | Azure AI Search、AWS Kendra、OpenSearch 等把 RAG 做成开箱产品 |
代表系统验证了同一个结论：RAG 的护城河不在模型，而在"知识底座 + 检索质量 + 引用体验"——谁的文档治理、索引质量、检索调优做得好，谁的问答产品就可靠。
搜索引擎是 RAG 最天然的宿主——它们早已拥有大规模索引、排序与点击反馈。必应 Chat 与 Google Bard 把"检索结果 + 生成式回答"结合，既改善了信息消费体验，也为"引用可溯源"提供了基础设施。这解释了为什么 RAG 的标杆系统多来自搜索厂商：RAG 的难点从来不在生成端，而在检索端的工程积累。
八、RAG 的工程选型
1. 向量数据库选型
| 方案 | 部署方式 | 规模 | 适合场景 |
|---|---|---|---|
| FAISS | 应用内嵌入 | 千万级 | 原型、单机、极致速度 |
| Milvus | 独立服务（可分布式） | 亿级+ | 生产级、高并发 |
| pgvector | PostgreSQL 插件 | 百万~千万级 | 与业务库同栈、事务一致 |
| Qdrant | 独立服务 | 千万级 | 全功能、易上手 |
| Elasticsearch | 独立服务 | 亿级 | 已有 ES 生态、混合检索 |
选型决策要点：并发、数据量、运维成本、是否需要混合检索。工程化落地见 RAG 实战 与 框架与工具选型。
2. Embedding 模型选型
| 模型 | 维度 | 特点 |
|---|---|---|
| bge（BAAI） | 1024 | 中文强、多语言 |
| E5（微软） | 1024 | 多语言、检索基准高 |
| text-embedding-3（OpenAI） | 1536/3072 | 闭源 API、生态好 |
| GTE（阿里） | 1024 | 中文强 |
选择时注意：维度影响存储成本与检索速度；上下文长度决定单块文档的编码上限；不同语言的模型不能混用。
3. 一个完整的 RAG 提示模板
系统提示：
你是一位严格基于"资料库"作答的助手。规则：
1. 只能使用资料中的信息，不得编造；
2. 每个论断后标注来源编号，如[1]；
3. 资料不足以回答时，明确说"资料库中没有相关信息"，并给出最接近的检索建议。
资料：
[1] {检索片段 1}
[2] {检索片段 2}
[3] {检索片段 3}
用户问题：{query}4. Chunk 参数实验方法
| 参数 | 起点 | 调整方向 |
|---|---|---|
| chunk 大小 | 400 token | 答案片段长→加大；噪声多→减小 |
| 重叠 | 50~100 token | 切断了关键句→加大 |
| top-k | 4 | 召回不足→加大；噪声多→减小 |
| 重排序 | 必开 | 相关性差→换交叉编码器 |
5. 检索调优检查清单
- [ ] 测试集覆盖真实问题分布（golden set）
- [ ] 混合检索（BM25 + 向量）已启用
- [ ] 重排序模型已接入并对比前后效果
- [ ] 查询改写 / 多查询已实验
- [ ] 权限过滤（ACL）在检索前生效
- [ ] 评估指标（Recall@k、忠实度、答案相关）已上线
6. 组织级 RAG 的落地建议
企业级 RAG 与个人原型 RAG 的差距，几乎全在"治理"而非"算法"：权限模型（谁能看到哪些文档）必须在检索前落地，否则就是数据泄露事故；知识更新要有明确的所有者与审批流；向量库版本要与文档版本联动；答案要有可追溯的引用与审核路径。另一个常被低估的环节是冷启动评测：在没有任何线上数据时，先用人工梳理的 100 条真实问题建立 golden set，再逐步自动化。这些建议与更完整的落地框架见 RAG 实战 与 常见陷阱与反模式。
清单之外，还有一个"软性"但决定成败的因素：文档治理。同一个实体多种写法（"OpenAI" 与 "openai"、公司全称与简称）、不同来源互相矛盾的表述、频繁变更的版本，都会让检索与生成反复出错。治理投入虽不直接体现在代码里，却是检索质量的天花板。文档治理与 RAG 的关系，正如数据清洗之于预训练——方法论见 预训练：数据与目标。
RAG 调优的第一原则
先改检索，再改生成。80% 的 RAG 质量问题出在"检索回来的不对"，而不是"模型不会答"。检索调优手段（HyDE、重排序、混合检索）详见 RAG 实战。
九、常见失败模式速查
| 失败模式 | 现象 | 主因 | 对策 |
|---|---|---|---|
| 检索偏题 | 答案与问题无关 | query 与文档语义不对齐 | 查询改写、HyDE、混合检索 |
| 上下文淹没 | 相关片段被噪声淹没 | chunk 太大 / top-k 太多 | 更小 chunk、重排序、压缩 |
| 忠实度低 | 答案编造细节 | 模型自由发挥 | 强约束提示、引用格式、评估兜底 |
| 知识不新 | 旧答案 | 索引未更新 | 增量索引、时效过滤 |
| 私有数据泄露 | 回答泄露无关文档 | 权限过滤缺失 | 检索前 ACL 过滤 |
最后送一句经验：RAG 项目失败，九成败在数据与检索，而非模型——先把文档治理与检索质量做到 90 分，生成端自然就稳了。
十、RAG 的进阶主题与 FAQ
1. 多跳检索：答案藏在两处怎么办
单轮检索只能拿到"与问题直接相似"的片段，而很多真实问题需要推理链：
问题：那家上周被收购的芯片公司总部在哪？
第 1 跳：检索“上周 芯片公司 收购” → 找到“XX 公司被 YY 收购”
第 2 跳：从 XX 公司名再检索“XX 公司 总部” → 找到答案多跳检索的实现方式：迭代检索（把上一轮答案作为下一轮查询）、查询扩展（同时检索多个子问题）、知识图谱增强（用实体关系图补齐跨文档关联）。复杂度更高，但能覆盖"间接关联"类问题。
2. 缓存与增量更新
| 策略 | 做法 | 收益 |
|---|---|---|
| 向量缓存 | 相同/相似问题直接命中历史答案 | 省 80%+ 调用成本 |
| 增量索引 | 文档变更只重建变更块 | 秒级更新 |
| 双区索引 | 热区（常问）+ 冷区（全量） | 控制成本 |
| 时效过滤 | 检索时按时间/版本过滤 | 避免旧数据作答 |
知识库的"活"程度，往往比模型选型更影响 RAG 质量。
3. Agentic RAG：把检索交给 Agent
传统 RAG 是"一次检索 + 一次生成"；Agentic RAG 让 基于 LLM 的 Agent 自主决定：查哪个库、查几次、结果够不够、要不要换策略。典型形态：
- 路由式：先判断问题类型，再选择对应知识库；
- 工具式：把检索、重排、Web 搜索都作为工具，由 Agent 编排；
- 反思式：生成后用评测自检，不足则再检索（Self-RAG 思路）。
Agentic RAG 灵活但更贵更不稳，适合"问题复杂度高、需要多源信息"的场景。
4. RAG 评测的自动化
离线流水线（每次改动跑一遍）：
① 构建 golden set：50~200 条真实问题 + 期望答案 + 期望引用
② 跑检索：算 Recall@k、MRR
③ 跑生成：用 RAGAS 或 LLM judge 打忠实度/相关性
④ 对比基线（前一个版本）→ 回归报告
⑤ 小流量线上 A/B 验证指标与工具细节见 评估实战。
5. 高频问题速答
| 问题 | 速答 |
|---|---|
| RAG 能消灭幻觉吗？ | 不能根治，但能大幅降低事实类幻觉 |
| 微调还是 RAG？ | 知识类 RAG、行为类微调、可叠加 |
| 长上下文能替代 RAG 吗？ | 不能，成本与更新速度不允许 |
| 需要多大向量库？ | 十万级用 pgvector/FAISS 足够 |
| 中文用什么 embedding？ | bge / GTE / E5 中文版 |
| RAG 最常翻车在哪？ | 检索质量，其次 chunk 策略 |
RAG 的三个阶段判断
Naive 能跑通，Advanced 能提分，Modular/Agentic 才能应对复杂业务。先别上最重的架构——把索引质量与评测集做好，多数项目已经赢了一大半。
最后，把 RAG 放在更大视野里看：它与"上下文工程"是同一枚硬币的两面。无论 RAG、长上下文还是提示压缩，本质都是在有限的推理预算内，把"最相关的信息"送到模型面前。区别只在于"谁来做筛选"：RAG 用检索器筛，长上下文靠模型自己在大输入里找，提示压缩用摘要器筛。理解这个统一视角，就能在具体场景里灵活组合：短文档直接全文给，长知识库用 RAG，超长单文档用 RAG + 长上下文混合。技术名词会过时，"把相关信息高效送达模型"这个命题不会。
再补一句：检索与生成的"分工"本质是"外挂知识 vs 内化知识"的选择——只要知识会变，RAG 就值得留作默认选项。
十一、RAG 的变体与相邻技术
1. 主流变体对比
| 变体 | 核心思路 | 适合 | 代价 |
|---|---|---|---|
| 标准 RAG | 向量检索 + 生成 | 通用知识库 | 检索质量决定上限 |
| GraphRAG | 知识图谱 + 图遍历检索 | 强关联、多跳问题 | 图谱构建成本高 |
| RAPTOR | 递归聚类摘要树 | 长文档层次理解 | 离线构建复杂 |
| HyDE | 先生成假设答案再检索 | 零样本检索冷启动 | 多一次生成 |
| RAG-Fusion | 多查询 + RRF 融合 | 提高召回 | 查询成本翻倍 |
| Self-RAG | 自我反思决定是否检索 | 减少无谓检索 | 需训练反思 token |
2. RAG 与知识图谱问答
知识图谱问答（KGQA）用结构化三元组回答"谁、在哪里、与谁相关"类问题，确定性高但构建与维护成本高；RAG 灵活但确定性低。实践中常"图谱 + RAG"混合：用图谱补关联，用向量检索补语义。
3. RAG + 微调的组合模式
| 组合 | 解决什么 | 怎么搭 |
|---|---|---|
| RAG 给知识 + 微调给风格 | 知识 + 客服口吻/格式 | 检索片段 + LoRA 模型 |
| 微调检索器 | 检索质量差 | 用标注对微调双塔/重排器 |
| 微调生成器引用格式 | 引用格式乱 | 用带引用的指令数据微调 |
组合原则：微调不改知识（那是 RAG 的活），RAG 不改风格（那是微调的活）。
4. RAG 与 MCP / 工具化
RAG 检索本身也可以做成工具：通过 MCP 暴露"检索企业知识库"，让 基于 LLM 的 Agent 在任务中按需调用——这是 Agentic RAG 的标准形态。
对研究者的提示：RAG 的开放问题集中在三处——"什么时候该检索"（查询意图判断）、"检索到什么算够"（相关性度量与停止条件）、"如何把检索结果的可信度传给生成端"（引用与不确定度传递）。这三个问题分别对应 Modular RAG 的路由、反思与生成控制模块，也是 Self-RAG、CRAG 等工作的核心。理解这三个开放问题，比追逐新框架更能把握 RAG 的研究脉络。
十二、RAG 关键论文清单
| 论文 / 工作 | 年份 | 一句话 |
|---|---|---|
| Retrieval-Augmented Generation（RAG） | 2020 | 开山之作 |
| DPR | 2020 | 密集检索双塔 |
| HyDE | 2022 | 零样本密集检索改进 |
| Self-RAG | 2023 | 自我反思检索 |
| CRAG | 2024 | 纠正检索质量 |
| RAGAS | 2023 | 自动化评估框架 |
| GraphRAG | 2024 | 图谱增强检索 |
对刚入门的读者，论文阅读顺序建议是：先读 2020 年 RAG 原始论文建立"检索-生成"的整体图景，再读 DPR 理解密集检索，然后看 HyDE、Self-RAG、CRAG 了解演进逻辑，最后用 RAGAS 理解评估。每篇只需抓住"解决了什么问题、引入了什么机制"，不必逐行推导。论文精读方法见 经典论文精读。
RAG 技术选型的一句话
需求越简单，方案越朴素：80% 的问答用"标准 RAG + 重排 + 评测闭环"即可；GraphRAG、Agentic RAG 只在明确需要多跳或自主决策时才值得引入。
十三、延伸阅读
- 幻觉：成因与缓解——RAG 缓解幻觉的机制背景
- 上下文与长文本——长上下文与 RAG 的权衡
- 微调：SFT 与参数高效微调——RAG vs 微调选型
- RAG 实战——端到端搭建与调优
- 评估实战——RAGAS 与 golden set
- 数据集与基准档案——评测基准与语料资源
- 基于 LLM 的 Agent——RAG 作为 Agent 的"知识工具"
参考资料
- Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（2020）——RAG 原始论文（arXiv）
- Karpukhin et al. Dense Passage Retrieval for Open-Domain Question Answering（DPR, 2020）——密集检索双塔模型论文（arXiv）
- Gao et al. Precise Zero-Shot Dense Retrieval without Relevance Labels（HyDE, 2022）——HyDE 论文（arXiv）
- Asai et al. Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection（2023）——Self-RAG 论文（arXiv）
- Yan et al. Corrective Retrieval Augmented Generation（CRAG, 2024）——CRAG 论文（arXiv）
- Es et al. RAGAS: Automated Evaluation of Retrieval Augmented Generation（2023）——RAGAS 评估框架论文（arXiv）
- Microsoft. Reinventing search with a new AI-powered Microsoft Bing（2023.2）——必应 Chat 官方博客
- Arcee-AI. Bespoke-Minerva-7B（Hugging Face）——RAG 专用微调模型权重页