22 · 评分器、可靠性与统计口径
用代码检查硬条件，用人工校准主观评分。
本站原创入门导读与合成教学示例。原始资料核实：2026-09-05。建议先读：21 · 建立 Agent 评估集。
理解概念
代码评分适合 JSON 结构、数值边界、文件存在与测试通过；模型评分适合开放文本，但可能偏好长度、措辞或自己的风格；人工评分适合校准复杂边界。先写评分标准和几个锚定样例，再让不同评分者交叉检查。
区分“多次尝试中至少成功一次”与“每次都成功”。前者衡量探索能力，后者更接近可依赖性。还应同时报告费用、延迟、越权与失败率，不能用一个平均总分掩盖严重错误。少量样本只适合发现问题，结论应保留不确定性。
一个最小例子
代码
# 每个任务重复三次，1 表示满足全部硬条件
runs = {"A": [1, 1, 1], "B": [1, 0, 0], "C": [0, 0, 0]}
at_least_once = sum(any(v) for v in runs.values()) / len(runs)
every_time = sum(all(v) for v in runs.values()) / len(runs)
print(round(at_least_once, 2), round(every_time, 2))
动手练习
先手算，再运行例子。为一个开放答案写 0、1、2 分评分锚点，找同学独立评分两次，记录分歧而不直接平均掉。
验收与预期结果
输出约 0.67 与 0.33，能解释两者含义。关键越权作为单独硬失败，不被文风高分抵消。
- 我能解释输入、过程与结果。
- 我保留了一个失败例与运行记录。
常见误区
模型评委也需要测试，尤其是面对诱导它打高分的答案。不要让被评对象自由改动评分标准。
延伸阅读
以下是相关方向的原始资料；本站练习不是官方课程作业或逐字翻译。
理解需要时间，记录让每一步都有迹可循。
回到学习路线图