深入浅出RAG——第8章：RAG 的局限性及应对策略

📖 本章学习目标

• 识别 RAG 系统的六大类典型失败模式及其根因
• 在项目中主动诊断检索失败、知识冲突和幻觉残留问题
• 理解为什么"加 RAG 就不会有幻觉"是一个危险的误解
• 建立合理的 RAG 技术预期，知道何时需要引入进阶方案

在《第7章：基础篇实战：文档问答机器人》中，我们构建了一个可运行的文档问答机器人。你很可能已经注意到，它并不是每次都能给到完美答案。有时检索到的文档不相关，有时模型忽略了检索结果，有时答案看起来合理但实际是错误的。

这通常不是你的代码实现有问题，而是由RAG的局限性所导致的。本章作为基础篇到进阶篇的桥梁，系统梳理 RAG 的局限，帮你理解后续章节（混合检索、Rerank、Self-RAG 等）为什么存在。后续的章节基本都是是针对本章揭示的问题而设计的解决方案。

当然，理解局限性不是为了让你放弃 RAG，而是为了让你在使用时更加谨慎，知道在什么时候该用什么优化手段。

一、检索失败：最核心的瓶颈

RAG 的核心假设是 "检索到的文档包含正确答案"。如果这个假设不成立，后续的生成环节再强大也无济于事。检索失败是 RAG 系统中最常见、也最难解决的问题之一。

1. 语义鸿沟

Embedding 模型虽能将文本映射到高维空间，但这并非完美的语义等价映射。人类认为语义相近的两个表达，在向量空间中可能距离很远。

// 语义鸿沟的典型场景
const query = "怎么让程序跑得更快？";
const doc = "数据库查询性能优化指南：索引策略与慢查询分析";

// 余弦相似度可能只有 0.45 ------
// "跑得更快" vs "性能优化" 在人类看来是近义，但向量空间距离不够近
const similarity = cosineSimilarity(
  await getEmbedding(query),
  await getEmbedding(doc)
);
console.log(similarity); // 输出: 0.45

为什么会出现这样的语义鸿沟呢？这是因为Embedding 模型的训练数据虽然庞大，但终究不可能覆盖所有表达方式。特别是以下情况非常容易出现语义鸿沟：

• 口语化表达 vs 专业术语："跑得更快"vs"性能优化"、"挂了"vs"服务不可用"
• 缩写和简称："K8s"vs"Kubernetes"、"CI/CD"vs"持续集成/持续部署"
• 行业黑话：每个行业都有自己的术语体系，通用 Embedding 模型可能无法准确理解

另外一些专业术语的表达也可能给RAG带来挑战，比如医疗文献中的"心梗"和查询中的"心脏病发作"，法律文档中的"违约"和查询中的"不履行合同"，这些在人类看来是等价的概念，Embedding 模型可能无法建立强关联。

针对语义上的鸿沟问题，通常可以使用以下策略进行缓解：

• 使用领域专用的 Embedding 模型（如医学、法律领域的微调模型）
• 在索引前对文档进行术语标准化（将"心梗"统一为"心肌梗死"）
• 采用混合检索（关键词 + 向量），见《第9章：高级检索策略》

2. 多义词歧义

同一个词在不同上下文中含义完全不同，向量只能捕捉一种"平均语义"。

// "苹果" 在两个语境中的 Embedding 差异
const query_tech = "苹果公司的市值是多少？";    // Embedding 偏向科技语境
const query_fruit = "苹果的营养价值是什么？";    // Embedding 偏向食品语境

const embedding_tech = await getEmbedding(query_tech);
const embedding_fruit = await getEmbedding(query_fruit);

// 两个向量的相似度可能不高，因为它们指向不同的语义方向
const similarity = cosineSimilarity(embedding_tech, embedding_fruit);
console.log(similarity); // 输出: 0.3-0.5（中等相似度，但不足以精确区分）

这种问题一个明显的特征是用户查询时可能没有足够的上下文让 Embedding 模型确定语义方向。特别是短查询（2-5 个词），歧义问题更加严重。比如：

• "Java"：编程语言还是印尼岛屿？
• "Python"：编程语言还是蟒蛇？
• "React"：前端框架还是化学反应？

针对多义词歧义的缓解策略可以是：

• 鼓励用户提供更完整的查询（如"Java 编程语言的学习路线"而非"Java"）
• 在 Prompt 中加入消歧指令，让 LLM 根据上下文判断
• 使用 Query Expansion（查询扩展）技术，自动生成多个可能的查询变体

3. 检索精度问题

即使语义匹配正确，检索结果的质量也可能参差不齐。

graph TD A[用户查询] --> B[Embedding 检索 Top-K] B --> C{检索结果质量} C -->|理想| D[Top-3 高度相关] C -->|常见问题| E[Top-3 中有 1-2 条无关] C -->|严重失败| F[Top-3 全部不相关] E --> G[噪声进入 Prompt<br/>干扰模型生成] F --> H[模型收到无关上下文<br/>输出不可控]

检索精度低的原因：

• 切分粒度不当 ：chunk 太大导致语义稀释，太小导致上下文缺失（见《第5章：文档切分》）
• Embedding 模型能力有限：不同模型在特定领域的表现差异很大
• 向量数据库索引参数不佳：HNSW 参数设置不当影响召回率
• 知识库质量问题：文档本身表述不清或信息过时

针对检索精度问题可以，通过人工评估检索结果的相关性继进行检查诊断，如果大部分检索结果的相关性评分低于 3 分，说明检索环节存在问题，需要优化。

二、知识冲突

当检索到的信息与 LLM 的内部知识不一致，或者多个检索结果之间相互矛盾时，就会产生知识冲突。

1. 检索结果 vs 模型内部知识

当检索到的文档内容与 LLM 训练时学到的知识冲突时，模型的行为是不确定的。如果没有给出明确的限制和约束，LLM有时遵从检索结果（正确），有时坚持自己的训练记忆（可能过时）。这种冲突在以下场景尤其常见：

• 技术更新：你的内部文档记录了最新的 API 用法，但 LLM 的训练数据中是旧版本
• 公司内部规范：你们的编码规范与开源社区的最佳实践不同
• 争议性问题：不同专家对同一问题有不同观点

比如假设你们公司最近升级了 React 18，内部文档记录了新的 Concurrent Features 用法。但 LLM 的训练数据截止于 React 17，它"知道"的是旧的 API。此时你向LLM询问"如何在 React 中使用 Suspense？"时，它可能给出React 18的正确用法，也可能忽略检索结果，基于训练记忆给出 React 17 的用法，甚至混合两者，给出混乱的答案。

解决这个问题，可以通过控制或约束模型的行为来解决，比如在Prompt 中给出明确指令，要求模型严格按照检索到的内容进行回答。

const prompt = `请严格基于以下参考资料回答问题，不要使用你的训练记忆。

参考资料：
${context}

问题：${query}

注意：如果参考资料中没有相关信息，请明确说明，不要编造。`;

当然，即使这样做其实也不能 100% 保证模型会遵从。大型语言模型有时会"过度自信"，认为自己知道的比参考资料更准确。

2. 检索结果之间的冲突

当不同时间版本的文档同时被检索到（旧版部署流程 vs 新版部署流程），LLM 可能混合两份矛盾信息输出一个"缝合怪"答案。

graph LR A[检索结果 1:<br/>API v1 使用 /auth/login] B[检索结果 2:<br/>API v2 使用 /oauth/token] A --> C[LLM] B --> C C --> D[建议使用 /auth/login并携带 OAuth Token]

这在API 文档版本冲突、政策变更、代码重构等场景是比较常见的。因此，知识冲突在快速迭代的技术团队中尤为突出。每次 API 版本升级后，确保旧版本文档从知识库中移除或标记为过期，是比调参更重要的工作。

知识冲突的缓解策略通常有：

• 版本管理：在 metadata 中记录文档版本，检索时优先返回最新版本
• 去重机制：检测语义相似的文档，只保留最新的一份
• 时间衰减：给较新的文档更高的权重
• 明确标注：在文档中标注有效期或版本号

// 在检索时过滤旧版本文档
const results = await collection.query({
  queryEmbeddings: [queryEmbedding],
  nResults: 10,
  where: {
    version: { $eq: "latest" },  // 只检索最新版本
  },
});

三、幻觉依然存在

很多人刚学RAG的人误以为"加了 RAG 就不会有幻觉"，因为毕竟已经明确给了相关资料给LLM，但这是一个比较危险的误解。RAG 虽然能大幅降低幻觉概率，但不能完全消除。以下是三种 RAG 场景下幻觉的具体表现形式。

1. 忽略检索结果

检索到了正确答案，但 LLM 在生成时忽略检索结果，基于自己的训练记忆生成回答。原因是模型对自身知识的置信度高于外部信息、检索结果在 Prompt 中的位置不当（见"Lost in the Middle"现象）、Prompt 指令不够明确等。

// 查询
const query = "我们公司的git仓库地址是什么？";

// 检索结果
const context = "[文档 1] 公司git仓库地址为 xxxxxxx";

// 模型输出（幻觉）
const answer = "抱歉，我无法访问您公司的内部信息。一般来说，代码仓库地址由网络管理员提供。";
// 模型忽略了检索结果，给出了通用回答

2. 过度推断

检索结果提供了部分信息，但LLM 在此基础上编造了不存在的细节，使其看起来更完整。

// 查询
const query = "如何回滚部署？";

// 检索结果（只包含部署步骤，没有回滚相关内容）
const context = "[文档 1] 部署步骤：1. 构建镜像 2. 部署到集群 3. 验证";

// 模型输出（幻觉）
const answer = `部署回滚分为以下三步：
1. 停止当前服务
2. 恢复到上一个版本的镜像
3. 重启服务并验证`;
// 这些信息全是编造的！检索结果中根本没有回滚相关内容

之所以会这样是因为LLM 的训练目标是生成连贯的文本，而不是严格基于给定信息。当它发现检索结果不完整时，会倾向于用自己的知识补全，使答案看起来更完整和专业。缓解的策略有：

• 在 Prompt 中明确禁止编造："如果资料中没有相关信息，请明确说明"
• 使用 Self-RAG 或 CRAG 等进阶技术（见《第14章：高级 RAG 技术》）
• 在后处理阶段验证答案是否真的基于检索结果

3. 来源错误标注

LLM 正确使用了检索内容，但在标注引用来源时指向了错误的文档，也就是说答案是对的，但溯源是错的。

// 检索到两个文档
const docs = [
  "[文档 1] React 18 引入了 Concurrent Features",
  "[文档 2] Vue 3 引入了 Composition API",
];

// 用户提问
const query = "Vue 3 的新特性是什么？";

// 模型输出
const answer = "Vue 3 引入了 Composition API [文档 1]";
// 答案正确，但引用标注错误（应该是[文档 2]）

这对于需要严格溯源的场景（如法律、医疗）是很致命的问题。因此，针对这些场景，我们可以通过要求模型在引用时摘录原文片段，便于后续验证、在后处理阶段检查引用是否正确、使用专门的引文验证工具等手段来优化。

// 改进的 Prompt，要求摘录原文
const prompt = `请基于参考资料回答问题，并在每个论断后标注引用。

格式要求：
- 使用 [文档 X] 标注来源
- 对于关键信息，摘录原文片段

参考资料：
${context}

问题：${query}`;

四、多跳推理的困难

RAG 擅长查找型问题，即答案直接写在文档的某个片段中。但对于需要组合多个分散信息源才能回答的问题，RAG 表现不佳。

1. 什么是多跳推理？

多跳推理（Multi-hop Reasoning） 指需要多次检索和推理才能回答的问题。典型的多跳问题：

• "2024 年入职且绩效为 A 的员工中，谁的工龄最长？"
• "对比 React 18 和 Vue 3 的状态管理方案，哪个更适合大型项目？"
• "根据最近的三次部署记录，平均部署时长是增加还是减少了？"

回答第一个问题需要检索员工列表（文档 A）、检索绩效记录（文档 B）、检索入职日期（文档 C）、做交叉比对和排序等一些列的操作。单次 RAG 检索只能找到与查询"语义相似"的片段，但无法完成逻辑推理步骤。

2. 为什么标准 RAG 无法处理多跳问题？

原因 1：单次检索的局限性

标准 RAG 只做一次检索，返回 Top-K 最相关的片段。但多跳问题需要的信息可能分布在多个不相关的文档中，它们的语义相似度都不高，无法在一次检索中全部召回。

原因 2：缺乏推理能力

LLM 虽然有推理能力，但它只能基于给定的 Prompt 进行推理。如果 Prompt 中缺少必要的信息（因为检索失败），推理就无法进行。

原因 3：上下文窗口限制

即使检索到了所有相关文档，把它们全部塞进 Prompt 可能超出上下文窗口，或者导致"Lost in the Middle"现象。

3. 如何解决多跳推理问题？

在《第15章：Agentic RAG ------ 让 RAG 具备自主决策能力》中，我们会展示如何用 Agent 的推理循环来解决多跳问题。其核心思路是：

• 迭代检索：根据初步检索结果，生成新的查询，再次检索
• 推理规划：让 LLM 先规划回答问题的步骤，然后逐步执行
• 工具调用：结合代码执行、数据库查询等工具，完成复杂计算

例如：

// Agent 处理多跳问题的伪代码
async function multiHopQuery(query: string) {
  // 第一步：分解问题
  const subQuestions = await llm.decompose(query);
  // 输出: ["哪些员工2024年入职？", "哪些员工绩效为A？", "他们的工龄分别是多少？"]
  
  // 第二步：逐个检索
  const answers = [];
  for (const q of subQuestions) {
    const docs = await retriever.invoke(q);
    const answer = await llm.answer(q, docs);
    answers.push(answer);
  }
  
  // 第三步：综合推理
  const finalAnswer = await llm.synthesize(query, answers);
  
  return finalAnswer;
}

五、长尾知识覆盖不足

1. Top-K 截断的代价

RAG 默认为每次查询只返回 Top-K（通常 3-10）个片段。当回答一个问题需要的信息分布在知识库的第 50 个最相关片段时，标准 RAG 根本看不到它。比如你的知识库有 10,000 个文档片段。用户问了一个非常具体的问题，正确答案在第 50 个最相关的片段中。但你设置了 k=5，所以模型只能看到前 5 个片段，无法给出正确答案。导致这种现象的原因有：

• Embedding 相似度排序不完美：最相关的片段不一定排在最前面
• 语义鸿沟：某些片段的表达方式与查询差异较大，相似度得分偏低
• 切分粒度问题：关键信息可能被分割到多个片段中，单个片段的相似度不高

2. "大海捞针"的悖论

所谓大海捞针指的是你找的信息非常具体，但信息量又特别大。知识库越大，关键信息被淹没在大量无关片段中的风险越大。用户的问题越具体，越可能指向长尾信息，而这些信息恰好最难被精准检索到。这就会导致小知识库信息少，容易全覆盖，但覆盖面窄，而大知识库覆盖面广，但关键信息容易被淹没这样的矛盾。

一般有以下可以考虑的缓解策略：

• 增大 k 值：返回更多候选片段段，但会增加噪声和成本
• 混合检索：结合关键词搜索和向量搜索，提高召回率
• 多路召回：从不同的索引或角度分别检索，然后合并结果
• Reranker：先用快速算法召回大量候选，再用精细模型重新排序

这些策略在《第9章：高级检索策略》和《第10章：检索后处理与重排序》中会详细讨论。

六、成本与延迟的权衡

相比纯 LLM 调用（直接生成），RAG 不仅增加了检索环节的固定延迟，还因为 Prompt 中注入了检索结果而消耗更多 Token。

1. 延迟分析

RAG增加的执行延迟通常来源于Embeddig生成、向量检索等阶段。

环节	对延迟的贡献	优化空间
Embedding 生成（查询）	~50-200ms	缓存常用查询、使用更快的模型
向量检索	~5-50ms	优化 HNSW 参数、使用 GPU 加速
Prompt 组装	~1ms	无关紧要
LLM 生成	~500-3000ms	流式输出、使用更快的模型、减少 Token 数
网络传输	~50-100ms	CDN、边缘计算
总计	~600-3400ms	主要优化点在 Embedding 和 LLM 生成

对于实时对话应用，2-3 秒的延迟是可以接受的。但对于高频查询场景（如搜索引擎），这个延迟可能过高。

2. 成本分析

以 OpenAI 为例，使用text-embedding-3-small模型Embedding 费用 为 $0.02/Mtoken，使用gpt-4o调用的费用为0.02/M\; token，使用gpt-4o调用的费用为$ 0.02/Mtoken，使用gpt−4o调用的费用为5/1M input tokens + $15/1M output tokens。

假设一次查询：

• 查询文本：50 token
• 检索结果：4 个片段 × 200 token = 800 token
• Prompt 总长度：850 token
• 生成答案：200 token

成本计算：

Embedding 费用: 50 / 1,000,000 × $0.02 = $0.000001
LLM Input 费用: 850 / 1,000,000 × $5 = $0.00425
LLM Output 费用: 200 / 1,000,000 × $15 = $0.003
总成本: $0.007251 ≈ 0.7 美分

相比之下，纯 LLM 调用（无 RAG）的成本：

LLM Input 费用: 50 / 1,000,000 × $5 = $0.00025
LLM Output 费用: 200 / 1,000,000 × $15 = $0.003
总成本: $0.00325 ≈ 0.3 美分

RAG 的成本是纯 LLM 的 2.2 倍，主要来自检索结果带来的额外 Input Token。

3. 优化策略

在《第17章：RAG 性能优化实战》中，我们会系统性地讨论优化方案，包括：

• 缓存：缓存常用查询的 Embedding 和答案
• 异步处理：将索引管道与查询管道分离，避免阻塞
• 模型选择：根据场景选择合适的 Embedding 和 LLM 模型
• Token 优化：压缩检索结果，只传递必要信息
• 批处理：批量生成 Embedding，减少 API 调用次数

七、局限性与进阶方案的对应关系

本章揭示的每个局限，在后续进阶篇中都有对应的解决策略：

局限	影响	对应的进阶方案（章节）
语义鸿沟	检索召回低	混合检索（《第9章：高级检索策略》）
检索结果噪声	生成质量不稳定	Reranker 重排序（《第10章：检索后处理与重排序》）
知识冲突	答案错误	Prompt 工程（《第11章：Prompt 工程与上下文优化》）+ 评估（《第12章：RAG 系统评估与指标体系》）
幻觉残留	信息捏造	Self-RAG / CRAG（《第14章：高级 RAG 技术》）
多跳推理困难	复杂问题无法回答	Agent 推理循环（《第15章：Agent RAG》）
长尾覆盖不足	遗漏关键信息	性能调优（《第13章：RAG 系统调优实战》）、多路检索（《第9章：高级检索策略》）
成本延迟	用户体验差	系统架构（《第16章：生产级 RAG 系统架构设计》）、性能优化（《第17章：RAG 性能优化实战》）

理解这些对应关系，能帮助你在遇到具体问题时快速定位解决方案。

八、建立合理的技术预期

在学习了 RAG 的局限性后，我们需要建立合理的技术预期，搞明白RAG能做什么，不能做什么，遇到哪种问题用什么方案处理优化。

（1）RAG 能做到什么

• 大幅降低幻觉概率
• 提供可溯源的答案，每条信息都有出处
• 支持实时知识更新，无需重新训练模型
• 处理大部分"查找型"问题，准确率可达 80%-90%

（2）RAG 不能做到什么

• 完全消除幻觉（仍会有 1%-5% 的错误率）
• 处理复杂的多跳推理问题（需要 Agent 辅助）
• 保证 100% 的检索召回率（长尾问题难以覆盖）
• 实现超低延迟（< 100ms，检索环节有固定开销）

（3）何时应该考虑其他方案

• 如果你的知识库高度同质化（检索精度极低）
• 如果问题都需要多跳推理（RAG 无法胜任）
• 如果延迟预算极其紧张（< 100ms）
• 如果需要 100% 的准确性（任何 AI 系统都无法保证）

至于应该使用哪种方案来替代RAG，你可以参考如下场景：

• Fine-tuning + RAG 混合：用 Fine-tuning 学习固定模式，用 RAG 注入时效性知识
• 纯 Fine-tuning：如果知识固定不变，且需要超低延迟
• 传统搜索引擎 + 规则引擎：如果问题模式固定，可以用规则解决
• 人工审核：对于关键场景，AI 生成后需要人工审核

FAQ

Q1：RAG 能完全消除幻觉吗？

不能。如本章第三节所述，RAG 场景下幻觉以三种形式残留：忽略检索结果、过度推断、来源标注错误。将幻觉率从"经常出现"降到"偶尔出现"是 RAG 能做到的，降到零不是。

在实际生产中，典型的幻觉率分布如下：

• 纯 LLM：15%-25%
• 标准 RAG：3%-8%
• 优化后的 RAG（含 Rerank、Self-RAG 等）：1%-3%

对于需要 100% 准确性的场景（如医疗诊断、法律建议），仍然需要人工审核。

Q2：什么时候应该放弃 RAG 换用其他方案？

如果你的知识库高度同质化（检索精度极低），或者问题都需要多跳推理（RAG 无法胜任），或者延迟预算极其紧张（< 100ms），那么纯 RAG 可能不是最优方案。可以考虑 Fine-tuning + RAG 混合，或用 Agent 替代标准 RAG。

Q3：为什么有时候检索到了正确答案，模型却不使用？

这涉及 Prompt 设计和模型行为的问题。检索结果在 Prompt 中的位置（开头 vs 末尾）、模型自身的知识置信度（高置信度时倾向忽略外部输入）都会影响。在《第11章：Prompt 工程与上下文优化》中会深入讨论解决方案。

常见原因包括：

• Lost in the Middle：检索结果放在 Prompt 中间，模型注意力不足
• 指令不明确：没有明确要求模型"严格基于参考资料"
• 模型过度自信：模型认为自己的知识更可靠
• 检索结果质量差：检索到的内容确实不相关或表述不清

Q4：如何量化 RAG 系统的失败率？

可以使用 RAGAS 等评估框架，自动化测量以下指标：

• Answer Relevance：答案是否与问题相关
• Faithfulness：答案是否忠实于检索结果
• Context Precision：检索结果中有多少是真正相关的
• Context Recall：真正相关的文档有多少被检索到了

在《第12章：RAG 系统评估与指标体系》中，我们会详细介绍这些指标的计算方法和优化策略。

练习

练习 1：诊断你的 RAG 系统

对你在《第7章：基础篇实战：文档问答机器人》中构建的问答机器人，提出 10 个不同难度的问题。记录每个问题的检索结果和最终答案，分类标记哪些应答存在本章描述的失败模式。

验证标准：

• 至少识别出 2 种不同的失败模式
• 记录具体的查询案例和失败原因
• 提出可能的优化方案

提示：

准备以下类型的问题：

1. 简单查找型：答案直接在文档中
2. 语义转换型：用不同表达方式询问相同内容
3. 多跳推理型：需要组合多个文档的信息
4. 长尾型：涉及文档中不太显眼的内容
5. 冲突型：文档中存在矛盾信息

练习 2：复现知识冲突场景

准备两份内容矛盾的文档（如旧版本和新版本的同一个 API 文档），同时索引到知识库中。针对该 API 提问，观察 LLM 如何处理冲突信息。

验证标准：

• 记录模型是遵从了检索结果中的新版本文档，还是输出了混合版本，或是忽略了检索结果
• 尝试不同的 Prompt 指令，看是否能控制模型行为
• 提出改进方案，避免知识冲突

提示：

# 文档 1（旧版本）
API 端点：/api/v1/users
认证方式：Basic Auth

# 文档 2（新版本）
API 端点：/api/v2/users
认证方式：Bearer Token

练习 3：测量检索精度

编写一个脚本，自动评估检索结果的相关性。准备 20 个测试问题和对应的正确答案（文档 ID），计算以下指标：

• Recall@K：正确答案是否在 Top-K 结果中
• MRR（Mean Reciprocal Rank）：正确答案的平均排名倒数
• Precision@K：Top-K 结果中有多少是相关的

验证标准：

• 能够自动化计算上述指标
• 针对不同 k 值（1、3、5、10）对比指标变化
• 分析检索失败的典型案例

提示：

interface TestCase {
  query: string;
  relevantDocIds: string[];  // 相关文档 ID 列表
}

function calculateRecallAtK(results: string[], relevantIds: string[], k: number): number {
  const topK = results.slice(0, k);
  const hits = topK.filter(id => relevantIds.includes(id)).length;
  return hits / relevantIds.length;
}

练习 4：实验不同的 Prompt 指令

尝试不同的 Prompt 设计，看是否能减少幻觉：

1. 宽松指令："请回答问题"
2. 严格指令："请严格基于参考资料回答，不要编造"
3. 引用要求："请在每个论断后标注引用来源"
4. 拒绝指令："如果资料中没有相关信息，请明确说明'无法回答'"

对每种指令，测试 10 个问题，统计幻觉率。

验证标准：

• 记录每种指令下的幻觉率
• 分析哪种指令最有效
• 总结 Prompt 设计的最佳实践

📚 延伸阅读

• Seven Failure Points When Engineering a Retrieval Augmented Generation System --- Barnett et al., 详细分析了 RAG 系统的七大失败模式，是本章的重要参考
• Lost in the Middle --- Liu et al., 揭示了 LLM 对长上下文中不同位置信息的关注度差异，解释了为什么检索结果的位置很重要
• RAGAS: Automated Evaluation of Retrieval Augmented Generation --- RAG 自动评估框架论文，介绍了如何量化评估 RAG 系统的表现
• Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection --- Self-RAG 原始论文，展示了如何让模型自我反思和纠正幻觉
• CRAG: Corrective RAG --- CRAG 论文，介绍了如何通过修正机制提高 RAG 的准确性