1

引言

本篇是接上篇RAG组合拳：AGI应用走向落地的40%（上篇）继续讲 RAG 组合拳。

上一篇讲到 openAI 的 RAG 案例中如何将企业知识库问答的准确率从 45% 提高到 65%，这一篇讲讲如何在 RAG 的 Rerank 环节和生成环节将回答准确率从 65% 提高到 98%(下图中的橙色方块部分)。

你将会看到以下内容：

1. RAG 流程中 Rerank 环节：常用 Rerank 模型使用、评估及代码参考示例。

2. RAG 流程中生成环节优化方法。

3. RAG 流程评估框架 RAGAS。

4. Data-driven 的方法持续迭代 RAG 应用，这一部分目前的文章比较少，本文探讨初步的思路。

和上篇类似，我们会将 RAG 中的各环节像串珠子一样串起来，对每个环节的细节会提供相应的优秀的参考文章和案例。这些文章在未来的实践中会持续更新，所以我所有的内容整理成飞书文档放在文末，非常适合大家收藏起来。[注] 为了和上一篇连续，文章标题序号沿续上一篇文章序号。

10

RAG 流程中 Rerank 环节

10.1

什么是 Rerank

首先通过一张图来直观地理解 Rerank 的效果。下图是 Rerank 模型 cohere 官网的效果对比图，左侧是维基百科原生的搜索排序，右侧是在左侧排序的基础上，进行重排后的结果，在右侧我们可以看到经过重排后，原先的排序会有较大的变化，比如原来排在第六位的文章重排后到了第一名。

简单说来，Rerank 就是把 RAG 中的检索环节结果中的 TopX(X通常较大比如50,100) 进行重新排序，类比于初赛入围后的复赛。那么为什么我们要这么斤斤计较排名结果，尤其是 Top3 的准确度？

我们想象在日常的 google 搜索中，作为用户你可能会扫一眼排在第一页的 20 篇文章，然后选择其中 5 篇来进行详细阅读。也就是说，google 只要给出 top20 篇，而不用再对这 20 篇进行严谨的排序，即可满足用户诉求。更重要的是，从搜索速度上来说，精准搜索 20 篇要远快于精准搜索 5 篇，你可以用简历的初筛和复试的速度来类比这个速度。

我们知道在 RAG 流程的最后环节，需要要把参考资料作为上下文发给大模型生成回答。如果我们把 Top20 的资料都发给大模型综合总结，显然会导致两个问题：

1. Token 消耗量大。

2. 过多内容会让大模型也会失忆。

所以，我们需要尽可能把最准确，最精炼的信息发给大模型，那么追求 TOP3 的精准度就是让 RAG 成功的关键步骤。

10.2

如何做 Rerank

Rerank 模型也有各大厂商的现成模型，目前我接触到的有：

• bge-reranker-base

• bge-reranker-large

• CohereRerank

网上有博主用长度约 36 页的 paper 作为测试数据，对以上三个模型进行评测，结果如下：

表中左列是使用的Embedding模型，对应的在不使用rerank和使用不同rerank模型下两个指标HitRate和 MRR的表现，两个指标的定义如下：

• HitRate：结果命中率，是期望结果在 TopN 中出现的概率。

• MRR：平均倒数排名(Mean Reciprocal Rank)，衡量期待结果在实际结果中的排序是否靠前。比如一次查询中，你期待的结果排在实际结果中的第一位，则 MRR 为：1 的倒数，如果排在第二位，则 MRR 为 2 的倒数 1/2。把所有查询中的倒数排名平均一下就是 MRR。

显然，如果要精准地找到 Top3 甚至是 Top1， MRR 对 Rerank 效果的评估更有意义。

事实上，我将上面的图用可视化的方式表达一下，可以看出 rerank 后 HitRate 的提升并不大(从80%到85%)，但 Rerank 后 MRR 的值有明显提升，从 65%左右(灰色柱所示) 可以提升到 85%甚至接近 90%以上(橘色、黄色、绿色柱代表不同 Rerank 模型的效果)，而这一结果和 OpenAI 成功案例中的数值基本一致。

我们也可以很容易看出：这三个 rerank 模型中的表现差别不大，而 Cohere 的 rerank 是付费的，对于大多数开发者来说，考虑开源的 BGE-Reranker-Large 即可(https://huggingface.co/BAAI/bge-reranker-large/tree/main上找到 models 文件下载安装)。

不过以上评测仅仅是以一篇 paper 为测试数据做的实验，如果大家希望用自己的数据做实验，可以参考以下文章中的代码做实验：《评测 Rerank 模型的代码实现》(https://blog.llamaindex.ai/boosting-rag-picking-the-best-embedding-reranker-models-42d079022e83)

Rerank 之后，意味着我们精准地找到了 top3 的相关资料，下一步就是将相关资料和用户最初的提问送给大模型生成最终回答。

11

RAG 流程中的生成环节

在 RAG 的生成环节要提高回答的准确率和直接问 ChatGPT 提高准确率的方法大概一致，在 OpenAI 的案例中提到了以下几种方法：

1. 优化提示词：最常见的就是指定 Role，rule，step(COT: Chain of Thought)，few shot，Step-Back Prompting，这些方法网络上文章很多，就不再赘述(系统学习参考 https://www.promptingguide.ai/) 。

2. Query expansion：比如在一次提问中暗含 3 个问题，我们需要把三个问题分开进行回答，然后在将答案合成返回给用户。

3. Tool use(工具使用)：在 OpenAI 的案例中提到的工具是 Text to SQL 方式，直接通过访问数据库来获取答案（这种方式已经超出 RAG 的范畴，迈向了 Agent 方法)。

这一部分和 RAG 本身的关系不大，不做赘述。

在大部分的文章中，RAG 流程到此就结束了，且目前几乎所有的知识库相关产品功能到此就结束了。但我们自己在实践的过程中认为，RAG 的评估应该作为最后一环，并以评测结果数据驱动 RAG 应用的迭代，可以作为优化 RAG 的重要方法。从互联网产品过来的同学应该都明白“数据驱动”的重要性。

12

评测 RAG: 打造 Data-driven 的 RAG 应用

RAG 的评估和前文提到的检索评估不一样，但二者又有相似之处。目前 RAG 的评估框架有几种，我们这里以开源框架 RAGAS 来说明，这也是 OpenAI 的案例中的评估方式。关于 RAGAS 的一切(从定义到使用可以参考 https://docs.ragas.io/)，在这里仅做简单介绍，让大家快速入门。

12.1

什么是 RAGAS

RAGAs 评估框架要求的输入是：

• 用户问题（question）

• 答案（answer）

• 上下文（contexts）

• 真实答案（ground truths）

上述输入可以通过 openAI GPT4 来生成，当然如果有现成的 FAQ 更好。利用这些信息，RAGAs 可以基于大型语言模型（LLMs）对 RAG 系统进行打分。

RAGAs 提供了两大类指标，一类评估生成能力，一类评估检索能力。

生成能力包含以下指标：

• 忠实度（faithfulness）：衡量回答是否属实，比如北京是中国的首都这是真实事件。

• 答案相关性（Answer relevancy）：衡量回答是否与答案相关，比如用户的问题是北京今天天气如何，回答为“北京是中国首都”，虽然事实正确，但并不相关。

• 答案语义相似性：Answer semantic similarity：衡量回答与答案的相似性

• 答案正确性：Answer Correctness：衡量回答与期待答案的正确性。**

检索能力包含以下指标：

• 上下文精度（Context precision)，衡量 Ground truth 在检索结果中是否排名较高，和检索评估中的 MRR(平均倒数排名)目标一致，但计算方法不一样。

• 上下文召回率（Context recall），衡量 Ground truth 与检索结果的相关性，和检索评估中的召回率 指标一致。

• 上下文相关性（Context relevancy），衡量检索结果与用户提问的相关性。

RAGAs 的指标计算方式在官网(https://docs.ragas.io/)上有，并且指标也在不断进化，在我写文章的前后就新增了一些指标，推荐大家关注官网学习。有了评估框架，构建 Data-driven 的 RAG 应用也就有了标杆。

12.2

我理想中的 Data-driven RAG 应用

到这里，我们看到 RAG 流程如此漫长，那么影响 RAG 成败的因素注定会很多。而我理想中的 data-driven 的 RAG 流程应该是：针对不同的知识库问答场景，以一个评估框架(RAGAS)，自动调优出最佳的分块方法、embedding 模型、rerank 模型、prompt 模板、大语言模型的组合。

比如我们有 4 种分块方法，2 种 embedding 模型，2 种 rerank 模型，3 种 prompt 模板，3 种大语言模型，那么 RAG 的方式就会有：4*2*2*3*3 = 144 种组合方式(当然，这是理论上最多的方式，实际中几个环节之间会有约束关系，比如某种 embedding 模型和某种 rerank 模型的组合是固定的)。我们对这 144 方式用同样的测试数据，使用同一个评估框架 RAGAS，就能找出最优组合。但这种方法的困难在于：

1. 测试成本高：RAG 环节组合的数量多，成本高。

2. 时间周期长：仅仅依赖测试数据还不够，最终也要结合用户的真实反馈数据（对答案的点赞、点踩）来评估，这就需要时间的积累。

或许放在目前的成本空间里，这不是一个 best practice，但长期来看，我们参考互联网产品中 A/B test，在 RAG 开始大规模地应用后，这种实践是必须的。比如 Amazon 在很早就开始对网站上的各种体验做 A/B test，长期累积的结果就构建了良好的用户体验和频繁的交易。

13

总结

在接近万字的长文中，终于给 RAG 所有的环节做了个大串烧。而万字背后的详情大约有近 5 万字的参考文章，且这些参考还在不断丰富、更新中。我自己也作为日常工作会经常翻阅、查看。为此我做了一个总结放在飞书文档里实时更新(目前含100M资料)，欢迎大家扫码二维码或者直接访问链接收藏(无需注册飞书)，如果你也有更好的资料，私信我一起分享。

链接：https://a8o6k6y8gp.feishu.cn/wiki/N6m5wbtHhiJvGZku8NTckaQfnqo?from=from_copylink