RAG 组合拳的下半部分来了。上一篇我们聊到，借助 OpenAI 的 RAG 实践案例，企业知识库问答的准确率可以从 45% 拉升到 65%。这一篇我们重点看看，如何在 Rerank（重排序）和生成这两个环节上做文章，把准确率从 65% 再往上推，目标是 98%。具体来说，就是下面图中橙色方块标出的那两块。
这篇会涉及这几个方面：
Rerank 环节中常用的模型、效果评估和可参考的代码；生成环节的优化思路；RAG 的整体评估框架 RAGAS；以及怎么用数据驱动的方法持续迭代 RAG 应用——这部分目前相关的讨论还不多，我们也来探讨一下初步的思路。
和上篇一样，我们会把 RAG 的各个步骤像串珠子一样串起来，每个环节的细节会附上一些优秀的参考文章和案例。这些资料会持续更新，相关内容都已经整理在飞书文档里了（链接在文末），方便大家收藏查阅。
RAG 流程中的 Rerank 环节
什么是 Rerank
先看一张图，直观感受一下 Rerank 的效果。这是 Cohere 官网的效果对比图，左侧是维基百科原生的搜索结果排序，右侧是在这个排序基础上重排后的结果。可以看到，经过重排，顺序发生了很大变化，比如原来排在第六的文档跑到了第一位。
简单来说，Rerank 就是把检索环节得到的 Top X（X 通常比较大，比如 50 或 100）结果重新排序，有点像初赛过了之后的复赛。那么，为什么我们要这么在意排名，特别是 Top 3 的精准度？
想象一下日常用 Google 搜索的场景：你可能会扫一眼第一页的 20 条结果，然后挑 5 个点开仔细看。对 Google 来说，给出 Top 20 就够了，并不需要精确排序这 20 条结果。更重要的是，从速度上看，粗搜 20 条比精搜 5 条快得多——这就好比简历筛选中的初筛和复试。
但在 RAG 的最后一个环节，我们需要把参考资料作为上下文喂给大模型来生成回答。如果一股脑儿把 Top 20 的资料全塞进去，会带来两个问题：一是 Token 消耗量大，二是内容太多会让大模型“失忆”。所以，我们得尽可能地把最准确、最精炼的信息给到大模型，追求 Top 3 的精准度，这才是 RAG 成功的关键。
如何做 Rerank
目前市面上有一些现成的 Rerank 模型，我接触到的有：
- bge-reranker-base
- bge-reranker-large
- CohereRerank
有博主用一篇约 36 页的 paper 作为测试数据，对这三个模型做了评测，结果如下：
表格左边是使用的 Embedding 模型，右边是对应的在不使用 Rerank 和使用不同 Rerank 模型下的 HitRate 和 MRR 表现。这两个指标的定义是：
- HitRate（命中率）：期望结果出现在 Top N 中的概率。
- MRR（平均倒数排名）：衡量期望结果在实际排序中是否靠前。比如一次查询中，你期望的结果排在第一，MRR 就是 1 的倒数；排在第二，MRR 就是 1/2。把所有查询的倒数排名平均一下，就是 MRR。
显然，如果目标是精准找到 Top 3 甚至 Top 1，MRR 对 Rerank 效果的评估更有意义。
把上面的数据可视化之后可以发现，Rerank 对 HitRate 的提升不算大（从 80% 到 85%），但 MRR 的提升很明显，从 65% 左右（灰色柱）提升到了 85% 甚至 90% 以上（橘色、黄色、绿色柱分别代表不同模型的效果）。这个结果和 OpenAI 成功案例中的数据基本一致。
另外也能看出，这三个 Rerank 模型的表现差别不大。Cohere 的 Rerank 是收费的，对大多数开发者来说，用开源的 BGE-Reranker-Large 就足够了（可以在 Hugging Face 上找到模型文件下载安装）。
不过，这个评测只是基于一篇 paper 的实验。如果大家想用自己的数据做测试，可以参考 LlamaIndex 博客上那篇《评测 Rerank 模型的代码实现》。
Rerank 之后，我们就精准地找到了 Top 3 的相关资料。下一步，就是把这些资料连同用户最初的提问，一起送给大模型来生成最终回答。
RAG 流程中的生成环节
在 RAG 的生成环节提高准确率，和直接问 ChatGPT 时提高准确率的方法大致相同。OpenAI 的案例中提到了几种：
- 优化提示词：比如指定角色、规则、步骤（思维链）、少样本提示、后退提示等。这方面的文章很多，不再赘述，可以系统学习 prompt 指南。
- Query expansion（查询扩展）：比如一个提问里暗含了 3 个子问题，需要把它们拆开分别回答，再把答案合成给用户。
- Tool use（工具使用）：OpenAI 案例中提到的工具是 Text to SQL，直接通过查数据库来获取答案。这其实已经超出了 RAG 的范畴，更接近 Agent 的思路了。
这一部分和 RAG 本身关联不大，就不展开了。
在大部分文章里，RAG 流程到这里就结束了，目前几乎所有的知识库产品功能也到此为止。但在实践中我们会发现，RAG 的评估应该作为最后一环，用评测结果数据来驱动 RAG 应用的迭代，这才是优化 RAG 的重要方法。从互联网产品过来的同学应该都明白“数据驱动”的价值。
评测 RAG：打造 Data-driven 的 RAG 应用
什么是 RAGAS
RAG 的评估和前文提到的检索评估不太一样，但也有相似之处。目前有几个评估框架，我们以开源的 RAGAS 为例来说明，OpenAI 的案例中也用了这种方式。关于 RAGAS 的一切（从定义到使用）可以参考官方文档，这里只做简单介绍，让大家快速入门。
RAGAS 评估框架需要的输入是：
- 用户问题（question）
- 答案（answer）
- 上下文（contexts）
- 真实答案（ground truths）
这些输入可以通过 GPT-4 生成，如果有现成的 FAQ 更好。利用这些信息，RAGAS 可以基于大语言模型对 RAG 系统进行打分。
RAGAS 提供了两大类指标：一类评估生成能力，一类评估检索能力。
生成能力指标：
- 忠实度（faithfulness）：衡量回答是否属实，比如“北京是中国的首都”是真实事件。
- 答案相关性（Answer relevancy）：衡量回答是否与问题相关。比如用户问“北京今天天气如何”，回答“北京是中国首都”虽然事实正确，但并不相关。
- 答案语义相似性（Answer semantic similarity）：衡量回答与答案的语义相似度。
- 答案正确性（Answer Correctness）：衡量回答与期待答案的正确性。
检索能力指标：
- 上下文精度（Context precision）：衡量真实答案在检索结果中是否排名靠前，和检索评估中的 MRR 目标一致，但计算方法不同。
- 上下文召回率（Context recall）：衡量真实答案与检索结果的相关性，和检索评估中的召回率指标一致。
- 上下文相关性（Context relevancy）：衡量检索结果与用户提问的相关性。
RAGAS 的指标计算方式在官网有详细介绍，而且指标也在不断进化，建议关注官网学习。有了评估框架，构建数据驱动的 RAG 应用就有了标杆。
理想中的 Data-driven RAG 应用
看到这里，你应该能感受到 RAG 的流程相当长，影响成败的因素自然也很多。一个理想的数据驱动 RAG 流程应该是：针对不同的知识库问答场景，以 RAGAS 为评估框架，自动调优出最佳的分块方法、Embedding 模型、Rerank 模型、Prompt 模板和大语言模型的组合。
比如，我们有 4 种分块方法、2 种 Embedding 模型、2 种 Rerank 模型、3 种 Prompt 模板、3 种大语言模型，那么理论上 RAG 的组合方式就有 4 × 2 × 2 × 3 × 3 = 144 种（当然，实际中各个环节之间有约束，比如某种 Embedding 模型和某种 Rerank 模型的组合是固定的）。对这 144 种方式用同样的测试数据、同一个评估框架，就能找出最优组合。但这种做法的困难在于：
- 测试成本高：排列组合多，成本自然高。
- 周期长：只靠测试数据还不够，最终还得结合用户的真实反馈（对答案的点赞、点踩）来评估，这需要时间积累。
在当前的成本约束下，这或许算不上最佳实践，但长远来看，参考互联网产品中的 A/B 测试，在 RAG 大规模应用后，这种做法是绕不开的。就像亚马逊很早就开始对网站上的各种体验做 A/B 测试，长期积累下来，构建了良好的用户体验和频繁的交易。
总结
接近万字的长文，总算把 RAG 的各个环节串了一遍。而万字背后的细节，大约有近 5 万字的参考文章，并且这些参考还在不断丰富和更新中。我自己在日常工作中也会经常翻阅。为了方便，我把所有内容总结在飞书文档里，会实时更新（目前包含约 100M 的资料），欢迎收藏查阅。