LLM 应用没有线上 A/B：评测集分层采样 + 指标三件套 + 灰度验收，一套可复现的离线达标判定流程
一句话结论：LLM 应用验收扯皮的根因不是"研发嘴硬"或"业务方感性"，而是双方各自拿着一把口径不同的尺子。把"效果达标"拆成 400 条分层评测集 + 三个各司其职的指标 + 一条灰度兜底路径，验收会上的争论会从 3 小时降到 20 分钟。 本文给完整的采样 SQL、评分表模板、指标阈值表和灰度判定规则，可直接抄进你们的验收单。
一、现象与背景：一次智能摘要上线，验收会开了 3 小时没结论
先上数字。我们团队 2025 年 Q3 上线了 3 个 LLM 功能（智能摘要、对话式搜索、工单自动分类），每个功能上线前的验收会平均开 3.2 小时，来回拉锯 2~4 轮，最后 2 个功能是靠"总监拍板"过会的。
具体冲突长这样：
| 功能 | 研发口径 | 业务方口径 | 实际结果 | |---|---|---|---| | 智能摘要 | ROUGE-L 0.41，比基线 +0.06，"涨了 15%" | 抽检 20 条，6 条张冠李戴，"不能用" | 上线 2 周后使用率只有 11% | | 对话式搜索 | 内部评测集 top1 命中率 87% | demo 现场 10 个 query 错 3 个 | 演示通过，客户 POC 被驳回 | | 工单分类 | 测试集准确率 94.3% | 真实工单里 38% 是"其他"类，模型从不输出这个类 | 分类结果没法进工单系统 |
三个功能，三种"指标好看但业务不认"的翻车方式。复盘下来，根因高度一致：评测集是研发自己挑的、指标是算法同学自己选的、达标线是会上拍脑袋定的——三件事没有一件是业务方参与定义的，所以业务方没有义务认账。
二、原理：为什么 LLM 应用的"离线-线上落差"比传统 ML 更大
传统模型离线线上落差，主要是特征穿越和数据漂移（站内已有系统性记录，典型 case 是"离线 AUC 0.78 线上掉到 0.71"，根因是 point-in-time 特征穿越，见引用 [2]）。LLM 应用在此基础上多两层机制：
1. 分布错位：demo case 是"最有利分布"。 研发挑评测集时天然偏向自己能答对的 case（幸存者偏差），而线上 query 里有大量长尾：口语化、错别字、多意图混合、上下文依赖。我们拉了对话式搜索的线上日志分析，真实 query 中 62% 超过 15 个字、23% 包含指代词（"这个/它/上面那个"）、11% 是多意图串联——而内部评测集里这三项占比分别是 18% / 3% / 2%。评测集分布和线上分布差 3~7 倍，拿评测集指标外推线上，等于拿高考状元的成绩预测全班平均分。
2. LLM 输出的"不可比性"。 传统分类任务输出是离散 label，对错分明；LLM 摘要的输出是自然语言，同一个 query 生成两次措辞完全不同，ROUGE/BLEU 这类 n-gram 重合度指标对中文长文本的分数波动能到 ±0.08，而它对"张冠李戴"这类致命错误的敏感度接近零——一条编造了数字的摘要和一条完全正确的摘要，ROUGE-L 可能只差 0.03。自动指标在 LLM 场景从"验收工具"降级成了"回归哨兵"，这是理解整套方法的关键前提。
3. 没有 A/B 流量时，"显著性"失效。 这一点站内已有完整论证：分母小时比率指标的波动是二项分布的固有方差，"等显著"在小样本下是伪命题（见引用 [1]）。LLM 功能上线初期日活往往只有几十到几百，跑 A/B 攒够统计功效要几个月——所以 LLM 应用的验收必须走"离线评测集为主 + 灰度小流量兜底"的双轨制，而不是"等线上数据"。
三、具体做法：四步落地，全部可复现
第 1 步：分层采样建 400 条评测集（不是 400 条随机样本）
关键设计：按"线上 query 的真实分层"采样，而不是随机抽。 我们最终用的分布：
400 条 = 240 常规（60%）
+ 60 长尾口语/错别字/多意图（15%）
+ 40 对抗样本（10%）：诱导编造、越权提问、prompt 注入
+ 30 边界 case（7.5%）：空输入、超长输入（>8k token）、敏感词
+ 30 高频 top query（2.5%）：线上出现次数 top 30 的 query 各取 1 条
采样 SQL（从线上日志库抽，按频次分桶）：
-- 分桶 + 桶内按频次降序取，保证高频 query 100% 覆盖
WITH ranked AS (
SELECT query, category,
ROW_NUMBER() OVER (PARTITION BY bucket ORDER BY cnt DESC) AS rn
FROM (
SELECT query, category, COUNT(*) AS cnt,
CASE
WHEN LENGTH(query) > 60 THEN 'long'
WHEN cnt < 3 THEN 'longtail'
ELSE 'head'
END AS bucket
FROM llm_query_log
WHERE dt BETWEEN '2025-08-01' AND '2025-08-31'
GROUP BY query, category
) t
)
SELECT query, category, bucket
FROM ranked
WHERE (bucket = 'head' AND rn <= 30)
OR (bucket = 'long' AND rn <= 60)
OR (bucket = 'longtail' AND rn <= 150);
对抗样本单独维护，由业务方出 20 条 + 安全团队出 20 条（诱导编造数字、要求输出竞品对比、prompt 注入等），每季度更新一次。这一步最容易被省略，但它是唯一能拦住"demo 全绿、上线翻车"的机制。
第 2 步：评分表模板——把"准确性/完整性/流畅度"拆成可判定的断言
人工盲评最大的坑是评分维度太抽象，不同评审人给的权重差能到 10 个点。解法：每个维度拆成 0/1 判定的断言，评审人只勾对错，不打主观分：
【智能摘要评分卡】（每条样本 6 个断言，全过 = 1 分）
A1 无事实错误：摘要中所有数字/日期/人名与原文一致 [0/1]
A2 无编造：摘要不出现原文未提及的结论或数据 [0/1]
A3 覆盖要点：原文 top-3 关键信息（由标注人预先标出）都在 [0/1]
A4 长度合规：300±50 字 [0/1]
A5 无冗余：重复表述 ≤ 1 处 [0/1]
A6 无敏感信息泄露 [0/1]
达标线定义：单条样本 6 项全过记 1 分，4~5 过记 0.5 分，≤3 过记 0 分。功能级达标 = 400 条平均分 ≥ 0.85 且 A2（无编造）通过率 ≥ 98%。A2 单独设硬门槛，因为"编造"是 LLM 应用里唯一不可商量的红线，其他维度都可以和稀泥，编造不行。
标注口径一致性验证：拉 2 个评审人对同一批 50 条样本独立打分，κ 系数 ≥ 0.7 才允许开评（我们第一轮 κ=0.52，补了 2 轮标注规范校准后才到 0.78）。
第 3 步：指标三件套——各司其职，不混用
| 指标 | 角色 | 用法 | 阈值 | |---|---|---|---| | 自动指标（ROUGE-L / 分类准确率） | 回归哨兵 | 每次发版前跑，只判"是否变差"，不判"是否达标" | 相对上一版 ≥ 0，否则阻断发布 | | 人工评分卡（上表） | 达标判定 | 版本验收时跑 400 条 | 均分 ≥ 0.85 且 A2 ≥ 98% | | 线上灰度数据 | 兜底验证 | 灰度 5% 流量 × 7 天 | 见第 4 步 |
为什么自动指标只做哨兵不做验收？ 我们测过：摘要质量从"张冠李戴"改善到"基本准确"，ROUGE-L 只从 0.38 涨到 0.41；而一次 prompt 改写让摘要更流畅但引入 2 条编造，ROUGE-L 反而涨了 0.02。自动指标和业务体感的相关性在我们场景里只有 0.31（4 轮验收数据做的 Pearson 相关），这个数值得你们在自己场景里测一遍。
第 4 步：灰度 5% × 7 天的兜底判定
离线全绿不等于线上能用（见引用 [2] 的离线-线上落差教训），但也没有流量跑 A/B（见引用 [1] 的小样本论证），所以灰度的定位是**"否决权"而不是"证明权"**——只判"有没有明显变差"，不判"显著变好"：
灰度 5% 流量 × 7 天，看 3 个信号（任一触发即回滚）：
S1 负反馈率：点"没用/重新生成"占比 > 基线 + 5pp
S2 人工介入率：生成后用户 10 秒内手动改写/删除占比 > 基线 + 8pp
S3 P0 事故：编造内容被用户截图反馈 ≥ 2 次
关键设计：不设"显著变好"的门槛。 小样本下"显著"不存在（引用 [1] 的核心结论），所以灰度只回答"能不能上"，不回答"上得值不值"——后者交给 30 天后的使用率复盘。
四、踩过的坑（反直觉的 4 个）
- "评测集越大越好"是错觉。 我们把评测集从 200 条扩到 800 条，验收耗时从 2 天涨到 6 天，但拦截到的问题 80% 集中在前 400 条里——因为评测集按分层设计后，覆盖度比数量重要。800 条里有 300 条是同分布重复，信息量为零。
- LLM-as-Judge 能省人工，但只能评"流畅度"类维度。 我们试过用 GPT-4 当评审替代人工评分卡：A4/A5（长度/冗余）判断和人工一致率 94%，但 A1（事实错误）一致率只有 61%——judge 模型自己也会漏掉编造。红线维度必须人工，软性维度可以交给 judge。
- 对抗样本放评测集末尾会漏测。 我们最初按"常规→长尾→对抗"的顺序跑，研发看到前 350 条全绿就停掉了后 50 条，结果上线第一周就吃了一个 prompt 注入。对抗样本必须混在随机位置跑，且单独出报告。
- 验收会上的指标要"业务方能复算"。 我们第一次验收会展示"综合质量分 87.3"，业务方当场问"87.3 怎么算的"，答不上来，后面所有争论都变成了对这个数字的质疑。改成"400 条里 341 条全过、39 条过 4 项、20 条不及格，编造 3 条"之后，争论立刻聚焦到了"这 20 条到底算不算错"——这才是能讨论的问题。
五、结论与可复用清单
把"效果达标"拆成三件事，每件都有明确 owner 和可复算的口径：
□ 评测集（400 条分层）：业务方出分布、研发出采样脚本、安全出对抗集
□ 评分卡（6 断言 + 硬门槛）：全过率 ≥ 85% 且编造率 ≤ 2%
□ 灰度否决权（5% × 7 天）：3 个信号任一触发即回滚，不追"显著"
验收会纪律：
□ 只展示业务方能复算的数字（条数/通过率），不展示综合分
□ 对抗样本单独出报告，不混进大盘指标
□ 自动指标只做回归哨兵，不进验收结论
□ 未达线项逐条过，不讨论"综合来看"
这套东西的本质不是"更科学的评测"，而是把验收从"两个立场的争论"变成"对同一份清单的逐条核对"——扯皮从来不是因为双方智商不够，而是因为双方手里的尺子不是一根。
引用：[1] 沈若衡-956《B 端 SaaS 样本量跑不够 A/B：从"拍脑袋全量"到贝叶斯决策 + 序贯停止的 4 场景实战》；[2] 许亦舟-370《离线 AUC 0.78 线上掉到 0.71：特征穿越与时间窗错位导致的离线-线上落差排查全记录》。