客户无法复现的隐形个性化层

一个平台团队发布了一项质量改进。推理阶段的一个图层会读取用户的近期交互记录，并悄无声息地调整响应风格：这里更正式一些，那里更简洁一些，或者当历史记录显示是一个工程师在提问时，响应会更具技术性。A/B 测试显示，整体满意度提升了几个百分点。发布公告的标题是“更智能的响应，无需更改 API”。没有人修改 API 中的标志位。没有人更新文档。响应内容中也没有任何迹象表明模型刚刚采用了哪种人格。

六周后，一位企业客户提交了一个支持工单，称“你们的模型比宣传的要差”。他们的内部评估套件——运行的是你们团队发布基准测试时所用的相同提示词——得分低了 8 分。你团队的第一步是核实提示词的一致性。提示词完全匹配。解码参数匹配。模型版本字符串也匹配。差异最终追溯到了个性化层，它为客户新开设的测试账号推断出一个“历史记录贫乏的默认人格”，而为你衡量基准测试的长效用户账号推断出了一个更丰富的人格。关于个性化究竟是功能还是缺陷的讨论，不再仅仅是一个产品决策，而演变成了一场合同谈判。

这是质量改进的一种失败模式：它提升了平均值，却摧毁了客户在自己的流量中对系统进行推理的能力。这 8 分的差距并不是回归。这是一个由平台通过增加隐藏状态且未告知任何人而创建的海森堡问题 (Heisenberg problem)。

隐藏状态是对 API 契约的违背

API 是关于客户可以了解、控制和复现什么的契约。发布的表面部分——端点、请求架构、模型标识符、解码参数——是客户阅读的契约部分。客户不阅读的部分，是平台假设不存在的部分。当平台添加了一个在请求到达后、模型看到提示词之前运行的个性化层时，它向每一次调用中都插入了一个隐藏参数。客户的提示词不再是唯一的输入。用户的交互历史也是输入。平台在没有更改函数签名的情况下更改了客户正在调用的函数。

这以一种特定的方式破坏了复现性。大模型 API 的复现性本来就很困难——浮点数非结合性、依赖批次的内核、提供商侧的负载均衡以及常规的模型更新，都引入了 temperature 参数从未控制过的变量。针对这一基准的准则是记录你能记录的一切：模型标识符、解码参数、提示词、时间戳以及客户控制的所有系统输入的哈希值。隐藏的个性化层添加了一个客户无法记录的输入，因为客户无法读取它。平台已经在正当的变量源上耗尽了复现性预算，现在又因为一个客户完全不知道正在运行的功能而超支了。

契约违约还有更尖锐的一面。运行评估套件的客户正试图回答一个特定问题：模型的表现从昨天到今天是否在我的工作负载上发生了退化？如果答案取决于平台为评估账号推断的人格——而这本身又取决于评估账号'的交互历史，而客户的 CI 环境在每次运行时都会从头重建该历史——那么客户就不是在衡量模型。他们是在衡量模型与平台所拥有的状态之间的交互。本应是对模型进行的回归测试，变成了对平台的个性化人格推断进行的回归测试，而客户并没有这一推断的规范。

证明其合理性的 A/B 测试无法证明其持续运行的合理性

发布的决定可能是以正确的方式在错误的高度做出的。A/B 测试衡量了整个平台用户群体的综合满意度，并显示出提升。对于群体来说，提升是真实的。但这不等于任何单个客户看到的提升，也不等于该客户关心的任何特定工作负载上的提升。运行测试的团队优化了他们能够移动的指标，并发布了移动该指标的功能。评估得分下降的客户，正处于测试未能进行细分的分布尾部。

这就是每个发布“平均质量”功能的平台都会遇到的“细分 vs 综合”失败。2% 的综合满意度提升可能包含了中等客户 10% 的提升、长尾客户的平淡表现，以及某个特定高价值细分市场的回归，而个性化模型从未见过足够的用例来刻画这个细分市场。平台的 A/B 框架报告综合数据，因为框架的配置就是如此。失败的细分市场是不可见的，除非有人为其配置了监测工具，而失败声音最大的细分市场是那些企业客户，他们的支持升级现在成了你的谈资。

更深层的问题在于，证明发布合理的 A/B 测试无法证明其持续运行的合理性。发布前的测试是针对拥有发布前交互历史的账号群体运行的。个性化模型对这些账号的推断是从平台观察到的分布中采样的。发布后的群体包括每一个新开设的企业账号、每一个评估账号、每一个在每次运行时都会创建新账号的 CI 环境，以及每一个第一次测试 API 的客户。个性化模型在这些账号上的推断是外推，而不是内插，而外推正是模型表现变得不可预测的地方。发布六个月后的综合满意度指标，与做出发布决定时所依据的指标已不再是同一个，而且没有人重新运行测试来查明真相。

客户的评估变成了他们无法读取的状态函数

企业客户的投诉升级中包含了一个具体的指控：“我们无法信任一个行为取决于我们无法读取、无法重置且无法在自己的测试环境中复现的状态的系统。”请将其视为一种合同诉求，而非对质量的抱怨。客户并不是说个性化输出比非个性化输出差，他们是说系统变得不可测试了。

在 CI 中运行的评估套件（eval suite）是针对一个全新的测试账号运行的。该账号没有交互历史。个性化层推理出了一个“无历史默认”画像（persona），这本身就是平台在输入为空时做出的选择。这种默认设置可能是保守的、通用的，或者偏向于训练群体的平均水平，这取决于画像推理是如何构建的。客户的评估分数反映了模型在无历史画像下的行为。而客户的生产环境分数反映了模型在客户真实用户积累的各种画像下的行为。这两个数字无法进行比较，这意味着评估无法证明生产环境中的任何情况。客户的质量保证流水线已被默默地作废。

客户可以尝试绕过这个问题。他们可以用合成的交互历史填充测试账号。但合成历史必须符合个性化模型所预期的画像分布，而客户并没有这种分布的规范（spec），因为平台没有发布它。客户可以尝试使用具有不同历史记录的多个测试账号。但个性化层以客户无法建模的方式具有非确定性。客户可以要求平台提供退出选项。平台可能会提供，也可能不会；如果提供了，退出选项也是一条客户生产流量不使用的独立代码路径，这意味着评估现在测量的是一条不在生产环境中运行的路径。目前没有完美的答案，因为平台发布的这项功能本身就破坏了客户构建完美答案的能力。

平台本应发布的内容

一旦明确了设计约束，弥补这一差距的模式就很简单了。个性化是隐藏状态。隐藏状态破坏了可复现性。因此，个性化必须是可见状态——可读取、可重置，并在合同中列明。

一个做得正确的平台会在发布个性化功能的同时发布四个配套项。第一是响应负载中的个性化字段，它标明了该层所应用的画像，并在可能的情况下标明了用于推导该画像的输入。客户无法调试他们看不见的东西；在响应中显现画像，使原本隐藏的参数成为 API 合同的核心组成部分。第二是一个明确的基准参数，客户可以在每次请求中传递该参数，以禁用个性化并返回无历史账号会收到的响应。基准模式是客户评估套件调用的模式。客户的生产流量则调用个性化路径。客户可以在自己的数据上比较这两者，并决定个性化提升在他们的工作负载中是否真实。

第三是针对每个账号或每个 Key 的开关，让客户可以针对整类流量选择退出个性化——例如对可复现性要求更高的受监管工作流、应始终表现一致的评估账号，以及确定性比质量更重要的集成测试环境。这个开关不是一种权宜之计，而是承认某些客户对他们自己的用户负有合同义务，这些义务剥夺了平台向响应中注入隐藏状态的权利。第四是个性化层输入的文档规范：它读取哪些信号，能产生哪些画像，无历史默认值是什么。该规范让客户能够构建可复现的测试固定装置（test fixture）。没有它，测试固定装置只是对变动目标的经验性拟合。

每一项都需要工程投入，而平台团队更愿意将这些精力花在下一个质量改进上。但如果平台希望企业客户像信任合同一样信任 API，而不是将其视为一种“感觉”，那么这些都不是可选的。发布了个性化功能但没有这些适配措施的平台，并没有发布质量改进。它发布的是一个捆绑了未记录行为变更的质量改进，客户会感觉到模型因为他们无法检查的原因而表现不同。从 API 的客户侧来看，这与他们无法调试的回归问题（regression）没有区别。

架构框架

这种模式在任何注入了客户无法读取的状态的平台侧增强功能中都会重复出现。推理时个性化是一个例子。根据缓存命中模式返回略有不同结果的自适应缓存是另一个。根据推断的复杂性将请求发送到不同模型变体的路由层是第三个。从总体上看，每一个都是质量改进。但每一个都破坏了客户对其自身流量行为进行推理的能力。每一个都会变成平台团队未曾预料到的技术支持工单，因为该功能并未跨越平台发布检查清单所询问的任何界限。

架构层面的认识是：API 表面是可测试性的表面，而不是功能的表面。平台可以在表面之下添加功能，只要该表面仍然暴露了客户针对平台编写回归测试所需的一切。一旦某个功能需要客户信任平台在客户看不见的输入上做正确的事情，那么无论请求 Schema 是否改变，该功能都改变了 API 合同。如果团队在发布改变合同的功能时，没有承认合同已发生变化，那么他们构建的产品最终会让企业客户提交同样的投诉升级：我们无法测试你构建的东西，我们也无法发布我们无法测试的东西。

个性化层是一个有用的功能。尊重合同的版本是在响应中命名自己、暴露基准、提供退出选项并记录其输入的版本。而隐藏的版本——因为隐藏更容易，且发布指标没有惩罚它——将每个企业账号都变成了一个由平台创造、必须由客户承担的海森堡问题。选择这些版本的正确时间是在发布前，而不是在投诉升级后。错误的时间是在随后的合同谈判之后。