上下文长度真的能形成护城河吗?
Kimi火了……
这是这波AI浪潮中,国内创业公司第一次真正“破圈”。最明显的标志是,在二级市场中,Kimi已被市场作为一个概念板块来对待,它们被称之为“Kimi概念股”。在之前爆炒的板块中,可能有华为产业链、苹果产业链,但是,因为一家创业公司而发酵一波行情还是第一次。
除了资本市场的关注,实际的用户量飙升,也能看出kimi的火爆程度。在“AI产品榜(aicpb.com)”统计的数据显示,Kimi智能助手在2024年2月的访问量达305万,较上个月增长107.6%,几乎成倍增长。
据第三方机构的最新统计数据显示,目前国内已经发布的大型语言模型数量已经超过了300个。这些大型模型的发布主体涵盖了科技巨头、国内顶尖的高等学府、以及各类科研机构,他们在资金投入、资源配置、人才聚集等方面都拥有绝对的优势。然而,在这样一个竞争激烈的环境中,为什么月之暗面这样一个成立仅仅一年的创业公司会引起最大的关注?
“起爆点”始于3月18日,月之暗面宣布在大模型长上下文窗口技术上取得新的突破,其自研的Kimi智能助手已支持200万字超长无损上下文,并于今日开启产品内测。
kimi上线的时间是2023年10月,当时可以支持无损上下文长度最多为20万汉字。在5个月的时间内,月之暗面直接将长文本能力提高10倍。按照AI领域的计算标准,200万汉字的长度大约为400万token。这种能力在全球知名大模型中的水平如何?下图可以比较明显看出,长文本能力最强的谷歌gemini 1.5、Claude3支持100万token,kimi 200万汉字上下文长度或已超越海外顶尖大模型水平。
但是,大模型仅仅某项能力的领先,似乎并不足以吸引所有的注意力,毕竟几乎所有大模型在发布的时候,都会交出一个优秀的基准测试成绩单,几乎所有大模型,都是“一位超越上一个被发布的模型”的优等生。
所以,在这样“卷”的大模型市场,kimi究竟为什么会火?其实它的火爆,也从侧面反应了大模型市场的痛点,过去一年,市场见到了太多大模型的发布,每次标准动作有以下几个:1、公布模型参数量;2、公布模型是开源还是闭源;3、公布测试集的成绩(这些测试集被用于评估大模型在不同领域的能力,包括语言理解、知识问答、文本创作等。通过这些测试集,研究人员和开发者可以比较不同模型的性能,并识别模型的优势和不足,具体测试集的测试功能,如下图所示)。4、行业内人士或极客们的评测文章。
图注:一些常用的评测数据集
一番标准动作之后,对于非行业用户,面对一些晦涩难懂的参数及技术词语,很难记住任何一个大模型有任何突出的特点。再加上国内大模型对C端开放的不多,且即使开放,对C端开放的也为比较基础的版本。用户对国产大模型的印象,基本停留在类似于ChatGPT的聊天机器人。可以尝鲜,但是并不知道大模型对我“实际能有什么用”。
于是大模型的宣发也进入了大众看来的行业内的自High——“看不懂有多牛,体验不到有什么用。”
kimi选择了一个更有辨识度的方式亮相。2023年10月10日,月之暗面的官方公众号发布kimi的上线官宣文章,标题中别有心裁地用了“欢迎与Moonshot AI共同开启Looooooooooong LLM时代”,"long"这个单词中间,特地敲入了十个“o",long一下子变得视觉可见的长。而公众号的第一句就是“今天,Moonshot AI 带着首个支持输入 20 万汉字的智能助手产品Kimi Chat 与大家见面了”。
所有的宣发内容,用户一眼就能记住一个词“长文本”。月之暗面是懂营销的,直接占领用户心智。从此,用户看到“长文本”,只能想到“月之暗面”。
月之暗面的目标是C端,为了让C端用户能够理解“长文本”这个技术名词,杨植麟用了更形象的比喻“支持更长的上下文”意味着大模型拥有更大的“内存”。这个世界已经被计算机、手机教育过了,每个普通人都有一个“简单粗暴”的认知,“内存大”就意味着这个手机或电脑配置更高、性能更牛、价格也更贵。
一波漂亮的宣传,在“卷评测分数”的大模型界轻松地赢得了普通用户的心。
在后续的重要宣发中,月之暗面不断重复kimi的长文本能力,创始人杨植麟也在采访中强调“为什么长文本是登月第一步?它很本质。它是新的计算机内存。”
早在20世纪60年代,艾·里斯与杰克·特劳特就提出了经典的《定位》理论,它的核心概念在于将品牌建设的焦点从产品本身转移到潜在客户的心理认知上。在定位理论中,占领用户心智意味着在目标消费者心中为品牌或产品创造一个独特、明确且吸引人的位置。这样,当消费者考虑购买某一类产品或服务时,你的品牌能够成为他们首先想到的选择。
当用户认为在国内的大模型中,长文本=kimi的时候,除非竞争对手能以绝对的实力碾压几个量级,但凡与kimi打平或者是微弱超越,都很难威胁到kimi在用户心目中的地位。即使是如百度、阿里等科技大厂也宣布开放长文本能力,似乎也丝毫没有影响到kimi的热度。
而且,kimi只有一个,在资本市场上,可以享受泡沫,但是当退潮的时候,还是要保持一分清醒。
图注:图片来源于网络,不代表本文观点
从营销策略拉回技术本质,kimi选择坚决攻克的大模型长文本能力,究竟有多重要?月之暗面创始人杨植麟把它解读为“新计算范式”,通用的世界模型,是需要long context的(长文本)的。
如何理解这句话?如果你把大模型当成一个和你对话的人,可以想象他和我们一样有短期记忆和长期记忆。长期记忆就是那些在大模型里的通过训练得到的向量和参数,你可以理解为这是它自身的知识库。而上下文就是短期记忆,当你想和他交流的时候,这些不在长期记忆中的新内容,乃至你们对话的全部过程必须以上下文为窗口提供给大模型,超过其上下文承载能力的部分,大模型就会忘掉。
GPT3.5-Turbo初版上下文窗口长度仅有4k token,也就是大概2000字,你和它对答超过两千字的内容它就基本记不住了,更别提让他记住复杂的文件了。在这种上下文环境中,可以说很难让LLM完成真正复杂,多步的操作,也无法处理文档等长格式。
为了让大模型能够做更多事,拓展上下文就成了各路大模型争相竞争的一个重要目标。作为OpenAI被公认的最强大对手,Antropic的大模型Claude的杀手锏就是长文本,其初代模型就支持100k token的上下文,直接可以处理5万字,使得不那么长的阅读分析任务足以在上下文限制中完成。这也使它一直在整体性能劣于OpenAI的情况下,总是能保有一群核心粉丝。
同时,长文本也能促进大模型基础能力的提升,前四个能力是大模型功能优化和拓展方面的,通过长文本去实现过去难以支持的功能,或增强过去支持很差的功能:
① 更好地理解文档。通过扩展LLM的上下文窗口,模型可以更好地捕捉文档中的长距离依赖和全局信息,从而提高摘要、问答等任务的性能。这是我们作为一般用户最经常要用的功能。
② 增强指代消解。更长的上下文窗口可以帮助模型更好地确定代词所指代的实体,从而提高指代消解的准确性。也就是说模型不会忘掉或搞混你们前面提到的“那个男人”,“那份文档”。
③ 改进机器翻译。扩展上下文有助于更好地保留原文的语义,尤其是在专业术语、歧义词等方面,提高翻译质量。
④ 增强few-shot学习能力。通过在扩展上下文中提供更多示例,LLM可以更好地进行few-shot学习,提高在新任务上的泛化能力。如今随着模型命令跟随的能力逐步增强,很多时候直接通过Prompt指令就可以让模型学到新的能力,比如做个英语教师,当个医生之类的。但这些功能描述会非常复杂,还需要举出例子帮助模型学习,长文本支持越好,在Prompt指令中能添加的例子就越多,模型就会学的越好。
另两项则是对模型基础功能的提升,因为现在的上下文增加模式除了RAG(检索增强生成)等引入外部存储的模式外,内生上下文提升都需要更改Transformer模型本身。因此在这个过程中模型的能力也会得到相应的提升,简单来说就是传统Transformer模型根本理解不了文本间隔比较远的内容间的联系,现在它能了,理解能力也就自然提升了。
① 提升大模型的语言理解和生成能力。更长的上下文有助于LLM更好地理解多轮对话、复杂文本中的语义,并生成更连贯、相关的响应。这对于对话系统、文本生成等应用很重要。
② 提高长文本推理和QA能力。扩展上下文使LLM能更好地处理涉及多文档、长文本的推理和QA任务。
在去年GPT4-Turbo还没有推出上下文长度128k版本的时候,OpenAI的开发者关系经理Logan Kilpatrick就曾经表示过,“上下文就是大语言模型的下一个关键突破”。从大语言模型的功能满足上看,也确实如此。
目前使用大语言模型的大多数人群,还是泛科技行业,有尝鲜能力的从业者、爱好者以及相关专业的学生,长文本处理能力毫无疑问是论文、深度研报、会议摘要这些有明确应用场景的刚需能力。月之暗面的登月第一步,从用户需求角度讲肯定是迈对了。
但这一步,从技术角度来讲,真的能领先多少?
如文章开头所述,在占领心智方面,Kimi已经形成了暂时的用户护城河,这其中“长文本”是一个重要的因素,但不是全部因素。
它能否像去年的Claude 一样,凭借着上下文长度形成一条稳定的护城河?在去年,这个答案也许是肯定的,但进入2024年,这项技术本身已经很难说的上是护城河了。当下,已经有越来越多成熟的手段去处理上下文的问题。
上下文扩展的问题之所以这么难解决,主要原因还是Transformer这个基础框架本身。
它最核心的问题有三个:
1)对文本长度记忆非常死板,超过训练集最大长度就无法处理:Transformer为输入序列的每个token的位置都映射了一个固定长度的向量。这是一个绝对的位置信息,导致模型对文本长度的记忆非常死板。一旦你给了模型超出训练集最大长度的信息时,这些超出的位置他就定位不了,也就读取和理解不了。很可惜的是,根据Sevice Now的研究员Harm de Vries的技术博客分析,现在模型训练用的主要素材之一公开可用的互联网抓取数据集CommonCrawl中,95%以上的语料数据文件的token数少于2k,并且实际上其中绝大多数的区间在1k以下。也就是说,它在训练这个过程中就是很难拓展到2k以上的文本长度。
2)注意力机制占据资源,耗费算力:因为自注意力机制需要计算每个token与其他所有token之间的相对注意力权重,所以token越长,计算量就越大,耗时越长。而且算出来的结果,还要储存成注意力得分矩阵,大量矩阵会占据巨大的存储空间,快速存储能力不足也不行。而且大部分 token之间其实就没啥关系,非要这么来回算一遍纯粹浪费资源。
3)不擅长处理远端信息:深度学习的基本逻辑之一是梯度下降,它通过不断地调整模型参数来最小化与结果差异的损失函数,从而使模型的预测能力得到提高。另一个逻辑就是反向传播,将梯度传播到更高的神经网络层级中,从而使模型能识别更复杂的模式和特征。当序列较长时,梯度在反向传播过程中可能变得非常小(梯度消失)或非常大(梯度爆炸),这导致模型无法学习到长距离的依赖关系。而且注意力机制本身就倾向于近距离词汇,远距离依赖关系对它来说优先级不高。
这三大难题其实已经有非常多的手段去规避。学界把增加上下文的方法主要归类为外推(Extrapolation)和内插(Interpolation)。一般都会并行使用。
外推负责解决训练外资料无法编码的问题,并保证长文本处理的能力。用通俗的语言来解释我们有一个巨大的语言模型,就像一个超级大脑,它通过阅读大量的书籍和文章来学习理解人类的语言和知识。但是,如果给它一段新的长文本,它可能会遇到一些之前没有接触过的内容,这时候它就需要一种特殊的能力来理解这些新信息。这种能力就是所谓的“外推”。
为了让这个语言模型能够处理超长的文章,我们需要给它一种特殊的编码方式,就像给这个超级大脑安装了一副可以看得更远的眼镜。这副眼镜就是“位置编码”,比如ALiBi和RoPE这样的编码方式,它们帮助语言模型理解更长的文本。
但是,长文本不仅长,还很复杂,需要语言模型快速而且准确地理解。为了解决这个问题,我们发明了一种叫做“稀疏注意力”的技术,它就像是给这个超级大脑装了一个高效的信息处理系统,让它可以快速聚焦在重要的信息上,而不是被无关的细节分散注意力。
还有一个问题,就是语言模型的“记忆”问题。就像电脑如果开太多程序会卡顿一样,语言模型处理太多信息也会遇到问题。这时候,我们有了像Transformer-XL这样的技术,它就像是给语言模型加了一个超级大的内存,让它可以记住更多的东西。而环注意力(Ring Attention)这个新技术,就像是给语言模型的大脑做了一个升级,让它在处理信息的时候更加高效,不会忘记重要的事情。
除了处理长文本,我们还需要让语言模型能够更好地理解它已经学过的内容,这就是“内插”。我们通过调整它的注意力机制,让它可以更轻松地找到信息之间的联系,就像是给这个超级大脑装了一个更聪明的搜索系统。
通过这些技术的提升,我们的语言模型变得越来越强大,虽然还不是完美无缺,但已经能够处理很多复杂的问题了。最近,微软的研究人员还发明了一种新的方法,叫做LongRoPE,它就像是给这个超级大脑的超能力做了一个升级,让它可以处理更多的信息,而且不需要重新训练或者更多的硬件支持。
本身这个方法略微复杂,会使用到1000步微调,但效果绝对值得这么大费周章。直接连重新训练和额外的硬件支持都不需要就可以把上下文窗口拓展到200万水平。
从学术的角度看,上下文似乎已经有了较为明确的突破路径。而业界头部公司模型的进化也说明了这一点。
早在Kimi引发国内大模型“长文本马拉松竞赛”的4个月前,美国大模型界就已经赛过一轮了。参赛的两名选手是OpenAI的GPT4-Turbo和Antrophric的Claude。在去年11月,OpenAI在Dev Day上发布了GPT4-Turbo, 最高支持128k上下文长度的输入,这一下打到了Claude的命门。在能力全面落后GPT4的基础上,唯一的优势也被超越,Antrophric顿时陷入了危机。在14天后,Antrophric紧急发布Claude 2.1,在其他能力没有显著增强的情况下,仅把上下文支持从100k提升到了200k来应对挑战。而在今年2月发布的Geminni 1.5更是直接把上下文窗口推到了100万的水位,这基本上是哈利波特全集的长度和1小时视频的量级。
这说明全球第一梯队的三个大模型,在去年都突破了长文本的限制。
这其中还有一个小插曲,Claude 2.1发布后,完全没想到行业人士这么快就对它进行了探针测试,可以用简单的概念来理解,就是大海捞针。
探针测试的逻辑是向长文章的不同位置中注入一些和文章完全不相关的话语,看它能不能找出来。能就说明它真的懂了,不能就说明它只是支持了这样的长度,但并没有记住。Claude 2.1探针综合召回率只有20%,可以说基本没记住,而对比GPT4 Turbo放出的论文中,128k长文本的召回率足有97%。
在这场公关战中落于下风的Claude紧急打了补丁,在12月6日放出更新,探针召回率大幅提升,而且按Antrophic官方的说法,他们只是加了个Prompt就解决了这个问题。
(官方文档:通过在克劳德的回答开头添加“这是上下文中最相关的句子:”这句话,我们在相同的评估中取得了明显更好的结果。)
(探针实验效果效果前后对比)
一个Prompt就能解决上下文拓展中出现的严重问题。如果不是Claude 本身在故意隐藏底牌,只能说到了12月份,这个护城河已经略浅了。
而到了3月份,中文大模型的这场最新版本的长文本战争时,其他厂商的快速跟上,更为“护城河略浅”加了些注脚。
但是,全球三大模型的长文本之战最终“高开低走”。
GPT4-Turbo 128k直到今天仍然仅对API用户(主要是专业开发者及公司)开放,一般用户只能用32 k的GPT4版本。
在今年3月发布的号称超越GPT4的Claude 3依然只支持到200K的上下文限制。
突然他们都不卷了。这是为什么?
首先是因为不划算
在上文提及注意力机制的时候,我们讲到因为其内生的运作逻辑,上下文越长需要计算的量级越大。上下文增加32倍时,计算量实际会增长大约1000倍。虽然靠着稀疏注意力等减负措施,时机运算量并没有那么巨大,但对模型来讲依然是非常大的负担。这从大模型的反应时间可以一窥:根据目前的测试反馈,Gemini在回答36万个上下文时需要约30秒,并且查询时间随着token数量呈非线性上升。而当在Claude 3 Opus中使用较长文本的上下文时,反应时间也会加长。其间Claude还会弹出提示,表示在长上下文的情况下,应答时间会显著变长,希望你耐心等待。
较大的计算量就意味着大量的算力和相应的成本。
GPT-4 128k版本之所以开放给API用户,是因为他们按输入token数量结算,自己承担这部分算力成本。对于20美元一个月的一般用户而言,这个并不划算。Claude 3 会员版本最近也开始限制同一时间段内的输入次数,预计也是在成本上有所承压。
虽然未来算力和模型速度都会变得越来越快,成本和用户体感都会进一步上升。但现在,如果长上下文的需求能够在当下支持框架下获得满足,大模型提供商何必“再卷一步”呢?
其次,长上下文的扩充在一定限度以后对模型整体能力的提升有限
前文提到,上下文对模型能力会有一定提升,尤其是处理长内容的连贯能力和推理能力上有所提升。在早期谷歌进行的较弱模型实验中,我们确实可以看到这样的明显正向关系。
但我们现在评价模型的角度实际上更综合,核心还是希望它能有更好的常识能力和推理能力。GPT4一直都不是支持上下文长度最长的模型,但其综合能力一直一骑绝尘了半年多时间。当上下文够用后,把时间花在优化模型的其他方面似乎更为合理。
在Langchain最近的研究中,他们设置了多个探针后发现,即使是支持长上下文的模型,在探针越多的情况下,其正确召回率仍然会衰退,而且对探针的推理能力衰退的更明显。所以,当前的方法下大模型可能能记住很长上下文,但懂多少,能用多少还是存疑的。
最后,有更便宜的,更有拓展性的解决方法,为什么死磕这条路?
在杨植麟过往的采访中,他曾经指出一种拓展上下文的模式是蜜蜂模式,属于一种走捷径的模式,不能真正的影响到模型的能力。这种模式就是RAG,也就是检索增强生成(RAG)。其基本逻辑就是在模型外部设置一个存储器,通过切片方法将我们输入给模型的长文本切成模型有能力识别的短文本小块,在取用时通过索引让大模型找到具体的分块。它和蜂巢一样一块块的所以被称作蜜蜂模式。
通过RAG,大模型可以考仅处理索引涉及到的小段落就可以,所以反馈速度很快,也更便宜。但它的问题正如杨植麟所说,因为是分块的,只能窥一斑难见长文本的一豹。
GPT4用的就是这样的模式,所以在32k的长度下也可以接受更大的文本进行阅读,但问题确实很多,它会经常返回说明明在文章里有的东西它找不到。
但这个问题最近也被攻破了。今年2月发布BGE Landmark embedding的论文也阐述了一种利用长上下文解决信息不完整检索的方法。通过引入无分块的检索方法,Landmark embedding能够更好地保证上下文的连贯性,并通过在训练时引入位置感知函数来有限感知连续信息段中最后一个句子,保证嵌入依然具备与Sentence Embedding相近的细节。这种方法大幅提升了长上下文RAG的精度。
另外,就像当下的数据库一样,因为我们日常生活工作中真正用到的上下文不仅包含了长文本、图片等非结构化数据,更包含了复杂的结构化数据,比如时间序列数据、图数据、代码的变更历史等等,处理这些数据依然需要足够高效的数据结构和检索算法。
100万token这个上下文长度,在文本,代码为主的场景下,已经足够满足99%我们当下的上下文用例了。再卷,对用户而言毫无价值。
当然,因为看一个五分钟的视频可能就需要10万以上的token,在多模态模型实装时代中,各个模型供应商还是有再往上卷的理由。但在当下的算力成本之下,它的大规模应用应该还很难。
最后,引出一个终极问题,靠”长文本“是否能形成大模型真正的护城河?”护城河“本质还是看未来,而未来是最难判断的。关于长文本本身有多大可扩展空间,杨植麟的回答是:“非常大。一方面是本身窗口的提升,有很长路要走,会有几个数量级。另一方面是,你不能只提升窗口,不能只看数字,今天是几百万还是多少亿的窗口没有意义。你要看它在这个窗口下能实现的推理能力、the faithfulness的能力(对原始信息的忠实度)、the instruction following的能力(遵循指令的能力)——不应该只追求单一指标,而是结合指标和能力。”
如果这两个维度持续提升,人类下达一个几万字、几十万字的复杂指令,大模型都能很好地、准确地执行,这确实是巨大的想象空间。到了那个时候,可能没有人会纠结,这家公司的核心竞争力究竟是长文本,还是别的什么。
这波AI浪潮才刚刚开始,未来的产品形态肯定是与今天完全不同的,我们还没有办法清晰地看到它未来的样子。但是似乎有一点是行业内的共识,属于AI时代的产品,一定是“去掉AI就不成立”的产品。杨植麟也有相似的判断“独特价值是你增量的智能。要抓住这个点,智能永远是最核心的增量价值。如果你这个产品最核心价值只有10%-20%来自于AI,就不成立”。
未来,你需要人工智能,它一定能理解你的长长的指令,但是它可能会忘记,在一路走来的过程中,还曾经路过叫做“长文本”的驿站。
文章来自微信公众号“腾讯科技”,作者:郝博阳 郭晓静
【开源免费】DeepBI是一款AI原生的数据分析平台。DeepBI充分利用大语言模型的能力来探索、查询、可视化和共享来自任何数据源的数据。用户可以使用DeepBI洞察数据并做出数据驱动的决策。
项目地址:https://github.com/DeepInsight-AI/DeepBI?tab=readme-ov-file
本地安装:https://www.deepbi.com/
【开源免费】airda(Air Data Agent)是面向数据分析的AI智能体,能够理解数据开发和数据分析需求、根据用户需要让数据可视化。
项目地址:https://github.com/hitsz-ids/airda
【开源免费】FASTGPT是基于LLM的知识库开源项目,提供开箱即用的数据处理、模型调用等能力。整体功能和“Dify”“RAGFlow”项目类似。很多接入微信,飞书的AI项目都基于该项目二次开发。
项目地址:https://github.com/labring/FastGPT
【开源免费】graphrag是微软推出的RAG项目,与传统的通过 RAG 方法使用向量相似性作为搜索技术不同,GraphRAG是使用知识图谱在推理复杂信息时大幅提高问答性能。
项目地址:https://github.com/microsoft/graphrag
【开源免费】Dify是最早一批实现RAG,Agent,模型管理等一站式AI开发的工具平台,并且项目方一直持续维护。其中在任务编排方面相对领先对手,可以帮助研发实现像字节扣子那样的功能。
项目地址:https://github.com/langgenius/dify
【开源免费】RAGFlow是和Dify类似的开源项目,该项目在大文件解析方面做的更出色,拓展编排方面相对弱一些。
项目地址:https://github.com/infiniflow/ragflow/tree/main
【开源免费】phidata是一个可以实现将数据转化成向量存储,并通过AI实现RAG功能的项目
项目地址:https://github.com/phidatahq/phidata
【开源免费】TaskingAI 是一个提供RAG,Agent,大模型管理等AI项目开发的工具平台,比LangChain更强大的中间件AI平台工具。
项目地址:https://github.com/TaskingAI/TaskingAI
【开源免费】XTuner 是一个高效、灵活、全能的轻量化大模型微调工具库。它帮助开发者提供一个简单易用的平台,可以对大语言模型(LLM)和多模态图文模型(VLM)进行预训练和轻量级微调。XTuner 支持多种微调算法,如 QLoRA、LoRA 和全量参数微调。
项目地址:https://github.com/InternLM/xtuner
【开源免费】LangGPT 是一个通过结构化和模板化的方法,编写高质量的AI提示词的开源项目。它可以让任何非专业的用户轻松创建高水平的提示词,进而高质量的帮助用户通过AI解决问题。
项目地址:https://github.com/langgptai/LangGPT/blob/main/README_zh.md
在线使用:https://kimi.moonshot.cn/kimiplus/conpg00t7lagbbsfqkq0