Google Gemini：大上下文窗口是杀手级功能吗？

RA AI衍生者训练营

已于 2024-06-28 16:11:16 修改

阅读量574

点赞数 13

文章标签： ai 人工智能

于 2024-06-28 15:57:08 首次发布

本文链接：https://blog.csdn.net/RamendeusStudio/article/details/140045713

版权

在八个月前，一封泄露的谷歌电子邮件透露，谷歌正努力超越其人工智能竞争对手。谷歌不仅没有围绕其人工智能产品的护城河——换句话说，没有建立起商业优势——也没有可以改变现状的秘诀。就在他们努力解决这个问题的同时，他们也看到像他们这样的私人资助的人工智能项目与开源人工智能模型之间的差距正在以“惊人”的速度缩小。

现在还不知道这个故事的结局。也许开源人工智能将继续在其早期成功的基础上继续发展，或者它可能会被谷歌、微软和苹果等财大气粗的竞争对手及其令人难以置信的海量数据所扼杀。目前，随着不同组织推出一系列快速的人工智能进步，冲突仍在继续。最近，谷歌在这个领域成为焦点，它宣布了其最新LLMGemini 1.5 Pro的预览版。另一天，另一个大型语言模型——或者看起来如此，直到谷歌描述了一个惊人的变化。

Gemini 1.5 Pro 大大扩展了上下文窗口——本质上，这是衡量 LLM 可以同时跟踪多少数据的指标。在过去的版本中，Gemini 的上下文窗口最多可容纳 128,000 个 token，就像 GPT-4 一样。但 Gemini 的新上下文窗口可容纳100 万个token，这一变化的影响是巨大的。

但在我们讨论上下文窗口对 LLM 功能的影响之前，我们需要回顾一下上下文窗口的工作原理。

上下文窗口（简而言之）

简单来说，上下文窗口决定了 LLM 在交互过程中可以记住多少信息。例如，如果您使用 ChatGPT，上下文窗口包括您给它的当前提示、您之前在该对话中输入的所有其他内容以及 ChatGPT 发回给您的每个回复。交谈时间长了，对话的旧部分就会从上下文窗口中消失，ChatGPT 会突然忘记这些细节。

128,000 个 token 上下文窗口听起来很大，但这个数字具有欺骗性。首先，考虑到一个普通单词在分解为 LLM 时实际上是 1 到 3 个 token。（经验法则是 3 个单词有 4 个 token，但随着语言变得更加复杂或在法律或医学等专业领域，这个数字会增加。）当你查看长文档、正在进行的交互和 AI 驱动的应用程序时，你很快就会发现你无法将你想要 LLM 知道的所有内容都放在其上下文窗口中。

因此，我们开发了一些巧妙的方法来解决上下文窗口限制。例如：

分块。你可以将大量数据分解，然后让 LLM 一次查看一部分。这种方法对某些任务（总结一篇较长的文档）很有效，但如果你需要分析整个文档中的概念，这种方法就不太有效了。
微调。你可以用你的特定数据训练 LLM。除了时间和费用之外，关键问题是你的新数据很容易被 LLM 已经吸收的更大的通用训练数据集所淹没。通常，它不会坚持下去。此外，许多 LLM 根本不支持微调——包括 GPT-4 和 Gemini。
检索增强生成 (RAG)。首先，您将文本内容转换为一种特殊的表示形式，称为嵌入。（嵌入是 LLM 工作方式的重要组成部分。本质上，它们是一种捕捉内容含义的数字表示。）一旦有了嵌入，您就可以将它们放在向量数据库中。现在，您可以使用语义搜索的魔力来查看提示并在数据库中找到概念相关的内容，然后将其输入到 LLM 中。换句话说，您只给它重要的东西。

最后一点是当今最常见的方法。RAG 高效且可预测。如果您拥有大量松散相关的文档，它的效果会非常好。例如，假设您正在创建一个技术支持聊天机器人，该聊天机器人从公司的知识库文章中提取信息。使用 RAG，您可以找到相关数据，并将其与您的提示一起提供给 LLM。本质上，您是在告诉 LLM 在回答提示时要查看哪里。

但 RAG 并不完美。它迫使你花费更多时间准备数据。它并不容易进入一个全新的数据集。如果你确实需要一次性考虑大量信息，它就不是那么有效——例如，你正在寻找小说中的总体主题或代码库中的功能。但尽管有局限性，RAG 还是非常接近当今的最佳实践。

至少，直到 Gemini 1.5 Pro 改变剧本之前，情况都是如此。

惊喜时刻

尽管 Gemini 1.5 Pro 尚未发布，但已进行了严格限制的试用。其结果令人大开眼界。

一些最令人印象深刻的例子表明，Gemini 能够创建涵盖大量知识的分析。谷歌的演示令人印象深刻，但他们过去曾被指责进行演示和挑选示例。我对独立测试人员更感兴趣，他们报告的结果同样引人注目。

例如，Conor Grennan将一本 300 页的小说交给 Gemini，并要求它描述主要人物、寻找情节转折，并找出人物感受到某些情绪的例子。Gemini 毫不费力地提出了贯穿整本书的细致入微的论点。YouTube 上流行的Fireship 频道的创建者 Jeff Delaney向 Gemini 提供了包含数千个文件的整个代码库，并要求它添加新功能。Gemini 不仅编写了正确的代码，还遵循了现有项目的风格，使用已经建立的组件、库和约定。其他演示展示了 Gemini 识别应用程序中的问题、提取关键示例并编写 API 文档。

如果你想要用其他东西来填充 Gemini 巨大的上下文窗口，还有另一个新功能——视频。视频的标记方式与文字不同，占用的空间要大得多。但即便如此，100 万个标记上下文窗口可以容纳大约一小时的视频——足以浏览一部电影并回答有关其内容的复杂问题。当谷歌要求 Gemini在一部 Buster Keaton 电影中寻找具体细节时，它就是这样做的，比如在他们没有识别的场景中，在一张纸上写下的文字。

未来的LLM

大型上下文窗口是未来的发展方向吗？到目前为止，普遍的看法是大型上下文窗口充其量只是部分解决方案。我们担心它们在计算时间上会非常昂贵。一项研究发现，LLM 并不擅长在长上下文窗口中间查找信息，而更擅长查找出现在开头或结尾的细节。所有这些因素都支持同一个结论：强行将您的内容放入上下文窗口是幼稚且成本高昂的。将所有数据转储到一个请求中并不是与 LLM 交谈的正确方法。

现在看来，未来似乎突然发生了变化。大型上下文窗口即将出现，它们可以让LLM对广泛的知识集有更全面、更全面的理解。去年无法用文本完成的任务现在即将在视频中成为可能。谷歌研究院正在研究 Gemini 的一个变体，将上下文窗口扩展到惊人的 1000 万个标记。

有两个事实显而易见。首先，在LLM之争中挑选赢家是愚蠢的行为。其次，变化的步伐并没有减缓——而是在加快。

欢迎你分享你的作品到我们的平台上. http://www.shxcj.com 或者 www.2img.ai 让更多的人看到你的才华。

创作不易，觉得不错的话，点个赞吧！！！