这道题其实问的是,在自动化[[Agent]]系统里怎么平衡效率和安全性,说白了就是什么时候该让机器自己干,什么时候必须拉人进来。我理解的核心思路是分层决策,加一个动态的切换机制,不是一刀切。
先说整体的框架,我习惯分成三层:感知层、决策层、执行层。感知层负责收集不确定性的信号,比如模型的logits分布、工具返回异常、或者知识缺口。决策层根据这些信号做多因子融合,判断要不要转人工。执行层负责无缝切换,还得保留上下文,让人工接手时能直接接着干。
具体说一下置信度阈值。这个不能只看模型输出的softmax概率,因为很多模型没校准,概率高不一定准。我会先用Temperature scaling或者Platt scaling做校准,得到一个校准后的置信度。然后结合任务维度的置信度,比如历史同类型任务的准确率,动态调整阈值。另外我会用联合触发机制,比如模型置信度低并且关键实体识别模糊,两个条件同时满足才转人工。这样能避免过度保守或者漏判。
再一个就是风险等级矩阵。风险等级取决于操作不可逆性、数据敏感度和合规要求。举个例子,客服退款场景里,查询订单状态或者可撤销的操作,风险等级低,自动处理就好;修改配置或者发通知,风险中,需要用户确认;涉及资金操作、隐私数据或者合规敏感场景,比如退款超过一定额度,就必须人工介入。这里有个关键点,风险等级和置信度阈值要解耦联动。高风险任务即使模型置信度很高,也可能触发复核,因为安全优先级更高。
动态调度策略这块,我会用在线学习,根据人工反馈的错误案例,每周更新阈值参数。还会做上下文感知的降级,比如高峰期自动放宽非关键任务的置信度阈值,但核心安全规则硬编码,不能覆盖。另外人机接力也很重要,Agent完成80%的工作,人工聚焦关键决策点,保留完整上下文快照,这样效率最高。
这里有个有意思的延伸,就是人工介入的ROI权衡。比如客服系统里,每转一个人工工单都有成本,时薪乘以平均处理时长。如果阈值设得太低,人工成本飙升;设得太高,错误率上升。所以上线前我会先量化这个成本模型,设定可接受的错误率上限,然后用A/B测试持续优化切换边界。
所以整体上,我更倾向于把Agent系统看成一个人机协作的框架,自动处理覆盖大部分常规场景,人工作为兜底和例外处理。前提是必须做好上下文保留和风险分级,否则切换会很生硬,用户体验也差。常见失败场景就是阈值设死,或者风险等级没考虑全,导致该转人工的没转,或者不该转的频繁转。