群体感知微调：当单一模型不够，而针对每个用户的微调又负担过重时

我在上个季度交谈过的一个团队发布了一个微调模型，该模型在内部评估中比基础模型高出 4 分，但在接下来的 6 周内，他们却眼睁睁地看着排名前三的客户流失。评估结果没问题。聚合指标没问题。微调模型只是恰好在中位数用户（即询问简短事实性问题的小型企业买家）身上表现出色，而在企业法律客群中悄悄退化了，而后者那些长篇、包含大量引证的查询才是真正的营收驱动力。没有人按照客户等级对评估进行切片分析，因为建模端的人并不知道客户等级至关重要。

大多数关于微调的讨论都处于两个极端之一。一端是“一个微调统治所有”的方法，它在所有客户数据的混合体上训练单个专业化模型，并冲刷掉了原本在基础模型中区分各细分市场的特定客群行为。另一端是“单客户微调”方法，它为每个租户训练一个单独的适配器（adapter），这在客户数量少于 100 个时在运维上是可以忍受的，但在达到几百个左右时就会崩溃。一个有趣的中间地带——由少数几个客群感知微调模型来服务细分的客群——在大多数生产实践手册中是缺失的。

这个中间地带才是真正的工程工作所在。客群感知微调将微调视为一种披着模型决策外衣的细分决策。你实际上并不是在问“我应该在什么数据上进行训练”——你是在问“这个模型是为谁而存在的，以及有多少个不同的‘谁’”。不先问第二个问题的团队，最终会针对一个无法代表任何真实客户的聚合分布进行训练。

聚合与单用户之间缺失的中间环节

极端情况占据主导地位的原因是，每种情况都有一个简洁的故障模式，在设计文档中很容易自圆其说。单一微调对所有人都会以同样的方式失败，这感觉很公平。单租户微调完美地隔离了爆炸半径，这感觉很安全。两者都忽略了生产流量几乎从未有过平坦的分布。通常有 3 到 8 个起关键作用的集群，它们中表现最好和最差之间的差距大到足以让整体平均值丢失大部分信号。

典型的症状是评估分数提高了，但满意度（CSAT）或留存率指标却持平甚至变差。这就是从外部观察到的客群退化现象。模型在大部分流量上胜出（这正是评估采样最密集的地方），却在长尾部分落败，而评估中这一部分的占比与其营收权重并不相符。聚合指标掩盖了稀有子群体上的严重失败，而你业务中的稀有子群体通常正是高营收的群体。

单客户微调从定义上解决了这个问题，但运维成本是极其惨重的。你每入驻一个客户，就多了一个需要永久维护的训练流水线。每一次基础模型升级都会变成 N 个重新训练任务。每一次回归都会变成 N 次调查。客群感知微调能以较小的固定成本为你带来大部分细分收益。

寻找合适的客群数量

第一个决策是你实际上拥有多少个客群。太少的话，你就会带着额外的步骤回到聚合指标的问题上。太多的话，你就在假装自己没有在做单用户微调，而实际上却是在趋近它。对于大多数产品来说，有用的答案在 3 到 8 个之间。

定义客群边界的实际信号：

• 行业垂直领域 —— 法律、医疗、金融、零售。词汇、引用期望和风险承受能力的差异大到单一模型无法很好地兼顾。
• 账户等级 —— 免费版、专业版、企业版。每个等级的查询分布是真正的不同，而不仅仅是规模更大。
• 语言区域 —— 即使都在“模型会说英语”的范畴内，英国法律英语和美国技术英语对同一个提示词的要求也不同。
• 任务类型 —— 摘要 vs. 提取 vs. 开放式生成。这些因素对行为的驱动作用往往超过了客户身份。
• 交互模式 —— 单次 API 调用用户 vs. 智能体（agent）工作流 vs. 交互式聊天。工具使用密度和轮次计数改变了“优质生成内容”的定义。

正确的客群轴并不总是产品营销所使用的那一个。营销细分通常是区分客户如何购买的客群，而不是他们如何使用产品的客群。对微调至关重要的客群是那些能区分客户如何向模型提问的客群。对生产流量进行客群识别，基于提示词嵌入（prompt embeddings）和响应分布而非账户元数据进行聚类，几乎总能改变至少一个边界。

你最终可能会得到少数几个重叠的轴——例如“垂直领域 × 等级”——你必须决定是对它们进行交叉组合（8 个客群）还是选择主轴（4 个客群）。除非你有明确的理由不这样做，否则请选择主轴。客群数量增加带来的运维成本增长速度远快于其带来的质量提升速度。

在训练任何模型之前先对评估进行切片

最重要的一条准则是在你开始训练群体感知 (cohort-aware) 模型之前，而不是之后，就对评估 (eval) 进行切片。如果你目前的评估只是一个单一的数值，并且你无法按群体拆解并复现其得分，那么你就无法判断群体感知微调是否真的胜出。你只能看到平均值是否发生了变化。

在实践中，按群体进行的评估切片意味着三件事。首先，评估集中的每个示例都标有其所属群体，评估报告会显示每个群体的得分以及聚合得分。其次，评估集的群体构成被作为一个独立的属性进行跟踪——如果你 70% 的评估数据属于同一个群体，那么聚合得分主要反映的就是该群体的得分。第三，任何单一群体的回归 (regression) 都会独立于聚合结果阻止发布。如果一个模型在整体上提升了两点，但在企业群体上损失了三点，那么该模型就不会发布。

跳过这一步的团队几乎总是会以惨痛的方式重新认识到它的重要性。他们发布了一个群体感知微调模型，聚合指标上升了，随后客户发起了投诉。在投诉发生后，有人对数据进行了切片，结果发现群体回归在离线评估中一直清晰可见——只是当时没有切片能让它暴露出来。

请求时的路由

一旦你拥有了 N 个群体微调模型，你就需要决定由哪一个来处理给定的请求。这个问题的真实版本比大多数架构图所展示的要困难得多，因为路由层决定了用户会遇到哪个模型的优缺点，而错误的路由与模型本身的回归是无法区分的。

生产环境中出现了三种路由策略：

• 元数据路由 (Metadata routing) —— 根据请求信封中的账户等级、语言或垂直行业进行路由。当群体维度确实属于提示词 (prompt) 之外的外部因素时，这种方式成本低、具有确定性且准确。
• 语义路由 (Semantic routing) —— 对提示词进行嵌入 (embed)，并路由到质心最近的群体。当群体是按任务或交互模式而非账户属性定义时，这种方式非常有用。
• 分类器路由 (Classifier routing) —— 由一个专门的小型分类器（或 LLM 调用）来挑选群体。这种方式最灵活，成本最高，并且增加了一个故障模式：如果分类器出错，你会归咎于群体微调模型。

大多数生产系统最终会采用分层方法：元数据路由处理简单的 80%，语义或分类器路由处理其余部分，当群体确实存在歧义时，通过置信度阈值回退 (fallback) 到基础模型。回退机制是团队最容易忽略且事后后悔的部分。如果一个分类器被迫对一个它不确定的群体做出承诺，它会将对抗性或分布外 (out-of-distribution) 的提示词路由到恰好最接近的微调模型，而该微调模型会给出自信的错误答案，因为它是在更窄的分布上训练的。基础模型的回退为长尾情况提供了一个合理的默认选择。

目前，这类服务的架构已经非常成熟。多 LoRA 服务系统可以将基础模型保留在 GPU 显存中，并按请求切换适配器权重，适配器切换的成本相对于推理成本而言非常小。像 S-LoRA 这样的生产系统可以从单个基础模型并发服务数千个适配器，而像 vLLM 的 LoRA 支持和 SageMaker 的多适配器推理等专用框架，使得这成为了一个配置决策，而非研究项目。群体数量的上限取决于你的评估和运维能力，而不是 GPU 能容纳多少个适配器。

每个群体的持续训练

群体偏移是相互独立的。当法院裁决改变了从业者询问引用问题的方式时，法律群体的分布就会发生变化。当客户导入新的 SKU 词汇表时，零售群体的分布就会发生变化。每当市场部门开展活动改变注册用户构成时，免费层级群体的分布就会发生变化。将所有群体视为一个共同训练的单一训练语料库，意味着每个群体都要承受其他群体波动带来的影响。

正确的做法是建立一个按群体的训练流水线，根据各自的时间表对每个群体微调模型进行重新训练，并由各自的评估切片进行门控。有些群体可以稳定数个季度；有些则需要每月重新训练。将它们耦合在一起是一种得不偿失的节约——你虽然节省了流水线上的工程精力，但付出的代价要么是微调模型陈旧，要么是对不需要重新训练的群体进行了不必要的重训练。

这也将基础模型的升级从一场 N 倍的灾难转变为有序的滚动发布。当基础模型发生变化时，各个群体可以独立进行重新微调和重新验证。分布最稳定的群体先进行；评估最不稳定的群体最后进行并接受额外审查。对客户可见的升级受限于最慢的群体，但工程工作是可以并行的。

归因：证明提升是真实的

群体感知微调最困难的部分是证明群体感知版本确实胜出，而不是以不同的方式平均了相同的总分。聚合评估不会告诉你这一点。一个在群体 A 上赢了三点、在群体 B 上输了一点、在群体 C 上毫无斩获的模型，在聚合指标上看起来与在三个群体上均等提升的模型是一样的，但第一个模型是在做实事，而第二个模型只是增加了方差。

真正重要的归因模型是相对于聚合基准的按群体胜率。对于每个群体，问题在于特定群体的微调是否既击败了之前的群体微调（重新训练是否值得），又击败了聚合的“一个微调适配所有”模型（群体方法是否值得其运维成本）。如果群体感知版本在为其训练的群体上没有击败聚合基准，那么该群体就不值得进行微调。将其合并回基础模型或与邻近群体合并。

这也是捕获高收益群体回归故障模式的地方。只跟踪聚合评估的团队会发布一个改善了中位数但悄悄损害了长尾的模型。而跟踪按群体胜出的团队会在客户在生产环境中发现回归之前，就在离线指标中看到它。

微调是一个细分决策

让感知群组的微调（cohort-aware fine-tuning）奏效的架构领悟是：模型决策和细分决策其实是同一个决策。“我应该用什么数据进行训练”和“这个模型是为谁而存在的”是一个问题的两种表述，而先回答第二个问题会改变下游的一切 —— 评估设计、路由层、重训练节奏以及归因模型，都取决于群组的定义。

能够处理好这一点的团队最终会得到少量的微调模型 —— 通常是三到六个 —— 他们可以为这些模型命名、证明其合理性并进行运维。群组轴对产品、工程和客户成功部门来说都是清晰可见的。评估切片与路由层的形状一致。训练流水线根据每个群组的漂移（drift）情况，按相应的计划对其实施重训练。聚合指标虽然存在，但不会据此做出任何决策。

没处理好这一点的团队最终只能在两种方案间做选择：一种是单一的微调模型，这会让最优质的客户感到失望；另一种是针对每个租户（per-tenant）的微调模型，这会耗尽他们的 MLOps 预算。杠杆作用存在于中间地带，而这要求预先承认存在不同类型的用户，这些类型至关重要，并且模型策略必须遵循客户策略，而不是领先于客户策略。

下次有人提议进行微调时，第一个要问的问题不是“用什么数据”，而是“为谁而做”。如果答案是“为了所有人”，那么微调可能不是合适的工具。如果答案是“为了客户 X”，那么你的运维未来将变得昂贵。如果答案是“为了这三四种使用场景”，那么你可能处于针对群组的中间地带，而这正是真正能产生回报的工作所在。