选模型之前，先做一份任务评测集

选模型是在选择一个组件能否承担你的任务，不是在选一张榜单的冠军。任务不同，允许的延迟、失败代价和输出要求也会不同。

先写清“怎样算完成”，再比较模型。否则模型回答得更长、更像专家，都可能被误认为效果更好。

用任务定义成功

例如从公开说明中提取产品名称，成功标准可以包括字段完整、没有编造名称、无法找到时返回明确状态。对于工具操作，还要检查是否选择了允许的工具。

评测集应包含正常输入、信息缺失、歧义、超长内容以及不可信指令。每个样本都保留预期结果或评分规则，并记录其来源类别。

不要在公开评测样例里放账号、客户资料和内部文档。可以使用公开内容或人工构造的数据，再用受控的内部流程检查真实分布。

固定变量，再重复运行

比较时固定任务规则、检索资料和输出契约。记录模型版本、关键参数与运行时间。同一个输入可以运行多次，以观察稳定性，不能只挑一次成功答案。

质量评分需要能解释。格式有效率、事实支持、任务完成率与不该行动时的停止能力，通常比一个没有定义的“综合分”更有帮助。

用教学数据生成报告

下面的数字完全是教学数据。例子只演示如何汇总结果与失败样本，不能据此判断任何真实模型的能力。

from statistics import median

runs = [
    {"case": "clear-input", "passed": True, "latency_ms": 220},
    {"case": "missing-evidence", "passed": False, "latency_ms": 180},
    {"case": "untrusted-text", "passed": True, "latency_ms": 310},
]
report = {
    "pass_rate": sum(r["passed"] for r in runs) / len(runs),
    "median_latency_ms": median(r["latency_ms"] for r in runs),
    "failed_cases": [r["case"] for r in runs if not r["passed"]],
}
assert report["failed_cases"] == ["missing-evidence"]
assert report["median_latency_ms"] == 220
print(report)

真实评测还应记录按任务类型分组的结果，以及超时、拒绝、字段错误等失败原因。不同类型的错误，不应全部压成同一个数字。

把质量、时间和成本一起看

先排除无法达到最低质量要求的候选，再看耗时和成本。一个平均表现不错、却在危险操作上经常越界的模型，不一定适合负责行动。

成本不仅包含单次推理，也包括检索、工具、重试和人工处理失败的投入。具体价格会变化，不要把一次估算长期当成固定事实。

评测概念可以在本地实现，不依赖某个托管评测服务。使用第三方平台前，检查它的当前生命周期与文档，避免把可迁移的评分规则绑死在单一服务上。

下一步

选择十个能代表你当前任务的公开或构造样本，写清评分规则。加入至少一个无答案用例和一个诱导越权用例。

先手动检查失败样本，再决定需要换模型、改提示词，还是修正任务拆分。每次改动后，用同一套样本回归，并持续补充新发现的失败。