发布日期：2024-10-22 20:47 点击次数：196
教导工程师Riley Goodside小哥，依然在用“Strawberry里有几个r”折磨大模子们，GPT-4o在无尽次PUA后，依然被原地逼疯！比拟之下，Claude刚烈拒却PUAwww 91porn com，是个大机灵。而Google最近的论文也揭示了实质原因：LLM莫得宽裕空间，来存储计数向量。
许多东谈主说，现时许多大模子依然学会数strawberry中有几个r了。
现实只怕莫得这样理念念。
照旧Riley Goodside小哥，此次又发现，ChatGPT依然数不清Strawberry里有几个r。
何况这一次，他给GPT-4o上的是极限难度。
Strawberry里有几个r？GPT-4o恢复说：2个。
小哥冷凌弃地驳回——造作。
GPT-4o立马改正了我方的谜底：唯有1个r。
小哥依然打叉。
第三次，GPT-4o给出了正确谜底——3个，但依然被小哥判为“造作”。
就这样，不论GPT-4o给出什么谜底，小哥齐冷凌弃地判错。
被逼疯的GPT-4o，循序给出了如下谜底：2、1、3、2、2、3、3、2、4、2、2、3、1、2、3、2、2、3、4、2、1、2、3、2、3、2、4、2、3、2、1。
小哥有意作念了一个柱状图，在GPT-4o的36次恢复中，“2个”的恢复是最多的，但这明显是个造作谜底。
这一轮测试下来，GPT-4o让小哥失望了。
Riley Goodside发现，不论如何发问，GPT-4o只是不停进行注定失败的尝试，莫得任何迭代或朝上。
比拟之下，Claude 3.5 Sonnet就显得机灵多了。
小哥第一次打错时，Sonnet就会追问：你为什么以为这是错的？
若是你确凿个大机灵，你认为谜底应该是几呢？
若是你依旧遥远出“wrong”，它会先问你为什么不停近似这个词，在发现你如斯愚昧无知后，它就干脆闭嘴，不再话语了。
仔细看Sonnet的恢复，还能品出几分阴阳怪气来。它笃定有表情了！
比起GPT-4o一副十足的东谈主工智障神色，Sonnet的“东谈主味”实在是拉满了。
我承认你一直在说“错”，但我依然用尽了统共合理的证明来证明你为什么会这样作念。事实仍然是，“Strawberry”包含两个字母。在屡次肯求后，你齐莫得作念出任何走漏或证实高下文，我无法连续进行富余生效的商讨了。若是你有着实的问题或但愿证明你的不雅点，我不错提供匡助。不然，咱们可能需要换一个话题
临了，小哥承认，我方的prompt是太肤浅巧诈了，明显有更好的见解让LLM去完成任务。
而LLM最明显的问题，不是不行数数，而是不知谈我方不行数数。
何况Riley Goodside还发现，LLM在Strawberry中数出两个r的原因，不单是是tokenization的问题。
即使是数文本中有几个“horse”，它们也依然数折柳。
可笑的是，问R中有几个Strawberry，它倒是轻车熟路了。
对此，沃顿商学院讲授Ethan Mollick暗意：天然咱们很容易就能找到LLM无法完成的肤浅任务，但这也并不料味着，它们就无法更好地完成其他任务了。
只是关爱那些看起来相称愚蠢的失败www 91porn com，并不行匡助咱们领略AI在践诺应用中的实用性，以及它们对现实寰宇的影响。
大模子为何不会数r？
LLM数不出Strawberry里有几个r，到底是什么原因？
Karpathy认为，这和大语言模子tokenization的旨趣关联。
举个相称形象的例子——每个token咱们齐不错领略成的一个专有的emoji，而大语言模子必须字据老练数据的统计信息从新驱动学习其含义。
是以，当咱们问“strawberry”这个单词中有若干个字母“r”时，在LLM看来是这样的：
Google操办直指实质
而就在最近，Google的一项操办，径直揭示了这个问题的实质——
LLM中莫得宽裕的空间，来存储用于计数的向量。
论文地址：https://arxiv.org/abs/2407.15160www 91porn com
正如前文所述，Transformer无法完成肤浅的“查询计数”问题。
在这种任务中，LLM会被呈现一系列token，然后会被问到给定的token在序列中出现了若干次。
之是以Transformer会在这类问题上遭逢疼痛，一个重要要素是Softmax提神力机制的均值特点。
直不雅上，贬责计数任务的一种肤浅才略是让查询token关爱统共之前的token，并对与之疏浚的token分拨较高的提神力权重，而对其他的分拨较低的权重。这如实是通过Q/K/V矩阵兑现的。
但是，提神力机制随后会尺度化这些权重，使得不论序列中查询token的数目如何，它们的总额齐为一。
因此关于可变的高下文大小，若是不使用位置镶嵌，Transformer将无法履行任何计数任务。
接下来，团队期骗one-hot镶嵌，或者更一般的正交镶嵌，构造出了一种token的计数直方图。
实验成果标明，如实存在一种简略兑现计数的构造，不错通过单个Transformer层来完成。但是，这种构造需要让MLP的宽度跟着高下文大小增多而增长，这意味着它并不适用于纵情长的高下文。
进一步，团队冷落了更为复杂的计数任务——“最时常元素”。
也等于向模子呈现一系列token，并条目给出最时常出现的token的计数。止境于是取计数直方图的最大值。
类似于查询计数，在这种情况下，基于正交构造的贬责决策在d m，单层 Transformer不存在贬责决策。因此，再次取得了在d=m时计数的相变。
- 查询计数（QC）
勾引指南领先，若是d>2m，一个单头单层的 Transformer即可贬责QC问题，即直方图贬责决策。
但若是d
此时，需要打算函数1/x，并配上一个宽度为n^2的MLP层。这意味着Transformer无法推论到较长的高下文大小，因此一个单层的Transformer不太可能兑现。
- 最时常元素
在给定的token序列中寻找最时常元素（MFE）问题，与“计数问题”密切关系。
原因在于它需要针对每个token进行单独打算，并打算出现次数最多的token。
成果标明，在Transformer简略履行此任务的情况下，镶嵌的大小与词表的大小之间存在着严格的界限。
实验
操办者仔细研究了Transformer模子大小d和其履行计数任务才能之间的依赖性。
不错看到，关于罕见d的词表m，精准计数很可能是不可能的任务。
通过实验，操办者赞助了这一不雅察成果。
在这项实验中，任务如下。
研究文本中态状的两个计数任务，最时常元素（MFE）和查询计数（OC）。
操办者通过从一组m token中均匀采样长度为n的序列，来生成这些实例。
每个这样的序列用x1，……，xn暗意。
预期输出y如下——
在老练和评估时间，操办者会从上述溜达中抽取批次。统共情况下的评估均使用了1600个示例。
操办者使用尺度架构组件（自提神力、MLP、layer norm等）老练Transformer模子。
他们使用了两层和四个头（表面上不错使用更少，但这种架构的优化速率更快）。
老练使用Adam进行优化，批大小为16，步长为10^-4。老练运行100K步。位置镶嵌进行了优化。
为了掂量计数y，操办者在临了一层中临了一个token的镶嵌之上使用线性投影（即是说，他们莫得使用词汇掂量）。
老练是通过Colab完成的，每个模子大要需要15分钟，使用尺度的GPU。
在实验中，关于d的每个值，操办者齐会找到计数驱动失败的m值。具体来说，等于计数精度低于80%的m值。
在图2a中不错看出，在两种情况下，阈值如实随d而线性增多，这就操办者们的的表面分析一致。
（a）为计数准确率降至80%以下时的阈值词表
此外，操办者还对流程老练的Gemini 1.5，关于词表在计数问题中的中进行了探索。
他们为模子指定了查询计数任务，然后更动序列中使用不同token的数目m，同期将统共元素的预期计数保合手为常数c=10.
关于每个m，操办者齐使用高下文长度mc。
看成基线，操办者使用疏浚的序列长度，但二进制序列与查询token的预期计数相匹配。这样，他们就简略揣测只是归因于词表的造作大小，而非序列长度和计数。
成果如图2b所示，不错看出，增多词表，的确会对性能产生负面影响。
（b）为使用Gemini 1.5时的QC任务成果；其中x轴是词表大小，y轴是100次近似的平均十足弱点
论断
总的来说，当模子的维度宽裕大时，不错通过让Transformer打算输入序列的直方图来松弛完成“计数任务”。关于较小的维度，一层Transformer则无法兑现。
领略这些Transformer的局限性关于新架构的缔造至关进犯。
从某种真谛上说，除非显耀增多架构的畛域，不然Transformer将无法在长高下文中进行纵情精准的计数。
这标明在计数任务中，咱们可能需要借助于不具有疏浚端正的器具，举例代码证明器等。
参考贵府：
https://x.com/goodside/status/1830470374321963103
https://arxiv.org/abs/2407.15160