有道QAnything背后的故事—关于RAG的一点经验分享

近日，咱们开源了有道自研的RAG（Retrieval Augmented Generation)引擎QAnything。该引擎答运用户上传PDF、图片、Word、Excel、PowerPoint等多种格局的文档，并完成类似于ChatGPT的互动问答功用，其间每个答案都能精确追溯到相应的文档阶段来历。QAnything支撑纯本地布置，上传文档数量无上限，问答精确率高。

QAnything自开源以来，敏捷招引了开发者社区的广泛重视，并很快登上了GitHub trending榜单。短短一个月内，下载次数已达数万次，其间，咱们的语义嵌入排序模型BCEmbedding更是到达了惊人的60万次下载。依据社区的热情反馈，咱们决议同享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文件中杂乱的图文混排，仅仅提取文本往往会带来信息的失真。例如，将具有逻辑连贯性的文本分割成多个片段，或许将图表数据错误地融入文本，这些都会严重影响信息的精确性。正因如此，咱们长期致力于文档解析技能的研制，能够精确地辨认和剖析文档中的每一部分，无论是阶段、图表、公式仍是其他元素，保证将用户的查询以最合适机器处理的方式进行组织和检索。

凭借有道翻译巨大的用户基础，咱们得以在实践运用中不断完善和优化咱们的体系。日均活跃用户数达百万等级的大数据反馈，为咱们供给了名贵的实践阅历，使咱们能够持续提高体系功用，满意用户对高质量翻译和问答服务的需求。

从文档问答到速读

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

咱们做有道速读，一开始首要是面向论文阅览做的。这也是咱们新技能的试验田，迭代快一点。咱们看到了wordtune出了个阶段摘要和对照的功用，用着特别爽，可是很贵，咱们就把那个功用与RAG整合在一同，又能摘要读阶段，又能问答，便利溯源。论文一般都会讲自己办法多好，咱们就把其他人对这篇论文的评价信息也给整合起来了，做了论文口碑，把一篇论文的优势和约束更客观的展现出来。在内部做研制的进程中，有个研究人员期望能主动写总述，咱们就在速读上加上了主动总述的功用，对每一篇论文，把前后引用的论文悉数抓来，主动做问答，然后整理成报告。

有道速读能够看作是RAG在某个笔直范畴的运用。由于里边的口碑、总述、文章解读等功用，都能够认为是先设置一个模版，有一堆问题（或许主动生成的），然后经过自问自答的方式，生成要害信息，终究再总结润饰成文，这一切进程都是全主动的。

速读给了咱们一个练习场，让咱们调试运用新技能，这个进程也学到了许多，团队前进很大。当然，速读现在也不只约束于论文阅览了。

从速读到Qanything

速读首要是单篇问答（6月份刚上线时分只支撑单篇，现在也支撑多篇问答了，和QAnything首要差异是速读更侧重阅览的场景，QAnything侧重问答的场景，底层引擎是相同的），且只支撑pdf的格局。QAnything是支撑多文档问答的，不限文档格局。

做Qanything有个契机。上一年7月份的时分，网易的IT集团想晋级他们的客服体系，找到咱们，问能否依据他们的IT文档做一个主动问答机器人，由于他们看到了咱们的文档问答作用，觉得做的不错。所以咱们就拿着他们的文档和前史的问答数据快速试验了一下，发现经过咱们的体系后，70%的转人工的次数都能够被省下来，由AI来答复。

客服这个场景，用户的文档格局十分多样，答复问题需要概括各种文档的内容。所以咱们在这个场景需求的推进下，做了多文档问答。咱们给这个多文档问答体系取了一个大气的姓名，叫Qanything，中文姓名叫“万物皆可问”。

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

在上一年8月份的时分，除了内部客户要，有道智云的外部B端客户也需要这样的多文档问答体系，还需要私有化。所以咱们就做了大模型的小型化适配，做了私有化的版别，能够直接跑在游戏本上的。整个体系是完好的，可直接运用，也能够经过API调用。给了客户，卖了点钱。

从QAanyhing到升学咨询

咱们一向将qanything的体会页挂在网上，首要是为了做有道智云toB生意的时分给外部用户体会的，也没怎样宣扬。上一年9月份的时分，忽然有一天，咱们的精品课事业部（有道领世）的人找上门来，说期望合作QAnything。本来，他们不知道经过哪里的渠道知道了咱们的QAnything，去体会了下，发现作用很好。比他们自己用langchain/lamma index chatgpt 建立了好久的体系，作用要好许多。

有道领世在高中升学范畴深耕多年，堆集了海量的升学数据材料，有几万份的文档，还有大量的数据存储在数据库里。咱们的使命是经过QAnything，结合这样的堆集的数据，打造出一个私人AI规划师，针对每个家长和学生，供给个性化、愈加全面、专业、及时的升学规划服务。

一开始，咱们把悉数数据直接塞入咱们QAnything体系，升学百科问答只要45%的精确率。经过一段时间的反复迭代优化，咱们把确确率提高到了95%。现在体系能够解答用户关于高考方针、升学路径、学习日子以及职业规划等各种问题。未来跟着不断地数据弥补和更新，精确率会一向上涨。

有道AI升学规划师产品做出来后，咱们都为它的体会感到冷艳。

Qanything开源

本年1月份，咱们整理了下咱们的QAnything的代码和模型，将合适开源的部分敞开出来了。咱们做这事，期望能和社区一同，共同推进RAG技能运用的发展。最近这个月，社区给了咱们很对反馈，也让咱们获益良多。

QAnything架构解析

这次开源包括了模型和体系等所有必要的模块。模型方面包括ocr解析、embedding/rerank，以及大模型。体系方面包括向量数据库、mysql数据库、前端、后端等必要的模块。整个引擎的功用完好，用户能够直接下载，不需要再搭配其他的模块即可运用。体系可扩展性也十分好，只需硬盘内存满意，就能够一向建库，支撑无上限的文档。

QAnything的全体架构图

体系的工作流程首要包括三个环节：

• 索引（indexing）：文本索引的构建包括以下进程：文档解析、文本分块、Embedding向量化和创立索引。先将不同格局的原始文件解析转化为纯文本，再把文本切分成较小的文本块。经过Embedding为每一个文本块生成一个向量表明，用于核算文本向量和问题向量之间的类似度。创立索引将原始文本块和Embedding向量以键值对的方式存储，以便将来进行快速和频频的查找。
• 检索（Retrieval）：运用Embedding模型将用户输入问题转化为向量，核算问题的Embedding向量和语料库中文本块Embedding向量之间的类似度，挑选类似度最高的前K个文档块作为当时问题的增强上下文信息。
• 生成（Generation）：将检索得到的前K个文本块和用户问题一同送进大模型，让大模型依据给定的文本块来答复用户的问题。

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尽或许提高精度。

咱们在Embedding模型练习中，不运用难负样例发掘，只在Reranker中运用。以下是咱们的几点观点，供参阅。

1. 咱们在练习Embedding模型时发现，过难的负样本对模型练习有危害，练习进程中会使模型“困惑”，影响模型终究功用[19]。Embedding模型算法自身功用上限有限，许多难负样本只要细微差异，“类似”程度很高。就像让一个小学生强行去学习微积分，这种数据对Embedding练习是“有毒”的。
2. 在大量的语料库中，没有人工校验的主动化难负样例发掘，难免会“挖到正例”。语料库很大，里边常常会混有正例，运用已有Embedding模型去发掘正例，常常会挖到正例，毒害模型练习。应该有不少调参工程师有这种惨痛阅历。
3. 其实所谓的“正例”和“难负样例”应该是依据你事务的定义来的。RAG场景下，之前人们认为的难负样例或许就成为了正例。比如要答复“小明喜欢吃苹果吗？”，RAG场景下召回“小明喜欢吃苹果”和“小明不喜欢吃苹果”都是符合方针的，而学术定义的语义类似这两句话又是难负样例。

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

检索排序作用评测方式LlamaIndex（github.com/run-llama/l…

为了公正起见，咱们复刻LlamaIndex博客评测流程，将bce-embedding-base_v1和bce-reranker-base_v1与其他Embedding和Reranker模型进行比照剖析。在此，咱们先明确一些状况，LlamaIndex博客（blog.llamaindex.ai/boosting-ra… v2（arxiv.org/abs/2307.09…

LlamaIndex博客评测复刻

如上表所示，

• 在没有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的组合能够完成最好的作用。

多范畴、多语种和跨语种RAG作用正如上所述的LlamaIndex博客（huggingface.co/datasets/ma…范畴泛化性，双语和跨语种才能，咱们依照该博客的办法构建了一个多范畴（核算机科学，物理学，生物学，经济学，数学，量化金融等范畴）的中英双语种和中英跨语种评测数据，CrosslingualMultiDomainsDataset（huggingface.co/datasets/ma…

为了使咱们这个数据集质量尽或许高，咱们选用OpenAI的gpt-4-1106-preview用于数据生成。为了防止数据走漏，评测用的英文数据咱们挑选了ArXiv上2023年12月30日最新的各范畴英文文章；中文数据挑选Semantic Scholar相应范畴高质量的尽或许新的中文文章。

咱们针对市面上最强的常用开源、闭源embedding和reranker模型，进行体系性评测剖析，成果如上图所示。

• 竖排比照，bce-embedding-base_v1的体现和之前相同，具有很好的作用，语种支撑和范畴掩盖都很不错。最新的openai-embed-3和bge-m3体现出顽强的功用，具有良好的多语种和跨语种才能，具有良好的范畴泛化性。Cohere和e5的多语种embedding模型相同体现出不错的作用。而其他单语种embedding模型体现却不尽如人意（JinaAI-v2-Base-zh和bge-large-zh-v1.5稍好一些）。

• 横排比照，reranker模块能够明显改善检索作用。其间CohereRerank和bge-reranker-large作用适当，bce-reranker-base_v1具有比前二者更好的精排才能。

• 综上，bce-embedding-base_v1和bce-reranker-base_v1的组合能够完成最好的检索作用（93.46/77.02），比其他开源闭源最好组合（bge-m3-large bge-reranker-large，89.94/70.17），hit rate提高3.53%，mrr提高6.85%。

Rerank的必要性

为啥需要rerank，上面数字或许还不直观。咱们在开源的github上放了一张图，意思是QAnything在常识库的数据越多，精确率越高。而一般建立的RAG，假如没有rerank这一环节，在数据输入多了以后，作用反而下降了。

咱们在做升学问答的时分，遇到一个风趣的现象：咱们分批往RAG常识库中灌入数据，每加一批数据都做一次评测，调查跟着数据量变大，问答作用的变化状况：

• baseline：第一批数据参加后问答正确率有42.6%，此刻有一些问题没答复上来是由于的确缺少相关材料。咱们持续加数据…
• 迎来上涨：第二批加了更大都据，掩盖常识范围更广。精确率提高到了60.2%，提高十分明显，看来加数据的确仍是挺有用的。
• 坏消息：当参加第三批数据的时分，咱们最担心的事情仍是发生了。正确率急剧下降，跌了将近8个百分点。

不是所的RAG体系都能保证：数据越多，作用越好。跟着数据的增多，数据之间或许会有彼此搅扰，导致检索退化的问题，影响问答的质量。

这个现象在最近的一篇论文：The Power of Noise: Redefining Retrieval for RAG Systems（arXiv:2401.14887v2）也有一些解说，关于RAG体系，假如喂给大模型的输入是相近容易混淆的话，对正确性的影响是最大的。

以咱们遇到的一个case为例，大连医科大学怎样样？这个问题在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年…更相关。

加上两阶段检索后，从头跑一下试验：

在数据不变的状况，两阶段检索问答精确率从52.8%提高到65.9%，这个成果再次证明了一阶段检索中存在数据相互搅扰的状况。两阶段检索能够最大化的发掘出数据的潜力，咱们持续加数据，作用能够安稳提高。如下图所示，两阶段检索最大的含义不是在某一个试验上面提高了10个点。它最大的含义在于让“数据越多，作用越好”变成了实际。在实践运用中，由于rerank比embedding慢得多，所以一般用两阶段检索。速度慢不是cross-encoder的模型比bi-encoder的模型速度慢。要害在于，bi-encoder能够离线核算海量文本块的向量化表明，把它们暂存在向量数据库中，在问答检索的时分只需要核算一个query的向量化表明就能够了。拿着query的向量表明去库里找最类似的文本即可。可是cross-encoder需要实时核算两个文本块的相关度，假如候选文本有几万条，每一条都需要和query一同送进BERT模型中算一遍，需要实时算几万次。这个成本是十分巨大的。所以，咱们能够把检索进程分为两个阶段：召回（粗排）和重排:

• 第一个阶段的方针是尽或许多的召回类似的文本片段，这个阶段的文本得分排序不是特别靠谱，所以候选的topK能够设置大一些，比如topK=100；
• 第二个阶段的方针是对100个粗排的候选文本片段进行从头排序，用cross-encoder核算100个候选文本和query的相关度得分；

两阶段检索结合能够统筹作用和效率。

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

如何微调？

1. 指令微调数据结构咱们为Qwen-7B-QAnything模型结构了丰富的指令微调数据集，涵盖了多种类型的数据，包括依据参阅信息的结构化问答数据（单文档/多文档的事实问答、多文档的概括总结/推理类问答、信息抽取）、多轮对话查询重写、阶段摘要、敞开域问答、中英文翻译以及跨学科问答等。

2. 指令微调模型练习

虽然与大模型的预练习比较，指令微调成本较低，但在微调数据不完好或份额不平衡的初期探究阶段，选用全参数微调的代价依然较高。为了尽或许下降试验成本并快速验证微调作用，咱们首要选用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参数装备，以完成最佳作用。

3. 指令微调模型问答作用评价

咱们参阅了这篇文章：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对检索外部常识源包括不相关信息的鲁棒性更好。

揭露数据集的benchmark的评测成果

本地布置

QAnything开源项目为本地布置的大型言语模型（LLM）供给了三种推理结构后端选项：FasterTransformer、vLLM和Huggingface Transformers。这些选项满意了不同用户关于布置LLM的需求，完成了在高功用与通用性之间的平衡。

FasterTransformer (github.com/NVIDIA/Fast…)是由NVIDIA开源的一个高功用LLM推理结构，专为NVIDIA GPU优化。它的长处在于支撑大型模型的INT8-Weight-Only推理，能在保持模型精度的一起削减推理延时和GPU显存运用，提高了在相同GPU装备下的多并发吞吐功用。FasterTransformer的模型权重转化与详细GPU型号无关，供给了一定的布置灵活性，但需要GPU具有一定的核算才能（FP16推理支撑核算才能7.0及以上，INT8-Weight-Only支撑7.5及以上）。此外，FasterTransformer作为Triton Inference Server的后端 (github.com/triton-infe…)施行LLM推理，支撑Linux/Windows 11 WSL2布置。NVIDIA还依据FasterTransformer和TensorRT开发了新的推理结构TensorRT-LLM (github.com/NVIDIA/Tens…)，进一步提高了推理功用，但这也意味着与NVIDIA GPU的绑定更严密，献身了一定的灵活性和通用性。

vLLM (github.com/vllm-projec…)是由UC Berkeley LMSYS团队开发的另一款高功用LLM推理结构，其运用PagedAttention技能优化KV Cache办理，并结合并行采样和接连批处理恳求调度办理，支撑NVIDIA和AMD GPU，提高了体系吞吐功用。经过Huggingface Transformers练习的模型能够轻松布置为Python服务，展现出良好的体系灵活性。vLLM经过AWQ和GPTQ等算法支撑INT4-Weight-Only推理，节省显存一起削减推理延时，但或许会细微影响模型精度和生成质量。QAnything运用FastChat (github.com/lm-sys/Fast…)供给的接口运用vLLM后端，供给了兼容OpenAI API的调用接口，默许选用bfloat16推理，对GPU和算力有一定要求。

Huggingface Transformers (github.com/huggingface…)是由Huggingface团队开发的一个通用性强、灵活性高的Transformer模型库，与PyTorch等深度学习结构合作，支撑模型练习和Python服务布置。虽然在大都状况下，其推理功用或许不及FasterTransformer和vLLM，但它兼容不同算力等级的GPU。QAnything经过复用FastChat(github.com/lm-sys/Fast…)供给的接口运用Huggingface Transformers后端，完成了兼容OpenAI API的调用，选用load_in_8bit装备加载模型以节省显存，一起运用bfloat16进行推理。

关于开源

自从「QAnything」项目敞开源代码以来，受到了开发社区的热烈欢迎和广泛认可。到2024年2月29日，项目在GitHub上现已堆集近5000个星标，这反映出了其流行度和用户对其价值的高度评价。

欢迎点击下面的链接下载试用：

QAnything github:github.com/netease-you… QAnything gitee:gitee.com/netease-you… 欢迎咱们在GitHub上为「QAnything」加星助力，便利收到新版别更新的通知！