Put the Quality Bar in the Business's Hands
你 AI 的质量标准，就存在某个工程师笔记本电脑里的一张电子表格里。这就是问题所在。
我反复看到同样的套路。技术团队构建 AI、定义什么叫"足够好"、并设定阈值。业务方签一次字，之后再也不去想它。然后抱怨开始了。AI 通过了内部检查，却在真实世界里失败，因为定义质量的人从未和感受质量的人谈过。
这个修复对双方都不舒服：把质量标准交到业务手里。让真正干活的人来定标准，让工程师照着标准去构建。
为什么工程师不该拥有这个标准
工程师拥有管道。他们不拥有判断。
"足够好"是一个业务决策，而不是技术决策。什么算可接受的错误率，取决于输出是拿来干什么的。内部草稿里的一个错误，代价是一小时。面向客户报价里的一个错误，代价是一个客户。合规文件里的一个错误，代价是监管上门。同一个模型、同一个准确率数字，三种完全不同的质量标准。
工程师看着模型的准确率，能告诉你那个数字。但他们没法告诉你哪些错误是可以容忍的，因为这取决于客户、合同、风险——那些业务方知道、而工程师从未被告知的东西。当标准是由感受不到后果的人来定的时候，标准就是定错的。
质量不是一项技术测量。它是关于你能承受哪些错误的业务决策。感受错误的人，才该做这个决定。
三个问题的准则
让这件事从哲学变得可操作的，就在这里。业务方不需要机器学习学位就能定质量标准。他们需要三个问题，套用到 AI 产出的每一个结果上。
问题一：你会把它原样发给客户吗？这是底线。如果答案是"不"，这个输出就不能发出去。没有例外，没有变通。
问题二：如果它错了，代价是什么？这是校准。供内部使用的摘要，错误成本很低。报价单，错误成本很高。对这个问题的回答，决定了输出要多仔细地检查——以及 AI 在到达人工之前要通过多少道检查。
问题三：什么会让你不用检查就信任它？这是目标状态。这个问题迫使人们说出真正的标准，而不是含糊地比划。当答案是具体的，比如"当零件号对得上系统时，我就信任它"，工程师就有了要构建的目标。当答案是含糊的，比如"当它对的时候"，你就找到了模型和业务之间的鸿沟。
三个问题。没有要背的准则，没有要抽象定义的阈值。业务方按任务回答它们，答案就变成了规格。
审查实际是怎么运转的
业务方定标准，而标准是在工作中被执行，不是在会议里。
先挑风险最高的输出。那个一旦出错伤害最大的。让操作者坐下来，拿着真实的例子——好的输出、坏的输出、边界输出——让他们去分类。这是校准，值得面对面做，因为分类的对话会浮出工程师从未见过的判断。"这个没问题，因为客户已经知道上下文。""这个不行，因为它读起来像机器人写的。"这才是真正的质量标准，用感受它的人的话说出来。
然后操作者在设定的一段时间里，对照标准审查实时输出，他们决策的日志就变成了训练数据和评估集。AI 被调优，直到操作者不再标记为止。不是直到工程师的指标说它好。而是直到操作者说它好。
这就是循环：业务方定标准，操作者执行标准，日志教模型，模型改进，直到操作者安静下来。每走一遍循环，质量决策就更多地落入业务手里。
阻力，以及为什么值得推过去
反对来自两边。工程师说业务方不知道自己在要求什么。业务方说没时间审查 AI 输出。两边都对，两边都抓错了重点。
业务方是感受错误的那一方。他们的审查时间，是把标准定对的代价，而这比一个错误标准的代价便宜。工程师得到了比模糊规格更好的东西——他们得到了具体、由例子驱动的"好"的定义，这正是让他们的工作变容易的东西。
回报体现在指标里。更少的升级，因为输出被校准到业务方真正能容忍的程度。更快的批准，因为操作者信任他们帮忙定义的系统。以及一个不断改进的模型，因为它是用使用者的判断在训练，而不是构建者的猜测。
质量标准属于感受错误的人。三个问题、真实的例子、以及一个教模型的审查循环。这才是你构建业务真正信任的 AI 的方式——因为标准是业务自己建的。