大模型_3：RAG

标签：检索 RAG 模型 Embedding 文本问答

目录：

1. 背景介绍
2. 什么是 RAG？
3. RAG 技术范式发展
4、RAG 的生态
5. QAnything介绍
6. QAnything架构解析
7. 二阶段检索器（Two-stage Retriever）
8. LLM模型微调
9. RAG 和微调应该如何选择？
10. 本地部署
11. 应用示例
12. 基本能力
13. 文本向量算法与工具

1. 背景介绍

2022年底，OpenAI发布了对话大语言模型（Large Language Model, LLM）产品ChatGPT，ChatGPT因其“善解人意”和“博闻强识”的特点而走红，在全世界掀起了一场风暴。

“善解人意”意味着LLM有很强的问题理解能力（query understanding），很好地理解用户指令；
“博闻强识”展示了LLM对世界知识的记忆和理解，搭配其强大的in context learning的能力，可以很好地理解用户给的背景知识，根据用户问题进行回答。

这些特点让大众认识到LLM在ODQA场景的巨大潜力。不幸的是，强如ChatGPT这样的LLM还是有一些局限性。

Chatgpt有时会给用户错误的回答而误导用户，并且Chatpgt也无法告诉用户它对自己的回答有多大把握。
另一方面，即使ChatGPT这类LLM参数量很大，但也无法记住海量的世界知识，尤其是那些长尾知识（指的是数据集中少量类别占总数据集比重较大）。
LLM的预训练数据是某一时间之前的，不能很好地“紧跟时代”，存在知识时效性问题。

检索增强生成（Retrieval-Augmented Generation，RAG）利用检索非参数化的知识来提升知识密集型任务的性能，为解决大模型“幻觉”（答非所问），知识的“时效性”，私域数据等问题提供了很好的方向。

2.什么是 RAG？

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

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

论文原文：https://arxiv.org/abs/2312.10997

官方仓库：https://github.com/Tongji-KGLLM/RAG-Survey

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

索引（indexing）：文本索引的构建包括以下步骤：文档解析、文本分块、Embedding 向量化和创建索引。
- 先将不同格式的原始文件解析转换为纯文本，再把文本切分成较小的文本块。
- 通过 Embedding 为每一个文本块生成一个向量表示，用于计算文本向量和问题向量之间的相似度。
- 创建索引将原始文本块和 Embedding 向量以键值对的形式存储，以便将来进行快速和频繁的搜索。
检索（Retrieval）：使用 Embedding 模型将用户输入问题转换为向量，计算问题的 Embedding 向量和语料库中文本块 Embedding 向量之间的相似度，选择相似度最高的前 K 个文档块作为当前问题的增强上下文信息。
生成（Generation）：将检索得到的前 K 个文本块和用户问题一起送进大模型，让大模型基于给定的文本块来回答用户的问题。

RAG 更全面的信息请参阅综述论文：Retrieval-Augmented Generation for Large Language Models: A Survey

3.RAG 技术范式发展

在 RAG 的技术发展过程中，我们从技术范式角度，将其总结成如下几个阶段：

朴素（Naive RAG）:前文案例中展示了经典的 RAG 流程，也被称为 Naive RAG
进阶的RAG（Advanced RAG）:Naive RAG 在检索质量、响应生成质量以及增强过程中存在多个挑战。Advanced RAG 范式随后被提出，并在数据索引、检索前和检索后都进行了额外处理。通过更精细的数据清洗、设计文档结构和添加元数据等方法提升文本的一致性、准确性和检索效率。在检索前阶段则可以使用问题的重写、路由和扩充等方式对齐问题和文档块之间的语义差异。在检索后阶段则可以通过将检索出来的文档库进行重排序避免 “Lost in the Middle ” 现象的发生。或是通过上下文筛选与压缩的方式缩短窗口长度。
模块化RAG（Modular RAG）:随着 RAG 技术的进一步发展和演变，新的技术突破了传统的 Naive RAG 检索 — 生成框架，基于此我们提出模块化 RAG 的概念。在结构上它更加自由的和灵活，引入了更多的具体功能模块，例如查询搜索引擎、融合多个回答。技术上将检索与微调、强化学习等技术融合。流程上也对 RAG 模块之间进行设计和编排，出现了多种的 RAG 模式。然而，模块化 RAG 并不是突然出现的，三个范式之间是继承与发展的关系。Advanced RAG 是 Modular RAG 的一种特例形式，而 Naive RAG 则是 Advanced RAG 的一种特例。

4、RAG生态

RAG 的应用已经不仅仅局限于问答系统，其影响力正在扩展到更多领域。现在，推荐系统、信息抽取和报告生成等多种任务都开始受益于 RAG 技术的应用。

与此同时，RAG 技术栈也在井喷。除了已知的 Langchain 和 LlamaIndex 等工具，市场上涌现出更多针对性的 RAG 工具，例如：用途定制化，满足更加聚焦场景的需求；使用简易化，进一步降低上手门槛的；功能专业化，逐渐面向生产环境。

如下：RAG生态系统概览：

5.QAnything

QAnything[github] (Question and Answer based on Anything)是网易有道开源的检索增强生成式应用（RAG）项目，在有道许多商业产品实践中已经积累丰富的经验，比如有道速读和有道翻译。

github：https://github.com/netease-youdao/QAnything
试用：https://ai.youdao.com/saas/qanything/#/home

QAnything是一个支持任意格式文件或数据库的本地知识库问答系统，可获得准确、快速、靠谱的问答体验。QAnything支持断网离线使用，可私有化。

与市场上的其他Retrieval Augmented Generation (RAG) 产品相比，QAnything引擎的研发轨迹略显不同。

它不是一开始就被设定为一个具体的项目目标，而是在项目进展中，通过不断的探索和实践，逐步成形的。这个过程虽然经历了一些波折，但正是这些经历，让我们在RAG领域积累了丰富的实践经验。

从文档翻译到文档问答

QAnything的研发团队最初专注于文档翻译。2022年我们启动了一个为期一年的文档翻译的升级的项目，到2023年3月份上线，效果提升显著。正好那时候ChatGPT和类似技术正在兴起，我们意识到这正是将我们现有技术扩展至文档问答的绝佳时机。因此，我们毫不犹豫地为我们的文档翻译服务增添了问答功能，该功能能够根据文档内容自动推荐问题并提供答案，于5月份正式推出。

之所以能够轻松地扩展到文档问答，是因为有道在文档翻译领域的深厚积累。我们的文档翻译服务因其卓越的性能而闻名，这主要得益于两大核心技术：先进的翻译引擎和精准的文档解析/OCR技术。

多年来，在翻译和OCR领域的持续探索和创新，为我们构建Retrieval Augmented Generation (RAG) 系统提供了坚实的基础。

首先，核心技术方面，我们的翻译模型基于Transformer架构，这与当前研究领域的大型语言模型（LLM）紧密相连，实质上并无显著区别。所谓LLM，就是很大的Transformer模型，就是我们天天在研究的东西。ChatGPT出来后，我们之所以能迅速掌握并扩展我们的模型，例如开发了针对教育场景的“子曰”大模型，这一切都得益于我们对Transformer模型的深入理解和应用。
接着，关于RAG系统，它不仅仅是外部数据和LLM的简单叠加。鉴于用户文档的多样性，特别是PDF文件中复杂的图文混排，仅仅提取文本往往会带来信息的失真。例如，将具有逻辑连贯性的文本分割成多个片段，或者将图表数据错误地融入文本，这些都会严重影响信息的准确性。正因如此，我们长期致力于文档解析技术的研发，能够精确地识别和分析文档中的每一部分，无论是段落、图表、公式还是其他元素，确保将用户的查询以最适合机器处理的方式进行组织和检索。

借助有道翻译庞大的用户基础，我们得以在实际应用中不断完善和优化我们的系统。日均活跃用户数达百万级别的大数据反馈，为我们提供了宝贵的实践经验，使我们能够持续提升系统性能，满足用户对高质量翻译和问答服务的需求。

从文档问答到速读

有道速读(https://read.youdao.com) 是我们算法研究员从自己的需求出发做的产品。有道翻译桌面端虽然已经上线了文档问答，但是它主要是面向大众设计的，适合通用的文档。我们经常读论文，希望有一些论文相关的更个性一点的功能。而有道翻译用户量太大了，不方便随意改动。

我们做有道速读，一开始主要是面向论文阅读做的。这也是我们新技术的试验田，迭代快一点。我们看到了wordtune出了个段落摘要和对照的功能，用着特别爽，但是很贵，我们就把那个功能与RAG整合在一起，又能摘要读段落，又能问答，方便溯源。论文一般都会讲自己方法多好，我们就把其他人对这篇论文的评价信息也给整合起来了，做了论文口碑，把一篇论文的优势和局限更客观的展示出来。在内部做研发的过程中，有个研究人员希望能自动写综述，我们就在速读上加上了自动综述的功能，对每一篇论文，把前后引用的论文全部抓来，自动做问答，然后整理成报告。

有道速读可以看作是RAG在某个垂直领域的应用。因为里面的口碑、综述、文章解读等功能，都可以认为是先设置一个模版，有一堆问题（或者自动生成的），然后通过自问自答的方式，生成关键信息，最后再总结润色成文，这一切过程都是全自动的。

从速读到Qanything

速读主要是单篇问答（6月份刚上线时候只支持单篇，现在也支持多篇问答了，和QAnything主要区别是速读更偏重阅读的场景，QAnything偏重问答的场景，底层引擎是一样的），且只支持pdf的格式。QAnything是支持多文档问答的，不限文档格式。

做Qanything有个契机。去年7月份的时候，网易的IT集团想升级他们的客服系统，找到我们，问能否基于他们的IT文档做一个自动问答机器人，因为他们看到了我们的文档问答效果，觉得做的不错。于是我们就拿着他们的文档和历史的问答数据快速实验了一下，发现经过我们的系统后，70%的转人工的次数都可以被省下来，由AI来回答。

客服这个场景，用户的文档格式非常多样，回答问题需要综合各种文档的内容。于是我们在这个场景需求的推动下，做了多文档问答。我们给这个多文档问答系统取了一个大气的名字，叫Qanything，中文名字叫“万物皆可问”。

QAnything，也是我们的愿景。QAnything的前两个字母是Q和A，也是问答的意思，后面是anything，希望什么都可以放进去，什么东西都可以提问。

6.QAnything架构解析

2024年1月份，我们整理了下我们的QAnything的代码和模型，将适合开源的部分开放出来了。我们做这事，希望能和社区一起，共同推动RAG技术应用的发展。最近这个月，社区给了我们很对反馈，也让我们受益良多。

这次开源包括了模型和系统等所有必要的模块。

模型方面：包括ocr解析、embedding/rerank，以及大模型。
系统方面：包括向量数据库、mysql数据库、前端、后端等必要的模块。

整个引擎的功能完整，用户可以直接下载，不需要再搭配其他的模块即可使用。系统可扩展性也非常好，只要硬盘内存足够，就可以一直建库，支持无上限的文档。

QAnything的整体架构图如下：

系统的工作流程主要包含三个环节：

索引（indexing）：文本索引的构建包括以下步骤：文档解析、文本分块、Embedding向量化和创建索引。先将不同格式的原始文件解析转换为纯文本，再把文本切分成较小的文本块。通过Embedding为每一个文本块生成一个向量表示，用于计算文本向量和问题向量之间的相似度。创建索引将原始文本块和Embedding向量以键值对的形式存储，以便将来进行快速和频繁的搜索。
检索（Retrieval）：使用Embedding模型将用户输入问题转换为向量，计算问题的Embedding向量和语料库中文本块Embedding向量之间的相似度，选择相似度最高的前K个文档块作为当前问题的增强上下文信息。
生成（Generation）：将检索得到的前K个文本块和用户问题一起送进大模型，让大模型基于给定的文本块来回答用户的问题。

Bcembedding模型 [https://github.com/netease-youdao/BCEmbedding]

Embedding是RAG系统里面最关键的模块。为啥要自己训练embedding模型？一开始我们也是直接去尝试openai的ada embedding以及开源的embedding模型。但是我们很快发现，这样做有很大弊端。

首先，在我们的业务场景下，外部的embedding效果并不如宣传的那么好。openai的embedding接口除了效果不好外，还很慢。我们后来自研了embedding，因为是放在自己服务器上，调用起来比openai接口快一百倍。
其次，很多开源的embedding模型在mteb等地方刷傍刷的很高，但是那些刷榜的分值并不完全能反映真实的效果。
第三，我们业务场景有很多混合语言的情况，比如库里面放的是英文的文档，用户用中文去问答。这种跨语种的能力，现有模型支持不好。
第四，单纯的embedding在检索排序上天花板比较低，所以我们在embedding的基础上又做了rerank，共享同样的底座，head不一样。

为啥我们自己训练的模型会比openai的效果好？

我们认为可能是通才和专才的区别。openai是通才，但是它的效果远未达到万能的地步，大家不必迷信。在我们的场景下(客服问答以及一些toB客户的场景），openai的ada2 embedding的检索准确率只有60%，而经过训练的bcembedding检索准确率可以达到95%。

我们自研的BCEmbedding，总的来讲有两个特色：

中英双语和跨语种能力: 我们收集开源数据集（包括摘要、翻译、语义改写、问答等），来实现模型通用的基础语义表征能力。为了实现一个模型就可以实现中英双语、跨语种的检索任务，我们依赖网易有道多年积累的强大的翻译引擎，对数据进行处理，获得中英双语和跨语种数据集。实现一个模型就可以完成双语和跨语种任务。
多领域覆盖：我们分析现有市面上常见或可能的应用场景，收集了包括：教育、医疗、法律、金融、百科、科研论文、客服(faq)、通用QA等场景的语料，使得模型可以覆盖尽可能多的应用场景。同样的依靠网易有道翻译引擎，获得多领域覆盖的中英双语和跨语种数据集。实现一个模型就可以支持多业务场景，用户可以开箱即用。

我们在训练的过程中，发现一个有意思的现象，数据标签的构建对模型的效果影响非常大。相信大家一定听过“难例挖掘”的概念，在机器学习中模型性能上不去时候，经常是因为一些例子比较难，模型训练时候见的比较少，多挖掘一些难例给模型，就能够提升模型的性能。但是在embedding训练的时候，我们发现难例挖掘反而会降低模型的性能。我们猜测原因是embedding模型本身的能力有限，不应该给过难的任务。我们想要让模型做多领域覆盖，多语种、跨语种覆盖（还要覆盖代码检索和工具检索），这已经给Embedding增加很多负担了，应该想想怎么给Embedding“减负”。

因为Embedding模型是dual-encoder，query 和 passage（指文本块）在“离线”地语义向量提取时没有信息交互，全靠模型将query和passages“硬”编码到语义空间中，再去语义检索。而rerank的阶段，cross-encoder可以充分交互query和passage信息，潜力大的多。所以我们定了目标，embedding尽可能提高召回，rerank尽可能提高精度。

7. 二阶段检索器（Two-stage Retriever）

检索模块对RAG最终问答的正确率和用户体验非常重要，获得一个“善解人意”的高效检索器成为大家重要的研究方向。大家认同一个好的检索器的评判标准是：

1、尽可能召回用户问题所需的相关文本片段，
2、越相关的、对回答问题越有帮助的片段应该在越靠前的位置，过滤低质量片段。

“离线”的 Embedding 搭配“在线”的 Reranker

二阶段检索包含检索和精排两个阶段，如下图所示，因其很好地平衡了检索效果和速度，成为RAG流程中的常用选择。

检索阶段:常采用基于向量的密集检索方法，对用户问题和知识库语料进行语义向量提取，然后搜索和用户问题语义相近的若干片段。提取语义向量的Embedding模型一般采用dual-encoder的架构，可以预先（offline）对庞大的知识库语料提取语义向量。用户提问时，模型只需实时提取用户问题的语义向量，就可利用向量数据库进行语义检索了。这个过程中，知识库语料的语义向量提取是一个“静态”的、“离线”的过程，模型在提取用户问题和知识库语料的语义向量时，没有信息交互。该方式的好处是效率可以非常高，但这也限制了语义检索性能的上限。
精排阶段：为了解决信息交互的问题，采用cross-encoder架构，Reranker模型可以实现用户问题和知识库语料有信息交互，可以识别到更加准确的语义关系，算法性能上限非常高。该方式的缺点是，需要对用户问题和知识库语料进行实时（online）语义关系提取，效率比较低，无法对全量的知识库语料进行实时处理。
所以结合检索和精排二者的优势，检索阶段可以快速召回用户问题所需的相关文本片段，精排阶段可以将正确相关片段尽可能排在靠前位置，并过滤掉低质量的片段。

二阶段检索可以很好的权衡检索效果和效率，具有巨大应用价值。

BCEmbedding - 二阶段检索算法模型库

需求分析
首先我们分析RAG场景检索的目标是什么，需要检索的相关文本片段有什么特征。用户的问题一般可以分为翻译、总结、信息查询、问答等几类需求，所以检索器应该具备将不同语种的翻译文本做关联的能力（跨语种检索能力），具备将长原文和短摘要进行关联的能力，具备将不同表述但相同语义的文本做关联的能力，具备将不同问题但相同意图的问题进行关联的能力，具备将问题和可能的答案文本进行关联的能力。此外，为了给问答大模型尽可能高质量的知识片段，检索应该给出尽可能多的相关片段（EmbeddingModel），并且真正有用的片段应该在更靠前的位置（RerankerModel），可以过滤掉低质量文本片段。最后，我们期望我们的算法模型可以覆盖尽可能多的领域和场景，可以实现一个模型打通多个业务场景，让开源社区的用户获得开箱即用的模型，不需要再做微调。

算法设计

中英双语和跨语种能力: 我们收集开源数据集（包括摘要、翻译、语义改写、问答等），来实现模型通用的基础语义表征能力。为了实现一个模型就可以实现中英双语、跨语种的检索任务，我们依赖网易有道多年积累的强大的翻译引擎，对数据进行处理，获得中英双语和跨语种数据集。实现一个模型就可以完成双语和跨语种任务。
多领域覆盖：我们分析现有市面上常见或可能的应用场景，收集了包括：教育、医疗、法律、金融、百科、科研论文、客服(faq)、通用QA等场景的语料，使得模型可以覆盖尽可能多的应用场景。同样的依靠网易有道翻译引擎，获得多领域覆盖的中英双语和跨语种数据集。实现一个模型就可以支持多业务场景，用户可以开箱即用。

标签分配（label assign）

我们的BCEmbedding设计为二阶段检索器，“离线”的Embedding负责尽可能召回，“在线”的Reranker负责精排和低质量过滤。原因正如之前分析，Embedding模型是dual-encoder，query和passage在“离线”地语义向量提取时没有信息交互，全靠模型将query和passages“硬”编码到语义空间中，再去语义检索。可想而知，只要训练目标和任务稍微难一点，就会显著影响训练模型的最终性能。Reranker “在线”的cross-encoder可以充分交互query和passage信息，可以被安排来做“精排”这个有难度的工作。

前面我提到想要让模型做多领域覆盖，多语种、跨语种覆盖（还要覆盖代码检索和工具检索），这已经给Embedding增加很多负担了，下一步想想怎么给Embedding“减负”。

标签分配直接决定你训出来模型能做什么样的事，有什么“脾气”和“秉性”。标签分配也直接决定模型训练的难易程度。其实只要你的标签分配和你的业务目标一致就可以，学术研究设定的标签分配和你的业务目标有时候是不一致的。

难负样例挖掘？

我们在Embedding模型训练中，不使用难负样例挖掘，只在Reranker中使用。以下是我们的几点看法，供参考。

我们在训练Embedding模型时发现，过难的负样本对模型训练有损害，训练过程中会使模型“困惑”，影响模型最终性能。Embedding模型算法本身性能上限有限，很多难负样本只有细微差异，“相似”程度很高。就像让一个小学生强行去学习微积分，这种数据对Embedding训练是“有毒”的。
在大量的语料库中，没有人工校验的自动化难负样例挖掘，难免会“挖到正例”。语料库很大，里面经常会混有正例，利用已有Embedding模型去挖掘正例，经常会挖到正例，毒害模型训练。应该有不少调参工程师有这种惨痛经历。
其实所谓的“正例”和“难负样例”应该是根据你业务的定义来的。RAG场景下，之前人们认为的难负样例可能就成为了正例。比如要回答“小明喜欢吃苹果吗？”，RAG场景下召回“小明喜欢吃苹果”和“小明不喜欢吃苹果”都是符合目标的，而学术定义的语义相似这两句话又是难负样例。

所以回归我们业务目标和好检索器的“评判标准”，Embedding模型应该能尽量召回相关片段，不要将精排Reranker要干的事强压在Embedding身上，“越俎代庖”终究会害了它。

抛弃Instruction（指令）设定

关于为什么抛弃instruction，下面结合我们实际使用给出我们的看法。INSTRUCTOR 将instruction引入到语义向量表征中，对各个任务、各个数据集设计不同的instruction，可以使模型产生类似LLM指令跟随的能力。当遇到新场景、新数据集时，利用instruction可以实现zero-shot的语义表征能力。类似prompt的作用，设计instruction可以对不同的任务、不同的数据集进行子空间划分，缓解不同任务不同数据集之间数据分布和模式的冲突，激发出模型在预先定义的子空间的语义表征能力。从算法角度出发，将LLM的prompt应用在Embedding模型中，缓解不同任务、不同数据模式冲突，利用instructions让模型将文本编码到指定的语义空间，是一个精妙的想法。

不过，对每个任务、每个数据“精心”地设计instruction，人工设计痕迹较重，使用起来不方便通用。而且这种人为划分子空间来训练模型的方式复杂化学习目标，非常考验模型本身的容量（能力），比如INSTRUCTOR 在Base模型规模上的增益比Large模型规模的增益小很多。最近开源的Embedding模型将instruction更加简化，只对不同类任务进行instruction设计，或者只对Retrieval任务和非Retrieval任务进行区分。这种简化的方式更像人工设计硬编码一些任务子空间，缓解不同类任务的训练冲突。此时的instruction已经失去了INSTRCTOR的zero-shot的能力，沦为硬编码（instrcution稍微变一下，会有明显性能损失）。

其实更深一步，instruction也可以看成是标签分配的问题，较优的标签分配原则是：1、尽可能相同的数据分布、没有冲突的模式，分成一类，2、类别定义尽量简单，简化学习目标，3、紧跟业务目标（影响评测指标的计算方式）。

首先考虑到模型能力和实际模型推理效率，我们选用Base规模的模型，该规模的模型本身能力不是那么强悍。我们的算法模型定位是多语种、跨语种和尽可能多的专业领域覆盖，该定位本身目标难度就比较大了。如果再通过instrcution划分子空间复杂化学习任务，可能并不是一个好的选择。其次，从实际的使用角度来说，在RAG产品使用过程中，用户的实际问题多种多样，用户问题的意图也是千万变化，算法开发者“绞尽脑汁”地精心设计instrcution对用户来说常常是不易理解的，甚至用户自己都不知道自己的问题属于算法开发者预定义的哪种类型任务、是否需要instrcution、以及用哪种类型的instrcution，使用起来不友好。另一方面，RAG中检索的业务目标是，找出用户问题相关的片段。此时不仅仅要检索该问题的答案相关的片段，也要检索该问题相似问题，因为相似问题的上下文常常含有原问题的答案相关内容，比如客服FAQ场景。所以，我们将RAG需要检索的目标设置为正例（这个目标可能是相似问题，可能是对应答案，可能是短摘要对应的原长文，也可能是相关的推理过程）

最终效果

如表一所示，Embedding检索top 10片段，由Reranker精排，最后取top 5片段算指标。“WithoutReranker”设置下，bce-embedding-base_v1在top 5的片段检索性能虽然不是最好的，因为bce-embedding-base_v1并不善于精排（将groundtruth放在前面top 5）。但是经过Reranker之后的top 5，bce-embedding-base_v1指标是最好的，说明bce-embedding-base_v1在top 10的检索片段，召回的groundtruth比其他Embedding都要多，再利用bce-reranker-base_v1就可以实现最好的性能。

所以正如我们一开始的设计，Embedding负责尽可能召回，不把精排的压力压在Embedding身上，让Reranker这种上限高的角色来做精排这种难任务。bce-embedding-base_v1和bce-reranker-base_v1的组合拳可以实现最好的检索效果。

有意义的Rerank分数

评判标准”中好检索器还有一个特点，可以过滤低质量信息。我们设计的Reranker模型，输出的(query, passage)语义相关分数，不仅能用来做psaages排序，其分数的绝对值还有真实的语义相关意义，表征(query, passage)语义相关程度到底有多少，这可以用来判断哪些是低质量passages，就可以实现低质量片段过滤。这对RAG中LLM的回答问题非常有帮助，更干练、干扰信息少的context，可以提高LLM回答质量。

根据我们业务实践经验和开源社区同事的反馈，我们的bce-reranker-base_v1输出的分数可以以0.35～0.4为阈值，来进行低质量passage过滤。用户实际使用反馈，收获很不错的效果。

小结
我们设计了BCEmbedding（Bilingual and Crosslingual Embedding, BCEmbedding）算法模型库，包含EmbeddingModel和RerankerModel两种模型。设计一套RAG适配的标签分配方法，给Embedding减负；EmbeddingModel抛弃Instruction设定，不需要费尽心思设计每个任务设计的instruction，就能实现问题与相似问题检索，问题与候选答案检索，短摘要与长文本检索；设计RerankerModel训练loss，使得模型可以输出有意义的语义相关分数，实现低质量片段过滤，而不是仅仅用于排序。

最终，EmbeddingModel一个模型实现中英双语，以及中英跨语种的检索能力；RerankerModel可以只需一个模型实现中英日韩，以及中英日韩四个语种跨语种语义精排能力；EmbeddingModel和RerankerModel一个模型可以覆盖常见的RAG落地领域，比如：教育、医疗、法律、金融、科研论文、客服(FAQ)、通用QA等场景。

使用指南
我们开源二阶段检索模型EmbeddingModel(bce-embedding-base_v1)和RerankerModel(bce-reranker-base_v1)，可免费商用。同时我们提供一个配套的模型使用算法库BCEmbedding：

EmbeddingModel和RerankerModel可支持BCEmbedding，transformers，sentence-transformers框架推理模型；
提供LangChain和LlamaIndex的集成接口，可方便集成到现有基于LangChain或LlamaIndex的RAG产品中。
RerankerModel提供rerank方法，可以支持长passages（token数超过512）的精排。
RerankerModel提供rerank方法，可以提供有意义的query和passage的语义相关分数（0～1），可用于在精排，进一步过滤低质量passage，减少无关信息对LLM问答的干扰。

LlamaIndex评测RAG效果

检索排序效果评测方式 LlamaIndex（https://github.com/run-llama/llama_index）：是一个著名的大模型应用的开源框架，在RAG社区中很受欢迎。最近，LlamaIndex博客（https://blog.llamaindex.ai/boosting-rag-picking-the-best-embedding-reranker-models-42d079022e83）对市面上常用的embedding和reranker模型进行RAG流程的评测，吸引广泛关注。

为了公平起见，我们复刻LlamaIndex博客评测流程，将bce-embedding-base_v1和bce-reranker-base_v1与其他Embedding和Reranker模型进行对比分析。在此，我们先明确一些情况，LlamaIndex博客的评测只使用了llama v2（https://arxiv.org/abs/2307.09288）这一篇英文论文来进行评测的，所以该评测是在纯英文、限定语种（英文）、限定领域（人工智能）场景下进行的。

如上表所示，

在没有Reranker模块的设置下，bce-embedding-base_v1显著优于其他常见的开源和闭源英文embedding模型。
在相同reranker配置下（竖排对比），bce-embedding-base_v1也都是优于其他开源、闭源embedding模型。
在相同的embedding配置下（横排对比），利用reranker模型可以显著提升检索效果，印证前面所述二阶段检索的优势。bce-reranker-base_v1比其他常见的开源、闭源reranker模型具备更好的精排能力。

综上，bce-embedding-base_v1和bce-reranker-base_v1的组合可以实现最好的效果。

总结和展望
我们开源的BCEmbedding的两个检索模型bce-embedding-base_v1和bce-reranker-base_v1，最终目的是给RAG社区提供一套强有力的检索基础算法模型，可以拿来直接用，最好不需要finetune。bce-embedding-base_v1和bce-reranker-base_v1组合的二阶段检索器可以实现一个模型覆盖中英双语、跨语种场景，一个模型可以覆盖众多RAG常见的落地应用场景，并具备优异的性能。

未来针对RAG更多的应用场景，BCEmbedding会进行以下几个方向的关注和尝试：更多常用语种的支持，比如EmbeddingModel后续会支持中英日韩及其跨语种能力；支持更多场景的检索需求，比如代码检索和工具检索，适配更广阔的RAG应用场景；更好的用户意图理解，利用语义向量尽可能关联到到用户意图目标的片段。

8、LLM模型微调

我们的开源项目QAnything引入了一款7B参数规模的大型语言模型Qwen-7B-QAnything，该模型是在Qwen-7B基础上，通过使用我们团队精心构建的中英文高质量指令数据进行微调得到的。随着开源大型语言模型（LLM）基座模型的能力不断增强，我们通过在这些优秀的基座模型上进行后续训练，包括继续预训练、指令微调（SFT）和偏好对齐等工作，以更有效地满足RAG应用对大模型的特定需求，从而实现高性价比的模型优化。

为什么要微调？

RAG技术结合了知识检索与生成模型，通过从外部知识源检索信息，并将这些信息与用户问题整合成完整的Prompt输入到大模型中，以便根据这些参考信息回答问题。然而，当面对含有专业术语或通俗缩写的开放性问题时，直接使用开源Chat模型可能会导致模型回答不准确。此外，为了最大化利用大模型的上下文窗口，RAG应用倾向于保留尽可能多的检索信息，这可能会使得模型的注意力分散，降低其遵循指令的能力，进而引发回答中的重复内容、关键信息丢失等问题。为了提高大模型在参考信息不足时的诚实度，加入与用户问题关联度低的负样本进行微调训练变得必要。

在选择基座模型时，我们寻找能够支持中英文、至少具备4K上下文窗口的模型，且能在单块GPU上部署，优先考虑7B以下参数规模的模型以便于未来在消费级硬件上部署。Qwen-7B，一个阿里云研发的70亿参数的通用大模型，以其在多个基准测试中的卓越表现成为我们的选择。该模型通过在超过2.4万亿tokens的数据上预训练，包含了丰富的中英文、多语言、编程、数学等领域数据，确保了广泛的覆盖面。考虑到7B参数规模的限制，我们在指令微调时采用了结构化指令模板，以增强模型在实际应用中的指令遵循能力。

如下图：QAnything的prompt

如何微调？

指令微调数据构造我们为Qwen-7B-QAnything模型构造了丰富的指令微调数据集，涵盖了多种类型的数据，包括基于参考信息的结构化问答数据（单文档/多文档的事实问答、多文档的归纳总结/推理类问答、信息抽取）、多轮对话查询重写、段落摘要、开放域问答、中英文翻译以及跨学科问答等。
指令微调模型训练：尽管与大模型的预训练相比，指令微调成本较低，但在微调数据不完整或比例不平衡的初期探索阶段，采用全参数微调的代价依然较高。为了尽可能降低实验成本并快速验证微调效果，我们首先采用LoRA方法进行微调探索，待实验条件稳定后，再转向全参数微调。
- 我们的LoRA微调配置如下：使用8张A40显卡的单机环境，初始学习率设为3e-5，每张卡的批量大小为2，采用16步的梯度累积，同时利用bfloat16精度训练以避免溢出并增强稳定性。
- 此外，我们采用QLoRA + DeepSpeed Zero2 + FlashAttention配置以节约训练所需的显存。
- QLoRA通过4比特量化技术压缩预训练语言模型，使用NormalFloat4数据类型存储基模型权重，冻结基模型参数，并以低秩适配器（LoRA参数）形式添加少量可训练参数。
- 在微调阶段，QLoRA将权重从NormalFloat4数据类型反量化为bfloat16进行前向和后向传播，仅更新bfloat16格式的LoRA参数权重梯度。
- 与LoRA原论文不同，针对指令微调数据规模达到百万级别的情况，我们在所有线性层添加低秩适配器，并发现增加lora_rank和lora_alpha参数能显著提升微调效果。
- 因此，我们为Qwen-7B模型微调采取了特定的LoRA参数配置，以实现最佳效果。
指令微调模型问答效果评估：我们参考了这篇文章：Benchmarking Large Language Models in Retrieval-Augmented Generation，使用开源 Benchmark 的事实型文档问答测试集，对微调过后的LLM做质量评估。中、英文测试集分别包含300条，
- Context Noise Ratio （0～0.8）表示LLM 输入Context中不相关噪声片段的比例。
- 回答准确率指标结果说明：Qwen-7B-Chat (QwenLM 2023)表示论文中的结果，
- Qwen-7B-Chat表示使用开源Chat模型和结构化指令模版的结果，
- Qwen-7B-QAnything 表示QAnything开源项目微调模型的结果。
- 模型评估时使用了top_p采样。结果表明 Qwen-7B-QAnything对检索外部知识源包含不相关信息的鲁棒性更好。

9、RAG 和微调应该如何选择？

RAG 就像给模型一本教科书，用于定制的信息检索，非常适合特定的查询。

另一方面，FT 就像一个学生随着时间的推移内化知识，更适合模仿特定的结构、风格或格式。

FT 可以通过增强基础模型知识、调整输出和教授复杂指令来提高模型的性能和效率。然而，它不那么擅长整合新知识或快速迭代新的用例。

RAG 和 FT，并不是相互排斥的，它们可以是互补的，联合使用可能会产生最佳性能。

RAG 与其他大模型微调技术对比

10、本地部署

QAnything开源项目为本地部署的大型语言模型（LLM）提供了三种推理框架后端选项：FasterTransformer、vLLM和Huggingface Transformers。这些选项满足了不同用户对于部署LLM的需求，实现了在高性能与通用性之间的平衡。

FasterTransformer (https://github.com/NVIDIA/FasterTransformer) ：是由NVIDIA开源的一个高性能LLM推理框架，专为NVIDIA GPU优化。它的优点在于支持大型模型的INT8-Weight-Only推理，能在保持模型精度的同时减少推理延时和GPU显存使用，提高了在相同GPU配置下的多并发吞吐性能。FasterTransformer的模型权重转换与具体GPU型号无关，提供了一定的部署灵活性，但需要GPU具备一定的计算能力（FP16推理支持计算能力7.0及以上，INT8-Weight-Only支持7.5及以上）。此外，FasterTransformer作为Triton Inference Server的后端 (https://github.com/triton-inference-server/fastertransformer_backend) 实施LLM推理，支持Linux/Windows 11 WSL2部署。NVIDIA还基于FasterTransformer和TensorRT开发了新的推理框架TensorRT-LLM (https://github.com/NVIDIA/TensorRT-LLM)，进一步提高了推理性能，但这也意味着与NVIDIA GPU的绑定更紧密，牺牲了一定的灵活性和通用性。
vLLM (https://github.com/vllm-project/vllm) ：是由UC Berkeley LMSYS团队开发的另一款高性能LLM推理框架，其利用PagedAttention技术优化KV Cache管理，并结合并行采样和连续批处理请求调度管理，支持NVIDIA和AMD GPU，提高了系统吞吐性能。通过Huggingface Transformers训练的模型可以轻松部署为Python服务，展现出良好的系统灵活性。vLLM通过AWQ和GPTQ等算法支持INT4-Weight-Only推理，节省显存同时减少推理延时，但可能会轻微影响模型精度和生成质量。QAnything利用FastChat (https://github.com/lm-sys/FastChat)提供的接口使用vLLM后端，提供了兼容OpenAI API的调用接口，默认采用bfloat16推理，对GPU和算力有一定要求。
Huggingface Transformers (https://github.com/huggingface/transformers)：是由Huggingface团队开发的一个通用性强、灵活性高的Transformer模型库，与PyTorch等深度学习框架配合，支持模型训练和Python服务部署。虽然在多数情况下，其推理性能可能不及FasterTransformer和vLLM，但它兼容不同算力等级的GPU。QAnything通过复用FastChat(https://github.com/lm-sys/FastChat)提供的接口使用Huggingface Transformers后端，实现了兼容OpenAI API的调用，采用load_in_8bit配置加载模型以节省显存，同时使用bfloat16进行推理。

11、应用示例：知识库里面灌的数据越多，问答的效果越好

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

先别着急！在开始组织人力收集整理数据之前，我们首先得弄清楚一件事情：RAG 系统，数据越多，效果越好吗？

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

海量数据放心灌，我可以一批一批地往知识库中加数据，不用担心数据量太大相互干扰导致效果不佳。
快速迭代快速优化，对于上线之后的 badcase，业务侧可以直接通过加相应数据来快速迭代优化。
降低数据成本，收集和整理的成本，不用费劲心思去做数据去重和脏数据的处理。
增加系统的稳定性，如果我加的数据不相关，问答的效果不一定会变好，但是起码能保证以前的效果不会变差。

反之，那工作量可就大了

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

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

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

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

用户问题：收集了 176 个升学百科相关的问题，包括升学路径、志愿填报、选科等相关政策咨询问题。
RAG 系统：一个经典的 RAG 系统，包括文本解析切片，embedding 向量化建库，检索相关片段，语言模型总结问答等模块。
领域数据：我们收集了海量升学规划相关的资料来验证数据的问题，包括教育领域的互联网数据，书本资料，FAQ 问答对等。

结果：检索退化问题

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

baseline：第一批数据加入后问答正确率有 42.6%，此时有一些问题没回答上来是因为确实缺少相关资料。我们继续加数据…
迎来上涨：第二批加了更多数据，覆盖知识范围更广。准确率提升到了 60.2%，提升非常明显，看来加数据确实还是挺有用的。
坏消息：当加入第三批数据的时候，我们最担心的事情还是发生了。正确率急剧下降，跌了将近 8 个百分点。

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

具体问题具体分析

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

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

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

语义检索：相似≠相关
文本片段与 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 是最相关的，语言模型也能轻松根据相关信息回答出问题，再也不会说不知道了。