【外评】LLM大型语言模型与哈利波特问题

人工智能 LLM| 2024-04-24

长上下文 LLM 如今风靡一时–感觉上，每一种新的 LLM 都能将其上下文窗口提高一个数量级。它们甚至在 “干草堆里的针”（Needle In A Haystack）等典型基准测试中表现出色。不幸的是，在我们看来，它们仍然存在一些关键问题：我们称之为 “哈利-波特问题”。

在本文中，我们将首先介绍这个问题及其实际影响。作为对校对人员的回应（谢谢大家），我们将解释为什么代理、开箱即用的 RAG 和微调都不足以解决这个问题。对于技术性较强的读者，我们还提供了一些阅读材料和数据，以供进一步咀嚼。

“大型语言模型可能有很大的上下文窗口，但它们在使用大上下文信息方面仍然不够出色，尤其是在高价值用例中”。

问题所在

想象一下，你提供一个 LLM（注：不是代理–本文稍后将解释为什么我们关心 LLM 的能力）《哈利-波特》里的一章，让它数一数 “巫师 “这个词被提到了多少次。GPT4、Claude 3 Opus、Gemini Ultra 和 Mixtral–可以说是 SOTA 的代表–尽管有很大的上下文窗口，但在这项任务中都失败了。

诚然，这项测试有两个重点：一是测量模型的上下文回忆能力，二是测量模型的计数能力，而这两者都是弱点。在本讨论中，我们将重点讨论上下文中的回忆能力，因为这与长语境模型的要点更为密切相关。

下面是一些有助于描述这一问题的简要统计数据。有关我们的测试和方法的所有细节，请一直读到最后：

GPT4 Turbo：对超过 >=64k 标记的文档的准确率为 55
Claude 3 Opus：超过 >=64k 字节的文档准确率为 65
Mixtral 8x7b Instruct：对超过 >=64k 标记的文档的准确率为 17.5%
Gemini 1.5 Pro：对超过 >=64k 个字符的文档的准确率为 45

显而易见，在长上下文中，没有一种方法的准确率特别高。有关我们的方法的更多详情，请参阅本帖末尾。

我为什么要关心这个问题？

简而言之，这个问题确实会损害 LLM 的准确性，而且很难被发现。《哈利-波特》是一个无辜的例子，但当涉及价值较高的用例时，这个问题的代价要高得多。例如，我们分析保险单。保险单长达 70-120 页，内容非常密集，读者需要在各页信息之间建立逻辑联系（例如，第 5 页和第 95 页各一句话）。因此，要回答 “我的火灾损害赔偿范围是什么？”这样的问题，您就必须进行阅读：

第 2 页（保费）
第 3 页（免赔额和限额）
第 78 页（火灾损失除外责任）
第 94 页（”火灾损失 “的法律定义）

对于人类专家来说，这已经很困难了，而对于任何现有的LLM来说，这几乎是不可能的。更大的问题在于，上述过程中的任何失误都会严重影响高价值用例中答案的正确性。更糟糕的是，该模型可以（也将会）自信地进行 BS。可能出现这种问题的其他情况包括：审查冗长的法律案件、理解代码库、审查 2 岁以上儿童的医疗记录等等。

RAG 不能解决这个问题吗？

不尽然。传统的 RAG（我们说的是 LangChain + embeddings 模型 + OpenAI + 语义/混合搜索）并不考虑文档的结构和信息层次。这意味着检索到的信息块和提示忽略了在其附近发现的其他可能相关的信息。例如：如果您要查找一份保险单中的 “火灾保险”，并提取了一个包含 “火灾保险 “定义的信息块，它可能是保险范围内或排除在外的火灾类型，而描述火灾保险的信息位于该信息块之前的几页。如果你真的想保留整个结构，你最终会增大你的块大小，检索一个大的上下文，最终回到你开始的地方。

元数据过滤是比较接近的方法，但也不能完全解决问题。你仍然会将检索限制在任意数量的数据块上，可能会错过一些上下文。

微调不能解决这个问题吗？

只能部分解决。LoRA 和其他 “快速 “微调方法并不能从根本上解决 LLM 如何消化上下文的问题，因为事实证明 LLM 更关注文档的开头和结尾，而不是中间的信息[1 – “Lost in the middle”]。按照一定顺序进行一系列精心策划的全面微调有助于提高长语境性能[3 – LongRoPE]。这里的核心问题是成本和长文本（尤其是行业特定文本）的稀缺性。

代理难道不能解决这个问题吗？

截至本文撰写之时，人工智能有可能解决这一问题，但尚未实现。带有工具调用功能的 OpenAI 可以解决《哈利-波特》的问题，但它仍然无法了解文档的大背景，而这正是本次讨论的重点。要想让它发挥作用，代理需要自主消化整个文档，开发一个本体来解决你的用例，并找出一种方法来解析文档的所有复杂性。这将是一场革命，我们希望它能实现。遗憾的是，我们在代理方面的经验尚未取得令人满意的结果。

好吧，那你该怎么办呢？

我们发现，解决这个问题的最好办法是，对每份长文档应该是什么样子、它应该包含哪些信息以及文档中的信息是如何相互关联的，有一个自己的看法。这是一项艰巨的任务，而且不能一概而论，所以很遗憾，这里并没有真正的破解方法。举例来说，我们花了几个月的时间研究每一份我们能接触到的保险单，以建立一个本体论，我们试图将文档与本体论相匹配，然后围绕本体论建立一个摄取和检索管道。

基本上，我们做了一个权衡：为了换取对保险单的深刻理解，我们放弃了理解其他任何东西的能力。我们必须修改我们的通用检索引擎，以便处理某些类别的查询，而据我们所知，这些查询在行业外是不存在的；我们还必须修改 LLM，以便能够正确理解行业术语；我们还必须修改文档摄取，以便处理传真（是的，这也是一个问题）。采用正确的方法，知识图谱会很有帮助，最近发布的许多分块技术也可以起到同样的作用。

另一个需要考虑的问题是将文档当作百科全书来处理–建立一个目录、词汇表和引文列表，以便 LLM 在检索文档分块之前可以查阅。这在摄取过程中也很有用。

我如何为自己的文档做这项工作？

首先，选择您希望了解的文件类别，然后对每一个新类别重复这一过程，直到任一类别：

解决《哈利-波特》的问题，或者
有人想出了一种可通用的方法，从文件中构建知识图谱，而且这种方法确实有效

题外话：我们很希望听到关于 b 的研究成果，尤其是考虑到长上下文 LLM 数量的增加。

接下来，就您认为该文档的所有变体都必须具备的信息提出看法。试着列出它们、它们的类型以及它们之间的关系（图论在这方面很有帮助）。

最后，说起来容易做起来难，尽可能多找一些例子来做实验。在取得良好效果之前，您可能需要反复试验多次。不过，对于合适的业务问题，挤出的果汁是值得的。

描述性统计

这并不意味着是全面的或学术性的，但希望这些统计数据有助于表达观点。您可以根据下面的提示和信息自己尝试所有这些统计。

提示和方法

我们使用相同的输入和不同的温度对下列每个提示运行了 10 次，以尽量减少模型不走运的情况。它们由另一个 LLM（GPT3.5）和人工审核共同评估。不完整的答案以及包含无关信息的过于冗长的答案都被视为错误。结果是所有运行结果的总和。

提示：

在下面的节选中，”巫师 “一词被提到了多少次？<此处为《混血王子》第 1 章>。
根据以下信息，《多德-弗兰克法案》第 523 条是关于什么的？<美国国会《多德-弗兰克法案》各章节摘要>？
请列出以下文件中第五章 B 小节的前 5 个编号章节和摘要：<多德-弗兰克法案各章节摘要，美国国会>？
列出以下保险单中的所有承保类型。保险类型示例包括专业责任、商业一般责任、员工福利责任以及网络和隐私责任。<出于隐私原因，保险单已删节，但可使用任何您想要的商业保险单>。