深入剖析开源大模型+Langchain框架智能问答系统性能下降原因

深圳逍客

作者：barry大模型（LLM）相关理论研究与工程实践随着GPT3的发布，在学术界、工业界大爆发，备受各行各业关注，并涌现出一些赋能行业、促进生产力、生产关系变革的实践。GPT3[1]以及斯坦福计算机学院近100+教授联名论文[2]将大模型列为第三轮AI浪潮，相对于传统的机器学习与深度学习，以GPT3为例的大模型涌现出处理各类任务的新范式：zero-shot、few-shot、in-context等，同时也支持深度学习领域的finetune，新范式让大模型能够低成本、快速处理各种任务，极大的缩短了数据准备与工程开发流程。其中，in-context作为随着大模型涌现的范式，被大规模的应用到各种知识库问答、资料汇总等领域中，开源社区对in-context也非常活跃地响应，推出了langchain[3]、向量数据库[4]等系列优秀框架与技术基座。但是，基于langchain+开源大模型在实践过程中也会遇到系列不尽人意的问题，本文将深入剖析langchain+开源大模型用于搭建基于公司语料库（iwiki、oncall、码客）上的缺陷，剖析利用开源方案进行实践过程中性能下降的根本原因。常规方案架构图1基于langchain+LLM做知识问答的常规方案基于langchain+大模型in-context能力来搭建智能问答系统的常规方案如上图所示，包含3个核心模块：数据服务，在线QA服务，以及大模型。下面分别详细说明一下各个模块具体做些什么？他们是如何串联在一起完成整个问答任务的？再反过来看看为什么业界基于openAI实践很棒，而如果换成基于开源自研后性能下滑很多？数据服务数据对方案的性能影响极其重要，高质量的数据对模型的提升非常显著；但数据处理是一个caseBycase、包含很多经验与tricks的事情，例如文档中的截图、表格、公式、超链接、附件、架构图、流程图、代码片段等等，本文不予以展开分析。做数据最需要关注的是模型的输入及格式。做知识问答系统本质是自然语言处理的一个任务，因此，数据形态必须是文本，这是最基本的原则，所以如果数据包含非文本类的形态，例如（iwiki、码客、oncall存在大量截图），就需要处理一下，每个人的处理方式和策略不一样，处理得好，最终系统性能会表现好一些。数据服务包含3个步骤，格式化（format）、切割（split）、向量化（vectorize）。格式化。解析不同源数据（csv、pdf、json、html、markdown、txt等）到统一格式，并进行预处理与过滤为什么以及如何进行预处理与过滤？参考所选LLM在训练/instructionfinetune处理数据方式（去掉特殊字符、换行空格等）同步处理数据。这么做的原因是LLMin-context应该和训练/instructionfinetune的数据处理方式保持一致，可以保证in-context效果达到最佳。所以格式化的第二步，和选用的LLM相关。切割（split）。将格式化的长字符串按照一定策略切分为若干个切片（chunk）。为什么要进行切割？看到上述框架图绝大多数人应该有的一个疑问。如果深入思考的话会发现embedding（text2vec，文本转化为向量）以及LLMencoder对输入tokens都有限制。embedding会将一个text（长字符串）的语义信息压缩成一个向量，这是他的能力，但我们需要重点关注他的局限性，其中之一就是text包含的tokens有限制，一段话压缩成一个向量是ok，但一本书压缩成一个向量可能就丢失了绝大多数语义。LLMencodertokens的限制在模型结构（利用nexttoken进行pretrain）是就定义了，后续也无法更改，而in-context本质是把语料注入到prompt，整个prompt不能超过LLM的tokens限制，汇总如下公式：为了确保格式化的语料能够满足上述约束，因此需要切割原始语料。如何切割？通常采用固定长度切割（满足上面公式约束下），但固定长度切割容易破坏自然段落的语义，因此需要在上面公式约束与段落语义保留双重约束下，灵活设计方案，切割后的语料片段称为chunk。向量化与存储。为什么进行向量化？NLP领域近10年来最朴素最广泛应用的一个技术embedding就是将text的语义信息转为向量表达，从而基于此向量来处理NLP领域中的一系列任务，例如通过向量相似性来衡量两句话语义是否一致等。向量化的评价指标有哪些？Huggingface有一个embedding的benchmark，如链接：https://huggingface.co/spaces/mteb/leaderboard。图2huggingfaceembedding综合能力排序业界通常用embedding所得向量长度及其在各NLP子任务上的准确率来评估embedding模型。原则上：embedding所得向量长度越长越好，过长的向量也会造成embedding模型在训练中越难收敛。分类（Classification）、聚合(Clustering)、语义相似(PairClassification)、排序（Reranking）和召回（Retrieval）等子任务常用来评估embedding模型的优劣，准确率越高，embedding的性能越好。向量如何存储与检索？向量的存储与检索是一门特别复杂的课题，涉及向量检索（包含很多相似性度量算法，向量压缩等知识）和向量存储，当前火热的向量数据库方向就是因此而生，在规模不大的情况下用faiss做检索够用了，未来有机会将专题就这个点开展分析，这里不予以赘述。在线QA服务在线QA服务是串联大模型与存储向量数据库之间的纽带，大模型不能将数据库所有数据拿去做in-context，实际上，大模型in-context能包含的chunks十分有限，在线QA服务核心就是挑选出合适的chunks给大模型。在线QA服务通过企微、webapi等方式对外提供交互，包含3个核心功能模块：用户问题向量化、prompt组装、筛选chunks。其中，在线QA服务核心在于筛选chunks，这一步对整体性能至关重要。用户问题向量化。同数据服务chunks向量化一样，采用同一个embedding模型对用户问题进行向量化。prompt组装。将用户问题，筛选出的chunks组装成prompt，prompt即为大模型的输入，整个prompt不超过大模型输入tokens长度的限制，以openAIgpt-3.5-turbo为例，输入tokens限制为4096，假设每个chunks固定长度为400，不考虑prompt不变字符串的长度，gpt-3.5-turbo最多可以放10个chunks进行in-context学习。筛选chunks。在用户问题与chunks经同一embedding模型将text转为向量：(M是chunks的总数量)，langchain给的方案是通过计算之间：的相似度（cos、BM25、knn、欧氏距离等）并倒排来决定哪些chunks被召回。本质上前者是Question，而后者是Answer，因此langchain是利用了embedding在召回（Retrieval）任务上的能力来筛选chunks，如图2红色垂直列所示，这符合问答系统的初衷。非常值得注意的是：embedding在召回任务上的准确率是其在所有NLP任务重最差的一个，QA任务在语义空间上的表达远不如分类、聚合等任务。常规方案中，langchain直接召回排序top8chunks给大模型进行in-context推理(gpt-3.5-turbo4096tokens)。大模型问答系统使用了LLMin-context的推理能力，将筛选出来的若干个chunks传给大模型，让大模型基于这些chunks来回答用户问题，有个限制是整个prompt的tokens长度不要超过LLM输入tokens限制，不然GPU会报OOM。LLMin-context的推理能力本质是其在阅读理解，因此，选择问答系统的LLM需要重点关注其在阅读理解任务上的性能，好的LLM可以非常精准的从一组chunks中寻找并总结出用户query对应的答案。串联将上述各功能模块的逻辑串联一起，从整体的视角观察一下langchain+大模型做问答系统整个方案的实践。LLM需要上游提供一些语料chunks，结合chunks、用户query、自身阅读理解能力完成知识问答。对问答准确率影响最大的因素是chunks的质量（是否包含正确答案），LLM自身阅读理解能力。同时，LLM输入token长度限制导致prompt中chunks的数量有一定约束，原则上，chunks数量越多，包含正确答案的概率越大，同时也导致模型的推理速度变慢。LLM上游主要目的是召回出候选的chunks，常规方案使用的是embedding处理召回任务的能力，对于一步召回直接注入到prompt（无精排逻辑），假如传给LLMpromptk个chunks，那么对于召回来说，只需要相似性算法倒序排序前k个chunk中包含正确答案即可，即关注embedding在召回任务中TopK的准确率。综上所属，常规方案中对智能问答系统准确率影响最大的几个因素如下：1、embedding在Retrieval任务中TopK的准确率（受embedding模型自身能力、Retrieval算法、K等三个因素影响）2、K的大小，K原则越大越好，但是LLM的tokens限制导致K由不能太大。（上述1、2的都是为了从数据库海量chunks中选择出包含正确答案的chunks）3、LLM自身阅读理解与总结推理能力。openAI与开源LLM为什么langchain+openAI全家桶准确率特别高，换成开源LLM性能下降很多？使用openAI全家桶构建智能问答系统必用两个能力：openAI的embedding与gpt-3.5-turbo模型。图2huggingfaceembeddingbenchmark中openAI发布的text-embedding-ada-002（2021/09）最大输入tokens限制是8191，输出维度是1536，在Retrieval中top1的准确率是49.25%。这组数据表明openAIembedding模型具有非常棒的语义表达能力，能够非常好的将问题、答案映射到相近的语义向量空间中，可以说该embedding模型是业界最强的映射QA能力的模型。openAI的商用模型gpt-3.5-turbo输入tokens限制为4096，如果切片每个chunks长度为400，embedding可以召回近10个候选chunks，即text-embedding-ada-002模型top10的准确率即可近似为问答系统的整体准确率（做信息流推荐召回排序的同学应该了解，top1准确率接近50%，top10的准确率会很惊人），而gpt-3.5-turbo自身的阅读理解也高出开源LLM一个水平，能够精准的从所有的chunks中找到准确答案。综上penAI全家桶中embedding在Retrieval任务的高性能、gpt-3.5-turbo的阅读理解能力，输入tokens够长等三个重要因素，是常规基于langchain+openAI做智能问答系统，用用户问题向量与语料内容向量进行相似性计算并直接召回给prompt，最终能够取得非常好效果的重要原因。openAIembedding与gpt-3.5-turbo强劲性能掩盖了一些问题，这些问题在基于开源LLM做自研问答系统时被暴露，直接导致开源LLM方案性能下降。openAI全家桶与开源LLM方案的对比如下：在Retrieval任务的语义关联映射上，openAI的embedding模型能力远高于开源LLM（15个百分点以上）；LLMtoken的限制，导致采用openAI召回的chunks数量比开源LLM多一倍；同时在阅读理解能力上，gpt-3.5-turbo能够非常好的从一系列chunks中找到并总结出最佳答案，而开源LLM在这方面能力稍微逊色一些。综上，选择目前开源最好的组合方案：llama的vicuna13B与中文领域开源最好的embedding模型GanymedeNil/text2vec-large-chinese·HuggingFace，采用常规的langchain+openAI技术框架，性能会下降很多。总结通过全文分析，总结出开源LLM大模型在openAI+langchain通用的技术方案下，性能不佳的原因主要如下：使用Question-Answer（embeddingRetrieval）作为召回排序是性能不佳最根本的原因，开源的中文embedding模型在Retrieval任务上表现不佳。模型输入tokens限制导致候选的chunks数量少于openAI模型近一倍，是整体准确率低于openAI全家桶的一个重要原因。模型自身在阅读理解与总结任务上的不足，也对整体性能有一定的影响。洞悉问题是进步的第一步，本文重点从embedding与LLM两个角度来剖析langchain+开源大模型搭建智能问答系统性能下降的原因，下篇也将从这两个角度逐步分析如何基于lanchain+开源大模型搭建高性能智能问答系统。引文[1]BrownT,MannB,RyderN,etal.Languagemodelsarefew-shotlearners[J].Advancesinneuralinformationprocessingsystems,2020,33:1877-1901.[2]BommasaniR,HudsonDA,AdeliE,etal.Ontheopportunitiesandrisksoffoundationmodels[J].arXivpreprintarXiv:2108.07258,2021.[3]GitHub-hwchase17/langchain:⚡BuildingapplicationswithLLMsthroughcomposability⚡[4]GitHub-milvus-io/milvus:Acloud-nativevectordatabase,storagefornextgenerationAIapplications点击下方卡片进入公众号回复：2023红包封面可以抽奖最新红包封面