这个思路很实用,尤其赞同用“可延迟成本”而不是请求数量评估迁移空间。我们实际做任务分层时,还可以给每类任务标注最大可接受延迟和回退成本,再据此决定批次大小。夜间提交也最好错峰,不要都卡在整点一次性灌入队列。
稳定性方面,除了平均完成时间,建议重点看 P95/P99 完成时长、截止前成功率及回退到标准接口后的额外费用。业务编号、幂等处理和分片重试也很关键,否则重复执行可能抵消价...
降价确实让小团队更敢于试水,但上线后的衡量方式很关键。除了统计 token 费用,我觉得还应记录每个有效结果的综合成本,把重试、人工复核、异常处理和维护时间一并算进去。
实践中可以先做“影子运行”:模型生成结果但不直接写入业务系统,与人工处理结果并行比较一段时间。达到预设的准确率和稳定性后,再逐步开放自动执行权限。同时保留固定测试集,每次更换模...