收益：
- 能够建立模式和基于规则的输出验证层
- 能够在高影响力的决策中有意义地要求人参与
- 能够使用第二个模型设计基于验证和信任阈值的路由
语言模型产生流畅、有说服力且通常准确的语言模型，但“有说服力”并不等于“正确”。该模型可以默默地拟合金额、日期或 JSON 字段；这称为幻觉（模型自信地产生现实中不存在的信息）。在企业系统中，如果该输出流向下一步（付款、电子邮件、数据库写入），错误就会蔓延到现实世界。在本单元中，我们将学习在输出进入系统之前使用验证层对其进行过滤，并在高影响力决策中要求人机参与。
为什么需要输出验证？
模型输出可能会以两种主要方式被损坏：格式（不符合预期的 JSON 模式，字段丢失/过多）和内容（格式正确但值错误 - 不存在的产品代码、不合逻辑的日期）。安全方面还有第三个维度：恶意输出（由于注入或泄漏而产生的恶意命令）。一个可靠的系统将这三个人都挡在了门口。
注意：“模型大致准确”不是生产标准。在没有验证的系统中，即使千分之一的错误也意味着每天 100,000 个请求中的 100 个错误交易。
身份验证层：一步一步
- 模式验证。检查机器的输出是否符合预期的结构：字段是否存在，其类型是否正确，是否填写了必填字段？
- 规则/业务逻辑验证。价值观是否符合业务规则？ （金额 > 0，日期不是将来的日期，产品代码属于目录。）
- 参考/源代码控制。如果模型产生断言，它可以链接到源吗？ （RAG 引用确实在文档中吗？）
- 使用第二个模型（法学硕士作为法官）进行验证。独立模型将输出评估为“正确/不完整/有风险”。
- 信任阈值和方向。如果模型或验证器报告置信度较低，则输出不会自动通过；是针对人类的。
- 人为控制。高效或低安全性的结果取决于专家的批准。
四个可复制模板
方案+“不懂就补”一起：
仅返回以下 JSON 模式中的响应：写入“low”。切勿将估算写得好像它是准确的一样。
用第二个模型验证（判断提示）：
您是一名独立验证者。下面是一个<source>文本和一个<claim>。检查声明中的每个数字和日期是否在来源中逐字出现。对于每一个，说：“已验证|不在来源中|与来源相矛盾。”如果其中之一“不存在/冲突”，请将结果标记为“需要人工审核”。<source>{{ text }}</source><claim>{{ model_output }}</claim>
信任阈值路由规则：
路由规则：- emin_misin = "high" AND amount < 10,000 TL -> 自动处理- emin_misin = "medium" OR amount 10,000-100,000 TL -> 第二次模型验证- emin_misin = "low" OR amount > 100,000 TL -> 需要人工批准
人工审核汇总卡（加快审核）：
当向某人提出决定时，请出示这张卡：- 提议的内容是什么？ （一句话）- 它基于什么来源？ （文章/文档参考）- 两个最弱的假设是什么？- 如果获得批准，可以撤销吗？ （是/否）
弱提示/强提示
糟糕的方法
强硬的做法
“从发票中减去金额”（自由文本）
严格的 JSON 架构 + null + 信任字段
将输出直接写入支付系统
模式 → 规则 → 人工批准（如果需要）
只是告诉模型“确定”
使用第二个模型进行数字/日期验证
以同等的信心处理每个输出
基于影响力和信任的路由
强方法并不希望模型是正确的；它创造了一扇门，当你犯错时，它会抓住你。
三个迷你箱
案例 1 — 仅靠该计划是不够的。会计自动化以 JSON 形式从发票中提取金额。该方案是正确的，但模型在发票上生成“125,000”而不是“1,250.00”（十进制移位）。该计划未能抓住这一点；捕获规则验证（“金额必须与发票项目总数一致±1%”），并防止错误记录 112,500 TL。
案例 2——第二个模型捕捉到了幻觉。法律支持助理在合同摘要中写道：“提前 30 天通知终止”；不过，合同上写的是90天。当独立法官将模型标记为“与源冲突”时，输出将转发给人类并进行纠正。如果是自动的，客户会根据错误的日期通知取消。
案例 3 — 路由将负载减少了 70%。保险索赔系统自动批准低金额和高安全性索赔，并仅将高于阈值/低安全性的索赔发送给专家。在 3,200 个日常需求中，只有 950 个属于人类；专家将时间投入到真正有风险的 30% 上，平均交易时间从 4 小时下降到 40 分钟。
提示：不要设置人为控制，以便“人们可以看到一切”——这会让人们疲惫不堪，批准将成为橡皮图章。相反，只将高影响力和低可信度的输出传递给人类；这将注意力集中在真正重要的事情上。
让人类控制变得有意义
人机交互并不是在纸上打勾。审核者必须拥有 (1) 背景来理解该决定，(2) 可以访问来源，以及 (3) 有权说“不”。否则，控件仍然是装饰性的。审核卡（上面的第四个模板）旨在提供这种背景。
常见错误
- 只是进行模式验证并跳过内容/值错误。
- 认为通过告诉模型“确保”你正在做真正的验证。
- 自动实施高影响力、不可逆转的决策。
- 对每项输出进行人为控制，将批准变成毫无意义的橡皮图章。
- 向审稿人说“批准”，但不提供来源和背景。
- 处理具有相同风险的所有输出，无需建立信任阈值和路由。
综上所述
- 输出以三种方式被破坏：形式、内容和恶意意图；一个可靠的系统将这三个人都挡在了门口。
- 层：模式验证、规则/业务逻辑、源代码控制、第二模型（LLM-as-judge）和信任阈值路由。
- 对于高影响力和低安全性的输出，人机交互应该是强制性的。
- 人工审核必须有意义：审核者必须有背景、资源访问权限和说“不”的权力。
- 通过仅将有风险的产品（而非所有产出）导向人类，即可获得安全性和效率。
应用任务
举一个你自己的人工智能输出的例子。首先定义一个 JSON 模式并强制输出到它。然后编写至少两个业务规则（例如，“金额与项目总数匹配”）。最后，建立一个路由表：哪个信任/影响组合是自动进行的，哪个是第二个模型，哪个是人类？生成一个错误的样本并观察每一层捕获它的位置。
清单
- [ ] 我为输出定义了严格的模式并用机器验证它。
- [ ] 我添加了至少一项业务/规则验证（值逻辑）。
- [ ] 我可以将断言链接到源并检查它们。
- [ ] 第二个模型或人工验证可用于高影响/低安全性结果。
- [ ] 基于信任和影响力定义的路由规则。
- [ ] 向审稿人提供背景、来源和拒绝权。