大家好，我是 Alvin，OutRival 的首席智能负责人。到现在为止，大家都听说过“Token 最大化”（token maxing）。人们在内部建立了排行榜，以谁使用的 AI Token 最多为荣。在 Meta，他们甚至为此设立了一个头衔——“Token 传奇”，这是给那些燃烧最多算力的人的荣誉勋章。这是一个有趣的梗，但如果你真的在交付产品，Token 使用量就是一个荒谬的成功衡量标准。

Token 不是工作本身，而是你为了完成工作所支付的费用。在 OutRival，我们的数字员工通过电话、短信和邮件处理复杂任务。在应用层，我们每天处理的 Token 数以十亿计。当你以这种规模运营时，每一次冗余的模型调用都会导致巨大的延迟和数百万美元的算力成本。看看这个提示词（prompt）。

我构建了一个合成代理，以镜像管道中结构性冗余的样子。假设我们要为一家名为 HarborBite 的虚构公司分类客户意图。我们都见过这种提示词：它包含 20 个边缘案例、过于吹毛求疵的定义，以及一段几乎是在恳求模型不要产生幻觉的文字。当你每天以数百万次的频率发送如此大量的文本时，这不再仅仅是一个提示词了。

这是一项巨大的、自找的算力税。如果你想给你的智能体更多能力，你需要架构上的空间来做到这一点。所以今天，我们要重新定义“Token 最大化”。它不应该是燃烧最多的 Token，而是从最小的 Token 负载中提取最大范围智能。那么，如何真正地进行“Token 最大化”呢？让我们进入操作手册。首先，是观测（Observe）。

你无法修复你无法衡量的东西。对你的共享模型客户端进行仪器化监控，使每次尝试都成为追踪的一部分，连接单个任务的模型调用、工具和重试。记录提示词版本、模型设置、Token 使用量、延迟和成本。OpenTelemetry 是追踪这些数据的绝佳框架。

现在你有了遥测数据，你就可以实际构建一个基准，以了解生产环境的运行状况。但大多数优化工作在这里撞上了墙。让我告诉你们通常的情况是怎样的：你拿着巨大的提示词，把它交给更小、更便宜的模型，并用几千个历史生产示例运行它。我们也做过这个实验：我们较便宜候选模型与我们昂贵的基础基准模型有约 18% 的不一致。

因此，自然地，我们将其剔除。它还不够好。但这 18% 到底代表什么？因为生产环境中的语言模型处理的是本质上模糊的真实生活输入，所以这 18% 实际上是一个复合指标。它引入了一个关键的隐藏变量：模型本身的基线方差。当输入混乱时，你的生产提示词不可避免地会与其过去的决定不一致。

为了隔离这个隐藏变量并了解重写实际上改变了什么，我们问了一个非常愚蠢的问题：生产环境真的与自己一致吗？我们运行了 AA 测试。我们称之为“天花板测试”。我们将庞大且昂贵的生产模型在相同的输入上运行了三次，并比较答案。我们发现它与自己不一致的时间约为 7%。

生产环境自身的一致性只有约 93%。因此，我们要求廉价候选模型达到一个标准，而我们现有的昂贵系统甚至无法达到这一标准。一旦建立了这个天花板测试基准，你终于有了一个可衡量的基线。现在你可以开始降低工作成本了。我有三个喜欢使用的技术杠杆，它们按顺序运行。

第一个是缓存（Caching）。具体来说，结构化你的提示词以最大化前缀缓存率，是一种非常简单且有效的方法来降低运行给定任务的成本。第二个杠杆是实际缩小提示词本身的规模。让我们把那个 HarborBite 的提示词例子再拿出来看看。这个提示词几乎长达 5,000 个 Token。

为什么？因为随着时间的推移，开发人员不断添加规则段落。例如，“不要将热情与授权混淆”就是这样一个例子。加上大量硬编码的对话记录，作为工作示例（worked examples）。没人愿意成为那个删除一行代码就搞崩生产环境的人。那你该怎么办？自动化它。将提示词工程转化为搜索问题。

使用像 DSPy 这样的框架，你可以停止手动编写指令。你定义确切的接口契约、输入、所需的输出模式以及评分函数。然后将其交给像 JEEP 这样的优化器（注：原文 Jeepa/Jeep，推测指 DSPy 中的优化组件或类似工具）。优化器将你的提示词视为搜索空间。

它针对你的基准运行，试图匹配那些历史标签。并利用失败的反馈来修订指令。它几乎删除了我们所有的长工作示例，并用紧凑的规则取而代之。在保持相同应用契约的情况下，指令 Token 减少了 51%。现在我们可以测试质量是否保持不变了。这就是即时利润（instant margin）。

第三个杠杆是实际缩小模型规模。现在你有了紧凑的提示词和可衡量的搜索循环，你不总是需要一个巨大的前沿模型。你可以开始激进地削减算力。这里有两个有趣的策略：首先，将庞大的提示词分解为较小的组件。你使用较便宜的模型来处理诸如初始路由或数据提取之类的事情，只唤醒昂贵的前沿模型进行重型推理。

其次，你可以使用我们刚刚构建的完全相同的 DSPy 搜索循环，但接入一个较小的模型。你让较小模型在其自身的提示词空间中进行搜索，以匹配由大型生产模型生成的基准答案。你实际上是在利用 JEEP 教导一个微型模型，使其针对你的特定数据集匹配大型模型的 task performance（任务表现）。

但优化的现实并不像这样简单，尤其是涉及这些小型模型时。如果你试图将大型模型的行为压缩到较小的模型中，你会注意到你引入了新的故障点和过拟合问题。在我们许多缩小规模的实验中，我们发现提示词还不够好以至于无法发布，这就引出了最后的障碍。我们将 Harbor 的提示词缩短了一半，但现在我们必须证明我们实际上没有破坏产品。

记住，这些模型是概率性的。生产环境并不总是与自己一致。同样，我们新的廉价候选模型也会有其自身的内部方差。因此，你在完全相同的输入上运行大规模的影子部署（shadow deployment），并从三个角度测量系统：生产环境对生产环境、候选模型对候选模型，以及候选模型对生产环境。这里有一些有用的数学逻辑。

将两个版本之间的分歧减去各自内部平均的分歧。剩下的部分给出了衡量两者决策概率差异程度的指标。这就是“上限测试”发挥作用的地方。我们不是在猜测，而是拥有数学基线来衡量在未做任何更改时这些答案的波动范围。关于这种漂移有一个秘密：不同并不自动意味着错误。

如果你的优化器完成了工作，分布应该会有所不同，因为更便宜的提示词实际上表现更好。我们并不一定要构建一个完美克隆的生产系统版本，该系统可能已经内置了一些缺陷。因此，不要对原始差异感到恐慌，提取差异并手动审查其中一些案例。

候选版本是否更好？生产环境版本是否更好？或者它们只是处理模糊输入两种同样可接受的不同方式吗？以 Harbor Bite 为例，假设完成的审查确认了 433 次回归错误，但也发现了 2,463 处明显的改进。这意味着对于每个回归错误，几乎有六次改进来自一个体积减半的提示词。

但你不能仅凭点估计就发布产品，必须考虑采样噪声。虽然我们在这一批特定请求上测量到了巨大的增益，但我们需要确切知道能在多大程度上赋予其统计置信度。因此，我们在净增益周围计算一个置信区间。

保持比较严格配对，两个版本回答完全相同的请求，并将同一对话的重复运行分组在一起。要声称候选版本更好，我们希望置信区间的下限高于零。如果区间跨越零点，在做出该声明之前我们需要更多证据。

最后一种健全性检查是必须单独对你的关键类别运行此数学计算。一个优秀的全球平均值实际上可能会无声地隐藏某个至关重要的客户意图正在崩溃的情况。如果你的关键类别表现良好且置信区间下限高于零，你就得到了答案：发布它并继续测量。

这就是你用明确的发布规则取代提示词工程猜测的方法的过程。缓存明显的内容，让优化器缩小你的指令范围，降级模型并使用上限测试来理解变化。然后测试质量是否保持得住。

这是你周一早上的作业：挑选你最昂贵的任务，测量你的基线方差，将其放入搜索循环中，找出你确切在为此支付多少冗余成本。我们需要夺回令牌的最大化利用权。让行业的其他人为排行榜上的高分而争斗，真正的令牌传奇是那些让每一个令牌都发挥价值的人。