跳转至

二十六：RAG

来源:http://mp.weixin.qq.com/s?__biz=MzYyNTk3Njg1NA==&mid=2247484281&idx=1&sn=f3b39ba7527d8c190927f7b1bd4b57a8&chksm=f01eb000c76939167aee12326f0ba8e5f19b2ef65bdd39fb3b849d311634f58bf751ab30cfe3#rd

1. 学习范围

本日主题是 RAG 的基本步骤。RAG, Retrieval-Augmented Generation，检索增强生成, 是把外部知识检索与大模型生成结合起来的方法，用于让模型回答私有知识、实时知识或需要证据支撑的问题。 本日重点覆盖 RAG 的基础链路： - RAG 的问题定义与适用场景。

  • 文档加载、清洗和元数据设计。

  • 文档切分 chunking。

  • embedding 模型和向量表示。

  • 向量索引与向量数据库。

  • query 处理与相似度检索。

  • top-k 召回、rerank 和上下文组装。

  • 基于检索上下文的生成 prompt。

  • RAG 基础评估和常见错误。

img

2. RAG 的核心定位

大模型的参数知识存在几个限制： - 知识可能过时。

  • 无法天然访问企业私有数据。

  • 难以给出可追溯证据。

  • 容易在不确定时编造。

  • 更新知识通常需要重新训练或微调。

RAG 的基本思路是：用户提问时，先从外部知识库检索相关资料，再把资料放入 prompt，让大模型基于资料生成答案。 基础流程：

Documents -> Load -> Clean -> Split -> Embed -> Index

User Query -> Rewrite/Embed -> Retrieve -> Rerank -> Context
           -> Prompt -> LLM -> Answer with citations
RAG 不等于简单地“接一个向量库”。它是一整套数据、检索、排序、上下文构造、生成和评估系统。

3. RAG 适用场景

RAG 适合： - 企业知识库问答。

  • 技术文档问答。

  • 法务、合同、制度查询。

  • 客服知识库。

  • 论文/报告阅读助手。

  • 需要引用来源的问答。

  • 高频更新知识。

RAG 不一定适合： - 完全不依赖外部知识的创意写作。

  • 需要模型掌握稳定风格或格式的任务，微调可能更合适。

  • 检索库质量极差的任务。

  • 需要严格推理但检索证据不足的任务。

RAG 的价值在于把“知识”放在外部可更新系统，把“语言理解和生成”交给大模型。

4. 数据源与文档加载

RAG 的上限很大程度取决于知识库质量。常见数据源包括： - PDF、Word、Markdown、HTML、TXT。

  • 数据库记录。

  • Wiki、Notion、Feishu、Confluence。

  • API 文档和代码仓库。

  • 工单、FAQ、聊天记录。

  • 表格和结构化数据。

文档加载时要保留： - 原文内容。

  • 标题层级。

  • URL 或文件路径。

  • 文档 ID。

  • 页码、章节、段落位置。

  • 更新时间。

  • 权限信息。

  • 数据来源类型。

这些元数据不仅用于引用，还用于过滤、权限控制、排序和调试。

5. 文档清洗

文档清洗目标是去掉噪声并保留语义结构。 常见清洗内容： - 去除页眉页脚、目录重复、广告和导航栏。

  • 修复 OCR 错误。

  • 处理表格、代码块、公式和图片说明。

  • 合并断行。

  • 保留标题层级。

  • 删除重复文档。

  • 统一编码和标点。

清洗不能过度。过度清洗可能删除关键信息，例如表格列名、法律条款编号、代码缩进和 Markdown 标题。

6. 文档切分 Chunking

文档切分是把长文档拆成可检索、可放入上下文的小块。切分影响召回率、上下文质量和生成准确性。 常见切分策略： - 固定长度切分：按字符或 token 数切。

  • 递归切分：优先按标题、段落、句子切，再按长度兜底。

  • 语义切分：根据语义边界切分。

  • 结构化切分：按 Markdown 标题、HTML 节点、PDF 页、表格行切分。

  • 代码切分：按函数、类、模块切分。

切分需要在粒度之间权衡： - chunk 太小：容易缺上下文，答案不完整。

  • chunk 太大：检索不精确，占用 prompt，上下文噪声多。

7. Chunk Size 与 Overlap

chunk size 通常按 token 或字符计。不同任务适合不同大小： - FAQ：小 chunk，精确匹配。

  • 技术文档：中等 chunk，保留段落上下文。

  • 法律合同：按条款和子条款切分。

  • 代码：按函数/类切分。

  • 长报告：按标题层级切分。

overlap 是相邻 chunk 的重叠区域，用于避免答案跨边界时信息丢失。

chunk 1: tokens 0-499
chunk 2: tokens 400-899
overlap: 100 tokens
overlap 太小可能断上下文，太大则增加索引冗余和重复召回。

8. Embedding 模型

embedding 模型把文本映射为向量，使语义相近的文本在向量空间中更接近。 RAG 中通常会 embedding： - 文档 chunk。

  • 用户 query。

然后计算相似度进行检索。 选择 embedding 模型时考虑： - 语言支持。

  • 领域适配。

  • 向量维度。

  • 最大输入长度。

  • 检索效果。

  • 推理成本和延迟。

  • 是否支持 query/document 双塔指令。

embedding 模型和生成模型可以不同。RAG 的检索质量很大程度取决于 embedding 模型是否适合领域。

9. 向量相似度

常见相似度指标： - cosine similarity 余弦相似度。

  • dot product 点积。

  • Euclidean distance 欧几里得距离。

cosine similarity 衡量方向相似度：

cos(q, d) = q · d / (||q|| ||d||)
如果向量已经归一化，cosine similarity 和 dot product 排序等价。 选择相似度时要与 embedding 模型训练方式和向量数据库索引配置一致。否则检索效果可能下降。

10. 向量索引与向量数据库

文档 chunk embedding 后需要建立索引。小规模数据可以暴力搜索；大规模数据通常使用 ANN, Approximate Nearest Neighbor。 常见索引思想： - Flat：精确搜索，慢但准确。

  • HNSW：图索引，查询快，常用。

  • IVF：聚类倒排，先找簇再搜索。

  • PQ：向量量化，节省内存但有精度损失。

常见向量数据库或库： - FAISS。

  • Milvus。

  • Qdrant。

  • Weaviate。

  • Chroma。

  • Elasticsearch / OpenSearch vector search。

选择时要考虑数据规模、过滤需求、更新频率、延迟、部署成本、权限和可观测性。

11. Query 处理

用户 query 进入检索前可能需要处理： - 去除无意义字符。

  • 多轮对话指代消解。

  • query rewrite。

  • query expansion。

  • 拆分多问题。

  • 提取过滤条件。

  • 生成结构化检索请求。

例如多轮问题：

用户：它支持私有部署吗？
需要结合历史，把“它”改写为具体产品名，否则检索可能失败。 Query 处理的目标是让检索请求更接近知识库中的表达。

12. 检索 Retrieve

基础向量检索流程：

query -> embedding(q)
docs -> embedding(chunks)
score = similarity(q, chunk)
return top-k chunks
top-k 太小可能漏召回，top-k 太大可能带来噪声并挤占上下文。常见做法是先召回较多候选，再通过 reranker 或规则过滤压缩到最终上下文。 检索不一定只用向量。很多场景需要 hybrid search，把 dense vector retrieval 和 BM25/关键词检索结合。

向量检索擅长语义相似，BM25 擅长关键词、编号、术语、代码符号、产品型号等精确匹配。 Hybrid search 适合： - 技术文档。

  • 法律条款。

  • 产品手册。

  • API 文档。

  • 包含大量专有名词和编号的知识库。

常见融合方式： - 分别召回再合并去重。

  • 分数归一化后加权。

  • Reciprocal Rank Fusion, RRF。

  • 先关键词过滤再向量召回。

14. Rerank

Reranker 对召回候选进行更精细排序。向量检索通常是 bi-encoder，query 和 document 独立编码，速度快但交互较弱。reranker 常使用 cross-encoder 或 LLM，对 query 和候选 chunk 一起打分，效果更好但成本更高。 常见流程：

retrieve top 50 -> rerank -> keep top 5
rerank 能提升 precision，减少无关上下文进入 prompt。但如果第一阶段没有召回正确文档，reranker 也无法凭空找回。

15. 上下文组装

检索结果需要组装成 LLM 可用上下文。上下文组装要考虑： - 相关性排序。

  • 去重。

  • 保留标题和来源。

  • 控制 token 预算。

  • 相邻 chunk 合并。

  • 引用 doc_id。

  • 权限过滤。

  • 避免互相矛盾资料混杂。

上下文模板示例：

[doc_1] 标题：...
来源：...
内容：...

[doc_2] 标题：...
来源：...
内容：...
保留 doc_id 有助于生成引用和后续验证。

16. 生成 Prompt

RAG 的生成 prompt 应明确： - 模型角色。

  • 只能基于上下文回答。

  • 引用格式。

  • 资料不足时拒答。

  • 输出结构。

  • 安全边界。

示例：

你是严谨的知识库问答助手。
请只根据 <context> 中的资料回答问题。
如果资料不足以回答，请说明“资料不足，无法确定”。
回答中每个关键结论都要引用对应 doc_id。

<context>
...
</context>

<question>
...
</question>
Prompt 不能弥补糟糕检索。如果上下文不相关，模型仍可能答错或拒答。

17. 引用与忠实性

RAG 的一个重要价值是答案可追溯。引用应满足： - 引用存在于检索上下文中。

  • 引用内容支持对应结论。

  • 引用粒度足够具体。

  • 不把无关文档作为证据。

常见问题： - 引用 doc_id 但内容不支持结论。

  • 多个来源冲突但答案未说明。

  • 根据模型参数知识回答却附上无关引用。

忠实性评估需要检查“答案是否被上下文支持”，而不是只看答案是否看起来正确。

18. RAG 基础评估

RAG 评估分为检索评估和生成评估。 检索评估： - Recall@k。

  • Precision@k。

  • MRR。

  • nDCG。

  • 命中率。

生成评估： - 答案正确性。

  • 上下文忠实性。

  • 引用准确性。

  • 完整性。

  • 拒答准确率。

  • 格式合规率。

端到端评估应构建标准问答集，并标注支持文档。只看最终答案无法定位是检索失败还是生成失败。

19. RAG 常见失败模式

常见失败模式： - 文档加载失败或格式丢失。

  • chunk 切分不合理。

  • embedding 模型不适合领域。

  • query 表达和文档表达不一致。

  • top-k 太小导致漏召回。

  • top-k 太大导致噪声多。

  • reranker 缺失或排序错误。

  • 上下文超长，关键信息被稀释。

  • prompt 未要求忠实引用。

  • 模型在资料不足时编造。

  • 权限过滤缺失导致越权回答。

排查要分层：先检查数据，再检查检索，再检查上下文，再检查生成。

20. 基础实现框架

一个最小 RAG 系统可以分为离线索引和在线问答。 离线阶段：

load documents
clean documents
split into chunks
embed chunks
store vectors + metadata
在线阶段：

receive query
rewrite query if needed
embed query
retrieve top-k chunks
rerank/filter
assemble context
call LLM
return answer with citations
工程上应记录每次回答使用了哪些 query、召回了哪些 chunk、分数是多少、最终 prompt 是什么、模型输出是什么。这些日志是调试 RAG 的基础。

21. RAG 与微调的关系

RAG 和微调解决不同问题： - RAG 擅长注入外部知识、实时知识和可追溯证据。

  • 微调擅长改变模型风格、格式、任务行为和领域语言模式。

常见组合： - 用 RAG 提供事实资料。

  • 用微调让模型更擅长阅读资料和按格式回答。

  • 用 prompt 控制引用和拒答。

  • 用规则/评估器校验输出。

如果知识频繁变化，优先 RAG；如果行为格式长期稳定，考虑微调。

22. 核心总结

RAG 基本步骤可以压缩为：

数据准备 -> 文档切分 -> 向量化 -> 建索引
用户问题 -> 检索 -> 重排 -> 上下文组装 -> 生成答案 -> 评估
关键原则： - 数据质量决定上限。

  • chunking 决定知识粒度。

  • embedding 决定语义召回能力。

  • hybrid search 解决关键词和语义互补。

  • rerank 提升最终上下文精度。

  • prompt 控制忠实性、引用和拒答。

  • 评估要拆分检索和生成，不能只看最终答案。

23. 参考资料

  • LangChain RAG tutorials: https://python.langchain.com/docs/tutorials/rag/

  • LangChain RAG from scratch playlist: https://www.youtube.com/playlist?list=PLaIDFEXuae2LXbO1_PKyVJiQ23ZztA0x

  • Retrieval-Augmented Generation paper: https://arxiv.org/abs/2005.11401

  • Lewis et al. RAG paper page: https://papers.nips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html

  • LlamaIndex RAG docs: https://docs.llamaindex.ai/en/stable/understanding/rag/

  • FAISS documentation: https://faiss.ai/

  • CSDN RAG 基础概念讲解: https://blog.csdn.net/2401_82452722/article/details/135934144

            预览时标签不可点

    <div class="