08. 线上 A/B Test 和评测流水线应该怎么做？

简单回答

大模型系统的 A/B Test 和传统系统类似（流量分桶、控制变量、统计显著性），但评估指标更复杂——既要看技术指标（延迟、token 消耗）也要看质量指标（回答准确性、用户满意度）。评测流水线通常包括离线评测（benchmark + LLM-as-Judge）和在线评测（A/B Test + 用户反馈），两者结合使用。

详细解释

A/B Test 的设计

在大模型系统中 A/B Test 的变量通常是：不同的 Prompt 版本、不同的模型（或模型版本）、不同的 RAG 策略（chunking 方式、reranker、top_k）、不同的 context 管理策略、不同的后处理/Guardrails 规则。

分流方式通常按用户 ID 或 session ID 做 hash 分桶，确保同一个用户在整个实验期间看到的是同一个版本。如果按 request 级别随机分流，用户在同一次对话中可能体验到不同版本，无法准确评估。

评估指标

大模型 A/B Test 的指标比传统的 CTR/转化率复杂得多。技术指标包括 TTFT、TPS、总延迟、token 消耗、错误率。用户行为指标包括会话长度（用户愿意聊多久）、点赞/点踩率、重新生成（regenerate）比例、复制/引用比例。质量指标最难衡量——用户满意度不等于"用户点了赞"，有时候用户没反馈不代表满意也不代表不满意。

一个实用的做法是把用户反馈和 LLM-as-Judge 结合。对每组实验的回答抽样，用 GPT-4 等强模型做 blind review（不告诉 judge 哪个是 A 组哪个是 B 组），在准确性、有用性、流畅度等维度打分。然后把 LLM-as-Judge 的评分和用户行为指标交叉验证。

统计显著性的挑战

大模型的输出方差比传统系统大得多，同一个 Prompt 多次调用可能得到质量差异很大的回答。这意味着需要更大的样本量才能达到统计显著性。通常需要至少几千到几万个请求才能得出可信的结论。如果流量不够，可以考虑加大实验周期或用 interleaving 方法（在同一个请求中同时跑两个版本，让 judge 比较）。

评测流水线

一个完整的评测流水线通常包含：

离线评测阶段：在 Prompt 改动或模型更新后，先在一个固定的 test set 上跑自动评测。test set 应该包含各种典型场景的 case，每个 case 有预期答案或评分标准。评测指标用自动指标（Rouge、BLEU、精确匹配等）+ LLM-as-Judge。如果离线评测通过了，才进入在线实验。

灰度发布阶段：先把新版本放到 1%~5% 的流量上，观察几天。重点看错误率、Guardrails 拦截率、用户投诉等负面指标。没有异常再逐步放量。

正式 A/B Test 阶段：50% vs 50% 或其他比例的流量对比，跑一到两周，收集足够数据后做统计分析。

Prompt 迭代的实测流程

改一个 Prompt 不能靠感觉。标准流程是：准备 50~100 个代表性 test case → 跑当前版本和新版本 → 用 LLM-as-Judge 做 pairwise 比较 → 如果新版本 win rate 显著高于 50%，再上线灰度。这个流程可以用 LangSmith、Promptfoo 等工具自动化。

面试时可以这样答

大模型系统的 A/B Test 框架和传统系统类似——按用户 ID 分桶、控制变量、看统计显著性。但有两个核心差异。第一是指标更复杂，除了延迟和错误率，还要评估回答质量，这通常需要 LLM-as-Judge 配合用户反馈来做。第二是方差更大，同一个 Prompt 的输出质量波动很大，需要更大的样本量才能得出可信结论。

评测流水线我一般分三个阶段。先做离线评测——在固定的 test set 上跑自动指标和 LLM-as-Judge，过了再上线。然后灰度 1%~5% 的流量观察负面指标。最后才是正式 A/B Test 对比。

Prompt 迭代也要走这个流程。准备 50~100 个代表性 case，跑新旧版本 pairwise 比较，win rate 显著才上线。不能靠感觉改 Prompt。

常见追问

1. LLM-as-Judge 的评分和真实用户满意度的相关性怎么样？
2. A/B Test 的实验周期一般多长？怎么判断数据够了？
3. 如果两个版本在不同维度各有优劣（A 更准确但 B 更流畅），怎么决策？