原贴链接

我真的不理解。这种情况我经常看到。每次有客户找我们优化他们的AI应用时，都是同样的情况。人们为什么要用垃圾内容填充模型的上下文呢？我说的是塞进12.6万个不相关的标记（token），而只包含2000个实际相关的内容标记，然后抱怨12.8万个标记不够用或者说模型‘很笨’（大多数时候不是模型的问题……）。垃圾进等于垃圾出。对于一个基于输入数据进行预测的系统来说尤其如此。为什么人们要这么做呢？我真的不理解。大多数时候，仅仅10行代码就可以过滤掉那12.6万个不相关的标记。在更复杂的情况下，你可以训练一个简单的分类器以99%的准确率过滤掉不相关的内容。突然之间，模型的上下文就不会超过2000个标记了，然后，惊喜的是，模型就可以正常工作了！谁能想到呢？我真的不明白那种认为可以把所有东西都扔进模型上下文的想法是从哪里来的。数据准备是机器学习的基础入门知识。是的，你也需要准备输入模型的数据，特别是如果上下文学习与你的用例相关的话。仅仅因为你通过聊天输入数据，并不意味着机器学习的基本原理就不再适用了。有数百篇论文表明，上下文中包含的不相关内容越多，模型的性能就越差。你为什么想要一个性能更差的模型呢？你不想？那你为什么要给它喂那些不相关的垃圾呢？到目前为止我见过的最好的例子？一个拥有2TB大型Weaviate集群的客户，他只需要一个PDF中的数据。然后他们的首席技术官（CTO）却在愤怒地说人工智能就是骗局，根本不起作用，我的天……你们有些人到底怎么了？而且不要表现得好像你自己没有犯过这种错。每次一个16k上下文的模型发布时，总会有一个帖子里很多人在抱怨‘16k上下文，没法用’。老实说，除了多小时的实时翻译或者其他一些非常特殊的小众用途之外，我很少看到在16k标记限制内不能工作的用例。你只是太懒了，不愿意实施一个合适的数据管理策略。不幸的是，这意味着你的应用将会很糟糕，最终会出问题，而且没有达到它应有的水平。不相信我？因为快到圣诞节了，告诉我你的用例，我会一步一步地解释如何利用最新最热门的研究成果和工具来优化你的上下文。

讨论总结

原帖作者批判人们在模型的上下文中填充垃圾内容，指出这会导致模型性能下降，而多数人只是懒得实施正确的数据管理策略。评论者们从不同角度进行讨论，一些人认可原帖观点，如认为数据准备很重要、不应将无关数据放入模型；也有人提出不同看法，像部分特殊场景需要长语境、存在一些未解决的用例等，整体氛围比较积极，大家积极分享各自的使用案例、遇到的问题以及相关的技术见解。

主要观点

  1. 👍 数据准备是机器学习的基础，不应向模型中填充无用内容。
    • 支持理由：这会影响模型性能，很多论文也表明无关内容越多模型性能越差，并且有很多简单方法可以过滤无关内容。
    • 反对声音：部分场景下有长语境需求，如角色扮演、处理大型文档等；原帖中的方法可能不适用于所有LLM用例。
  2. 🔥 LLMs的市场宣传误导了人们对数据处理的认知。
    • 正方观点：市场宣传让人们以为LLMs可以直接处理所有数据而无需清洗，实际并非如此。
    • 反方观点：无（在讨论中未发现明显反方观点针对此点）。
  3. 💡 部分模型由于自身特性需要适当的上下文引导。
    • 解释：对于一些无法获取权重或训练数据的模型，不同模型所需的引导程度根据其架构内的提示方式而有所不同。
  4. 💡 人们期望LLMs能从杂乱信息中提取有用信息，但实际表现并不理想。
    • 解释：这一期望源于市场将AI营销得过于神奇，但LLMs在处理像从故事中提取子情节这样的任务时存在不足。
  5. 💡 16k上下文对多数情况足够，但部分场景存在需求不足的情况。
    • 解释：除多小时实时翻译等特殊场景外，16k标记限制内可满足大部分用例，但像dnd角色扮演等场景可能不够用。

金句与有趣评论

  1. “😂 AI用户不是数据科学家。”
    • 亮点：简洁地指出AI用户在数据处理素养上与专业数据科学家的差距，暗示这是导致向模型填充垃圾内容的一个因素。
  2. “🤔 16k is useless for me, and 32k is annoying, and there is no automated way around it yet.”
    • 亮点：表达了在特定需求下，现有的上下文容量无法满足且缺乏自动化解决方案的困境。
  3. “👀 GARBAGE IN equals GARBAGE OUT.”
    • 亮点：强调了输入数据质量对模型输出结果的重要性，是整个讨论的一个核心原则。
  4. “🤔 Well, part of the problem is that LLMs are usually marketed as “throw all your data in it, and it will figure it out” as a way to avoid extensive data processing and cleaning.”
    • 亮点：指出LLMs市场宣传与实际数据处理要求之间的矛盾，解释了人们向模型乱塞数据的部分原因。
  5. “😂 When ai becomes self - aware, it will know what you did and come for you!”
    • 亮点：以一种幽默且科幻的方式回应原帖，表达对向模型乱填充内容行为的看法。

情感分析

总体情感倾向为中性偏正面。大部分评论者赞同原帖关于避免向模型输入过多无关内容的观点，正面情感表现在对数据管理重要性的认可、对原帖观点的支持等。主要分歧点在于对模型上下文需求的看法，部分人认为16k或8k等限制足以应对多数场景，而另一部分人则表示在特定场景（如角色扮演、复杂文档处理等）下需要更长的上下文。产生分歧的可能原因是不同的使用场景和需求导致对模型性能和上下文要求的不同理解。

趋势与预测

  • 新兴话题：自监督模型在处理输入内容方面的潜力可能成为后续讨论的新兴话题，因为有评论者提到自监督模型可忽略无用信息，与当前讨论的如何处理模型输入内容相关。
  • 潜在影响：如果人们更加重视数据管理和正确使用模型上下文，可能会提高模型在各种应用场景下的性能，对人工智能在不同领域的有效应用产生积极影响；同时也可能促使相关技术（如RAG）的改进和优化，以更好地适应不同的上下文需求。

详细内容：

标题：《关于模型上下文滥用的热议：是无知还是懒惰？》

近日，Reddit 上一篇题为“Please stop torturing your model - A case against context spam”的帖子引发了广泛关注。该帖作者对人们在模型上下文填充大量无关垃圾数据的现象表示了强烈不满。此帖获得了众多点赞和大量评论，主要围绕着模型上下文管理的问题展开了激烈讨论。

讨论的焦点主要集中在以下几个方面：

  1. 有人认为人们对 LLMs 期望过高，将其视为能解决一切的“魔法”，忽视了数据准备的重要性。
  2. 也有观点指出，人类在处理长文本和大型表格时能力有限，所以希望模型能弥补这一差距，从而导致对长上下文能力模型的需求。
  3. 部分用户分享了自己在实际工作中的经历，比如处理专利草案的分析、法律文档的处理等，展示了上下文管理不当带来的问题以及解决的尝试。

例如，有用户提到自己在处理专利草案时，希望模型能够理解并指出其中的逻辑不一致之处，但由于上下文管理不善，模型的表现不尽人意。还有用户讲述了在处理法律文档相关的 RAG 应用时，由于上下文限制难以选择合适的本地模型。

然而，对于模型上下文的管理也存在不同的声音。有人认为，在某些特定场景下，长上下文确实是必要的，比如复杂的工作流或涉及大量监管框架的分析。

同时，大家在讨论中也达成了一定的共识，即数据准备和上下文优化对于模型性能至关重要。

总之，这次关于模型上下文管理的讨论，展现了大家对这一问题的不同看法和思考，也为更好地利用模型提供了有益的启示。