1. 从“不说话”说起Jev 到底在解决什么问题第一次看到“不说话模型”这个说法我脑子里蹦出来的画面是那种在群里从不闲聊、只在关键节点甩出一句结论的老工程师。Jev 给我的感觉就是这样——它不跟你寒暄不给你写小作文也不试图用一段流畅的自然语言让你觉得“它很懂你”。它做的事情非常克制接收输入然后输出一个带概率的结构化决策。这件事听起来好像没什么大不了但你只要真正在业务系统里接过一次大模型就会明白“让模型说人话”和“让模型做决策”完全是两码事。我们过去两年习惯的交互范式是你给模型一段提示词它给你一段文本你再从这段文本里想办法解析出你要的字段。这个链路里最脆弱的一环就是“解析”——模型今天心情好给你输出标准 JSON明天可能就在 JSON 前面加一句“好的以下是您需要的结果”后天可能把布尔值写成“是/否”而不是 true/false。你写再多正则、加再多约束本质上都是在跟一个概率系统做对抗。Jev 的切入点就在这里。它不把自然语言当作最终产物而是把“决策”本身当作一等公民。你给它一个决策空间它返回的不是一段话而是一个分布——每个候选决策对应一个概率值。这个设计思路来自前 OpenAI 研究员的工作背景核心动机很直接在很多真实场景里我们根本不需要模型“说话”我们需要的是模型“选一个”并且告诉我们它有多确定。适合谁来关注这个东西三类人。第一类是正在做 Agent 或者自动化决策链路的工程师你们一定被“模型输出不稳定”折磨过第二类是做风控、审核、路由、推荐这类需要“在多个动作里选一个”的系统的开发者第三类是对 TypeSafe AI 这个方向感兴趣、想理解“类型安全”怎么和大模型结合的人。哪怕你暂时不打算接入 Jev理解它的设计哲学对你选型自己的方案也有直接帮助。2. Jev 的核心设计思路拆解2.1 为什么是“结构化决策”而不是“结构化输出”这里有个很容易混淆的点我得先把它掰开。市面上已经有很多工具在做“结构化输出”比如让模型返回 JSON、XML、YAML或者用 function calling 强制模型走某个 schema。这些方案解决的是“格式”问题——让输出可被程序解析。但 Jev 走得更远一步它解决的是“决策”问题。区别在哪举个例子。假设你在做一个客服工单路由系统用户发来一段话你需要决定这张工单分给“退款组”“技术组”还是“投诉组”。结构化输出的做法是让模型返回{category: 退款组}然后你拿这个字段去路由。但模型返回的这个“退款组”是一个字符串它背后没有概率信息。你不知道模型是 99% 确定还是 51% 确定。如果只有 51%你可能想加一个人工复核环节如果是 99%直接自动路由就行。Jev 的输出形态是退款组: 0.87, 技术组: 0.09, 投诉组: 0.04。这是一个分布。你拿到的不只是“选哪个”还有“有多确定”。这个差别在单次调用里可能不明显但在大规模自动化系统里它是决定你能不能设置置信度阈值、能不能做级联决策、能不能把低置信度样本挑出来人工处理的关键。提示如果你的业务里从来没有“置信度”这个概念所有决策都是非黑即白那 Jev 这类方案对你的边际收益可能有限。但只要你的系统里存在“拿不准就先转人工”这种逻辑概率化决策就是刚需。2.2 TypeSafe AI 这个标签意味着什么“TypeSafe AI”这个词最近被提得很多但很多人把它理解成“给 AI 加类型注解”这个理解太窄了。类型安全的核心价值不在于“好看”而在于“编译期就能发现错误”。放到 AI 决策场景里它意味着决策空间是预先定义好的、封闭的、可枚举的。模型不能凭空发明一个不存在的选项。这一点非常关键。你用普通大模型做分类它有可能返回一个你 schema 里根本没定义的类别比如你定义了三个组它给你返回“其他组”。这种“越界”在类型安全的框架下是不允许的——因为决策空间是一个类型模型只能在类型允许的取值范围内分配概率。这带来的直接好处是你的下游代码不需要写防御性分支来处理“模型返回了意料之外的值”这种情况。从工程角度看这大幅降低了集成成本。你可以把 Jev 的输出直接喂给一个 switch 语句或者路由表不需要中间做一层“合法性校验”。这层校验在传统方案里往往是 bug 的重灾区因为大家写校验的时候总会漏掉某些边界情况。2.3 System One 模型的定位热词里出现了“System One 模型”这个词借用了认知科学里“快思考”的概念。System One 指的是直觉式、快速、低能耗的决策过程对应的是 System Two 那种慢速、推理、高能耗的过程。Jev 把自己定位成 System One意思很明确它不打算做长链条推理不打算写论文它要做的是快速给出一个可靠的直觉判断。这个定位决定了它的适用边界。如果你需要的是“帮我分析这段合同里的法律风险并给出修改建议”那是 System Two 的活Jev 不适合。但如果你需要的是“这条评论是正面还是负面”“这个请求该走哪个处理管道”“这个用户当前处于哪个意图状态”这些都属于 System One 的范畴——决策空间有限、判断依据相对直接、对延迟敏感。把对的模型放在对的位置上比盲目追求“最强模型”要重要得多。3. 核心细节解析与实操要点3.1 决策空间的定义方式Jev 使用中最关键的一步是把你的业务问题转化成一个“决策空间”。这个空间必须满足几个条件互斥、完备、可枚举。互斥是说任意两个选项不能同时成立完备是说所有可能的情况都要被覆盖可枚举是说选项数量有限且明确。我拿一个实际场景来演示。假设你在做一个内容审核系统需要判断一条用户评论该被如何处理。决策空间可以定义为approve直接放行flag_review标记待人工复核reject直接拒绝escalate升级到高级审核这四个选项互斥吗是的一条评论最终只会走一条路。完备吗基本完备但如果出现“需要联系用户补充信息”这种情况你可能还得加一个选项。可枚举吗是的就四个。定义好之后你把这个空间交给 Jev它返回的就是这四个选项上的概率分布。这里有个实操心得决策空间不要定义得太细。我见过有人把决策空间定义成二十多个选项结果模型在每个选项上的概率都很低分布非常平坦反而失去了决策价值。一般来说三到七个选项是比较舒服的区间。选项太少决策粒度不够选项太多模型区分度下降。3.2 输入构造的注意事项Jev 的输入构造和普通提示词工程有相似之处但侧重点不同。普通提示词工程追求的是“让模型理解任务”而 Jev 的输入构造追求的是“让模型在决策空间上产生有区分度的分布”。这意味着你给模型的上下文应该包含那些真正能区分不同决策的信号而不是把所有相关信息一股脑塞进去。我的做法是先人工标注一批样本看看人类决策者在做判断时实际依赖哪些信息。然后把这些信息结构化地组织进输入里。比如做意图分类你可能需要的是用户当前这句话加上最近两轮对话而不是整个会话历史。历史太长反而会引入噪声让分布变得模糊。另一个要点是输入里不要包含“请选择”这类指令性语言。Jev 的设计假设是你已经把决策空间告诉它了它不需要你再用自然语言提醒它“要做选择”。多余的指令反而可能干扰它对决策空间的注意力分配。3.3 概率输出的解读与阈值设定拿到概率分布之后怎么用是另一个关键问题。最直接的做法是取 argmax也就是选概率最高的那个。但更成熟的做法是设置置信度阈值。我通常会把决策分成三档来处理置信度区间处理策略典型场景高于 0.85自动执行高确定性路由、自动放行0.6 到 0.85执行但记录可接受风险的操作留痕备查低于 0.6转人工或降级高风险决策、需要复核的场景这个阈值不是拍脑袋定的而是根据你的业务容错率反推出来的。如果你的业务对误判极其敏感那把自动执行的阈值提到 0.95 也不为过。反过来如果只是做个粗略分流0.7 就够了。关键是你要在系统里显式地定义这个阈值而不是默认 argmax 就是对的。注意概率值本身不是绝对校准的。也就是说模型说 0.9 确定不代表它在历史上真的有 90% 的准确率。你需要用自己的标注数据做一次校准分析看看在哪个概率区间上实际准确率是多少然后据此调整阈值。这一步很多人会跳过但它直接决定了你的系统是靠得住还是靠不住。4. 实操过程与核心环节实现4.1 从零搭建一个 Jev 风格的决策链路我拿一个具体项目来走一遍完整流程。场景是一个 SaaS 产品的用户反馈自动分类系统。用户提交反馈文本系统需要决定这条反馈该进入哪个处理队列。第一步定义决策空间。经过和业务方对齐确定五个队列bug_report、feature_request、billing_issue、account_problem、general_feedback。这五个选项互斥且完备。第二步准备标注数据。我从历史反馈里抽了 500 条人工标注了队列归属。这 500 条不是随便抽的我特意保证了每个队列至少有 80 条样本避免类别不平衡导致模型对某些队列的区分度不够。第三步构造输入模板。每条输入包含反馈标题、反馈正文的前 200 字、用户所属套餐等级。为什么加套餐等级因为 billing_issue 和 account_problem 在某些表述上很接近但不同套餐的用户遇到的问题类型有差异这个信号能帮助区分。第四步调用 Jev 获取概率分布。这里我用的是批量调用一次提交 50 条减少往返开销。返回的结果是一个二维数组每行对应一条反馈的五个概率值。第五步后处理。对每条反馈取最高概率的队列作为主队列同时记录置信度。置信度低于 0.6 的反馈额外打上一个needs_review标记进入人工复核队列。这套流程跑下来自动处理率大概在 78% 左右剩下 22% 进入人工复核。人工复核的准确率要求是 95% 以上因为复核人员只需要确认或修正队列归属工作量比从零分类小得多。4.2 参数选择与计算过程在阈值设定上我做了一个简单的计算。假设自动处理的准确率是 A人工复核的准确率是 H自动处理的比例是 p。那么整体准确率是p * A (1-p) * H。我希望整体准确率达到 92%。通过在小批量标注数据上测试我发现当阈值设为 0.6 时自动处理部分的准确率 A 大约是 88%自动处理比例 p 是 78%。代入公式0.78 * 0.88 0.22 * 0.95 0.6864 0.209 0.8954约 89.5%没到 92%。把阈值提到 0.7自动处理比例降到 65%但自动处理部分的准确率升到 93%。重新计算0.65 * 0.93 0.35 * 0.95 0.6045 0.3325 0.937约 93.7%达标了。所以我最终选了 0.7 作为阈值。这个过程说明一件事阈值不是越高越好也不是越低越好它是在“自动化覆盖率”和“准确率”之间做权衡。你要根据业务能接受的人工复核成本来反推这个值。4.3 与现有系统的集成方式Jev 的输出是概率分布这意味着你的下游系统需要能处理这种“软决策”。如果你的现有系统只接受硬分类结果那你有两个选择要么在 Jev 和现有系统之间加一层适配器把概率转成硬标签要么改造现有系统让它接受置信度信息。我建议选后者哪怕改造成本高一点。因为一旦你的系统能感知置信度你就能做很多以前做不了的事情。比如动态路由高置信度的直接走快速通道低置信度的走慢速通道但附带更多上下文给处理人员。这种灵活性是硬分类给不了的。集成时还要注意一点Jev 的调用应该做成异步的。因为决策链路往往在请求的关键路径上同步调用会增加延迟。我的做法是把 Jev 调用放在一个独立的消息队列里上游系统提交决策请求后立即返回一个任务 ID下游通过回调或轮询获取决策结果。这样即使 Jev 的响应时间是几百毫秒也不会阻塞主流程。5. 常见问题与排查技巧实录5.1 概率分布过于平坦怎么办这是最常见的问题。你拿到五个选项的概率发现都在 0.2 左右几乎没有区分度。原因通常有三个决策空间定义得太细、输入信号不够、或者任务本身就不适合做单步决策。排查顺序是这样的先看决策空间把那些语义上高度重叠的选项合并。比如billing_issue和payment_problem如果业务上处理方式一样就合并成一个。再看输入是不是关键信号没给到模型。比如做意图分类时如果只给当前这句话很多意图确实无法区分需要加上对话历史。最后看任务本身如果这个决策需要多步推理才能做出来那它就不适合 System One 模型你得换方案。5.2 某些选项的概率总是偏低如果某个选项在标注数据里样本很少模型对这个选项的“信心”就会不足导致它的概率被系统性压低。解决办法不是调模型而是调数据。要么补充这个选项的样本要么在损失函数里给这个选项更高的权重。Jev 本身不暴露损失函数所以你只能在数据层面做平衡。另一个可能是这个选项本身定义得不够清晰。我遇到过一种情况escalate这个选项标注人员自己都说不清什么情况下该选它导致标注一致性很低。模型学到的就是一个模糊的边界概率自然上不去。后来我们把escalate的触发条件写成明确的规则文档重新标注了一遍问题就解决了。5.3 延迟波动大Jev 作为 System One 模型理论上延迟应该比较稳定。如果你观察到延迟波动大先检查是不是输入长度差异太大。有些请求输入很短有些很长模型处理时间自然不同。解决办法是控制输入长度把超长输入截断或摘要后再提交。还有一个容易被忽略的点批量大小。批量提交虽然能提高吞吐但单次批量太大时尾延迟会上升。我实测下来批量大小在 20 到 50 之间比较平衡。超过 50 之后吞吐提升不明显但 P99 延迟会明显变差。5.4 常见问题速查表问题现象可能原因排查动作解决方向概率分布平坦决策空间过细 / 输入信号不足检查选项语义重叠度检查输入字段合并选项补充关键信号某选项概率系统性偏低样本不平衡 / 选项定义模糊统计各选项样本量检查标注一致性补充样本明确选项边界延迟波动大输入长度差异 / 批量过大统计输入长度分布检查批量设置截断长输入调整批量大小置信度与实际准确率不匹配未做概率校准按概率分桶统计实际准确率重新设定阈值或做校准映射集成后下游报错下游不接受概率输出检查下游接口契约加适配层或改造下游提示概率校准这件事我建议每上线一个新场景就做一次。不同场景下模型的校准曲线可能完全不同拿 A 场景的阈值去套 B 场景翻车概率很高。6. 我对这类方案的一些实际体会Jev 代表的这条路线本质上是在回答一个问题当大模型从“聊天工具”变成“系统组件”时它的输出形态应该是什么。自然语言是给人看的但系统组件之间对话需要的是结构化、可计算、带不确定性的信号。概率化决策就是这种信号的一种形式。我在实际项目里最大的体会是把决策和表达分开之后整个系统的可维护性上了一个台阶。以前模型输出一段话我要写解析器、写校验、写异常处理代码里到处是防御性逻辑。现在模型直接输出概率分布我的代码只需要处理数值逻辑清晰得多。而且因为决策空间是类型安全的很多错误在定义阶段就被排除了不会留到运行时才暴露。另一个体会是不要指望一个模型解决所有决策问题。Jev 适合的是那些“人类专家看一眼就能判断”的任务。如果某个决策需要查文档、做计算、多步推理那就该用 System Two 的方案或者把任务拆成多个 System One 决策串起来。把对的工具放在对的位置比追求单一模型的万能要务实得多。最后分享一个我在阈值调优上的小技巧不要一次性把阈值定死而是先设一个宽松的初始值上线收集一周的真实数据看看低置信度样本的实际分布再据此收紧。真实数据里的分布往往和你离线测试时看到的不一样因为线上输入的长尾情况比测试集丰富得多。让系统先跑起来再根据实际表现迭代比在离线阶段追求完美阈值要高效。
1. 从“不说话”说起Jev 到底在解决什么问题第一次看到“不说话模型”这个说法我脑子里蹦出来的画面是那种在群里从不闲聊、只在关键节点甩出一句结论的老工程师。Jev 给我的感觉就是这样——它不跟你寒暄不给你写小作文也不试图用一段流畅的自然语言让你觉得“它很懂你”。它做的事情非常克制接收输入然后输出一个带概率的结构化决策。这件事听起来好像没什么大不了但你只要真正在业务系统里接过一次大模型就会明白“让模型说人话”和“让模型做决策”完全是两码事。我们过去两年习惯的交互范式是你给模型一段提示词它给你一段文本你再从这段文本里想办法解析出你要的字段。这个链路里最脆弱的一环就是“解析”——模型今天心情好给你输出标准 JSON明天可能就在 JSON 前面加一句“好的以下是您需要的结果”后天可能把布尔值写成“是/否”而不是 true/false。你写再多正则、加再多约束本质上都是在跟一个概率系统做对抗。Jev 的切入点就在这里。它不把自然语言当作最终产物而是把“决策”本身当作一等公民。你给它一个决策空间它返回的不是一段话而是一个分布——每个候选决策对应一个概率值。这个设计思路来自前 OpenAI 研究员的工作背景核心动机很直接在很多真实场景里我们根本不需要模型“说话”我们需要的是模型“选一个”并且告诉我们它有多确定。适合谁来关注这个东西三类人。第一类是正在做 Agent 或者自动化决策链路的工程师你们一定被“模型输出不稳定”折磨过第二类是做风控、审核、路由、推荐这类需要“在多个动作里选一个”的系统的开发者第三类是对 TypeSafe AI 这个方向感兴趣、想理解“类型安全”怎么和大模型结合的人。哪怕你暂时不打算接入 Jev理解它的设计哲学对你选型自己的方案也有直接帮助。2. Jev 的核心设计思路拆解2.1 为什么是“结构化决策”而不是“结构化输出”这里有个很容易混淆的点我得先把它掰开。市面上已经有很多工具在做“结构化输出”比如让模型返回 JSON、XML、YAML或者用 function calling 强制模型走某个 schema。这些方案解决的是“格式”问题——让输出可被程序解析。但 Jev 走得更远一步它解决的是“决策”问题。区别在哪举个例子。假设你在做一个客服工单路由系统用户发来一段话你需要决定这张工单分给“退款组”“技术组”还是“投诉组”。结构化输出的做法是让模型返回{category: 退款组}然后你拿这个字段去路由。但模型返回的这个“退款组”是一个字符串它背后没有概率信息。你不知道模型是 99% 确定还是 51% 确定。如果只有 51%你可能想加一个人工复核环节如果是 99%直接自动路由就行。Jev 的输出形态是退款组: 0.87, 技术组: 0.09, 投诉组: 0.04。这是一个分布。你拿到的不只是“选哪个”还有“有多确定”。这个差别在单次调用里可能不明显但在大规模自动化系统里它是决定你能不能设置置信度阈值、能不能做级联决策、能不能把低置信度样本挑出来人工处理的关键。提示如果你的业务里从来没有“置信度”这个概念所有决策都是非黑即白那 Jev 这类方案对你的边际收益可能有限。但只要你的系统里存在“拿不准就先转人工”这种逻辑概率化决策就是刚需。2.2 TypeSafe AI 这个标签意味着什么“TypeSafe AI”这个词最近被提得很多但很多人把它理解成“给 AI 加类型注解”这个理解太窄了。类型安全的核心价值不在于“好看”而在于“编译期就能发现错误”。放到 AI 决策场景里它意味着决策空间是预先定义好的、封闭的、可枚举的。模型不能凭空发明一个不存在的选项。这一点非常关键。你用普通大模型做分类它有可能返回一个你 schema 里根本没定义的类别比如你定义了三个组它给你返回“其他组”。这种“越界”在类型安全的框架下是不允许的——因为决策空间是一个类型模型只能在类型允许的取值范围内分配概率。这带来的直接好处是你的下游代码不需要写防御性分支来处理“模型返回了意料之外的值”这种情况。从工程角度看这大幅降低了集成成本。你可以把 Jev 的输出直接喂给一个 switch 语句或者路由表不需要中间做一层“合法性校验”。这层校验在传统方案里往往是 bug 的重灾区因为大家写校验的时候总会漏掉某些边界情况。2.3 System One 模型的定位热词里出现了“System One 模型”这个词借用了认知科学里“快思考”的概念。System One 指的是直觉式、快速、低能耗的决策过程对应的是 System Two 那种慢速、推理、高能耗的过程。Jev 把自己定位成 System One意思很明确它不打算做长链条推理不打算写论文它要做的是快速给出一个可靠的直觉判断。这个定位决定了它的适用边界。如果你需要的是“帮我分析这段合同里的法律风险并给出修改建议”那是 System Two 的活Jev 不适合。但如果你需要的是“这条评论是正面还是负面”“这个请求该走哪个处理管道”“这个用户当前处于哪个意图状态”这些都属于 System One 的范畴——决策空间有限、判断依据相对直接、对延迟敏感。把对的模型放在对的位置上比盲目追求“最强模型”要重要得多。3. 核心细节解析与实操要点3.1 决策空间的定义方式Jev 使用中最关键的一步是把你的业务问题转化成一个“决策空间”。这个空间必须满足几个条件互斥、完备、可枚举。互斥是说任意两个选项不能同时成立完备是说所有可能的情况都要被覆盖可枚举是说选项数量有限且明确。我拿一个实际场景来演示。假设你在做一个内容审核系统需要判断一条用户评论该被如何处理。决策空间可以定义为approve直接放行flag_review标记待人工复核reject直接拒绝escalate升级到高级审核这四个选项互斥吗是的一条评论最终只会走一条路。完备吗基本完备但如果出现“需要联系用户补充信息”这种情况你可能还得加一个选项。可枚举吗是的就四个。定义好之后你把这个空间交给 Jev它返回的就是这四个选项上的概率分布。这里有个实操心得决策空间不要定义得太细。我见过有人把决策空间定义成二十多个选项结果模型在每个选项上的概率都很低分布非常平坦反而失去了决策价值。一般来说三到七个选项是比较舒服的区间。选项太少决策粒度不够选项太多模型区分度下降。3.2 输入构造的注意事项Jev 的输入构造和普通提示词工程有相似之处但侧重点不同。普通提示词工程追求的是“让模型理解任务”而 Jev 的输入构造追求的是“让模型在决策空间上产生有区分度的分布”。这意味着你给模型的上下文应该包含那些真正能区分不同决策的信号而不是把所有相关信息一股脑塞进去。我的做法是先人工标注一批样本看看人类决策者在做判断时实际依赖哪些信息。然后把这些信息结构化地组织进输入里。比如做意图分类你可能需要的是用户当前这句话加上最近两轮对话而不是整个会话历史。历史太长反而会引入噪声让分布变得模糊。另一个要点是输入里不要包含“请选择”这类指令性语言。Jev 的设计假设是你已经把决策空间告诉它了它不需要你再用自然语言提醒它“要做选择”。多余的指令反而可能干扰它对决策空间的注意力分配。3.3 概率输出的解读与阈值设定拿到概率分布之后怎么用是另一个关键问题。最直接的做法是取 argmax也就是选概率最高的那个。但更成熟的做法是设置置信度阈值。我通常会把决策分成三档来处理置信度区间处理策略典型场景高于 0.85自动执行高确定性路由、自动放行0.6 到 0.85执行但记录可接受风险的操作留痕备查低于 0.6转人工或降级高风险决策、需要复核的场景这个阈值不是拍脑袋定的而是根据你的业务容错率反推出来的。如果你的业务对误判极其敏感那把自动执行的阈值提到 0.95 也不为过。反过来如果只是做个粗略分流0.7 就够了。关键是你要在系统里显式地定义这个阈值而不是默认 argmax 就是对的。注意概率值本身不是绝对校准的。也就是说模型说 0.9 确定不代表它在历史上真的有 90% 的准确率。你需要用自己的标注数据做一次校准分析看看在哪个概率区间上实际准确率是多少然后据此调整阈值。这一步很多人会跳过但它直接决定了你的系统是靠得住还是靠不住。4. 实操过程与核心环节实现4.1 从零搭建一个 Jev 风格的决策链路我拿一个具体项目来走一遍完整流程。场景是一个 SaaS 产品的用户反馈自动分类系统。用户提交反馈文本系统需要决定这条反馈该进入哪个处理队列。第一步定义决策空间。经过和业务方对齐确定五个队列bug_report、feature_request、billing_issue、account_problem、general_feedback。这五个选项互斥且完备。第二步准备标注数据。我从历史反馈里抽了 500 条人工标注了队列归属。这 500 条不是随便抽的我特意保证了每个队列至少有 80 条样本避免类别不平衡导致模型对某些队列的区分度不够。第三步构造输入模板。每条输入包含反馈标题、反馈正文的前 200 字、用户所属套餐等级。为什么加套餐等级因为 billing_issue 和 account_problem 在某些表述上很接近但不同套餐的用户遇到的问题类型有差异这个信号能帮助区分。第四步调用 Jev 获取概率分布。这里我用的是批量调用一次提交 50 条减少往返开销。返回的结果是一个二维数组每行对应一条反馈的五个概率值。第五步后处理。对每条反馈取最高概率的队列作为主队列同时记录置信度。置信度低于 0.6 的反馈额外打上一个needs_review标记进入人工复核队列。这套流程跑下来自动处理率大概在 78% 左右剩下 22% 进入人工复核。人工复核的准确率要求是 95% 以上因为复核人员只需要确认或修正队列归属工作量比从零分类小得多。4.2 参数选择与计算过程在阈值设定上我做了一个简单的计算。假设自动处理的准确率是 A人工复核的准确率是 H自动处理的比例是 p。那么整体准确率是p * A (1-p) * H。我希望整体准确率达到 92%。通过在小批量标注数据上测试我发现当阈值设为 0.6 时自动处理部分的准确率 A 大约是 88%自动处理比例 p 是 78%。代入公式0.78 * 0.88 0.22 * 0.95 0.6864 0.209 0.8954约 89.5%没到 92%。把阈值提到 0.7自动处理比例降到 65%但自动处理部分的准确率升到 93%。重新计算0.65 * 0.93 0.35 * 0.95 0.6045 0.3325 0.937约 93.7%达标了。所以我最终选了 0.7 作为阈值。这个过程说明一件事阈值不是越高越好也不是越低越好它是在“自动化覆盖率”和“准确率”之间做权衡。你要根据业务能接受的人工复核成本来反推这个值。4.3 与现有系统的集成方式Jev 的输出是概率分布这意味着你的下游系统需要能处理这种“软决策”。如果你的现有系统只接受硬分类结果那你有两个选择要么在 Jev 和现有系统之间加一层适配器把概率转成硬标签要么改造现有系统让它接受置信度信息。我建议选后者哪怕改造成本高一点。因为一旦你的系统能感知置信度你就能做很多以前做不了的事情。比如动态路由高置信度的直接走快速通道低置信度的走慢速通道但附带更多上下文给处理人员。这种灵活性是硬分类给不了的。集成时还要注意一点Jev 的调用应该做成异步的。因为决策链路往往在请求的关键路径上同步调用会增加延迟。我的做法是把 Jev 调用放在一个独立的消息队列里上游系统提交决策请求后立即返回一个任务 ID下游通过回调或轮询获取决策结果。这样即使 Jev 的响应时间是几百毫秒也不会阻塞主流程。5. 常见问题与排查技巧实录5.1 概率分布过于平坦怎么办这是最常见的问题。你拿到五个选项的概率发现都在 0.2 左右几乎没有区分度。原因通常有三个决策空间定义得太细、输入信号不够、或者任务本身就不适合做单步决策。排查顺序是这样的先看决策空间把那些语义上高度重叠的选项合并。比如billing_issue和payment_problem如果业务上处理方式一样就合并成一个。再看输入是不是关键信号没给到模型。比如做意图分类时如果只给当前这句话很多意图确实无法区分需要加上对话历史。最后看任务本身如果这个决策需要多步推理才能做出来那它就不适合 System One 模型你得换方案。5.2 某些选项的概率总是偏低如果某个选项在标注数据里样本很少模型对这个选项的“信心”就会不足导致它的概率被系统性压低。解决办法不是调模型而是调数据。要么补充这个选项的样本要么在损失函数里给这个选项更高的权重。Jev 本身不暴露损失函数所以你只能在数据层面做平衡。另一个可能是这个选项本身定义得不够清晰。我遇到过一种情况escalate这个选项标注人员自己都说不清什么情况下该选它导致标注一致性很低。模型学到的就是一个模糊的边界概率自然上不去。后来我们把escalate的触发条件写成明确的规则文档重新标注了一遍问题就解决了。5.3 延迟波动大Jev 作为 System One 模型理论上延迟应该比较稳定。如果你观察到延迟波动大先检查是不是输入长度差异太大。有些请求输入很短有些很长模型处理时间自然不同。解决办法是控制输入长度把超长输入截断或摘要后再提交。还有一个容易被忽略的点批量大小。批量提交虽然能提高吞吐但单次批量太大时尾延迟会上升。我实测下来批量大小在 20 到 50 之间比较平衡。超过 50 之后吞吐提升不明显但 P99 延迟会明显变差。5.4 常见问题速查表问题现象可能原因排查动作解决方向概率分布平坦决策空间过细 / 输入信号不足检查选项语义重叠度检查输入字段合并选项补充关键信号某选项概率系统性偏低样本不平衡 / 选项定义模糊统计各选项样本量检查标注一致性补充样本明确选项边界延迟波动大输入长度差异 / 批量过大统计输入长度分布检查批量设置截断长输入调整批量大小置信度与实际准确率不匹配未做概率校准按概率分桶统计实际准确率重新设定阈值或做校准映射集成后下游报错下游不接受概率输出检查下游接口契约加适配层或改造下游提示概率校准这件事我建议每上线一个新场景就做一次。不同场景下模型的校准曲线可能完全不同拿 A 场景的阈值去套 B 场景翻车概率很高。6. 我对这类方案的一些实际体会Jev 代表的这条路线本质上是在回答一个问题当大模型从“聊天工具”变成“系统组件”时它的输出形态应该是什么。自然语言是给人看的但系统组件之间对话需要的是结构化、可计算、带不确定性的信号。概率化决策就是这种信号的一种形式。我在实际项目里最大的体会是把决策和表达分开之后整个系统的可维护性上了一个台阶。以前模型输出一段话我要写解析器、写校验、写异常处理代码里到处是防御性逻辑。现在模型直接输出概率分布我的代码只需要处理数值逻辑清晰得多。而且因为决策空间是类型安全的很多错误在定义阶段就被排除了不会留到运行时才暴露。另一个体会是不要指望一个模型解决所有决策问题。Jev 适合的是那些“人类专家看一眼就能判断”的任务。如果某个决策需要查文档、做计算、多步推理那就该用 System Two 的方案或者把任务拆成多个 System One 决策串起来。把对的工具放在对的位置比追求单一模型的万能要务实得多。最后分享一个我在阈值调优上的小技巧不要一次性把阈值定死而是先设一个宽松的初始值上线收集一周的真实数据看看低置信度样本的实际分布再据此收紧。真实数据里的分布往往和你离线测试时看到的不一样因为线上输入的长尾情况比测试集丰富得多。让系统先跑起来再根据实际表现迭代比在离线阶段追求完美阈值要高效。
