质量阈值
这是你愿意接受的最低质量分。低于这个阈值，说明回答效果还不够稳。
当前阈值
80
Evals：评测与回归验证
大模型系统最容易出现的错觉之一，是“我刚试了几个例子，看起来变好了”。真正可靠的工程流程不会只靠感觉，而会用评测集、阈值和版本对比去持续验证：这次修改到底提升了什么，又有没有把别的地方弄坏。
先定义指标
再跑版本对比
最后设门槛防回归
切换评测集，看看“通过”是怎么判定的
先选任务类型，再调整阈值。页面会即时判断哪些版本能过线，哪些虽然某项更高，但整体并不满足上线条件。
为什么 Demo 试用不能替代 Evals
样本太少
你手工试的几个例子很可能碰巧都是模型擅长的，无法覆盖真实线上分布。
容易偏向“惊艳案例”
人类很容易记住几个很亮眼的成功输出，却忽略那些频率不高但代价很大的错误。
没有统一门槛
如果没有预设阈值，团队每次都会陷入“我觉得可以”“我觉得还不稳”的争论。
无法发现回归
一次改动可能提高了一个场景，却悄悄让另一个场景退化。没有回归测试很难及时察觉。
一个实用的评测闭环
1
定义任务与指标
先说清楚到底要评什么，是正确率、引用质量、安全拒答还是延迟成本。
2
准备基准集
收集覆盖真实场景的数据，避免只看少量漂亮样例。
3
版本对比
每次修改都和基线版本比，不只看“有没有变好”，还看“有没有变坏”。
4
设门槛拦截
让关键指标达不到阈值时自动拦住，避免问题版本直接进入线上。
一句话总结： Evals 的价值，不只是告诉你“哪个版本更好”，更是把“上线靠感觉”变成“上线有证据、有门槛、有回归保护”。