RAG

RAG

  RAG 是 Retrieval-Augmented Generation（检索增强生成） 的缩写，是一种将信息检索系统与大语言模型（LLM）相结合的 AI 技术框架。它的核心思想是：在让模型生成回答之前，先从外部知识库中动态检索相关文档或知识片段，然后将这些检索到的内容作为上下文，辅助模型生成更准确、更可靠的答案。

为什么要用 RAG?

传统大语言模型虽然能力强大，但存在几个明显短板

（1）知识过时：模型训练完成后，知识停留在训练数据的时间点，无法获知新信息

（2）领域知识不足：通用模型在企业私有数据、专业垂直领域往往表现不佳

（3）幻觉：对于未知或模糊的事实，模型可能会“编造”看似合理但实际错误的内容

（4）可解释性差：用户难以知道回答的依据来源

提示

RAG 正是为了解决这些问题而设计：让模型“先查资料，再回答问题”，就像开卷考试一样，既利用了检索到的实时、私有知识，又发挥了生成模型的总结表达能力。

RAG 的工作流程

典型的 RAG 流程：

（1）索引（Indexing）
  将外部的知识源（如 PDF 文档、数据库、网页）切分成若干片段（chunks），通过嵌入模型（embedding model）将这些片段转换成向量，存入向量数据库（如 Faiss、Pinecone、Milvus）中，构建可快速搜索的索引。

（2）检索（Retrieval）
  当用户提出问题时，首先用相同的嵌入模型将问题转为查询向量，在向量数据库中进行相似性搜索，找出与问题语义最相关的前 K 个文档片段。

（3）增强（Augmentation）
  把检索到的相关片段与用户的原始问题拼接成一个提示模板（prompt），通常格式为：

请基于以下参考资料回答用户问题。
参考资料：{检索结果}
问题：{用户问题}

（4）生成（Generation）
  将组装好的提示送入大语言模型，模型结合外部知识和自身能力生成最终答案。同时，答案可以附带引用来源链接，增强可信度。

RAG基本流程.png

RAG 的关键组件

（1）嵌入模型（Embedding Model）：将文本等转换为数值向量，保证语义相似的文本在向量空间中距离更近

（2）向量数据库（Vector Store）：高效存储和检索高维向量，支持近似最近邻（ANN）搜索

（3）大语言模型（LLM）：负责理解上下文并生成自然语言回答

（4）分块策略（Chunking）：如何切分原始文档等直接影响检索质量，需平衡语义完整性和片段大小

（5）检索增强策略：除了基础语义检索，还可混合关键词检索（BM25）、重排序（Reranker）、多轮检索等提升精度

RAG 的典型应用场景

（1）企业知识库问答：基于公司内部文档、规章制度、产品手册回答员工问题

（2）客服系统：实时从产品文档或历史工单中检索信息，生成个性化回复

（3）多轮对话助手：结合对话历史和外部检索，提供持续且准确的帮助

（4）科学研究辅助：从论文库中检索相关文献，辅助研究者快速获取摘要与结论

（5）个人知识管理：与笔记工具结合，在私人笔记中搜索并生成答案

RAG 的优缺点

优点：

（1）可以随时更新知识源，无需重新训练模型。

（2）大幅减少幻觉，回答更可信、可溯源。

（3）保护隐私与安全，数据可保留在本地。

（4） 易于集成垂直领域知识，降低微调成本。

挑战与局限：

（1） 检索质量直接影响答案质量，错误或无关的片段会误导模型。

（2） 分块与检索策略需要针对数据特点精心调优。

（3） 引入检索会增加响应延迟。

（4） 对于需要复杂推理或跨多个片段综合的问题，仍有难度。

文档的切分

核心：语义连贯性
方法：
（1）固定大小切分：如按字符数、token 数
（2）按标点符号划分：如换行符
（3）按文档结构：如标题、章节
（4）按语义划分：将句子按相关性合并成段落

语义连贯性越来越好，实现难度越来越难

提示

应尽量保证划分后的同一段文本里面，语义是统一、完全的
太长语义不统一，影响检索效果
太短语义不完全，影响回答质量

优化

检索优化

（1）small to big 摘要检索

为什么要进行 Query 改写？

1. 弥补表达差异（语义鸿沟）
   用户习惯用自然语言描述需求，而系统的索引、知识库往往基于关键词、标准实体等结构化形式。同一种意思可能有多种说法（如“头疼”/“头痛”、“笔记本”/“笔记本电脑”），改写可以将用户口语化、简略化的表达对齐到系统能理解的标准方式。

2. 纠正输入错误与不规范
   原始查询中存在拼写错误（如“苹狗手机” → “苹果手机”）、大小写混乱、特殊符号、口语词（如“咋整”→“怎么办”）等问题，改写能将其标准化，避免检索失败。

3. 处理歧义与多义性
   一词多义会导致检索偏离意图（例如“苹果”可能指水果或公司）。改写可以通过上下文或领域知识进行消歧，添加限定词或替换为更准确的表达。

4. 提升召回率与精确率
   通过同义词扩展、上下位词泛化或细化，可以在保证相关性的前提下扩大或缩小搜索范围。比如将“桌子”扩展为“餐桌、书桌、办公桌”，或者将“华为”限定为“华为手机”。

5. 支持多轮对话的上下文理解
   在对话系统中，用户经常使用代词、省略或依赖前文（如“它多少钱？”）。改写需要结合历史对话进行指代消解与省略补全，生成完整的独立查询（如“iPhone 15 多少钱”），否则系统无法正确回应。

6. 适配下游系统要求
   某些搜索引擎、API 或数据库有特定的输入格式要求（如布尔逻辑、字段限定）。改写能将自然语言问题转化为结构化查询，例如将“2020年后上映的科幻电影”变成 year>2020 AND genre=科幻。

7. 用户意图澄清与分解
   复杂问题可能包含多个子意图，改写可以将其分解为多个简单查询分别处理，再汇总结果，提升复杂问题的解答能力。

总结：用户的原始问题通常很“烂”——模糊、口语化、信息不全；例如：那个配置怎么搞？——“那个”是哪个？“搞”是什么动作？

Query 改写5 种技术

（1）Multi-Query：把同一个问题改写成多个不同的表述，分别检索在合并

（2）HyDE：让 LLM 先生成一篇“假设性的、能够回答这个问题的文档”（即使内容可能是编造的），然后把这篇假设文档转换成向量，用这个向量去真正检索知识库

（3）Step-Back：退一步问更抽象的问题，如：Python3.12 有什么新特新? -> Python 版本更新内容

（4）Query Decomposition：把复杂问题拆成几个子问题分别检索

（5）Query Expansion：自动补充同义词和相关词

评估

RAG评估集四要素：问题、期望答案、相关文档、难度等级

来源：从真实用户日志中挑选、人工构造边界场景、用 LLM合成

100条是起步，好的评估集至少 500 条。

四个核心核心评估指标：

（1）Context Recall（检索召回）：相关文档是否被检索到了

（2）Context Precision（检索精确）：检索到的结果中相关的占比多高

（3）Faithfulness（生成忠实）：生成的答案是否忠实于检索到的上下文，没有编造

（4）Answer Relevancy（回答相关）：答案是否真正回答了用户的问题

评估的方式：人工抽样评测+LLM自动化评测结合，TopK命中统计、指标量化计算

高频提问：指标不高的原因、各指标优化难度、如何降低模型幻觉、如何规避无知识库场景编造答案

指标不高的原因？

（1）检索召回（Context Recall）低

• 知识库文档切分粒度过粗或过细，导致相关片段无法被有效检索；

• 嵌入模型与领域文本不匹配，语义表征不准；

• 检索策略单一（纯向量检索），未考虑关键词匹配或混合检索；

• 问题本身表达模糊，与文档用词差异大。

（2）检索精确（Context Procision）低

• 检索返回过多结果，混入大量与问题表面相似但是无关的段落；

• 未引入重排序（Rerank），缺乏对初检结果的精筛；

• 文档集合中相似主题内容占比过高，模型难以区分。

（3）生成忠实度（Faithfulness）低

• 生成模型偏好“流畅回答”，即便检索上下文不足时仍然强行编造；

• 指示指令未明确约束“仅依据给定文档作答”；

• 模型本身存在幻觉倾向，对上下文的引用不严格；

• 多轮对话中累计的上下文过长，模型忽略早期信息而自由发挥。

（4） 回答相关性（Answer Relevancy）低

• 生成答案偏离了用户真实意图，虽然利用了上下文但答非所问；

• 问题理解错误，或系统未对问题进行有效意图解析；

• 检索到了相关文档，但生成总结时丢失关键信息，导致答案与问题匹配度下降。

各指标的优化难度如何排序？有什么针对性策略？

容易优化：Context Recall & Context Precision
这两个指标主要依赖检索侧优化，可控性较强，难度较低。

• 调优文档切分（滑动窗口、语义分块）；

• 提升嵌入模型适配度（使用领域微调的向量模型）；

• 实施混合检索+重排序（BM25+向量+Cross-encoder Rerank）；

• 调节Top-K数量，平衡召回与精确。

中等难度：Answer Relevancy
需要让模型在正确理解问题的基础上合理利用检索结果，既要理解上下文又要紧贴问题。

• 丰富提示模板，展示关键信息与问题的关联；

• 引入问题改写（query rewriting）以消除歧义；

• 通过少样本示例强化模型对“相关性”的理解；

• 对生成结果使用LLM打分以迭代提示。

较难优化：Faithfulness
这是RAG落地中最顽固的问题，因为它涉及模型生成行为的深层次控制。

• 严格提示约束：“如果文档没有答案，直接回答‘不知道’”；

• 使用忠实度检测工具（如基于自然语言推理的判别模型）做后校验；

• 选型抗幻觉能力更强的基座模型，或进行对齐微调；

• 引入引文强制要求（让模型为每个声明标注来源片段）。

如何降低模型幻觉（主要指Faithfulness问题）？

（1）提示工程增强：在system prompt中嵌入强硬约束，例如：“你只能根据以下提供的文档回答，如果找不到答案，请直接说‘根据已知信息无法回答’。”

（2）检索阈值兜底：设置检索相似度最低阈值，当候选文档得分过低时调用拒答流程，不让模型接触低质量上下文。

（3）事实核验机制：在生成答案后，利用额外的NLI模型逐句核对是否被上下文支撑，不一致则标红或重新生成。

（4）Reduce空转自由：要求模型按“依据段落X，可以回答Y”的模板输出，将生成与引用强绑定，减少“凭感觉发挥”。

（5）利用忠实度评估指标闭环优化：将Faithfulness评分纳入实验追踪，针对性地调整提示、检索结果格式和模型参数。

如何规避无知识库场景下模型编造答案？

核心思路：明确界定“知识边界”，并设计清晰的拒答行为。

1. 检索侧拦截

   • 计算搜索得分（如向量相似度、BM25分数），低于预设阈值直接返回“未找到相关信息”，不进入生成阶段。

   • 结合关键实体匹配度，若问题中的核心实体在检索文档中的出现频率极低，视为超出知识范围。

2. 生成指令强化

   • 指令模板中增加：“如果提供的文档无法回答用户问题，请严格以‘抱歉，我目前的知识库中缺少相关信息’回复，绝对不要编造或使用外部知识。”

   • 给出反例和正例的few-shot示例，让模型学习“无信息时就拒绝”的模式。

3. 后置检测与兜底

   • 对生成的答案进行Faithfulness自动评估，如果得分极低或无法匹配到出处，自动替换为预设的拒答话术。

   • 利用不确定性估计：如果模型生成的logprob或置信度低，触发安全回应。

4. 人机协同监控

   • 将高风险场景（如医疗、金融）的未知回答推送给人工审核，累积无答案样本，扩展知识库覆盖。