CI里的忠实度检测怎么变成了随机抽奖机

在CI流水线里加了个 faithfulness gate 守门，硬性规定分数低于 0.8 就挂掉。结果昨天测试跑出个 0.79，我心想代码也没动啊，代码环境崩了？结果重跑了一遍，嘿，居然变 0.82 了。连着跑三次，分数像在玩蹦迪一样，一会儿 0.82 一会儿 0.80（这随机性真的让人想当场退学）。

如果测试结果全看运气，大家最后肯定都会演变成“只要报错就疯狂点重跑，直到变绿为止”的玄学派。我复盘了一下，这坑踩得挺有代表性：首先是 Temperature 没设为 0，很多 SDK 默认带采样随机性；其次是模型版本（比如用那种带 alias 的模型）会被厂商偷偷更新，导致评分标准变了；还有就是 Prompt 写的太模糊，没给明确的分数锚点，模型每次理解的“尺度”都不一样。

为了不让测试沦为摆设，我总结了几招应对这种“人格分裂”的方法：

1. 模型版本必须锁死：别用那种模糊的 alias，直接指名道姓用带日期的具体版本，Prompt 也要像代码一样进 Git 版本管理（别让它在 Prompt 里乱飞）。
2. 强制降噪：Temperature 必须调到 0，如果模型支持 Seed 尽量带上。
3. 用统计学降维打击：别盯着单次评分看，直接跑 k 次取平均值。如果分数在阈值附近反复横跳，干脆做个量化（Quantize），比如按 0.25 的步长取整，把那种微小的噪音直接抹平。

归根结底，咱们得把 LLM 给出的分数当成一种带噪声的观测值，而不是绝对真理。判断逻辑应该基于均值和标准差，而不是盯着那个跳动的临界点死磕（毕竟我们没法让模型变得像数学公式一样严谨）。