企业网站建设报价方案,做外贸学网站,产品设计公司有哪些,网站毕业设计怎么做PaperWeekly 原创 作者 | 苏剑林 单位 | 科学空间 研究方向 | NLP、神经网络 对于 LLM 来说#xff0c;通过增大 Tokenizer 的词表来提高压缩率#xff0c;从而缩短序列长度、降低解码成本#xff0c;是大家都喜闻乐见的事情。毕竟增大词表只需要增大 Embedding 层和… ©PaperWeekly 原创 · 作者 | 苏剑林 单位 | 科学空间 研究方向 | NLP、神经网络 对于 LLM 来说通过增大 Tokenizer 的词表来提高压缩率从而缩短序列长度、降低解码成本是大家都喜闻乐见的事情。毕竟增大词表只需要增大 Embedding 层和输出的 Dense 层这部分增加的计算量几乎不可感知但缩短序列长度之后带来的解码速度提升却是实打实的。 当然增加词表大小也可能会对模型效果带来一些负面影响所以也不能无节制地增加词表大小。本文就来分析增大词表后语言模型在续写任务上会出现的一个问题并提出参考的解决方案。 优劣分析 增加词表大小的好处是显而易见的。一方面由于 LLM 是自回归的它的解码会越来越慢而“增大词表 → 提高压缩率 → 缩短序列长度”换言之相同文本对应的 tokens 数变少了也就是解码步数变少了从而解码速度提升了另一方面语言模型的训练方式是 Teacher Forcing缩短序列长度能够缓解 Teacher Forcing 带来的 Exposure Bias 问题从而可能提升模型效果。 不过增大词表的缺点也很明显最直接的就是会割裂 token 与 token 之间在字符层面之间的联系从而可能会影响泛化甚至会损失做某些任务的能力。比如“太阳能”和“太阳”都是词表中的一个词的话模型是不知道“太阳能”是由“太阳”和“能”组成也不知道“太阳”是“太”和“阳”这样如果要做一些子词相关的任务就会比较艰难比如最经典的问“‘太阳能’反过来怎么读”期望回答时“能阳太”但由于模型不知道它是“太”、“阳”、“能”三个字组成从而很难回答正确。 续写问题 近日 Armen Aghajanyan 分享了另一个问题。他们在训练代码模型时使用了超大词表结果就是常见的命令如 “import numpy as np” 都变成了一个 token然后发现当用户输入 “import numpy” 时模型无法续写出 “as np”。原因很简单“import numpy as np” 被当作了一个 token于是当 “import numpy” 单独出现时模型会发现它后面永远不会接 “as np”接 “as np” 的都被合并成单独的 “import numpy as np” 了自然也无法完成续写。 这个现象确实很经典其实不单是代码模型常见的自然语言模型也会出现。比如当“太阳能”和“太阳”都成为了一个独立的 token 时用户输入“太阳”后接下来续写的字就基本不会是“能”了这可能不符合用户的分布期望又比如“白云”、“白云山”、“白云机场”都是一个独立的 token 时用户输入“广州的白云”后接下来也几乎不会续写出“广州的白云机场”、“广州的白云山”等等。 参考对策 然而笔者认为 Armen Aghajanyan 所提的现象并不能构成增大词表的缺点反而稍微处理一下之后它还有可能成为增大词表的优点。其实这个问题很简单以前没有 LLM 的时候基于“词表前缀搜索”我们也能做一定的补全任务现在有了 LLM难道我们就一定要囿于 LLM不能将基于 LLM 的续写和基于词表的续写结合起来吗 还是刚才的例子假设用户输入了“广州的白云”Tokenizer 将它分为“广州/的/白云”现在如果将这三个词直接转为 id 输入到模型中就会无法续写出“广州/的/白云机场”等结果。 这本质上是因为 Tokenizer 无法提前预估未来的文本从而导致分词结果出错当然也可以考虑在训练阶段就使用带有随机性的 tokenize 算法这种情况下“白云机场”可能作为一个词出现也可能作为“白云/机场”出现此时分词结果不至于严重影响后续效果甚至能增强泛化能力参考《Subword Regularization: Improving Neural Network Translation Models with Multiple Subword Candidates》。 那么我们是否可以预估一下未来的文本呢假设分词为“广州/的/白云”后我们回退一步拿“白云”去词表做前缀搜索不妨再假设搜索结果为“白云”、“白云机场”、“白云山”、“白云路”四个词这步搜索是纯粹基于词表做的相比 LLM 的计算量可以忽略不计。有了搜索结果后我们用 LLM 计算 由于输入都是相同的所以计算这四个条件概率只需要运行一次 LLM。有了这四个条件概率后我们将它们重新归一化然后进行采样。假如采样结果是“白云”那么我们就按照“广州/的/白云”来做续写如果采样到“白云机场”那么就可以输出“机场”并按照“广州/的/白云机场”来做续写依此类推。 这就轻松解决了 Armen Aghajanyan 所提到的问题并且将缺点转化为优点了压缩率高时即便回退了一步但是前缀搜索出来的词可能很长可以一次性生成更多的字。特别地回退操作只需要在采样第一步进行它只是为了避免输入不完整导致的分词错误从第二步开始就不需要回退操作了因此新增的计算量是非常少的。 值得一提的是微软有一个名为 “guidance” 的库也提出了同样的技巧参考这里。此外考虑更一般的场景有时候回退一步也不够比如 “import numpy as np” 的例子单输入 “import numpy” 时可能被分为 “import/ numpy” 了这时候起码要回退两步才能完整合理的序列。但这没有本质的区别只是细节上稍微复杂一些这里就不展开了读者部署推理模型的时候自行构造就好。 文章小结 本文介绍了超大词表的 LLM 在做文本续写任务时可能出现的一个问题并分享了参考的解决方案。 参考文献 [1] https://arxiv.org/abs/1804.10959 [2] https://github.com/guidance-ai/guidance#token-healing-notebook 更多阅读 #投 稿 通 道# 让你的文字被更多人看到 如何才能让更多的优质内容以更短路径到达读者群体缩短读者寻找优质内容的成本呢答案就是你不认识的人。 总有一些你不认识的人知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁促使不同背景、不同方向的学者和学术灵感相互碰撞迸发出更多的可能性。 PaperWeekly 鼓励高校实验室或个人在我们的平台上分享各类优质内容可以是最新论文解读也可以是学术热点剖析、科研心得或竞赛经验讲解等。我们的目的只有一个让知识真正流动起来。 稿件基本要求 • 文章确系个人原创作品未曾在公开渠道发表如为其他平台已发表或待发表的文章请明确标注 • 稿件建议以 markdown 格式撰写文中配图以附件形式发送要求图片清晰无版权问题 • PaperWeekly 尊重原作者署名权并将为每篇被采纳的原创首发稿件提供业内具有竞争力稿酬具体依据文章阅读量和文章质量阶梯制结算 投稿通道 • 投稿邮箱hrpaperweekly.site • 来稿请备注即时联系方式微信以便我们在稿件选用的第一时间联系作者 • 您也可以直接添加小编微信pwbot02快速投稿备注姓名-投稿 △长按添加PaperWeekly小编 现在在「知乎」也能找到我们了 进入知乎首页搜索「PaperWeekly」 点击「关注」订阅我们的专栏吧 · ·
