3 篇博文 含有标签「sampling」

打开任何上线超过一年的 AI 功能的生产环境配置，你会发现一个考古挖掘现场。temperature: 0.7 是因为有人想让演示看起来不那么机械。top_p: 0.85 是因为一个客户抱怨输出太普通。frequency_penalty: 0.4 是因为 2024 年有那么糟糕的一周，一个现在已经退役的模型一直在重复自己。这些决定都没有记录。它们都没有针对当前的基座模型进行重新测试。它们在每一次请求、每一次评估、每一次 A/B 测试中运行，塑造着自原始工单关闭以来再也没有人会有意识选择的行为。

这就是采样漂移（Sampling Drift）。它是由于权宜之计而进行的采样器微调的缓慢积累，这些微调最初的理由已经消失，而其效果却在不断叠加。你配置中的数值并不是经过“调优”的——它们是过去事故的化石记录，被缩放到了你当前的流量规模。

它之所以不可见，是结构性原因造成的。你运行的每一次评估都是针对当前的采样配置进行评分的，所以头条数据看起来总是没问题。当 Temperature 值比基座模型落后两个版本时，不会触发报警。也没有日历邀请会提醒你“在本季度重新网格化采样参数”。这种衰减是无声的，直到有人运行了一个干净的实验，发现一个质量提升、Token 减少，或者两者兼而有之的机会，就摆在眼前，且不需要任何工程成本。

一个 Web 服务请求在繁忙时段产生 5 个 Span。而一个现代的 Agent 会话产生 50 个，如果 Planner 决定递归，有时甚至会产生 1000 个。你们平台团队从微服务时代复制粘贴过来的 1% 均匀采样器，从定义上就会丢弃你真正关心的稀有故障——因为故障是稀有的，而均匀采样对稀有性没有任何判断力。

“我们对 Agent 拥有完全的可观测性”的真实版本听起来与营销版本不同。它听起来应该是：我们保留重要的 Trace，丢弃不重要的，并且我们预先知道哪些是哪些。这句话中的每一个词都至关重要，而那些在账单寄来之前一直忽视采样设计的平台团队，现在正被迫反向学习这一学科——在成本压力下，以及在经历了一个季度的故障之后，这些故障本应“在数据中”，但在有人查看之前就被剔除了。

你团队每个周一盯着看的调试语料库并不是生产环境的代表性样本。它具有明显的偏差，而且偏差的方向完全错误。1% 的头部采样在保留一个罕见的灾难性轨迹之前，会先保留一百次中位数请求——大多数团队只有在某种静默循环了数月的失败模式最终导致退款或停机，并试图在追踪存储（trace store）中寻找示例却一无所获时，才会发现这一点。

这并不是什么罕见的边缘情况。这是所有专为无状态 Web 服务设计、随后又被用于长时程（long-horizon）Agent 的可观测性栈的默认行为。同样的采样算法在处理 HTTP 请求追踪时表现良好，但在处理 Agent 时却会系统性地抹除那些最重要的轨迹——因为在这里，每个“请求”都是一个包含三十个步骤的计划，可能会调用数十个工具，重新生成三个子计划，并在第 27 步发生细微错误之前消耗数万个 token。

解决方法不是“增加采样”。增加采样只会让账单爆炸，而不会改变偏差——你只会得到更多已经过剩的普通数据。解决方法是改变你采样的对象，以只有在轨迹结束后才能获知的预测结果为基准。这需要抛弃基于头部的默认设置，并围绕尾部信号、异常权重以及能在 Agent 执行的长尾效应中存续的有界蓄水池（bounded reservoirs）重新构建保留层。