本文探讨了 RAG 系统中数据量与问答效果的关系。实验表明，单纯增加数据量可能导致检索退化，使准确率下降。这是因为传统 Bi-Encoder 检索仅计算相似度而非相关性，容易受噪声干扰。解决方案是采用两阶段检索框架：第一阶段利用 Bi-Encoder 快速召回候选集，第二阶段使用 Cross-Encoder 进行精细化重排。该方案有效解决了数据干扰问题，实现了数据越多效果越好的目标，并为后续优化如切片策略、多路召回等提供了方向。
当我们构建一个知识库问答应用的时候，总是希望知识库里面灌的数据越多，问答的效果越好。事实真是如此吗？本文将深入分析数据量如何影响 RAG（Retrieval-Augmented Generation）系统的问答效果，并讨论如何优化这一系统以适应不断增长的海量数据。
在人工智能问答系统的发展中，RAG 技术以其独特的检索增强生成方式，为减少大模型幻觉开辟了新的天地。然而，在实际落地过程中有一个很大的疑问：RAG 系统，数据越多效果越好吗？
大型语言模型（LLMs）已经展现出了强大的能力，但在实际应用中仍面临很多挑战，如模型幻觉、知识更新缓慢以及答案缺乏可信度等。LLM 虽然是在非常庞大的数据集上训练的，但并不是在您的私有数据上训练的。检索增强生成（RAG）通过将您的数据链接到 LLMs 来解决这个问题。
RAG 是一种将知识检索与生成模型相结合的技术，可以提高问答系统的准确性和相关性。它通过从外部知识源中动态检索信息，并将检索到的数据作为参考来组织答案，从而能有效缓解 LLM 中存在的幻觉问题。
RAG 的工作流程主要包含三个核心模块：
文本索引的构建包括以下步骤：文档解析、文本分块、Embedding 向量化和创建索引。
使用 Embedding 模型将用户输入问题转换为向量，计算问题的 Embedding 向量和语料库中文本块 Embedding 向量之间的相似度，选择相似度最高的前 K 个文档块作为当前问题的增强上下文信息。
将检索得到的前 K 个文本块和用户问题一起送进大模型，让大模型基于给定的文本块来回答用户的问题。
从宏观层面来看，RAG 包含两个核心的要素：数据和系统。RAG 的应用场景非常多，包括文档助手，智能客服机器人，领域/行业知识库问答等。不同的应用场景优化的侧重点可能有所差异。
对于文档助手这类应用来说，数据是已知的，上传几篇文档就针对这些文档来问问题。我们几乎不用关注数据侧的事情，把精力放在优化系统就可以了。
而对于领域/行业知识库问答来说，需要从数据侧和系统侧同时优化。因为如果用户问题回答不上来，有可能是没相关数据，也有可能是有数据但 RAG 系统没找到。
数据侧的优化很'简单'，就是尽可能多的收集领域内相关的数据，通通灌进知识库里面。但是，请先别着急！在开始组织人力收集整理数据之前，我们首先得弄清楚一件事情：RAG 系统，数据越多，效果越好吗？
如果答案是肯定的，意味着：
反之，那工作量可就大了。
以教育领域的知识库问答为例，我们基于 RAG 做了一个升学百科问答的应用，专门解答用户关于高考升学规划和志愿填报政策相关的问题。
升学百科问答不是给定数据，给定问题，然后只需要去优化算法或者系统的 Benchmark 任务。它的问题是开放的，数据也是开放的（你可以收集到尽可能多的相关数据来提升问答的效果）。所以优化的变量就多了一个：系统是一部分，数据也是一部分。问答效果的好坏不光取决于好的 RAG 系统，还取决于你的数据量够不够，覆盖的知识全不全？如何优化 RAG 能让它完全发挥出海量数据的价值是我们研究的重点。
关于数据量对 RAG 问答质量的影响，我们在升学百科问答项目中做了比较详细的研究。实验设置如下：
我们分批往 RAG 知识库中灌入数据，每加一批数据都做一次评测，观察随着数据量变大，问答效果的变化情况：
到这里，我们的问题有了答案，不是所有的 RAG 系统都能保证：数据越多，效果越好。海量数据有可能会把 AI 喂吐，随着数据的增多，数据之间可能会有相互干扰，导致检索退化的问题，影响问答的质量。
先抓一个典型看看，大连医科大学怎么样？这个问题在 v2 版本（加入第三批数据前）是能回答对的，v3 版本（加入第三批数据后）回答错了。看了一下送到 LLM 的文本片段，居然全部都是大连理工大学相关的信息。
问题分析：主要原因是第三批加入的某些文档中恰好有大连理工大学 xxx 怎么样？的句子，和 query 大连医科大学怎么样？表面上看起来确实非常像，Embedding 给它打了比较高的分。而类似大连医科大学师资介绍这样的片段相关性就稍微低了些。而 LLM 输入 token 有限制，前面两个最相关但是实际并不能回答 query 问题的片段就已经占满了 token 的窗口，只能把他俩送进 LLM 里。结果可想而知，啥都不知道。
文本片段与 query 的相似性和文本片段是否包含 query 的答案（相关性）是两回事。RAG 中一个非常重要的矛盾点在于检索召回的片段比较多，但是 LLM 输入 token 是有限制，所以必须把能回答 query 问题的片段（和问题最相关）给 LLM。
Embedding 也可以给出一个得分，但是这个得分描述的更多的是相似性。Embedding 本质上是一个双编码器，两个文本在模型内部没有任何信息交互。只在最后计算两个向量的余弦相似度时才进行唯一一次交互。所以 Embedding 检索只能把最相似的文本片段给你，没有能力来判断候选文本和 query 之间的相关性。但是相似又不等于相关。
从某种程度上，Embedding 其实就是在算两个文本块中相似字符的个数占比，它分不清 query 中的重点是大连医科大学，在它看来每个字符的重要性都是一样的。
Rerank 本质是一个 Cross-Encoder 的模型。Cross-Encoder 能让两个文本片段一开始就在 BERT 模型各层中通过 self-attention 进行交互。它能够用 self-attention 判断出来这个 query 中的重点在于大连医科大学，而不是怎么样？。所以，大连医科大学怎么样？这个 query 和大连医科大学创建于 1947 年… 更相关。
因为速度慢。这里说的速度慢不是 cross-encoder 的模型比 bi-encoder 的模型速度慢。关键在于 bi-encoder 可以离线计算海量文本块的向量化表示，把他们暂存在数据库中，在问答检索的时候只需要计算一个 query 的向量化表示就可以了。拿着 query 的向量表示去库里找最相似的文本即可。
但是 cross-encoder 需要实时计算两个文本块的相关度，如果候选文本有几万条，每一条都需要和 query 一起送进 BERT 模型中算一遍，需要实时算几万次。这个成本是非常巨大的。
所以，我们可以把检索过程分为两个阶段：召回（粗排）和重排。
两阶段检索结合可以兼顾效果和效率。
我们对上面升学百科中的文本片段用 Rerank 模型再做一次排序，重排序后的结果更加合理，和人的感受基本上是一致的。重排序之后送进 LLM 窗口内的文本和 query 是最相关的，语言模型也能轻松根据相关信息回答出问题，再也不会说不知道了。
在数据不变的情况，两阶段检索问答准确率有明显提升，这个结果再次证明了一阶段检索中存在数据互相干扰的情况。两阶段检索可以最大化的挖掘出数据的潜力，我们继续加数据，效果能够稳定提升。
两阶段检索最大的意义在于让'数据越多，效果越好'变成了现实。这是在准备开始优化一个 RAG 系统之前要确保的第一件事情。
两阶段检索是一个大的框架，给 RAG 提供了一个好的基础。未来可以在两阶段的基础上做更多细致的优化。这里有一些想法，贴出来和大家一起探讨：
RAG 系统并非简单的数据堆砌。随着数据量的增加，检索退化（Retrieval Degradation）现象会导致问答效果下降。这主要是因为传统的单阶段向量检索（Bi-Encoder）无法准确区分'相似'与'相关'。通过引入两阶段检索框架，即先用 Bi-Encoder 进行大规模召回，再用 Cross-Encoder（Rerank）进行精排，可以有效解决这一问题。这种架构使得系统在数据规模增长时仍能保持稳定的高质量输出，是实现企业级知识库问答的关键路径。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
