近日，我们开源了有道自研的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文件中复杂的图文混排，仅仅提取文本往往会带来信息的失真。例如，将具有逻辑连贯性的文本分割成多个片段，或者将图表数据错误地融入文本，这些都会严重影响信息的准确性。正因如此，我们长期致力于文档解析技术的研发，能够精确地识别和分析文档中的每一部分，无论是段落、图表、公式还是其他元素，确保将用户的查询以最适合机器处理的方式进行组织和检索。
借助有道翻译庞大的用户基础，我们得以在实际应用中不断完善和优化我们的系统。日均活跃用户数达百万级别的大数据反馈，为我们提供了宝贵的实践经验，使我们能够持续提升系统性能，满足用户对高质量翻译和问答服务的需求。
从文档问答到速读
有道速读(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，希望什么都可以放进去，什么东西都可以提问。
在去年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%。
中英双语和跨语种能力
多领域覆盖 我们分析现有市面上常见或可能的应用场景，收集了包括：教育、医疗、法律、金融、百科、科研论文、客服(faq)、通用QA等场景的语料，使得模型可以覆盖尽可能多的应用场景。同样的依靠网易有道翻译引擎，获得多领域覆盖的中英双语和跨语种数据集。实现一个模型就可以支持多业务场景，用户可以开箱即用。
我们在训练的过程中，发现一个有意思的现象，数据标签的构建对模型的效果影响非常大。相信大家一定听过“难例挖掘”的概念，在机器学习中模型性能上不去时候，经常是因为一些例子比较难，模型训练时候见的比较少，多挖掘一些难例给模型，就能够提升模型的性能。但是在embedding训练的时候，我们发现难例挖掘反而会降低模型的性能。我们猜测原因是embedding模型本身的能力有限，不应该给过难的任务。我们想要让模型做多领域覆盖，多语种、跨语种覆盖（还要覆盖代码检索和工具检索），这已经给Embedding增加很多负担了，应该想想怎么给Embedding“减负”。
因为Embedding模型是dual-encoder，query和passage在“离线”地语义向量提取时没有信息交互，全靠模型将query和passages“硬”编码到语义空间中，再去语义检索。而rerank的阶段，cross-encoder可以充分交互query和passage信息，潜力大的多。所以我们定了目标，embedding尽可能提高召回，rerank尽可能提高精度。
我们在训练Embedding模型时发现，过难的负样本对模型训练有损害，训练过程中会使模型“困惑”，影响模型最终性能[19]。Embedding模型算法本身性能上限有限，很多难负样本只有细微差异，“相似”程度很高。就像让一个小学生强行去学习微积分，这种数据对Embedding训练是“有毒”的。 在大量的语料库中，没有人工校验的自动化难负样例挖掘，难免会“挖到正例”。语料库很大，里面经常会混有正例，利用已有Embedding模型去挖掘正例，经常会挖到正例，毒害模型训练。应该有不少调参工程师有这种惨痛经历。 其实所谓的“正例”和“难负样例”应该是根据你业务的定义来的。RAG场景下，之前人们认为的难负样例可能就成为了正例。比如要回答“小明喜欢吃苹果吗？”，RAG场景下召回“小明喜欢吃苹果”和“小明不喜欢吃苹果”都是符合目标的，而学术定义的语义相似这两句话又是难负样例。
所以回归我们业务目标和好检索器的“评判标准”，Embedding模型应该能尽量召回相关片段，不要将精排Reranker要干的事强压在Embedding身上，“越俎代庖”终究会害了它。
为了公平起见，我们复刻LlamaIndex博客评测流程，将bce-embedding-base_v1和bce-reranker-base_v1与其他Embedding和Reranker模型进行对比分析。在此，我们先明确一些情况，LlamaIndex博客（https://blog.llamaindex.ai/boosting-rag-picking-the-best-embedding-reranker-models-42d079022e83）的评测只使用了llama v2（https://arxiv.org/abs/2307.09288）这一篇英文论文来进行评测的，所以该评测是在纯英文、限定语种（英文）、限定领域（人工智能）场景下进行的。
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的组合可以实现最好的效果。
为了使我们这个数据集质量尽可能高，我们采用OpenAI的 gpt-4-1106-preview用于数据生成。为了防止数据泄漏，评测用的英文数据我们选择了ArXiv上2023年12月30日最新的各领域英文文章；中文数据选择Semantic Scholar相应领域高质量的尽可能新的中文文章。
多领域、多语种和跨语种RAG评测
我们针对市面上最强的常用开源、闭源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，上面数字可能还不直观。我们在开源的github上放了一张图，意思是QAnything在知识库的数据越多，准确率越高。而一般搭建的RAG，如果没有rerank这一环节，在数据输入多了以后，效果反而下降了。
baseline：第一批数据加入后问答正确率有42.6%，此时有一些问题没回答上来是因为确实缺少相关资料。我们继续加数据… 迎来上涨：第二批加了更多数据，覆盖知识范围更广。准确率提升到了60.2%，提升非常明显，看来加数据确实还是挺有用的。 坏消息：当加入第三批数据的时候，我们最担心的事情还是发生了。正确率急剧下降，跌了将近8个百分点。
不是所的RAG系统都能保证：数据越多，效果越好。随着数据的增多，数据之间可能会有相互干扰，导致检索退化的问题，影响问答的质量。
这个现象在最近的一篇论文：The Power of Noise: Redefining Retrieval for RAG Systems （arXiv:2401.14887v2）也有一些解释，对于RAG系统，如果喂给大模型的输入是相近容易混淆的话，对正确性的影响是最大的。
主要原因是第三批加入的某些文档中恰好有 "大连理工大学xxx怎么样？" 的句子，和query "大连医科大学怎么样？" 表面上看起来确实非常像，Embedding给它打了比较高的分。
而类似大连医科大学师资介绍这样的片段相关性就稍微低了些。LLM输入token有限制，前面两个最相关但是实际并不能回答query问题的片段就已经占满了token的窗口，只能把他俩送进LLM里。结果可想而知，啥都不知道。
如下图所示，从某种程度上，Embedding其实就是在算两个文本块中相似字符的个数占比，它分不清query中的重点是大连医科大学，在它看来每个字符的重要性都是一样的。感兴趣的话可以计算一下下图中红字部分的占比，和最后余弦相似度的得分基本是吻合的。
加上两阶段检索后，重新跑一下实验：
第一个阶段的目标是尽可能多的召回相似的文本片段，这个阶段的文本得分排序不是特别靠谱，所以候选的topK可以设置大一些，比如topK=100； 第二个阶段的目标是对100个粗排的候选文本片段进行重新排序，用cross-encoder计算100个候选文本和query的相关度得分；
两阶段检索结合可以兼顾效果和效率。
LLM模型微调
为什么要微调？
RAG技术结合了知识检索与生成模型，通过从外部知识源检索信息，并将这些信息与用户问题整合成完整的Prompt输入到大模型中，以便根据这些参考信息回答问题。然而，当面对含有专业术语或通俗缩写的开放性问题时，直接使用开源Chat模型可能会导致模型回答不准确。此外，为了最大化利用大模型的上下文窗口，RAG应用倾向于保留尽可能多的检索信息，这可能会使得模型的注意力分散，降低其遵循指令的能力，进而引发回答中的重复内容、关键信息丢失等问题。为了提高大模型在参考信息不足时的诚实度，加入与用户问题关联度低的负样本进行微调训练变得必要。
在选择基座模型时，我们寻找能够支持中英文、至少具备4K上下文窗口的模型，且能在单块GPU上部署，优先考虑7B以下参数规模的模型以便于未来在消费级硬件上部署。Qwen-7B，一个阿里云研发的70亿参数的通用大模型，以其在多个基准测试中的卓越表现成为我们的选择。该模型通过在超过2.4万亿tokens的数据上预训练，包含了丰富的中英文、多语言、编程、数学等领域数据，确保了广泛的覆盖面。考虑到7B参数规模的限制，我们在指令微调时采用了结构化指令模板，以增强模型在实际应用中的指令遵循能力。
QAnything的prompt
如何微调？
尽管与大模型的预训练相比，指令微调成本较低，但在微调数据不完整或比例不平衡的初期探索阶段，采用全参数微调的代价依然较高。为了尽可能降低实验成本并快速验证微调效果，我们首先采用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. 指令微调模型问答效果评估
公开数据集的benchmark的评测结果
参考信息：
"2协同能力发现， . 32 6. 10. 3协同能力应用 32 6. 10. 4协同能力停止 32 6. 11跨BSSID漫游处理， 33 6. 11. 1协同流程 33 6. 11. 2协同能力发现， . 33 6. 11. 3协同能力应用 33 6. 11. 4协同能力停止 . 34 6. 12无效PMKID处理. . 34 6. 12. 1协同流程， . 34 6. 12. 2协同能力发现. . 34 6. 12. 3协同能力应用. 35T\/WAA 0012023 6. 12. 4协同能力停止 35 6. 13终端漫游断链通知. 35 6. 13. 1协同流程. . 35 6. 13. 2协同能力发现. 35 6. 13. 3协同能力应用. 36 6. 13. 4协同能力停止， 36 6. 14接入射频指示 . 36 6. 14. 1协同流程， 36 6. 14. 2协同能力发现. 37 6. 14. 3协同能力应用， 37 6. 14. 4协同能力停止，38T\/WAA0012023 前言 本文件按照GB\/T1. 1-2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起 草。 本文件由世界无线局域网应用发展联盟标准委员会提出并归口。 本文件由世界无线局域网应用发展联盟拥有>版权，未经允许，严禁转载。 本文件起草单位：中国电信集团有限公司、华为技术有限公司、中兴通讯股份有限公司、青岛海尔 科技有限公司、思博伦通信科技（北京）有限公司、烽火通信科技股份有限公司、灿芯技术（深圳）有 限>公司、中国质量认证中心、鹏城实验室、联发科技股份有限公司、瑞晟微电子（苏州）有限公司、新华 三技术有限公司、中国移动杭州研究院、上海海思技术有限公司、腾讯科技（深圳）有限公司、博为科 技有限公司。 本文件主要起>草人：赵伟峰、季晨荷、李炎、吴清根、刘文超、汤宪飞、白小飞、张浩、欧阳宇 展、杨永超、张罐东、孙旭红、鄂磊、张曦、陈金花、杜波、曲雅江、朱兰兰、杨文乐、杨智蛟、林本 谋、杨泉、贾渭东、李国峰、王兆旭、韩晓亮、吴军、王昊、周望松、胡波。 T\/WAA 0012023 网端漫游协同技术规范 1范围 本规范定义了无线局域网网端漫游协同的技术要求， 从协同终端侧与网络侧联合优化的思路出发， 通过定义LAN网络侧设备与终端设备之间的协同控制相关>的补充协议， 针对性解决漫游协同现有间题， 让更多的终端在更多的网络中有着更好的体验， 满足客户不断提高的业务场景需求， 支持WLAN产业的键 康发展。 本规范内定义的无线电要求应符合所在国的国家要求。 开展联盟性能及体验测试认证的设备必须满 足相关国家的监管要求，包括频谱范围、发射功率\/发射功率控制、干扰规避\/动态频率选择等要求。 2规范性引用文件 下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。 其中，注>日期的引用文件， 仅该日期对应的版本适用于本文件：不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文 件。 IEEE Standard for Information Technology Telecommunications and Information Exchange between Systems Local and Metropolitan" "221254 Reserved 255 Measurement not available 图29802. 11RCPI计算标准 25T\/WAA 0012023 注释：P代表终端接收信号强度，单位：dBm Link Margin定义按照802. 11协议标准执行，具体定义见IEEE Std. 802. 11-2020 3. 1章节，统一最小 值标准为-75dBm。 原文引用如下所述： STA might incorporate rate information and channel conditions, including interference, into its computation of link margin. The specific algorithm for computing the link margin is implementation dependent. 6. 6. 4协同能力停止 信号质量计算标准的能力目的是保证网络设备计算终端信号质量的准确性，STA和AP均支持该能力时， 不涉及服务能力停止。 6. 7终端主动漫游>阅值协商 6. 7. 1协同流程 本规范定义了一种流程，通过该流程可以协商终端主动漫游阔值。 如图30所示： STA NF 服务 Sassaest\/ Beass ociation Beguest suodsag sucgecosseg, aucdsny, Association 设鲁能力支排 限务 端主动漫游读值协高请求 应用 hold Negotiation Respo (Action) 终端主动湿游间值0商晚控 图30终端主动漫游阈值协商流程 6. 7. 2协同能力发现 支持终端主动漫游阔值协商的STA应在Probe Request\/Association Request\/Reassociation Request 中携带终端主动漫游阅值协商的能力支持信息。 支持终端主动漫游阅值协商的 AP应在ProbeResponse\/Beacon\/AssociationResponse\/ ReassociationResponse中携带终端主动漫游阔值协商的能力支持信息。 同>时支持终端主动漫游阔值协商的AP与STA可在指定约束条件触发后，按照协商后的漫游阔值触发漫 游。 26T\/WAA 0012023 终端主动漫游觸值协商的支持信息由Capability Set Feature Content承载， 其能力字段（Roaming ThresholdNegotiation）填充如5. 3. 2. 1. 2节与5. 3. 1. 3节所示。 6. 7. 3协同能力应用 支持终端主动漫游阀值协商的AP与STA通过Action帧协商主动漫游阀值， AP首先发起主动漫游阔值协 商， 通过发送Roaming Threshold Negotiation Action Request顿与终端协商主动漫游阔值， STA接受发 送响应报文Roaming Threshold Negotiation Action Response告知AP协商结果。 自主漫游阔值协商Action 帧定义见5. 3. 2. 2. 2。 注：本标准协商的是同频段内的终端自主漫游阅值，跨频段的自主漫游阅值不在本标准规范内协商。 6. 7. 4协同能力停止 AP\/STA发送Roaming Threshold Negotiation Teardown Action帧停比服务，定义见5. 3. 2. 2. 2:AP\/STA 发送802. 11Disassociation顿并成功接收到Ack后停止服务。 6. 8规范终端漫游引导参数 6. 8.""ICS 35. 060. 90 CCS M36 世界无线局域网应用发展联盟标准 T\/WAA-001-2023 无线局域网网端漫游协同技术要求 WirelessLocal Area Network Network-Terminal Roaming Collaboration Technical Specifications 2023-11-30发布 2023-12-01实施 世界无线局域网应用发展联盟（WAA）发布T\/WAA 0012023 目次 前言 V 1范围. 7 2规范性引用文件， . 1 3术语与定义 1 4缩略语. . 2 5总体方案概述 . 2 5. 1总体架构 . 2 5. 2协同流程. . 3 5. 3协同帧格式 . .4 5. 3. 1协同帧字段 5. 3. 2协同帧结构 11 6漫游协同特性 . .16 6. 1高效扫描 16 6. 1. 1协同流程， 16 6. 1. 2协同能力发现 17 6. 1. 3协同能力应用 17 6. 1. 4协同能力停止. 17 6. 2高效跨频段扫描 18 6. 2. 1协同流程 . 18 6. 2. 2协同能力发现 . . 18 6. 2. 3协同能力应用. . . 19 6. 2. 4协同能力停止. 19 6. 3邻居测量增强 . 19 6. 3. 1协同流程 . 19 6. 3. 2协同能力发现. 20 6. 3. 3协同>能力应用. 20 6. 3. 4协同能力停止. . 21 6. 4静默指示， 22 6. 4. 1协同流程 22 6. 4. 2协同能力发现 . 22 6. 4. 3协同能力应用. . 22 6. 4. 4协同能力停止. . 23T\/WAA 0012023 6. 5终端信道切换指示， 23 6. 5. 1协同流程 23 6. 5. 2协同能力发现. 23 6. 5. 3协同能力应用. 24 6. 5. 4协同能力停止. . 24 6. 6信号质量计算标准， . 24 6. 6.", "初次接入流程接入到目标网络中。 6. 12. 4协同能力停止 支持无效PMKID处理的设备将此能力作为基础能力，不涉及停止协同。 6. 13终端漫游断链通知 6. 13. 1协同流程 本规范定义了一种流程，通过该流程，STA在发起漫游前主动通过Deauthentication\/Deassociatio"
--- 我的问题或指令： 网端漫游由哪些单位起草 --- 请根据上述参考信息回答我的问题或回复我的指令。前面的参考信息可能有用，也可能没用，你需要从我给出的参考信息中选出与我的问题最相关的那些，来为你的回答提供依据。回答一定要忠于原文，简洁但不丢信息，不要胡乱编造。我的问题或指令是什么语种，你就用什么语种回复， 你的回复：
## Qwen-7B-Chat 回答: 本规范由世界无线局域网应用发展联盟标准委员会提出并归口。
## Qwen-7B-QAnything 回答: 本规范由世界无线局域网应用发展联盟标准委员会提出并归口，由中国电信集团有限公司、华为技术有限公司、中兴通讯股份有限公司、青岛海尔科技有限公司、思博伦通信科技（北京）有限公司、烽火通信科技股份有限公司、灿芯技术（深圳）有限公司、中国质量认证中心、鹏城实验室、联发科技股份有限公司、瑞晟微电子（苏州）有限公司、新华三技术有限公司、中国移动杭州研究院、上海海思技术有限公司、腾讯科技（深圳）有限公司、博为科技有限公司等单位起草。
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进行推理。
关于开源
自从「QAnything」项目开放源代码以来，受到了开发社区的热烈欢迎和广泛认可。截至2024年2月29日，项目在GitHub上已经积累近5000个星标，这反映出了其流行度和用户对其价值的高度评价。
