用户发现 gpt-6-astra 输出丢失空格，疑为追求 token 效率所致

返回博客 Astra缺失的空格 这个连贯的生命周期策略 当OpenAI发布gpt-6-astra时，我注意到模型编写的子代理提示中出现了一些奇怪的输出。它们包含一长串没有任何空格的单词： Freezeincludesyournewdiagnosticfilewriteswhilebenchmark 围绕Astra的营销宣传吹捧其token效率，看来他们为了追求这一点而牺牲了可读性。 这个代价划算吗？我想让你猜一猜，仅仅通过添加一些空格让它稍微更具可读性，效率会降低多少： Freeze includes your new diagnostic file writes while benchmark 把答案写在信封里！ 本文假设读者对“LLM大致如何工作”有所了解，需要掌握“LLM摄入和输出token”等概念。所有可视化均使用o200k分词器。 本文因令人兴奋的消息而更新…… 优化的第一原则是“为真实目标而优化”。代理目标就像猴爪，所以让我们定义我们想要什么。 我们想要有用的东西，我们想要低成本（时间和金钱，但假设吞吐量固定）。LLM按token计费，因此成本可以近似为token数量。 LLM在前向传播中完成其运算。上下文中的token只是它为下一次传播维护的状态。你可以在每次前向传播中做更多计算，但最终进入上下文的token的信息密度是一个限制因素。 绝大多数token是“内部推理状态”，用户看不到。这些token应尽可能信息密集。归根结底，计算量与熵成正比。 Astra使用o200k分词器，属于“字节对编码”家族。它们需要一个预分词器，在实际基于频率的合并操作之前将文本分解为单词。 你看到的每个插入符都是一个“单词”边界 任何token都不能超过预分词器定义的区间，因此它是你能在一个token中塞入多少字节的限制因素。这些强制边界点将用插入符^表示。 预分词器通常由正则表达式定义。我想向你展示o200k预分词器中使用的绝对之美： [^\r\n\p{L}\p{N}]?[\p{Lu}\p{Lt}\p{Lm}\p{Lo}\p{M}][\p{Ll}\p{Lm}\p{Lo}\p{M}]+(?i:'s|'t|'re|'ve|'m|'ll|'d)?|[^\r\n\p{L}\p{N}]?[\p{Lu}\p{Lt}\p{Lm}\p{Lo}\p{M}]+[\p{Ll}\p{Lm}\p{Lo}\p{M}](?i:'s|'t|'re|'ve|'m|'ll|'d)?|\p{N}{1,3}| ?[^\s\p{L}\p{N}]+[\r\n/]|\s[\r\n]+|\s+(?!\S)|\s+ 掸掉语法高亮器上的灰尘…… [^ \r\n\p{L}\p{N} ]? \p{Lu} \p{Lt} \p{Lm} \p{Lo} \p{M} ]* \p{Ll} \p{Lm} \p{Lo} \p{M} ]+ (?i: 's|'t|'re|'ve| 'm|'ll|'d )? | [^ \r\n\p{L}\p{N} ]? \p{Lu} \p{Lt} \p{Lm} \p{Lo} \p{M} ]+ \p{Ll} \p{Lm} \p{Lo} \p{M} ]* (?i: 's|'t|'re|'ve| 'm|'ll|'d )? | \p{N}{1,3} | ? [^ \s\p{L}\p{N} ]+ [\r\n/]* | \s* [\r\n]+ | \s+ (?!\S) | \s+ 可选前缀 可选大写 小写 可选缩略 单词 可选前缀 大写 可选小写 可选缩略 单词 数字 符号 换行 尾随空格 空白 哎呀。好吧，你知道他们怎么说吃大象的事——一次一个有限区间。 首先，可选前缀。它匹配一个不属于一堆东西的字符： [^ \r\n \p{L} \p{N} ]? 除以下之外的任何字符 CR / LF Unicode字母 Unicode数字 （而且它是可选的） 用“不是什么”来定义某物，这有点诗意，LLM确实喜欢这样…… 因此，可选前缀可以包含： 这意味着!important可以成为一个token（一个前导符号，一串小写字母），但!!important不能。它将被一串符号、然后一串字母所界定。 接下来是大写然后小写部分。这是包含实际字母的部分。正则表达式中前缀、大写、小写部分的重复是为了强制大写然后小写的顺序，而不匹配空段。我们只需过一遍其中一个。 \p{Lu} \p{Lt} \p{Lm} \p{Lo} \p{M} ]* \p{Ll} \p{Lm} \p{Lo} \p{M} ]+ 大写字母 标题大小写字母 修饰字母 其他字母 组合标记 零个或多个 小写字母 修饰字母 其他字母 组合标记 一个或多个 这将匹配： 而替代的大写、可选小写将匹配： 由于两种情况下正则表达式匹配都是大写然后小写，相反的小写到大写转换将始终在该大小写转换处产生边界。 helloWORLD永远不能成为一个token，无论它在训练数据中出现多少次。 (?i: 's| 't| 're| 've| 'm| 'll| 'd )? 不区分大小写 如wherefore's中 如woo't中 如which're中 如what've中 如thou'm中 如whoever'll中 如anybody'd中 （而且它是可选的） 这只是允许像you're这样的常见缩略词可能保持为一个token。 总的来说，预分词器强制了这种行为： 预分词器中没有任何东西阻止这成为一个token！ Freezeincludesyournewdiagnosticfilewriteswhilebenchmark 只要分词器的训练数据包含这类内容，这很可能更高效！ Freeze includes your new diagn ostic file writes while benchmark 10个token·每token 5.5字节 几乎每个单词一个token，这相当不错，对吧？ Freeze ·includes ·your ·new ·diagnostic ·file ·writes ·while ·benchmark 9个token·每token 7字节 哦，更好。另一个例子： This co herent l ifecycle pol ic yp re ferred over fin item ode heur istic 16个token·每token 3.69字节 This ·coherent ·lifecycle ·policy ·preferred ·over ·finite ·mode ·heuristic 9个token·每token 7.44字节 哦，那好多了。无空格版本破坏了单词-token对齐，产生了低效的碎片。 在我的会话中抽取的2,217条代理间消息样本中，总计181,749个token，更具可读性的版本具有：

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）