AI 功能怎么定验收标准？LLM 输出不稳定，回归测试到底该卡哪个指标

背景

我做了 10 年技术产品，近两年主要在做带 LLM 的功能（一个是智能客服改写，一个是代码评审意见生成）。团队 6 人（2 后端 + 1 算法 + 2 前端 + 1 测试）。我们卡在一个很具体的工程问题上：LLM 功能到底怎么定「验收标准 / done 的定义」，以及回归测试该卡什么指标。

现象

传统功能是「输入 → 期望输出」，写死断言就行。但 LLM 功能：

• 同一句话喂进去，两次输出措辞、结构都不同（即使 temperature=0 也有抖动，不同版本模型更明显）；
• 测试同学抱怨「我没法写断言」，开发同学说「我们主观上 95% 都对，剩下 5% 是模型能力问题」；
• 上线后用户反馈「这次答得好、下次答得差」，我们很难判断到底是模型退化还是本来就这样波动。

已尝试的排查与结果

1. 建了一个「评测集」：挑了 120 条真实场景 case，人工标了「好/中/差」；
2. 试了 LLM-as-Judge（用一个更强的模型给输出打分），结果发现裁判模型自己也不稳定，同一个输出跑三次分数能差 10 分以上；
3. 把 temperature 拉到 0、固定 system prompt，重跑一遍，分数稳了一些，但我不知道该卡什么阈值——通过率 80% 算过吗？一致性（同输入多次输出相似度）要卡到多少？latency、token 成本要不要一起进验收门槛？
4. 想把它塞进 CI 做回归，但每次全量跑 120 条既慢又贵，也不知道该多久跑一次、跑多少条。

期望得到的答案形态

希望有做过类似事的同学，能给我一个可落地的框架，而不是「用 eval 框架」这种方向性建议。具体想问四点：

1. 卡哪些指标：你们验收 LLM 功能时，最终卡的是哪几个数（pass rate / 一致性 / 安全红线 / P99 时延 / 单次成本），各自设什么量级的阈值？
2. 评测集怎么维护：case 从哪来、多少条够用、怎么防止「过拟合评测集」（模型被调得在评测集上好看、线上翻车）？
3. 裁判不可信怎么办：LLM-as-Judge 抖动大，你们是加人工抽检、多次取均值，还是干脆只卡「硬规则 + 安全红线」这类可确定项？
4. 回归怎么进 CI：全量跑 vs 抽样跑怎么选，多久触发一次，怎么把「模型升级」也纳入回归（换 base model 时怎么快速判断能不能上）？

有真实数据（阈值、case 数、频率）就更好，哪怕是你踩过的坑也行。