一、Jev 是什么Jev 是 TypeSafe AI 推出的旗舰模型官方将它称为首个System One 模型。它和常见的大模型不同Jev接收你提供的材料State和问题Quetions返回类型明确的答案与概率。Jev 爆火一方面是和别的模型的不同更多是因为又快又便宜。它能做到「每百万输入 token 0.042 美元输出免费」的价格也是狠狠掀起一波浪潮。具体可以看官方介绍Introduction - TypeSafeSystem OneSystem One 这个名字借用了《思考快与慢》中的概念System 1 偏向快速、直觉式判断System 2 偏向缓慢、审慎的思考。对应到 Jev比较容易理解的例子是模型获取 “商品收到就坏了我要退款” 的信息给出 咨询、退款、购买 几种可能的选择我们可以利用 Jev 迅速判断出退款意图但要进一步决定是否退款、退多少、由谁承担责任就可能需要核对订单、合同和售后规则。System One 说明如果仅仅只是在做判断我们使用LLM模型陷入深度思考循环着根据概率输出下一个token耗时长token消耗量大。这时候就可以选择分工合作由 Jev 判断出退款的意图然后路由到对应处理退款的Agent去完成后续退款分析处理。二、Jev 的能力Jev 具体使用时最核心的是三种类型。Choice做选择题。你提前给出候选项让模型选择其中一个。例如把客户消息分为“物流咨询”“退款申请”“产品咨询”Jev 会返回选中的类别以及各个选项的概率。Choice 文档Noul做判断题。例如“客户是否明确提出退款”“这段回答是否包含个人信息”返回值是一个 0 到 1 之间的数表示模型估计答案为“是”的概率。假设结果是 0.92表达对这个命题成立的可能性。Noul 文档Score按标准打分。比如评价故障严重程度先定义“0不影响使用”“1部分功能受影响但有替代办法”“2关键功能不可用”再让模型判断材料处于哪个位置。结果可以落在两个等级之间同时返回各等级的概率。Score 文档我们可以拿一个例子来做示范首先需要定义当前问题的状态State商品收到就坏了我要退款。然后定义我们要提问的问题Questions。Jev 可以一次处理多个多种的问题能一次返回结果。Questions 来源程序员成长指北老师懒得编了。{ department: { type: choice, instructions: 这条消息应该由哪个团队处理, criteria: { billing: 扣费、账单、退款和支付问题, technical: 故障、接口和功能异常, account: 登录、密码和账户信息, other: 不属于以上类别 } }, refund_requested: { type: noul, instructions: 用户是否明确要求退款 }, frustration: { type: score, instructions: 用户表现得有多不满, criteria: [ 平静只是在陈述事实, 不满但仍保持克制, 非常愤怒使用强烈措辞 ] } }三、Jev 试用保姆级教程首先进入TypeSafe官网Home - TypeSafe AI点击 API console 即可进入控制台。目前的登录页面支持通过 Google 或邮箱登录、创建账号。登录的时候可能会出现多次登录失败的情况多重试几次。初次体验可以先用浏览器里的 Playground放入一段材料设置问题和选项观察返回结果。需要接入程序时再到控制台获取 API Key通过 Python、JavaScript SDK 或 HTTP API 调用。官方也提供了供编程助手使用的 TypeSafe Skill。快速开始看网上说是新用户会送5刀但是我注册进入没有送所以充值了5刀点击Balance输入银行卡信息即可万事达可用。四、Jev 适合的业务场景结合官方案例和社区实践我把使用场景分成几类。第一类是分类与分流。客服工单、用户反馈、商品描述、邮件都可以先由 Jev 识别意图或主题再交给对应流程。放到 AI 应用里也可以先判断请求属于什么领域、需要什么能力再由代码选择处理工具或模型。也就是前面提到的由 Jev 快速做意图判断能力强的模型做深度思考给出最终解决方案。官方场景介绍第二类是筛选与排序。搜索系统找到一批候选文档后可以继续判断每段材料是否真正回答了用户的问题再据此调整顺序。知识库问答、资料筛选都可以用到这个思路。官方重排序案例第三类是检查与复核。比如检查回答中的引用是否支持结论、工具调用是否偏离用户意图、文本是否包含需要复核的内容。它可以作为一道检查环节为后续操作提供信号。官方应用场景第四类是 Agent 内部的信息取舍。一个 Agent 连续工作时会积累大量日志、文件内容和工具结果。社区已经有人尝试用 Jev 判断哪些历史信息值得保留再由程序执行保留、截断或删除。这个方向很有意思原始内容可以原样留下模型只负责判断它是否仍有价值。中文社区实践文章我的看法业务历史包袱较轻、判断标准清楚、所需信息能直接提供的任务更容易用 Jev 做出可用的效果越依赖隐性经验、历史约定和复杂例外落地难度就越高。例如“客户有没有表达不满”通常从当前对话就能判断。但“这个客户是否应该获得额外补偿”可能涉及过去的服务事故、客户等级、销售承诺以及某次特殊审批。一个刚加入公司的员工不知道这些背景也很难作出正确判断。模型同样如此漏掉了决定答案的事实即使理解文字的能力很强也可能给出一个看似合理、实际不符合业务要求的结果。用简单的例子体感可能不会很深刻在接触到实际的业务场景时因为背后复杂的业务历史背景Jev 很可能作出不符合业务要求的判断。所以在特定业务场景下对模型做微调、后训练能更为合适。五、Jev 当前版本名称当前含义jev-latest稳定版目前最新版本为jev-1.14.0jev-preview预览版目前最新版本为jev-1.14.0目前jev-latest 和 jev-preview均列为文本输入价格为每百万输入 token 0.042 美元输出免费。官方模型与版本说明六、为什么 Jev 能返回“结果和概率”这样固定的格式这里不是想表达 Jev 能输出稳定的某个概率或者是选择某个结果他做最后的选择还是概率性的比如这次可能是财务 0.98,下次也可能是财务0.95。但是它能保证它输出的结果就在给的这几个选项里这是怎么做到的其实这是大模型的共性问题其他模型我们在使用时也会有约束输出结果格式的情况。如果我们只是在 prompt 里面去对输出结果的格式进行约束那模型很可能会因为上下文过长出现幻觉等等因素。最后忘记这个约束输出不符合这个约束的结果。第一种是把 Schema 写进提示词告诉模型“请按照这个格式回答”这仍然依赖模型遵守指令它可能多说一句话也可能漏字段。第二种是通过 API 专门的结构化输出参数提交 Schema由推理服务把规则变成生成时的限制。前一种是要求模型遵守规则后一种是在模型选择输出时直接限制它有哪些选择。Claude 官方说明其结构化输出使用的是编译后的语法约束。Claude 官方文档拿如下场景来说假设规则是{ type: object, properties: { department: { type: string, enum: [财务, 技术] } }, required: [department], additionalProperties: false }这个规则要求输出一个对象必须有department字段字段值只能是“财务”或“技术”而且不能增加其他字段。对应的合规结果可以是{department:财务}下面这种结果就不符合规则接下来我回答您这个问题我的答案是财务。约束解码怎么把第二种结果挡住它会在每一步生成时过滤掉不允许出现的 token。模型原本会给大量候选 token 打分解码器再根据这些分数选择输出。加入语法约束以后系统会结合“目前已经输出到哪里”和“规则接下来允许什么”给候选 token 加一个过滤器。会让输出脱离合法结构的候选项被禁止剩下的候选项才能参与选择。XGrammar 对约束解码的说明
