一步步设计
先写人工标签与业务动作
虚构消息：“扣款失败了，但我也想取消下月续费。”可能同时涉及账单与取消意图。先明确应用要求单一主队列还是多标签；若只能选主队列，标注规则必须规定优先级，允许标注者给出歧义样本。模型一致不能修复错误的任务定义。
把三个量分开记录
Choice 的选项概率、confidence 与多次调用标签一致率不是同一个量。Noul 没有 confidence 字段，只记录陈述为真的概率及问题方向。若问题问“存在风险”，高 noul 应触发警惕；不能把所有高值都解释成允许执行。
固定输入后再观察波动
先在完全相同的 state、问题、模型版本和策略下重复；再单独做措辞或无关字段变化实验。不要一边更换输入，一边声称是在测相同请求的随机性。保留每次返回的完整分布、失败状态和耗时，缓存重放也必须标记。
先设计弃权，再考虑追加调用
本例可以把不明确的工单交人工，或者先问清是否要停止续费。多次投票只是候选策略；几个判断可能共享同一种偏差。只有在独立验证集证明追加判断改善错误和费用的取舍后，才考虑对临界样本增加调用，并设置次数上限。
同时公布正确率与自动覆盖率
虚构三次标签 billing、billing、cancel，只说明本样本多数标签为 billing，不说明真实答案就是 billing。用未用于调阈值的测试集检查自动执行部分的错误率、全量覆盖率和人工负担；分别报告语言、主队列和歧义输入，不只挑稳定案例。
完整走查 · 本站虚构样本
| 观察到什么 | 如何判断 | 代码怎么处理 |
|---|---|---|
| 三次都选 billing，但人工规则应选 cancel | 一致率100%，仍可能全错 | 保留错例并修订任务或问题 |
| billing、billing、cancel | 多数不构成新事实 | 按弃权规则复核，不直接取消 |
| 风险陈述 noul 很高 | 是风险概率，非执行许可 | 进入相应风险处理分支 |
可复制的设计草案
以下为本站原创示例。JSON 展示请求或输入形状；Python 仅计算虚构分数，不调用 API。真实接入仍需核对官方接口及任务策略。
# Offline example: invented labels, not API results.
from collections import Counter
labels = ["billing", "billing", "cancel"]
majority, count = Counter(labels).most_common(1)[0]
print(majority, count / len(labels))
# Agreement alone does not establish accuracy.
review_required = len(set(labels)) > 1
print("review:", review_required)容易踩的坑
- 把重复一致率当正确率。
- 把最高选项概率直接当 confidence。
- 不断重问直到出现想要的答案。
TRY / THINK / COMPARE
先想一想，再看解析
同一个输入五次结果相同，能宣布系统可靠了吗？
展开解析
不能。只观察了一个输入的五次结果，还没有人工真值、多样输入或独立测试。先报告条件与样本规模，再验证错误和回退策略。
交付前检查
- 标签规则和歧义处理已写明。
- 每次分布、版本与缓存状态都有记录。
- 调用次数有预算上限。
- 测试集没有用于选择阈值。
常见问题
重复调用一定提升准确率吗？
没有保证。要检验是否修复错误，而不只是减少标签变化。
弃权是不是失败？
它是可设计的结果；需要连同覆盖率和人工负担一起评估。
资料与延伸阅读
参考官方架构模式与 Datawhale 实战主题，本站独立编写讲解、案例与练习。示例为教学设计，未调用 API，不代表性能测试。