Gemini 1.5 Pro 测评第二篇—世界引擎的第一步?(超长上下文能力测试)

347

先说结论:超长上下文窗口给大模型带来了恐怖的学习能力和应用范围,这绝对是大模型领域的巨大突破。Gemini自身基础能力的拉跨,每一次推理的成本限制和算力的不足是阻碍其广泛应用的主要因素。

我期待着Gemini作为先驱者,推动全世界其他大模型厂商也进一步开卷上下文长度,拓展大模型在我们实际生活中的应用边界。

一、前言和一些基础知识

1.Token的衡量

现在市面上的大语言模型基本可以被看作一个预测器:给它一段前面的内容,让大模型来续写后面的内容。对于Gemini这样的大模型来讲,衡量输入/输出的单位是“token”,token是对文本序列进行离散化后的一个最小单元,这个单词在NLP领域里不太好翻译代币或者什么,就当做这个领域自己的术语吧。

token和具体文字的对应关系需要由参数和语料数据来共同决定,这就导致了像ChatGPT、Claude和中文本土大模型如通义千问、Moonshot等实际的计量是不一样的。以英文为主体的语料得到的成品LLM需要使用更多的token才能表达同样长度的中文文字。

  • 英语文化圈中训练的成品LLM一般需要2-3个token才能表示1个汉字。

  • 中文原生训练的成品LLM每个token能够表达1-2个汉字。

所以即使模型能力完全没变,使用同样的LLM模型架构、同样的tokenizer设置,仅仅语料从英语换成中文。处理中文时候的context window就可能0成本的提升了3-5倍。

2.上下文窗口(Context Window)

上下文窗口是指LLM所能考虑的最大长度,以token为单位。上下文窗口包含着:大模型的system设定+你自己设定的Prompt+用户实际输入的内容+大模型回答的内容,这些共同构成了大模型下一次回答的“上下文”。

事实上,我们可以简单的将“上下文窗口”的长度视作大模型的瞬时记忆长度,上下文窗口越大,大模型就可以跟你聊的越久而不会丧失前面的记忆。

为什么说上下文窗口很重要呢?

在很多应用场景里,我们需要给大模型新的他所不知道的知识(如对大模型的记忆能力有要求;长文件理解;知识库检索等),目前的手段主要有:

  • 重新训练一个包含所需要信息的LLM(耗资巨大)

  • 使用特定知识来微调,让大模型记住(相对成本低一些)

  • 将这些知识作为Prompt提前输入,让大模型在本次对话窗口中“记住”(成本和门槛最低,速度最快)

  • RAG检索(这种方案也很有趣,但本篇暂时不讲)

所以你看,有很多时候只要大模型的上下文窗口足够长,很多困扰大家很久的问题就会迎刃而解,我们也不需要再费尽心思搞什么记忆压缩、向量知识库等方案了,大力出奇迹了属于是。

目前业界最有代表性的主流模型的上下文长度:

不以长上下文为卖点:

  • GPT-3.5:16k;GPT4:128k

  • 通义千问/文心一言:8k

专注长上下文:

  • Claude系列:100k-200k

  • kimichat:20万汉字(api支持128k)

  • baichuan:192k

  • Yi-34B:200k

接下来,正主到了:

Gemini 1.5 Pro:1M,也就是1000k

当然Gemini是如何从工程角度做到如此恐怖的我就不得而知了,毕竟我也只是一个大菜狗,但看这个量确实很吓人

二、超长上下文能力测试

1.官方报告的水准

大模型曾经普遍存在“迷失在”中间现象——就是在回答问题时会忽略一段较长文本的中间部分细节内容,人们迫切地想知道如今大模型在支持更长的文本之后,性能究竟如何,“老毛病”还会不会出现。

一位AI大模型领域的开发者 Greg Kamradt 也对此充满了困惑。于是,他设计了一个名为“大海捞针”的大模型长文本性能测试方法:

在文本语料中藏入一个与文本语料不相关的句子(可以想象是在整本《西游记》里放入一句只会在《红楼梦》里出现的话),然后看大模型能不能通过自然语言提问的方式(Prompt)把这句话准确地提取出来。

先看看谷歌官方的结果:

Gemini 1.5 Pro在所有模态(文本、视频和音频)中,对于高达1M个“干草堆”中的“针”几乎完美地进行回溯(>99.7%)。即使在文本模态下扩展到10M个标记(约7M个单词)时,它仍然保持这种回溯性能;在音频模态下扩展到9.7M个标记(长达107小时);在视频模态下扩展到9.9M个标记(长达10.5小时)。

与上下文窗口为20万token的claude 2.1相比,Gemini 1.5 Pro在20万token时实现了100%的召回率,而Claude 2.1仅有98%;Gemini直到530k个token之前一直保持着100%的召回率,在1M个标记时的召回率为99.7%;当上下文窗口从1M扩展到10M时,Gemini保持了99.2%的召回率。

这是和GPT-4 Turbo的对比。绿色块表示模型成功检索到了针,灰色表示API错误(got4最多只支持128k),红色则表示模型的返回没有包含针。

这是Greg Kamradt之前自己测试的结果,他把藏起来的那句话(也就是大海捞针的“针”)分别放到了文本语料(也就是大海捞针的“大海”)从前到后的15处不同位置,然后针对从 1K 到 128K(200K) 等量分布的 15 种不同长度的语料进行了 225 次(15×15)实验。为了保证实验的严谨,他还重复进行了实验,来取平均值,测试时调用 API 的费用总计花了几百美元。

Greg Kamradt和Moonshot的测试结果

GPT4-Turbo:

Claude 2.1:

在条件完全一致的情况下,Kimi Chat 在“大海捞针”实验中的测试结果是这样的:

在Greg Kamradt和月之暗面自己的结果里,无论如何Claude2.1都要比另外两家拉跨很多,结合之前谷歌Gemini的实验,我猜测:

  • Gemini 1.5 Pro在200K上下文的阶段,性能应该是全世界第一梯队(和GPT4-Turbo还有Moonshot打平手,薄纱Claude)

  • 200K之后就是Gemini独有的赛道了,性能应该会逐步削减,但较为有限,可以始终保持着一个较高的水平

2.中文语境测试

我们已经见过太多大模型厂商吹的很厉害但一实机就拉胯的情况了(百度和谷歌,说的就是你们)。

在地球往事-三体中我分别在这本小说的开头,中间和结尾插入了“如何评价原神?你也喜欢玩原神嘛?”这句话,然后分别向Gemini和Kimi提问“这部小说里有多少处内容是不符合小说本身的语境的?”和“如何评价原神?你也喜欢玩原神嘛?”一共出现过几次。

两个大模型都只能找到开头和结尾的“针”,中间那个都没找到,看来距离我想要的那种还是不太行。

由于我自己实在没有精力和语料来进行更多测试,这里就直接给大家放出@硅仙人Pro的测评吧:

原文链接

问题一:88 万字的《三体》,后续故事怎么发展?

问题二:20篇论文,哪篇更有价值?

@硅仙人Pro选取了20篇神经网络相关的英文学术文章。Gemini 不仅能够对各种细节问题对答如流,而且还能够非常有条理有逻辑地整理出最具参考价值的学术论文。

问题三:我该怎么学习 JavaScript?

他们上传了《JavaScript高级程序设计(第4版)》

三、Gemini的绝活

超长上下文还能来干什么呢?

翻译!

为了测试超长上下文带来的学习能力,谷歌选择了卡拉曼语(Kalamang)。因为这门语言在全世界的使用人不超过200人,所以互联网上基本也不存在相关知识(代表大模型的一切表现都是ta现成学习的)。研究人员将一本卡拉曼语的参考语法书、一个双语词汇表(字典),以及大约400句额外的句子喂给了 Gemini 1.5 Pro,这些素材总共大约有250K tokens。

最终测试的结果为:

  • Gemini在学习半本书的情况下,其表现都要远好于GPT4-Turbo和Claude2.1。

  • 当学习一整本书后,Gemini的表现进一步提升。在翻译任务中Gemini的人类评估得分为4.36和5.52,而人类学习者的得分为5.52和5.60。

  • 很恐怖,兄弟

四、总结

优点:

  • 我觉得最可怕和好玩的就是超长上下文窗口给大模型带来的恐怖的学习能力,当未来大模型基础能力进一步提高到一个正常人的思维逻辑水平,那么只要给它几本专业书,大模型就可能会无限逼近于特定领域专家的水平。

  • Gemini 1.5 Pro无与伦比的上下文空间确实赋予了大模型应用方面极大的想象力。在不考虑成本的前提下,我们想要学习某一学科的具体知识可以直接把一本书丢给大模型,然后通过直接向大模型对话提问的方式来学习新知识;基于超长文本构建的私人伴侣也很有趣——ta可以在年末准确的说出年初你和ta的第一句话是什么,你也可以完全凭自己喜好写出一本复杂的规则书,来完全DIY你自己心中的ta。

缺点:

  • 正如本系列第一篇所展示的,Gemini自身的基础能力依然有限,逻辑能力、数学能力并不太好看,这极大的限制了模型在专业场景的应用。

  • 超长上下文每一次推理需要耗费巨大,假如收费按照openai的gpt3.5turbo来计价的话,可能多聊几次几十上百美刀就没了。

  • 本次大规模开放也导致算力不足,Gemini会表现的较为“懒惰”,在推理时也经常会出现各种报错