RAG详解：防止聊天机器人编造公司信息

常见的早期聊天机器人任务是这样的：回答来自公司文件的问题。一个快速制作的原型往往听起来很完善——但实际上会编造事实。它可能会声称“在12个国家提供全天候支持”，而实际上仅在某个国家提供服务，且仅在工作时间，并且还需要特定的IT人员在场才能响应。

这种缺陷正是RAG（检索增强生成）存在的意义：能够生成答案的模型与真正拥有该组织真实数据的模型并非同一回事。如果没有数据支撑，那些表现流畅的模型就会像在婚礼上夸夸其谈地编造家族历史的自大亲戚——正确率大约40%，但自信度却达到100%。

第一部分：RAG究竟是什么？

RAG即检索增强生成。其原理其实很简单。

系统不会仅要求模型依靠训练记忆来回答，而是先获取相关资料，再基于这些资料要求其给出答案。

可以把文本模型想象成一个能力出众但过于自信的实习生：写作能力很强，却记不住2023年的人力资源政策。RAG的任务就是在回答开始之前，把正确的资料交给这个实习生。

没有RAG时：回答依赖于记忆（内容陈旧、泛化严重或与公司实际情况不符）。有RAG时：回答除了依赖记忆，还结合了为该问题获取的文件。

一个值得牢记的简洁公式：

正确的信息 × 正确的上下文 × 正确的提示 = 正确的答案

第二部分：RAG流程

检索增强并非一次简单的操作，而是一个多步骤的过程：如果其中任何一步出错，答案就会延迟出现或错误。

第一步——知识来源

资料存储在何处？PDF文件、Word文档、Notion页面、SQL表格、Slack导出内容以及被遗忘的电子表格都属于知识来源。

第二步——文档加载器（数据导入）

数据摄取功能会将PDF/HTML/CSV等格式转换为结构清晰、统一的标准格式——通常类似如下形式：

Document(
  page_content="The quick brown fox...",
  metadata={"source": "annual_report.pdf", "page": 12, "author": "Finance Team"}
)

如果跳过仔细的加载流程，直接将原始PDF字节注入处理流程，往往会导致页眉页脚内容被误认为是“事实”（比如“根据第92页中的第47行……”）。其实没人需要这些页面装饰内容。

教训：脏数据输入会导致脏数据检索和错误答案。务必在源头保证数据清洁。

第三步——分块处理（即“切披萨”）

200页的PDF文件无法直接输入提示词中。上下文窗口容量有限，如果只请求一个食谱却向模型提供整本菜谱，会降低查询的准确性。

因此，文档会被分割成片段。

常见的策略有：

• 固定大小分块——每隔N个标记进行切割。速度快，但会导致句子中间被截断。
• 带重叠的固定大小分块——采用相同的切割方式但稍作重叠，以便保留边界上下文。这是常见的默认设置。
• 分层/递归分块——先处理章节和段落，然后再进行切割。
• 语义分块——通过嵌入模型将主题相同的句子归类到一起。更智能，但计算成本更高。
• 基于大语言模型的分块——让模型决定切割位置。成本较高，但适用于法律或医疗文本。

在看到合同中的“shall NOT be liable”被分割在“shall”之后后，一个实用的规则是：先从固定大小加重叠的方式开始；只有当检索质量确实不佳时才增加复杂性。

第四站——嵌入模型（将文字转化为GPS坐标）

嵌入模型能把句子转换成一组数字，这些数字体现的是句子的含义而非拼写形式。即使完全没有相同的词汇，语义相近的句子也会被存储在彼此邻近的位置。

“如何重置密码？”与“忘记了登录凭证”几乎没有任何共同的词汇，但表达的意思却十分接近。关键词搜索无法捕捉到这种关联，而嵌入模型则通过比较含义来发现它。

技术发展历程从仅统计词频的“词袋模型”→TF-IDF→Word2Vec→BERT，再到能够理解上下文的现代嵌入API及开源模型（如OpenAI、Cohere、BGE、E5等）。

类比：词袋模型相当于逐字进行的机器翻译；而现代嵌入模型则更像那些同时了解两种文化并能理解其意图的人。

第五站——向量存储库（存放所有数字列表的仓库）

当片段转化为向量后，就需要高效的存储与检索机制：如 Pinecone、Qdrant、Weaviate、Milvus、ChromaDB、FAISS 以及类似的系统。

针对某个查询，返回向量与查询向量距离最近的 Top-K 个片段。索引构建方式包括：

• 暴力搜索——逐一比较所有向量。精确度高，但大规模时速度极慢。
• 近似最近邻算法（ANN）——精确度略低，但速度更快。是常用的默认方案。
• IVF 算法——先对向量进行聚类，仅搜索有潜力的簇。
• HNSW 算法——快速遍历邻居图。在实战中的 RAG 应用中十分常见。

为追求“完美精确度”而对数百万个向量使用暴力搜索，会让本应毫秒级的查询延迟至休息时间那么长。应根据数据量来选择索引方式，而非出于面子考虑。

步骤 6 —— 检索（相似度搜索）

当有问题出现时，使用与处理文件相同的模型来嵌入该问题——混合使用不同模型是典型的错误做法——然后获取Top-K个相似的文本片段。

余弦相似度是常用的衡量标准：它关注两个向量的方向一致性，而不考虑长度因素。无论文本长度如何，这一标准都能保持稳定。

步骤7——增强处理（为模型提供合适的输入）

获取到的文本片段会被与用户问题一起插入提示词中，这就是“增强处理”步骤：

System: You are a helpful assistant. Only answer using the context below.
Context: [retrieved chunk 1] [retrieved chunk 2] [retrieved chunk 3]
Question: What is our refund policy?

步骤8——生成答案（大语言模型最终输出结果）

只有到这时，模型才会基于获取到的上下文而非主观感觉来写出最终答案。

第三部分：区分“能运行”与“运行良好”的关键因素

教程通常只讲解基本流程，而实际系统的质量往往需要更多考量。

重新排序——因为最初的搜索结果并不总是最佳结果

双编码器检索速度快但精度较低：查询内容和文档分别被编码后再进行比较。这种方法很适合将数百万条记录缩小到约50个候选项。

“快速且大致正确”并不等同于“完全正确”，因此速度较慢的交叉编码器重新排序器会同时对查询内容和文档进行评分，从而捕捉其中的细微差别、否定含义及上下文信息。它仅在候选列表上运行，进而筛选出真正的最佳结果。

类比：双编码器负责快速浏览简历以生成候选列表；交叉编码器则负责进行深入面试。

在无需重排的医疗常见问题解答机器人中，关于酒精相互作用的问题可能会引出仅词汇相同的其他药物。而交叉编码器重排机制通常能立即解决这一问题。在精度至关重要的领域（法律、医疗、金融），重排是必须的，而非可选的。

混合搜索——因为单独使用词汇搜索和向量搜索都有所欠缺

向量搜索能够捕捉含义，但可能忽略精确的标记——如SKU代码、错误编号、专有名词。BM25词汇搜索则能准确匹配字符串，但无法识别同义词。

混合搜索结合了BM25和向量检索技术：既具备关键词的精确度，又拥有语义层面的召回能力。当不确定时，混合搜索是绝佳的默认选择——很少会更差，往往效果更好。

RAG融合——像团队项目一样整合多种观点（不过这次它真的可行）

多种检索器（密集型、关键词型、领域专用型）会生成多份排序列表。RAG Fusion结合Reciprocal Rank Fusion (RRF)对这些列表进行整合。

尽管公式看起来很复杂，但其原理其实很简单：在多种独立方法中都排名靠前的文档很可能具有相关性。RRF更看重不同列表之间的一致性，而非那些在不同检索器间无法比较的原始分数。

RRF(d) = Σ  1 / (k + rank_i(d))

此处k的值通常为60——这更多是行业惯例而非推导出的固定值。

元数据——日后能拯救你的标签

元数据是关于数据的数据：标题、作者、日期、来源、访问权限。在出现访问规则之前，元数据似乎并无特别意义——比如“绝不对外部用户展示内部人力资源文档”——而access_level: internal这样的标签就变得至关重要了。

元数据可用于实现过滤、重新排序优化、访问控制以及故障排查（“为什么2019年的文档会回答2026年的问题？”→缺少日期过滤功能）。

内存与缓存——因为没人愿意为同样的计算付两次费

有两个常被混淆的概念：

• 内存 = 长期存储用户偏好、之前的对话内容以及持久性事实。
• 缓存 = 短期重复使用成本较高的结果（模型回复、搜索结果）以应对多次查询。

内存让助手的表现更加连贯一致；缓存则使其响应更快且成本更低。将二者混用——例如为偏好设置10分钟的过期时间并尝试“缓存”——可能会导致在对话进行到一半时丢失用户的姓名。应保持这两个概念的区分。

第4部分：何时不应使用RAG？

检索增强并非万能解决方案。

以下情况应避免使用RAG：

• 该问题属于模型已能处理的常识类内容（“法国的首都”无需向量索引）。
• 事实会不断变化（价格、实时比分等）——建议使用API。
• 任务具有高度创造性（诗歌创作、头脑风暴等）——检索功能几乎起不到作用。
• 语料库规模足够小，可直接放入提示词中。
• 超低延迟要求不能容忍额外的检索步骤。

有时解决方案是优化提示词或进行微调，而非采用完整的向量处理流程。在构建系统之前先选定工具。

第五部分：通过惨痛教训总结的最佳实践

1. 合理分块，避免过小或过大。过小的片段会丢失上下文，过大的片段则会降低精确度，建议采用有重叠的分块方式。
2. 文件与查询使用同一嵌入模型。混合使用不同模型相当于用不同的度量标准进行计算。

在准确性至关重要的情况下启用重新排序功能。虽延迟稍高，但能显著提升质量。

从一开始就为元数据添加标签。未来的过滤功能会需要这些标签。

持续进行评估。要跟踪Recall@k / Precision@k指标以及生成内容的准确性/相关性。主观感受不能作为衡量标准。

缓存成本较高的稳定结果；仅更新发生变化的内容。不要冻结变化迅速的事实，也无需重新计算静态内容。

设定约束机制。通过审核、引用标注以及幻觉检测，避免在演示中出现看似可信的错误内容。

那些将检索视为事后事项的团队通常会再次遇到同样的问题：加载器中隐性的模式漂移、将否定内容一分为二的块边界、离线索引与在线查询之间的嵌入模型不匹配，以及仅衡量“响应延迟”而忽视内容准确性的控制面板。成熟的RAG实践会将流程中的每个环节都视为需要明确负责人、测试方案及回滚计划的交付成果——尤其是当该系统用于服务客户或遵循严格监管的工作流程时。

在评估变更效果时，建议采用配对实验：使用相同的问题集和评分标准，对比在调整分块策略或重排算法前后Recall@k值与内容合理性指标。由于生成器无法引用那些从未进入上下文窗口的信息，因此微小的检索改进往往比仅调整提示词带来的更大提升更为有效。

RAG核心原则

正确的信息 → 正确的上下文 → 正确的提示词 → 正确的答案。

RAG是一种技术手段，而非魔法。通过干净的输入数据、合理的检索方式、诚实的信息增强，以及精准的生成提示词，就能把一个过于自信的人变成先仔细阅读文件、得到充分信息的专家——同时避免编造根本不存在的24/7全球服务。