语音AI订餐中人类究竟应该确认什么？
在一个合成语音订餐示例中，一个重复的语音标记变成了三个汉堡。系统提供了一个合理的修正建议：将数量更改为一个。对于产品团队而言，棘手的问题在于该建议与提交订单的许可之间发生了什么。看似有用的替换并没有确定客户真正想要的是什么。
说明：以下示例是Veriprajna的Drive-Thru Order Firewall中的合成订单，该防火墙在模拟厨房显示屏之前验证结构化供应商输出。它既不识别人类的真实音频，也不向餐厅的POS系统发送订单。
我希望人工确认能够解决特定的不确定性。这需要将三项判断分离开来：客户的真实意图、餐厅策略是否允许该订单，以及所提议的精确订单是否满足各项检查。将这些判断合并到一个批准按钮中，会导致很难明确一次批准究竟意味着什么。
修正只是关于意图的假设
重复标记的测试夹具包含一段不流畅的转录文本、三个完全相同的原始标记以及三个汉堡的数量。其提供的置信度得分为0.71，低于配置的审核阈值0.85。因此，重复规则和低置信度规则将该订单置于HOLD状态。重复规则建议改为一个汉堡。
对于呈现在操作员面前的选项而言，一个汉堡是一个合理的候选值。但它并不是预期数量的证明。重复标记或许能解释结构化输出，但检测到重复的规则无法询问客户究竟是什么意思。自动将三个替换为一个，只是用未经确认的解释取代了存疑的解释。
拒绝订单则伴随着不同的代价。这相当于把需要澄清的解释当成了无法挽回任何可接受订单的情况。在这一步我更倾向于搁置（hold），因为这样可以保留原始证据，并将预期的数量保持开放。在生产环境中，确认应当针对数量本身提出询问，而不是要求操作员背书系统的整体置信度。
这是一种设计立场，而非此应用中已完成的工作流。演示中的Approve Correction和Escalate按钮会改变自身标签并被禁用。它们不会重新提交、放行、记录人工操作或更改收据。生产团队仍需构建能够使回答产生实际效力的对话机制和状态转换。
非同寻常的要求也可能被准确理解
意图解释只是暂停处理的原因之一。另一个合成夹具包含18,000个水杯，其提供的置信度得分为0.97，且客户菜单价格为零。由于该数量超过了配置的八杯水上限，关卡对其进行了搁置。无论是较高的输入得分还是零价格，都无法回答是否允许该数量继续推进。该得分只是来自夹具的输入，并非经过校准的许可概率。
极端的数量使这种区分显而易见。更困难的产品决策在于客户确实想要的异常数量。假设有一份超出餐厅常规自动限制的团体订单。如果客户确认了该数字，解释可能已经明确，但许可依然悬而未决。将其压缩到常规上限会篡改客户要求。而直接拒绝则可能扼杀合法需求。
在策略允许特例的情况下，我更倾向于使用例外阈值来触发审核。此时操作员需要决定餐厅是否可以接受已确认的订单，这可能需要通过独立授权的途径。旨在限制自动提交的阈值，不应悄然变成改写客户意图的规则。
这需要消耗注意力。更宽松的自动阈值会放行更多异常订单；更严格的阈值则会带来更多的审核工作。演示无法为餐厅做出这种权衡选择。其上限源自预设的合成订单历史，其分布反映了该历史中的数据表现。它既不能确立真实门店的接待能力，也无法确定合法团体订单的发生频率。在采纳此类策略之前，团队需要关于可接受例外情况及其实际确认负担的充分证据。
确认必须精确适用于下一笔订单
即使经过确认的修正，其结果仍可能无效。大额订单夹具初始包含40份薯条和40杯汽水。数量规则提议将薯条减少到四份，但保持40杯汽水不变。汽水的上限是六杯。因此，即便同意将四份薯条作为合适替代，提议的订单中依然存在另一项数量违规。
这就是我坚持将确认与验证严格区分的原因。客户确认解决的是意图问题。授权操作员的例外决策解决的是策略问题。检查提议的完整订单解决的是下一笔交易是否符合适用规则。这些结论中的任何一个都无法从其他结论中安全推断出来。
对于生产工作流，我要求确认的提议在提交前必须重新通过验证。如果操作员可以推翻策略，该权限应当明确声明，并绑定到所接受的特定规则与订单上。宽泛的批准不应抹去不相关的违规。这些是未来实现的要求，而非当前修正控件所展示的功能。
建议可以提供帮助而无需赋予许可
解释性模型批注具有实用但更为狭窄的作用：它可以使搁置的原因更易于阅读。在随附的创始人录像中，该批注使用了缓存的真实咨询响应。它并非在每次重放时都进行全新的推理。引擎首先使用确定性规则做出决策；随后的咨询文本无法改变该决策。咨询调用在处理流程中是同步的，因此这种权限分离并不证明模型处理不会增加请求延迟。
这份订单验证详细解析展示了这一边界和合成示例。它们支持了一个可审查的设计论点，但并非表明预设策略或未完成的操作员工作流已具备部署条件。
以下是关于订单审核示例的创始人录像。
对我而言，决定性的产品评审在于跟踪提议订单直至其下一个被允许的操作。谁确认了其含义？谁可以批准特例？是什么检查了完整结果？在这些答案完全指向同一笔精确订单之前，令人宽慰的修正和批准标签只会让交易处于未完成状态。
