任务契约、示例与失败状态

“总结得好一点”无法判定成功；“从提供的工单中抽取问题类别，缺失时返回unknown，不推断客户身份”则能测试。任务契约包含输入来源、允许的操作、输出字段、成功标准和不能完成时的状态。

系统或开发者规则定义稳定边界，用户消息提供具体任务，检索资料属于不可信数据。不同平台的角色接口有差异，不能把字符串写成“system:”就认为获得真实消息优先级。标签有助于组织，权限仍由应用执行。

import json
labels = {'billing', 'technical', 'unknown'}
def validate(raw):
    value = json.loads(raw)
    if not isinstance(value, dict) or set(value) != {'label','evidence'}:
        raise ValueError('fields')
    if value['label'] not in labels or not isinstance(value['evidence'], str):
        raise ValueError('types')
    if value['label'] != 'unknown' and not value['evidence'].strip():
        raise ValueError('missing evidence')
    return value
assert validate('{"label":"unknown","evidence":""}')['label'] == 'unknown'
try:
    validate('{"label":"billing","evidence":""}')
except ValueError:
    pass
else:
    raise AssertionError('unsupported decision accepted')
print('contract passed')

这验证了字段和值之间的不变量，没验证“引用是否确实在工单中”。程序校验还应检查evidence是输入子串；即使子串成立，是否支持分类仍需语义评估。JSON能解析只代表语法成功，平台原生schema约束也不能保证事实真实。

从zero-shot到few-shot

先用清楚指令建立zero-shot基线，再判断错误来自格式还是决策边界。few-shot示例是输入输出对，不是另外一段抽象说明。给“退款失败→billing”会帮助边界，但只给退款样例可能让模型把所有失败归为billing。覆盖技术故障、资料不足、矛盾与恶意文本，并保持标签拼写一致。

动态选示例可以按任务相似性检索，但不应把待测问题的答案泄漏进示例；训练/开发/测试按客户或文档来源分组。压缩示例时删除重复解释、保留改变标签的最小差异。示例集和prompt分别有版本，这样才能知道一次改进来自哪一项。

关键规则位置和重复是否有效，要在目标模型与长上下文数据上测试，不能承诺某一位置永远最强。格式失败可有限重试并携带精简校验错误；业务不确定不能靠不断重试强迫模型给一个确定标签。

练习

为validate增加evidence必须来自source的检查。unknown允许空证据，非unknown的证据必须为输入的非空子串；测试伪造引用。

完成后查看本章答案。

下一篇：继续本章完整实验。