🟢 I Spent a Week With GeminiPro 1.5—It’s Fantastic
😀 作者：Dan Shipper｜ Every 的联合创始人兼 CEO
这周，我获得了 Google 最新私人测试版大语言模型(LLM) Gemini Pro 1.5 的使用权限，它远超过公司以往发布的任何模型。(这与广为人知的 Gemini 版本不同，后者因拒绝生成白人图片而上了头条。那将很快被人遗忘；而这个新版本将在接下来的几个月乃至几年中保持其重要性。)
Gemini Pro 1.5 可以阅读一整本小说，并详细告诉我书中隐藏的一个场景。它能完整阅读一个代码库，并提出在哪里添加新功能的建议，并附上示例代码。它甚至能够浏览我在 Readwise 上的所有重点内容，并为我正在撰写的论文挑选合适的引用。
不知怎的，Google 设法开发出一个 AI 模型，它能在每次询问时舒适地处理高达 100万个令牌。举个例子，你可以把 Eliezer Yudkowsky 写的长达 1,967 页的作品 《哈利·波特与理性方法》 放进给 Gemini 的每一条消息中。（为什么要这样做呢？当然是为了科学。）
Gemini Pro 1.5 的两大突破
- Gemini Pro 1.5 的上下文窗口远超其他模型。 当 Gemini Pro 1.5 轻松处理整个理性末日风格的粉丝小说时，GPT-4 Turbo 只能处理 128,000 令牌，这大概只够处理 Peter Singer 那本相对较薄的 354 页著作 《动物解放》，这是有效利他主义运动的基石文本之一。
上周，GPT-4 的上下文窗口还显得很大；但本周，用过 Gemini Pro 1.5 后，这数字似乎就像是会让 Derek Zoolander 头发卷曲的量：
- Gemini Pro 1.5 能够充分利用整个上下文窗口。 在我的测试中，Gemini Pro 1.5 对于大量的提示处理得非常好，这是一个重大的进步，现有模型在处理大量文本时性能会大幅下降。即便它们的上下文窗口较小，当提示接近这些限制时，它们的表现通常不佳，往往会忘记你在提示开始时说过的内容或错过中间的关键信息。但这对于 Gemini 来说却不是问题。
这些上下文窗口的改进非常关键，因为它们让模型使用起来更加智能、更加便捷。或许 GPT-4 也能达到同样的效果，但你需要编写大量额外的代码。但现在你应该明白：有了 Gemini，你就无需这些额外的基础设施。它直接就能用。
为什么上下文窗口的大小很重要
我一直在阅读 Chaim Potok 的 1967 年小说《被选中的人》。它讲述了两个布鲁克林犹太人从敌对到相爱的故事，在一次可怕的垒球事故中找到了友谊和个人成长。（作为一个犹太人，我想说，是的，“可怕的垒球事故”是自摩西分开红海以来书中最具犹太人特色的引发事件。）
在书中，Reuven Malter 和他的正统派犹太教校垒球队正在对阵一个由 Danny Saunders 领导的哈西德派队伍。在一个关键的开场场景中，充满愤怒的 Danny 击打了一记直线球朝 Reuven 方向，球打在了 Reuven 的脸上，打碎了他的眼镜，玻璃碎片飞入他的眼睛，几乎使他失明。尽管受了伤，Reuven 还是接住了球。他的队友们首先关心的不是他的眼睛或他刚遭受的创伤性头部伤害——而是他接住了球。
如果你像我一样是一名作家，并且你正在键入像我刚才写的这样的轶事，你可能想在你的文章中引用 Reuven 的一位队友在他接住球后说的话，以使其更加生动。
如果你求助于 ChatGPT，它一开始可能做不到很好的效果：
这是错误的。因为，正如我所说，Sydney Goldberg 并不关心 Reuven 的伤害——他关心的是比赛！但并非无计可施。如果你给 ChatGPT 一个《被选中的人》的纯文本版本，并问同样的问题，它会给出一个很好的回答：
这是正确的！（它还为我们证实了 Sydney Goldberg 的优先顺序是正确的。）那么发生了什么呢？
ChatGPT 的行为就像我给它一个开卷考试。我们可以通过在问问题时给它一张带有一些额外信息的小卡片来改善 ChatGPT 的回答，这些信息可能会被用来回答问题。
在这个例子中，我们给了它一整本书来阅读。但你会注意到一个问题：整本书无法适应 ChatGPT 的上下文窗口。那么它是如何工作的呢？
为了回答我的问题，ChatGPT 中有大量的代码执行检索：它将《被选中的人》分成小块，通过它们来找到看起来与查询相关的部分。检索代码将原始问题，“Sydney Goldberg 在棒球击中 Reuven 的眼睛后第一件说的事情是什么？”和它能找到的书中最相关的文本部分传递给 GPT-4，后者产生了答案。（更详细的解释，阅读这篇文章。）
再次，我们必须将 GPT-4 传递给 文本块——而不是整本书——因为 GPT-4 只能在其上下文窗口中适应那么多文本。如果你在注意，你会看到问题所在：因为上下文窗口很小，我们模型回答某些类型查询的性能受限于我们寻找相关信息片段给模型的能力有多好。（我大约一年前写过这种现象 在这篇文章中。）
如果我们的搜索功能没有找到相关的文本块，那么 GPT-4 的答案就不会好。无论 GPT-4 多聪明——它只能做得和我们找到的块一样好。
假设我们几周后继续阅读《被选中的人》。我们已经读完了前两个部分，在我们开始第三部分之前，我们想要总结一下书中到目前为止发生的事情。我们将它上传到 ChatGPT 并要求它总结：
ChatGPT 给出了一个正确但不够详细的模糊答案，因为它无法将足够的书内容适应其上下文窗口以输出一个好的答案。
让我们看看当我们不必将书分成块时会发生什么。相反，我们使用 Gemini，它可以一次性阅读整本书：
你会注意到，Gemini 的答案更加详细，提供了 ChatGPT 无法提供的书中的关键情节点。（从技术上讲，我们可能也能从 GPT-4 那里得到类似的总结，如果我们设计了一个巧妙的系统来分块和总结它，但这需要大量工作，而 Gemini 使这项工作变得不必要。）
Gemini 的用途不仅限于读自我发现的小说和垒球事故。还有数百个其他用途，这些以前很难用 ChatGPT 或自定义解决方案来完成。
例如，在 Every，我们正在孵化一个软件产品，可以帮助 你用 AI 组织你的文件。我编写了文件组织器的原始代码，我们的首席工程师 Avishek 编写了 GPT-4 集成。他想知道在现有代码库中哪里可以接入 GPT-4 集成。所以我们将它上传到 Gemini 并询问：
它找到了代码中正确的位置，并编写了 Avishek 需要的代码以完成集成。这几乎如魔法般，极大地加快了开发人员的生产力，特别是在更大的项目上。
而且，情况并不止于此。我长时间以来一直在写关于变压器模型可能如何成为思维的副驾驶——和结束我们整理笔记的需求的文章。Gemini Pro 1.5 正是朝这个方向迈出的一步。例如，最近我正在写一篇关于我注意到的一种效应的文章，我称之为“我自己可以做”综合征，其中人们倾向于不使用 ChatGPT 和类似工具，因为他们觉得如果自己做，可以更快、更好地完成同样的任务。这就像那些缺乏经验的经理，他们对报告过度管理到几乎自己完成大部分工作的程度，确保按照他们想要的方式完成，但在这个过程中牺牲了大量的杠杆作用。
我想要一个开头的轶事，所以我请 Gemini 在我的阅读亮点中找到一个。它找到了一个完美的：
我找不到更好的轶事了，它不是一个普遍的故事——它来自我自己的阅读历史和品味。
📍 我后来发现这个轶事是捏造的。这个想法的总体方向是对的——卢斯确实同时运营了 时代 的编辑和商业两侧——所以它指引我朝正确的方向前进。但在我复查我的 Readwise 亮点后，我找不到 Gemini 提出的确切引语。（我只是在文章的早期版本被 Gwern 和其他精明的 Hacker News 评论者指出后才发现这一点。）
所以 Gemini 并不完美。你确实需要检查它的工作。但如果你小心谨慎，它是一个强大的工具。
再次，所有这些都回到了上下文窗口的问题。这种表现只有在我们不需要在将信息交给模型之前搜索或整理相关信息片段的情况下才可能实现。我们只需将我们拥有的一切都输入进去，让模型完成剩下的工作。
使用大上下文窗口更加容易，并且它们可以在不需要额外检索代码的情况下提供更一致、更强大的结果。问题是：下一步是什么？
大上下文模型的未来
大约一年前我写道：
“人们很长时间以来一直在说数据是新的石油。但我确实认为，在这种情况下，如果你花了很多时间收集和整理自己的个人笔记、文章、书籍和亮点，这将等同于在 OPEC 危机期间在你的卧室里拥有一个装满石油的油桶。”
Gemini 就是为什么这是真的的完美示例。有了它的大上下文窗口，你一直在收集的所有个人数据都准备好了，在适当的时间和适当的地方被部署到你需要的任何任务中。你拥有的个人数据越多——即使是杂乱无章的——越好。
不过，还有一些重要的注意事项：
首先，这是一个我可以免费使用的私人测试版。这些模型在公开发布时的表现通常有所不同，我们不知道 Gemini 在 Google 规模运营时的表现会如何。也无法确定当它上线时，向 Gemini 输入 100 万个令牌将花费多少。随着时间的推移，使用它的成本可能会显著降低，但这需要一段时间。
其次，Gemini 相当慢。许多请求花费了一分钟或更长时间才返回，因此它并不是每个 LLM 使用案例的即插即用替代品。它用于那些你不需要经常做的重活。我也期望随着时间的推移速度会显著提高，但目前还没有达到。
OpenAI 还有很多工作要做，我将关注他们的反应。但我脑海中的其他参与者——像 Langchain、LlamaIndex（我是投资者）、Pinecone 和 Weaviate——在某种程度上都是在赌注上，检索 将是 LLM 使用的一个重要组成部分。它们要么提供执行切块和搜索信息以传递给 LLM 的库，要么提供保持信息可搜索和安全的数据存储。正如我之前提到的，当你有一个大的上下文窗口时，检索变得不那么相关，因为你可以在每个请求中输入所有的信息。
你可能认为这些公司有麻烦了。Gemini 的巨大上下文窗口确实使他们正在构建的一些东西对基本查询来说变得不那么重要。但我认为长期来看，检索仍然会很重要。
如果有一件事我们对人类了解，那就是我们的野心会随着我们拥有满足它的工具而扩大。如果 100 万令牌上下文模型成为常态，我们将学会填满它们。每个聊天提示将包括我们所有的电子邮件，所有的日记条目，甚至也许还有一两本书。检索仍将用于弄清哪 100 万个令牌最相关，而不是现在用于的：找出哪 1,000 个令牌最相关。
💡 这是一个激动人心的时刻。在接下来的几周内，期待我的更多实验！