RAG

RAG 是 Retrieval-Augmented Generation，中文常译为检索增强生成。它的核心是：先从外部知识源检索相关材料，再让模型基于材料生成答案。

1. RAG 解决什么问题

LLM 本身有几个天然限制：

• 不知道训练后才出现的新信息
• 不知道企业内部私有知识
• 对长尾细节容易编造
• 很难稳定引用具体来源

RAG 的价值在于把“参数记忆”之外的知识按需注入模型上下文。

2. 基本流程

用户问题
  -> 查询改写
  -> 检索相关文档
  -> 重排和过滤
  -> 拼接上下文
  -> 模型生成答案
  -> 引用和校验

最小版本可以只有“检索 -> 生成”，但生产系统通常需要查询改写、重排、引用校验和评测。

3. 核心组成

3.1 文档处理

• 文档加载
• 清洗
• 分段
• 元数据提取
• 权限标记

3.2 向量化与索引

• embedding 模型
• 向量数据库
• 关键词索引
• 混合检索

3.3 检索

• top-k
• metadata 过滤
• 查询改写
• 多路召回

3.4 重排

重排器用于把初步召回结果重新排序，提升真正相关片段的优先级。

3.5 生成与引用

生成时要尽量要求：

• 只基于给定上下文回答
• 无依据时明确说明不知道
• 引用对应来源
• 不把检索片段之外的推断伪装成事实

4. Chunk 设计

chunk 太小：

• 上下文不完整
• 容易丢失定义和条件

chunk 太大：

• 噪声变多
• 检索不精确
• 成本上升

常见策略：

• 按标题层级切分
• 按语义段落切分
• 滑动窗口保留上下文
• 给 chunk 附带文档标题、章节、时间、权限等 metadata

5. RAG 的常见模式

5.1 Naive RAG

直接向量检索后生成答案。

优点是简单，缺点是召回和引用质量不稳定。

5.2 Hybrid RAG

结合向量检索和关键词检索。

适合包含专有名词、代码符号、编号、API 名称的知识库。

5.3 Agentic RAG

由 Agent 决定何时检索、检索什么、是否需要二次检索。

适合复杂研究、报告生成、多文档对比。

5.4 Graph RAG

把实体和关系显式建模，适合组织关系复杂、实体关联强的知识库。

6. 评测指标

不要只看最终回答是否像样，要拆开评测：

• 检索召回是否命中正确文档
• 检索片段是否足够支持答案
• 引用是否对应原文
• 答案是否忠实于来源
• 无答案问题是否能拒答
• 延迟和成本是否可接受

7. 常见失败模式

• 文档切分破坏语义
• embedding 对专有名词不敏感
• top-k 太小导致漏召回
• top-k 太大导致噪声淹没重点
• 引用存在但结论不被引用支持
• 权限过滤缺失导致越权回答
• 旧文档覆盖了新文档

8. 工程建议

• 先做最小闭环，再优化召回
• 保留原始 query、改写 query、召回片段、最终引用
• 对高频问题建立评测集
• 对不同文档类型采用不同切分策略
• 对权限、时间和版本做 metadata 过滤
• 不要把 RAG 当成“自动正确”的事实系统

9. 与 Agent 的关系

RAG 解决“模型不知道什么”，Agent 解决“模型如何多步做事”。

两者结合后就是 Agent+RAG。

10. 参考

• LangChain RAG 教程：https://python.langchain.com/docs/tutorials/rag/
• LlamaIndex 文档：https://docs.llamaindex.ai/