北京
OpenAI的Decisions API本周正式开放通用。真正值得看的不是又多了一个接口，而是这次发布把一件事挑明了：有些AI任务需要生成，很多任务只需要一个有边界的判断。
原型阶段让同一个通用模型去分类请求、选择动作、起草回复、再审批结果，确实省事。但到了生产环境，这几件事的要求和失败方式完全不同。一个更可测试的AI工作流，可以拆成四层。
第一层：硬约束交给确定性规则
有些判断不该依赖概率推理。权限、合同限制、数据驻留要求、支出上限、已知安全策略，都属于普通应用逻辑的地盘。模型可以帮忙识别相关上下文，但不该悄悄覆盖一条硬规则。如果一个条件必须永远产出同样的结果，那就从代码开始。
第二层：重复性判断交给有边界的模型
分类、排优先级、路由、打分，和开放式生成不是一回事。有边界的判断层接收证据，返回一个受约束的结果：一个概率、从已知集合里选出的一个选项，或者按评分标准给出的分数。输出更容易验证，也更容易被应用的其他部分消费。典型场景包括：
- 把支持请求路由到正确的队列
- 给某个智能体动作打分，判断是否需要复核
- 选择由哪个模型处理下一步
- 给待人工检查的文档排优先级
这一层同样需要评估。概率不会自动校准，置信阈值应该从有代表性的应用数据里推导出来，而不是随手拍一个。
第三层：开放式工作交给生成模型
输出空间真正开放的地方再用生成模型：起草解释、综合多份文档、写代码、规划多步任务。目标不是躲开大模型，而是把它们留给那些更广的能力确实能产生价值的工作。
一个简化的工作流大致是这样：请求违反硬策略，就拦截或升级；否则先分类和路由，拿到判断结果；如果判断置信度低或影响大，送人工复核；其余情况才交给选定的模型和工作流继续跑。
第四层：后果重大的不确定性交给人工复核
人工复核路径应该是架构的一部分，而不是上线后打的应急补丁。当动作不可逆、会影响他人、会访问敏感数据，或者落在评估用过的样例之外时，复核尤其重要。
测试这套架构时，别只盯模型的原始准确率。要跟踪的是：判断校准度、端到端延迟、每个成功完成的工作流成本、升级与回退率、真实输入变化下的性能漂移，以及每一个判断是否可审计。
正在浮现的教训是，“我们该用哪个模型”正在变成错误的第一问。更好的问法是：每一步到底需要哪种推理？
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
