完蛋！我把 AI 喂吐了！

2024-02-07
江苏
本文字数：5351 字
阅读完需：约 18 分钟

当我们用 RAG 构建一个知识库问答应用的时候，总是希望知识库里面灌的数据越多，问答的效果越好，事实真是如此吗？这篇文章给大家答案。

引言

在人工智能问答系统的发展中，RAG（Retrieval-Augmented Generation）技术以其独特的检索增强生成方式，为减少大模型幻觉开辟了新的天地。然而，在实际落地过程中有一个很大的疑问：RAG 系统，数据越多效果越好吗？本文将深入分析数据量如何影响 RAG 系统的问答效果，并讨论如何优化这一系统以适应不断增长的海量数据。

什么是 RAG？

大型语言模型（LLMs）已经展现出了强大的能力，但在实际应用中仍面临很多挑战，如模型幻觉、知识更新缓慢以及答案缺乏可信度等。LLM 虽然是在非常庞大的数据集上训练的，但并不是在您的数据上训练的。检索增强生成（RAG）通过将您的数据链接到 LLMs 来解决这个问题。

RAG 是一种将知识检索与生成模型相结合的技术，可以提高问答系统的准确性和相关性。它通过从外部知识源中动态检索信息，并将检索到的数据作为参考来组织答案，从而能有效缓解 LLM 中存在的幻觉问题。

RAG 系统

RAG 的工作流程主要包含三个模块：

索引（indexing）：文本索引的构建包括以下步骤：文档解析、文本分块、Embedding 向量化和创建索引。先将不同格式的原始文件解析转换为纯文本，再把文本切分成较小的文本块。通过 Embedding 为每一个文本块生成一个向量表示，用于计算文本向量和问题向量之间的相似度。创建索引将原始文本块和 Embedding 向量以键值对的形式存储，以便将来进行快速和频繁的搜索。

检索（Retrieval）：使用 Embedding 模型将用户输入问题转换为向量，计算问题的 Embedding 向量和语料库中文本块 Embedding 向量之间的相似度，选择相似度最高的前 K 个文档块作为当前问题的增强上下文信息。

生成（Generation）：将检索得到的前 K 个文本块和用户问题一起送进大模型，让大模型基于给定的文本块来回答用户的问题。

有关 RAG 更全面的信息请参阅综述论文：Retrieval-Augmented Generation for Large Language Models: A Survey，不想阅读原始英文论文？使用「有道速读」快速了解什么是 RAG？

RAG 系统：数据越多，效果越好吗？

从宏观层面来看，RAG 包含两个核心的要素：数据和系统。RAG 的应用场景非常多，包括文档助手，智能客服机器人，领域 / 行业知识库问答等。不同的应用场景优化的侧重点可能有所差异。

对于文档助手这类应用来说，数据是已知的，我就上传几篇文档，就针对这些文档来问问题。我们几乎不用关注数据侧的事情，把精力放在优化系统就可以了。

而对于领域 / 行业知识库问答来说，需要从数据侧和系统侧同时优化。因为如果用户问题回答不上来，有可能是没相关数据，也有可能是有数据但 RAG 系统没找到。

数据侧的优化很 “简单”，就是尽可能多的收集领域内相关的数据，通通灌进知识库里面。但是， 请先别着急！在开始组织人力收集整理数据之前，我们首先得弄清楚一件事情：RAG 系统，数据越多，效果越好吗？

如果答案是肯定的，意味着：

海量数据放心灌，我可以一批一批地往知识库中加数据，不用担心数据量太大相互干扰导致效果不佳。

快速迭代快速优化，对于上线之后的 badcase，业务侧可以直接通过加相应数据来快速迭代优化。

降低数据成本，收集和整理的成本，不用费劲心思去做数据去重和脏数据的处理。

增加系统的稳定性，如果我加的数据不相关，问答的效果不一定会变好，但是起码能保证以前的效果不会变差。

反之，那工作量可就大了😭

实验：数据量对于问答效果的影响

以教育领域的知识库问答为例，我们基于 RAG 做了一个升学百科问答的应用，专门解答用户关于高考升学规划和志愿填报政策相关的问题。

升学百科问答

升学百科问答不是给定数据，给定问题，然后只需要去优化算法或者系统的 Benchmark 任务。它的问题是开放的，数据也是开放的（你可以收集到尽可能多的相关数据来提升问答的效果）。所以优化的变量就多了一个：系统是一部分，数据也是一部分。问答效果的好坏不光取决于好的 RAG 系统，还取决于你的数据量够不够，覆盖的知识全不全？如何优化 RAG 能让它完全发挥出海量数据的价值是我们研究的重点。

关于数据量对 RAG 问答质量的影响，我们在升学百科问答项目中做了比较详细的研究。实验设置如下：

用户问题：收集了 176 个升学百科相关的问题，包括升学路径、志愿填报、选科等相关政策咨询问题。

RAG 系统：一个经典的 RAG 系统，包括文本解析切片，embedding 向量化建库，检索相关片段，语言模型总结问答等模块。

领域数据：我们收集了海量升学规划相关的资料来验证数据的问题，包括教育领域的互联网数据，书本资料，FAQ 问答对等。

RAG 在升学百科问答中的实践

结果：检索退化问题

我们分批往 RAG 知识库中灌入数据，每加一批数据都做一次评测，观察随着数据量变大，问答效果的变化情况：

baseline：第一批数据加入后问答正确率有 42.6%，此时有一些问题没回答上来是因为确实缺少相关资料。我们继续加数据…

迎来上涨：第二批加了更多数据，覆盖知识范围更广。准确率提升到了 60.2%，提升非常明显，看来加数据确实还是挺有用的。

坏消息：当加入第三批数据的时候，我们最担心的事情还是发生了。正确率急剧下降，跌了将近 8 个百分点。

到这里，我们的问题有了答案，不是所的 RAG 系统都能保证：数据越多，效果越好。海量数据有可能会把 AI 喂吐，随着数据的增多，数据之间可能会有相互干扰，导致检索退化的问题，影响问答的质量。

具体问题具体分析

先抓一个典型看看，大连医科大学怎么样？这个问题在 v2 版本（加入第三批数据前）是能回答对的，v3 版本（加入第三批数据后）回答错了。看了一下送到 LLM 的文本片段，居然全部都是大连理工大学相关的信息。

问题分析：大连医科大学的问答结果

主要原因是第三批加入的某些文档中恰好有大连理工大学 xxx 怎么样？的句子，和 query 大连医科大学怎么样？表面上看起来确实非常像，Embedding 给它打了比较高的分。

而类似大连医科大学师资介绍这样的片段相关性就稍微低了些。而 LLM 输入 token 有限制，前面两个最相关但是实际并不能回答 query 问题的片段就已经占满了 token 的窗口，只能把他俩送进 LLM 里。结果可想而知，啥都不知道。

RAG 中的检索退化问题

语义检索：相似≠相关

文本片段与 query 的相似性和文本片段是否包含 query 的答案（相关性）是两回事。RAG 中一个非常重要的矛盾点在于检索召回的片段比较多，但是 LLM 输入 token 是有限制，所以必须把能回答 query 问题的片段（和问题最相关）给 LLM。

Embedding（Bi-Encoder）

Embedding 也可以给出一个得分，但是这个得分描述的更多的是相似性。Embedding 本质上是一个双编码器，两个文本在模型内部没有任何信息交互。只在最后计算两个向量的余弦相似度时才进行唯一一次交互。所以 Embedding 检索只能把最相似的文本片段给你，没有能力来判断候选文本和 query 之间的相关性。但是相似又不等于相关。

如下图所示，从某种程度上，Embedding 其实就是在算两个文本块中相似字符的个数占比，它分不清 query 中的重点是大连医科大学，在它看来每个字符的重要性都是一样的。感兴趣的话可以计算一下下图中红字部分的占比，和最后余弦相似度的得分基本是吻合的。

Embedding 原理

Rerank（Cross-Encoder）

Rerank 本质是一个 Cross-Encoder 的模型。Cross-Encoder 能让两个文本片段一开始就在 BERT 模型各层中通过 self-attention 进行交互。它能够用 self-attention 判断出来这个 query 中的重点在于大连医科大学，而不是怎么样？。所以，如下图所示，大连医科大学怎么样？这个 query 和大连医科大学创建于 1947 年… 更相关。

Rerank 原理

Cross-Encoder 这么好，为什么不直接用？

因为速度慢。这里说的速度慢不是 cross-encoder 的模型比 bi-encoder 的模型速度慢。关键在于 bi-encoder 可以离线计算海量文本块的向量化表示，把他们暂存在向量数据库中，在问答检索的时候只需要计算一个 query 的向量化表示就可以了。拿着 query 的向量表示去库里找最相似的文本即可。

但是 cross-encoder 需要实时计算两个文本块的相关度，如果候选文本有几万条，每一条都需要和 query 一起送进 BERT 模型中算一遍，需要实时算几万次。这个成本是非常巨大的。

所以，我们可以把检索过程分为两个阶段：召回（粗排）和重排。

第一个阶段的目标是尽可能多的召回相似的文本片段，这个阶段的文本得分排序不是特别靠谱，所以候选的 topK 可以设置大一些，比如 topK=100；
第二个阶段的目标是对 100 个粗排的候选文本片段进行重新排序，用 cross-encoder 计算 100 个候选文本和 query 的相关度得分；

两阶段检索结合可以兼顾效果和效率。

两阶段检索在 RAG 中的实验

我们对上面升学百科中的文本片段用 Rerank 模型再做一次排序，重排序后的结果如下图所示，左右可以对照着看，左边是 Rerank 之前的文本片段，右边是 Rerank 重排之后的文本片段。可以明显看到右边文本片段的得分和排序更加合理，和人的感受基本上是一致的。重排序之后送进 LLM 窗口内的文本和 query 是最相关的，语言模型也能轻松根据相关信息回答出问题，再也不会说不知道了。

两阶段检索在 RAG 中的实验

QAnything：两阶段检索问答框架

QAnything (Question and Answer based on Anything) 是致力于支持任意格式文件或数据库的本地知识库问答系统。基于有道自研两阶段检索框架，能够做到数据越多，问答效果越好！

QAnything 具有以下特点：

数据安全放心用，完全离线使用；

跨语种知识随意问，中英文问答随意切换，无所谓文件是什么语种；

海量数据放心灌，两阶段向量排序，解决了大规模数据检索退化的问题，数据越多，效果越好；

生产级系统直接装，可直接部署企业级应用；

一键安装轻松用，无需繁琐的配置，一键安装部署，拿来就用；

多知识库随时切，支持多个知识库联合问答。

完全开源，完全免费！

QAnything 系统架构

QAnything 使用的有道自研检索组件 BCEmbedding 有非常强悍的双语和跨语种能力，能消除语义检索里面的中英语言之间的差异。其中包含的 embedding 和 rerank 模型均达到业界 SOTA，详细评测指标请参考：有道 BECEmbedding 模型和 Rerank 模型指标汇总，如果需要单独使用 embedding 和 rerank 组件，点击下面的链接进行下载：

https://github.com/netease-youdao/BCEmbed‍ding

最终结果

至此，我们可以在以上两阶段检索的 QAnything 系统上重新跑前三批数据的实验了。结果如下：