一张售后工单进来，系统要判断它属于退款、物流还是技术问题。一张产品照片进来，系统要标出是否疑似缺陷。这两件事的交付物都是判断。给客户解释退款政策、综合材料写分析报告，才需要生成文字。
如果把这些任务全部接到同一个通用大模型上，接口可能统一了，成本和验收标准却未必合适。企业做 AI 选型，可以先问一句：这个环节最终需要一段话，还是一个可供业务系统使用的判断？
一、从 Jev 到 d1：先看任务，再看模型
9 月 15 日，TypeSafe 发布 Jev，主打供软件直接使用的结构化判断：输入材料与预先定义的问题，返回带概率的类型化结果，放弃自由文本生成。[6] 它把一个问题摆到了企业面前：分类、路由、评分这些环节，是否需要先生成一段话？
10 月 5 日，Liquid AI 发布支持文本与图像输入的 d1 决策模型。它接收材料和问题，返回判断概率、分类或评分，不生成自由文本；官方展示了工单筛选和视觉质检等应用。[1][2]
d1 的官方发布说明也直接把 Jev 作为文本决策能力的比较对象，并强调自身支持图像输入。[1] 两者的共同方向，是把判断任务从文字生成中独立出来；这不代表它们有相同的架构、部署条件或业务效果。
从 Jev 到 d1，这提供了一个值得企业评估的方向：对于标签明确、结果结构固定的环节，可以把判断能力单独拿出来选型。它并不意味着通用大模型失去价值，也不能推出“所有判断任务都该换 d1”。
尤其要看清发布说明的边界。厂商展示的比较采用特定任务与测试设置，各应用每个模型仅运行一次，费用按公开标价计算，没有计入提示缓存折扣。[1] 企业应把它作为候选方案线索，收益仍需自己的业务数据验证。
截至本文核查，d1 官方提供的是 API 使用路径，模型目录也标注为 API；不能据此宣称它已支持企业内网私有化部署。[1][2] 有数据出域约束的项目，应先核对服务条款、数据处理与部署条件，再决定是否测试。
二、三类误区，会把便宜调用变成昂贵流程
误区一：输出很短，就认为任务很简单
“是否退款”可能只输出两个字，但背后包含订单状态、合同条款和审批权限。与之相比，“把已确定的工单标签写入队列”可以很简单。
任务难度由证据、判断边界和错误后果决定。选型前要明确：输入是否齐全，标签能否稳定定义，结果是给人参考还是直接触发动作。退款资格判断和实际付款，也应是分别控制的两个环节。
误区二：整体准确率够高，就直接自动执行
把物流问题错分到技术队列，会增加等待与转派；把缺陷产品判为合格，可能影响交付。两种错误都算“错一次”，业务代价却不一样。
因此应分别统计错分、漏判和各类别表现。精确率回答“判为缺陷的里面有多少确实有缺陷”，召回率回答“真实缺陷找出了多少”。[4] 不能用一个整体准确率掩盖高风险类别的漏判。
误区三：模型给了概率，就把它当作正确率保证
模型输出的概率，需要在目标业务数据上检验。概率校准讨论的正是预测概率与实际事件频率是否吻合。[3] 对新产品、新光照、口语工单或罕见缺陷，不能直接套用原来的放行阈值。
信息不足、类别接近、高风险结果应有复核路径。让通用大模型处理疑难样本也是一种候选分工，但是否减少错误要另行测试；第二次模型调用不等于人工确认，也不会天然消除第一步的误判。
三、规则、专用模型、通用大模型怎样分工
下面的“专用模型”包括围绕固定标签训练的分类器、视觉检测模型，以及 Jev、d1 这类面向结构化判断的模型。它们的训练要求、部署方式和效果不同，需要分别评估。
| 路线 | 优先评估的任务 | 需要验证的边界 |
|---|---|---|
| 规则与业务查询 | 明确字段、固定条件、确定性流程 | 字段缺失、条件变化、规则覆盖不足 |
| 专用模型 | 稳定标签的分类、筛选、评分与视觉判断 | 样本代表性、少数类表现、概率与阈值 |
| 通用大模型 | 开放表达、材料综合、多步理解与文字生成 | 内容正确性、依据完整性、调用与复核成本 |
| 人工复核 | 高风险、证据不足、超出任务边界的结果 | 复核时限、责任归属、结果回流 |
以售后流程为例，这是方案示意，非客户案例：订单状态从业务系统查询；工单先分类；需要给客户写解释时，再让通用大模型结合已核实信息生成；涉及退款、赔付等动作，由业务系统检查权限并执行审批。
视觉质检同样要拆开。图像采集、疑似缺陷识别、复核、放行分别有自己的责任边界。拍摄条件变化可能改变模型表现，返工与拦截动作也需要记录。厂商演示中的图像判断，不能直接等同于一条产线的验收结果。
通用大模型还可以帮助整理标注规范、分析异常，但产线是否放行，必须由预先定义的业务策略控制。模型输出建议，业务系统控制执行，这样才能明确出了问题由谁处理、怎样回退。
四、把成本算到验收通过的业务结果
只比较每次调用单价，容易漏掉人工复核、返工、错误处理和运维。同一个模型，输入长度、问题数量、重试次数和并发要求也会影响账单。
以 d1 为例，官方说明它不生成输出 token，但每个问题分别计费，随问题提供的图像也重复计入输入用量。[2] 一次请求问多个问题，不能据此理解为只付一次材料费用。成本测算应使用实际请求与账单数据。
企业可以统一采用下面的内部核算口径：
单位合格结果成本＝周期总成本 ÷ 验收通过的业务件数。
周期总成本包括模型调用或自有算力、人工复核、返工处理、可归因误判损失，以及建设与运维的周期摊销。各项按实际发生的成本归集，避免把同一次错误处理费用重复计算。
工单场景中，一件结果可定义为“完成正确分派并通过抽检”；质检场景中，可定义为“按约定检验流程完成判断并通过复核或抽检”。统计窗口、抽检方式和迟发错误的回补规则，要在对照实验前约定。
例如某方案调用便宜，但大量结果要人工复核，人工等待还拖慢整个流程，就可能不适合直接扩大应用。这是需要用成本表验证的判断，不是预设哪条路线一定更贵。一个只提供辅助标签的方案，也不能与包含客服答复、执行和审计的完整系统直接比较总价。
五、小范围验证，怎样避免只做出一个演示
第一步，固定任务与基线。由业务人员定义标签、特殊情况和最终动作，同时记录现有流程的成本与耗时。若业务人员对同一工单都无法一致分类，应先修订标签规范。
第二步，准备脱敏后的历史样本。覆盖常见类别、少数类别、缺失信息和异常输入；视觉场景还要覆盖相机、光照、产品批次等变化。调阈值的数据与最终验收数据分开，避免测试结果被反复调参污染。
第三步，用同一批材料比较可行路线。规则、专用模型与通用大模型，都按相同的结果定义评估。通用大模型能输出固定格式，也可以是判断任务的候选；是否值得替换，取决于业务效果与总成本，而非模型名称。
第四步，影子运行。让新方案给出建议，实际业务继续沿用现有流程，观察真实流量下的错误、等待与复核负担。模型、输入处理、阈值和规则版本都要留记录，以便追溯差异。
第五步，小范围上线并保留回退。模型超时、证据不足或样本超出适用范围时，转人工或现有流程。关键验收项可以这样约定：
| 验收项 | 要回答的问题 |
|---|---|
| 错分与漏判 | 哪些类别容易出错，高风险错误是否可接受？ |
| 人工复核比例 | 自动化减少了什么工作，是否把负担转移给了复核人员？ |
| 端到端时延 | 包含排队、重试、复核和系统写入后，业务能否按时完成？ |
| 单位合格成本 | 在相同验收口径下，总成本是否改善？ |
六、什么情况适合哪条路线
明确字段就能判断的流程，先评估规则。标签稳定、任务重复、样本可以持续维护的分类与质检，适合把专用模型纳入对照。需要生成文字、综合多种证据或频繁处理新问题时，通用大模型值得保留。结果触发高风险动作时，保留相应审批与人工确认。
海星技术服务的公开服务范围包含场景 PoC、AI 工程、视觉检测、智能客服与私有化基座。[5] 具体项目可以从一张任务清单和一套验收口径开始，再选择模型与部署路线；本文不代表已经完成 d1 集成，也不承诺某个模型的收益。
如果正在评估工单分类或视觉质检，可以向风远科技提交业务场景，获取初步方案建议。
资讯来源与数据说明
[1] Liquid AI：Introducing d1: The most capable decision model, now with vision（2026-10-05；厂商测试，非风远科技实测）
[2] Liquid AI：Decision Models 官方文档（2026-10-06 核查；能力、计费与部署可用性以最新文档为准）
[3] scikit-learn：Probability calibration（概率校准定义与验证原则）
[4] scikit-learn：Metrics and scoring（分类评估指标）
[5] 风远科技：海星技术服务公开服务范围（本文仅引用服务范围，不使用客户效果数字）
[6] TypeSafe：Introducing System One Models & Jev（2026-09-15；能力定位来自官方发布，不引用厂商倍数作为企业收益）
本文的流程与核算方式是方案建议，不是客户案例或收益承诺。选型应以业务样本、部署约束和共同约定的验收标准为依据。