把大模型当分类器用这件事,OpenAI 给了一套专门的接口
过去要让模型回答「这封邮件是不是投诉」「这条工单该派给哪个组」,常见做法是写一段提示词,要求模型只输出「是/否」或某个类别名,再用正则去解析。Decisions API 想解决的就是这一层:问题和候选项由开发者定义,模型直接返回结构化的判断。
据 DataCamp 的上手教程,一个 API 请求里可以同时塞进多道判断,对同一段输入一次性拿到是非概率、类别和分数;而网页测试区一次只能试一种。LangChain 也已经在 langchain-openai 里放了对应的封装。
用通用对话模型做分类,最麻烦的不是准确率,而是输出不稳定:偶尔多说一句、换个同义词、格式跑偏,下游代码就要兜底。把判断收窄成固定的几种形态,带来的是可预期的返回结构和可以直接拿来设阈值的概率值。客服分流、内容审核、日志告警分级、评测打分这类大批量、低单价的任务,对这一点比对文采敏感得多。
这也和 OpenAI 最近的产品路线一致:从一个大而全的对话接口,逐步拆出面向具体工作流的专用接口。结构化输出、批处理、评测,再到这次的 Decisions,方向都是让模型更像一个可以嵌进系统的组件。
官方尚未就 Decisions API 发布完整的说明文档,背后具体用的是哪个模型、按什么计费、概率值是否经过校准,现有信息都来自第三方教程和测试区本身。第三方材料里提到的模型名称,目前也找不到 OpenAI 一手页面印证。真要上生产,最好先拿自己的历史数据跑一轮,看看它给出的概率和人工标注到底对不对得上。