我最近接触的一个产品团队针对回复人格设定（简洁、详尽、对话式）进行了一项为期三周的 A/B 测试，覆盖了所有用户群组。系统提示词描述了这三种设定，并要求模型选择最匹配用户的那一种。当他们打开数据集编写分析报告时，一个数字让他们愣住了：“详尽”组占据了 91% 的流量。另外两组的比例小到几乎可以忽略不计。
他们的实验平台没有标记任何异常。没有触发任何警报。流水线完全按照他们的指令运行。三周所谓的“多人格测试”产生了一个只能告诉他们关于“详尽”信息的数据集。另外两组样本太少，根本无法进行任何统计推断。
房间里的第一直觉是提示词需要改进——更好的指令、更清晰的人格区分、为对话式场景提供更刻意的示例。如果是在十年前基于规则的路由器中，这个诊断是正确的。但对于模型来说，它是错误的。提示词不是变量，路由器才是。
当模型充当随机分配器时，它并不随机
如果你读过关于因果推断的论文，你就会知道 A/B 测试的金科玉律：实验组分配必须独立于实验单元。你必须在你正在衡量的系统之外掷硬币。一旦你让你正在衡量的系统参与掷硬币，硬币就不再公平了，你认为你正在进行的对比实验就不是你实际进行的对比。
要求语言模型选择一个人格设定正是违反了这一规则。模型不是硬币。它是一个高维函数，其对自己行为的先验是由数以 TB 计的训练数据塑造的。当你写下“根据用户选择简洁、详尽或对话式”时，你并不是在委托一个随机过程。你是在顺从一个在你的产品诞生前几个月就已经定型的学习偏好。
关于这一点的文献研究并不晦涩。LLM 输出中的冗长偏差（Verbosity bias）在不同模型家族和训练方案中都有记录——RLHF、DPO 以及对长思维链（chain-of-thought）轨迹的监督微调都强化了模型趋向于更长、更详尽回复的倾向，通常不考虑增加的长度是否真的提高了质量。根据任务和提示词的不同，冗长补偿（Verbosity compensation）的频率在 13.6% 到 74% 之间，即使提示词明确要求简洁，这种模式依然存在。模型对输出长度的先验并不弱。在许多生产环境中，它是房间里最强烈的信号。
因此，当你的系统提示词提供三个设定作为自由选择时，模型并没有在运行你的实验。它是在对自己的训练偏好进行一项观察性研究，并像这是用户要求的反馈一样汇报结果。
为什么你的实验平台没有察觉
故事中最令人不安的部分不是不平衡的发生，而是在一个理论上配备了检测手段的平台中，这种不平衡竟然连续三周未被发现。
样本比例失调（Sample Ratio Mismatch，简称 SRM）检测是防止这种失效模式的标准护栏。针对预期分配进行的卡方检验（chi-squared test）会在累积流量上持续运行，并拒绝为分配偏差超过合理阈值的实验评分。SRM 检测器并不罕见；它们内置在每一个现代实验平台中，建议的显著性阈值通常设定在 p < 0.01 左右。
检测器没有触发的原因很简单。平台监控的是用户被分配 到的组别，而不是模型选择 的组别。从平台的角度来看，进入实验的每个用户都被分配到了一个单一的“人格路由”处理中，而最终产生的设定被视为模型回复的一个属性，而不是实验分配的一个属性。真正起作用的随机分配器（模型）位于平台监控的随机分配器的下游。
这就是结构性的教训。只有当 SRM 检测正在检查的分配正是驱动对比的分配时，它才有效。如果实验的有效组别是在平台随机分配器下游的一个不透明函数内部确定的，那么从结构上讲，SRM 是无法察觉的。平台没有坏。它只是对一个从未被问及的问题保持了正确的沉默。
架构修复：在模型外部进行路由
最干净的修复方案也是最乏味的。人格设定分配应该由你的应用程序在调用模型之前，使用平台的随机分配器来执行。选定的人格设定随后作为模型必须服从的参数传递到系统提示词中，而不是作为一个供其选择的菜单。
在实践中，区别如下。错误的写法是系统提示词说：“根据用户的明显偏好，选择简洁、详尽或对话式。” 正确的写法是系统提示词说：“请以 {persona} 人格进行回复。定义：{definition}。” 人格变量由负责分配产品中所有其他实验组的同一个路由器填充。
这把决定权推到了模型之外，随之而来的是三个自动产生的结果。首先，实验平台的 SRM 检测器现在监控的是它一向擅长监控的分配，任何分配偏差都会像其他 A/B 测试一样触发警报。其次，你的统计功效计算（power calculation）变得真实可靠，因为各组的比例保证会按照你指定的比例填充。第三，你的事后分析是在对比你声称要对比的东西，而不是在衡量模型偏好的同时叠加了用户测量值的噪点。
一个自然的反对意见是：模型外路由失去了让模型使用路由器无法看到的上下文的表面好处。只有当你已经诚实地完成了实验后，这个反对意见才值得认真对待。如果你通过平衡的组别发现某一个人格设定在质量上占主导地位，你可以构建一个确定性的路由器，根据可观察的用户特征做出选择。如果你发现模型的选择确实优于你的路由器，你可以将模型作为路由器发布，但你要意识到你发布的是一个观察系统，而不是一个经过测试的系统。无论如何，你都拥有了证据。你无法同时拥有受控实验和模型选择的处理。
在模型侧分支上进行强反馈的平衡审计 在模型外部进行路由是结构性的修复方案。而技术手段上的修复是在每一个由模型（而非你的平台）决定的分支上添加平衡审计（Balance Audit）。这些审计并不能取代 SRM 检测，而是与其并存，监控平台视角结束与模型视角开始之间的衔接处。
一个有效的平衡审计如下所示：对于任何值是从模型输出中解析出来的用户可见分支——如人设、语气、语言、工具选择、拒绝与回答的判断、引用的检索源选择——应用程序都会将该分支值作为结构化事件发送。该事件上的监控器会计算滑动窗口内的经验分布，并当分布超出预期分布的可调包络区间时发出警报。该区间应足够宽以容忍季节性偏移，同时又要足够窄，以便在几天（而非几周）内捕捉到失效的分支。
这类审计最难的部分是确定预期分布。对于新上线的功能，你并没有现成的分布。解决方法是在将分支视为实验性分支之前，先在一个基准窗口期内进行无条件记录，然后由明确的负责人将观察到的分布提升为预期分布。开始时选择较宽的容差，随着信心的积累逐步收窄，并将对预期分布的任何更改视为像配置更改一样需要评审的深思熟虑的决定。随后，该审计将捕捉到导致人设坍塌的 Bug，以及其他六个你尚未发现的 Bug，因为每个模型侧分支都是一个平台并不知道其存在的随机发生器。
管理层维度的论点 这个案例在组织内部引发的讨论通常不是技术性的，而是关于实验的目的究竟是什么。
如果 A/B 测试的目的是建立因果效应——即在用户相同的情况下，某个人设能带来多少留存率的提升——那么模型就不能参与分配。让模型代理变量的结果，从本质上讲，是把一项关于模型偏好的观察性研究，以随机对照试验的格式呈现出来。这种呈现方式才是问题所在。团队处理实验报告的方式与处理观察性研究报告的方式截然不同，而这两者之间的差距正是错误决策滋生的地方。
资深工程师或产品经理可以用三句话将这个论点带入规划会议。首先，任何值由模型决定的分支都不是实验的分支，它是模型的输出，而平台无法察觉其中的区别。其次，模型对其自身行为做出的任何决定都受其训练数据先验知识的支配，这种力量比系统提示词中的任何单个句子都强大。第三，真正实验的规则是：随机发生器必须存在于你平台所属的代码中，而不是碰巧包含在你的提示词句子中。
推论，也是更难提出的论点是：一些团队会发现，他们在生产环境中表现最好的变体从始至终都是模型首选的那一个。诚实的反应不应该是宣布实验成功，而是应当认识到，这种看起来聪明的授权实际上是一次错失的测量，并应在随机发生器归位的情况下重新进行实验。模型的偏好可能是正确答案，但在你真正提出问题之前，你是不会知道的。
下周一可以落地到代码库的行动项 从上述论点中可以总结出一份简短的清单：
审计生产环境中的每一项 A/B 测试，寻找那些值是从模型输出中解析出来的分支。它们中的每一个都有可能出现同样的失败模式。
将人设、语气、语言及任何其他与实验相关的分配移动到模型调用之前的确定性路由器中，并将结果作为模型必须遵守的参数传递到提示词中。
在你无法或不愿绕过的每一个剩余模型侧分支上添加平衡审计，并配备明确的预期分布和负责人。
将 SRM 检测专门视为对平台随机发生器的检查，而不是实验在下游结构良好的保证。
当平衡审计触发时，不要通过放宽包络区间来消除它。要像对待 SRM 警报一样对待它：停止实验，找到分配衔接处，要么将其移入你的控制之下，要么记录下为什么分支失效是可以接受的。
更深层的启示是，LLM 产品中的 A/B 测试表面上看起来与任何其他产品中的 A/B 测试相似，但实则不然。模型是一个你的平台无法察觉的下游随机发生器，其分布受早于你路线图的训练数据影响，且其参与的任何决策都会在不标记替换的情况下，将受控实验转变为观察性研究。做对这一点的团队并不是那些拥有最好提示词的团队。而是那些认识到模型是一个待测量的组件而非可以咨询的同事，并将随机发生器保留在平台仍能发挥作用的代码中的团队。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
