原贴链接

人们依赖哪些测量方法来评估一个给定模型对提供的提示上下文的注意力程度？

多年来，关于上下文长度的夸大声明层出不穷，从4K到大约120K（如mistral nemo），但我尚未看到任何关于模型在生成新内容时实际利用这些上下文令牌的程度的单一测量。许多临时测试表明，它们的表现都很差。

具体来说，在进行一项专注于模型从提供的上下文中“回忆”特定事实的能力的测试，或者提出需要模型同时关注上下文开头和结尾的问题时，它们都表现得相当糟糕。

我使用Mistral Nemo模型进行了一个简单测试，目前看来，该模型在关注上下文信息方面似乎是最不差的，我发现它能够合理地关注到大约6K个令牌，而在9K个令牌时，它已经无法关注整个上下文。这意味着它在9K时对于摘要或提取等任务已经基本不可用，这使得模型声称支持的剩余110-120K上下文范围基本上无用。

这仍然是我遇到的最佳开源权重模型，因此模型注意力的现状似乎相当黯淡。这就是为什么我想知道模型创建者如何评估他们的模型实际利用其架构提供的上下文长度的程度，以及这些测量在模型评估卡片或文献中被称为什么。

任何见解都将受到欢迎。

讨论总结

本次讨论主要聚焦于模型在处理长上下文时的表现问题，特别是如何评估模型是否有效地利用了提供的上下文。参与者普遍认为，尽管模型声称支持高达120K的上下文长度，但在实际测试中，模型在处理超过6K至9K的上下文时表现不佳，尤其是在需要模型“回忆”特定事实或关注上下文两端的情况下。讨论中提到了Mistral Nemo模型在处理9K以上的上下文时已经无法有效利用整个上下文，这使得模型在摘要或提取任务中的实用性大打折扣。此外，评论中还提到了其他用户对Mistral NeMo性能的失望，以及对其他模型如Llama 3.1和Gemini pro的评价。讨论的总体氛围是寻求更严格的评估标准来衡量模型的上下文处理能力。

主要观点

  1. 👍 模型在处理长上下文时表现不佳
    • 支持理由：实际测试显示，模型在处理超过6K至9K的上下文时表现不佳。
    • 反对声音：缺乏有效的评估方法来衡量模型对长上下文的关注能力。
  2. 🔥 Mistral Nemo模型在处理超过6K至9K的上下文时已经无法有效利用整个上下文
    • 正方观点：这是目前表现最好的模型之一。
    • 反方观点：这使得模型在摘要或提取任务中的实用性大打折扣。
  3. 💡 需要更严格的评估标准来衡量模型的上下文处理能力
    • 解释：目前缺乏标准化测试来区分真正有效的模型和夸大其词的模型。

金句与有趣评论

  1. “😂 Just to add a fact to your second paragraph: There have already been claims of 4M context (a Llama 3 fine-tune).”
    • 亮点：强调了模型在处理极长上下文时的挑战。
  2. “🤔 People sometimes publish the results of the needle in the haystack eval. I think that’s what you’re looking for: https://arxiv.org/pdf/2407.11963”
    • 亮点：提供了一种可能的评估方法。
  3. “👀 The thought that struck me personally when I read the paper was that inserting wildly out of distribution tokens (needles that don’t naturally fit the text they’re injected to) would indeed stick out like an eye-sore, making it much easier for the model to detect them, than if the needles were organic in with respect to the token distribution of the text they were inserted into.”
    • 亮点：深入分析了评估方法的逻辑。

情感分析

讨论的总体情感倾向是失望和寻求改进。主要分歧点在于模型在处理长上下文时的实际表现与声称的能力之间的差距。可能的原因包括缺乏有效的评估方法和标准化测试，以及模型在处理复杂上下文时的局限性。

趋势与预测

  • 新兴话题：更严格的评估标准和方法可能会成为未来讨论的热点。
  • 潜在影响：改进的评估方法可能会推动模型在处理长上下文时的性能提升，从而提高其在实际应用中的实用性。