过去几年我们习惯了这样使用大模型提出一个问题然后等待它生成一段回答。比如这条用户反馈严重吗这篇文章质量怎么样这个销售线索值得跟进吗这个产品创意有没有继续验证的价值ChatGPT、Claude 这样的通用模型都可以回答这些问题而且通常还能给出相当完整的分析。但如果我们换一个角度就会发现另一类需求正在出现我并不需要 AI 再给我写一篇分析我只是需要它稳定地判断一个变量。例如是否紧急 0.87 用户挫败感 2.1 / 4 应该分配给哪个部门 technical 是否存在明显风险 0.73这些结果不是为了给人阅读而是为了让程序继续执行下一步。Jev 正是针对这类问题而设计的。一、Jev 是什么Jev 是 TypeSafe AI 提供的一种结构化 AI evaluation 模型。它的基本思路与普通聊天模型有明显区别。使用 ChatGPT 时我们通常是Prompt ↓ LLM ↓ 自然语言回答而 Jev 的基本结构是State Questions ↓ Jev ↓ Structured Answers你首先提供一个需要被判断的state。它既可以是一段文本也可以是 object 或 array因此可以表示用户消息、聊天记录、业务数据、Agent 当前状态等。然后定义一个或多个明确的问题Jev 返回对应的结构化结果。(TypeSafe AI)目前 Jev 的核心问题类型有三种Noul、Choice 和 Score。官方 Playground 和 API 都允许在一次请求中混合使用这些问题。(TypeSafe AI)Noul 适合回答 Yes / No 类型的问题例如“这条消息是否表现出明显的紧迫性”但它返回的不是简单的true / false而是一个 01 的概率值。(TypeSafe AI)Choice 用于从预先定义的候选项中选择例如billing technical salesJev 不仅会返回选择结果还会给出各候选项的概率分布。(TypeSafe AI)Score 则适合按照一个有序 rubric 进行评分。例如0 没有明显挫败感 1 有些不满 2 明显沮丧 3 强烈愤怒Jev 返回的是基于这些等级概率分布计算出来的 score而不是简单选择一个整数档位。(TypeSafe AI)于是我们可以把 Jev 粗略理解成一个把非结构化语义信息转化成结构化概率信号的模型。二、它与 ChatGPT 到底有什么区别这可能是理解 Jev 最重要的问题。因为如果问“ChatGPT 能不能判断一条客服消息是否紧急”答案当然是能。甚至如果让 ChatGPT 分析为什么紧急它通常还能给出比 Jev 丰富得多的解释。所以 Jev 的价值并不是“它能做 ChatGPT 做不到的事情”。两者真正的区别在于产品目标不同。ChatGPT 更像一个通用知识工作者研究 分析 解释 推理 生成 讨论 提出方案而 Jev 更像一个Semantic Measurement Engine——语义测量引擎。它并不试图完整解决一个开放问题而是把一个已经定义清楚的问题变成稳定、结构化、程序可以直接使用的信号。可以这样比较能力ChatGPTJev开放式分析很适合不属于主要用途创意与方案生成很适合不适合深度解释原因很适合有限固定 rubric 判断可以核心用途Yes/No 概率可以构造原生能力多类别概率分布可以构造原生能力结构化评分可以原生设计批量自动判断可以更自然程序直接消费结果需要额外约束天然适合Workflow / Agent Gate可以很适合所以二者不是简单的竞争关系。一个很自然的组合方式反而是ChatGPT 负责理解问题、研究、分析、生成 ↓ 形成结构化 State ↓ Jev 负责固定标准下的语义测量 ↓ 结构化信号 ↓ 普通程序 执行确定性逻辑也就是说ChatGPT 更像 AnalystJev 更像 Instrument。三、Jev 最值得关注的能力Semantic IF传统程序最擅长处理明确的数据条件。例如ifprice100:...或者ifretry_count3:...但现实世界中大量重要条件并不是数字。例如用户现在是不是非常生气这份材料里的证据是否充分这段回复有没有回避用户的问题这条内容有没有明显的销售意图这个 Agent 的结果是否值得提交给人工审核过去这些条件往往意味着人工阅读 → 判断 → 操作而大模型带来的一个重要变化是我们开始可以把它们转换为类似iffrustration_probability0.8:escalate()或者ifevidence_sufficient0.85:continue_workflow()这里的frustration_probability和evidence_sufficient并不是传统数据库字段而是 AI 从自然语言或复杂状态中计算出来的语义变量。这可能是理解 Jev 最好的方式Jev 可以成为软件系统里的 Semantic IF。它连接的是两个原来相距很远的世界自然语言 / 人类语义 ↓ Jev ↓ 数字 / 类别 / 概率 ↓ 传统软件逻辑四、哪些场景特别适合 Jev判断 Jev 是否适合一个任务可以先问一个问题这个任务是不是“给定一个 State反复判断几个已经定义好的语义变量”如果答案是肯定的Jev 通常就值得考虑。客服、工单和反馈分类这是最直接的一类应用。比如一条用户反馈进来可以同时判断department urgency frustration refund_intent churn_risk needs_human_reviewTypeSafe 官方 Quick Start 使用的就是类似例子根据客服文本判断处理部门、用户 frustration 和 urgency。(TypeSafe AI)真正有价值的地方并不是“分类”本身而是这些信号可以马上进入后续系统用户消息 ↓ Jev ↓ Urgency 0.93 Frustration High Department Technical ↓ 提高优先级 分给技术支持 必要时人工介入内容审核和质量控制很多质量问题很难靠关键词解决。比如回答是否真正解决了用户问题是否存在明显夸大是否缺乏必要证据是否符合品牌语气是否存在需要人工复核的风险这些问题都有一个共同特征人很容易理解但很难写成传统规则。而一旦它们能够定义成相对稳定的 rubric就很适合交给 Jev 做重复测量。AI Agent 的质量门控这一类场景可能比单纯分类更有价值。未来越来越多工作流会是Agent 1 执行任务 ↓ Agent 2 继续执行 ↓ 调用外部系统 ↓ 最终提交问题在于什么时候允许 Agent 继续例如证据是否充分 任务是否真的完成 结果是否与要求一致 是否存在明显风险 是否需要人工介入这时 Jev 可以位于 Agent workflow 中间Agent Output ↓ Jev ↓ quality_sufficient 0.91 needs_review 0.08 ↓ 继续执行它承担的是语义 Gate。销售、CRM 和线索处理大量销售数据其实是非结构化文本邮件、聊天记录、电话摘要、会议纪要。可以提取购买意图 价格敏感度 决策阶段 流失风险 下一步行动意愿然后再交给普通 CRM 系统处理。关键仍然不是让 Jev“替销售员思考”而是把大量文本转化成可比较的业务信号。用户研究和评论分析如果有几条评论直接让 ChatGPT 阅读通常更方便。但如果是1000 条 10000 条 100000 条问题开始变化。此时更重要的是把评论稳定地变成control_problem ads_complaint difficulty content_shortage pricing_problem frustration retention_signal然后统计Controls 27% Ads 22% Difficulty 16% Content 14% ...最后再让 ChatGPT深入研究最重要的几个 cluster。于是形成一种很合理的分工Jev 做宽度ChatGPT 做深度。Rubric 型评价系统还有大量工作本质上不是分类而是按照固定标准反复评估。比如简历质量 文章结构 学习作业 设计方案 测试报告 项目文档 产品需求 销售话术如果评价维度已经明确就可以使用 Score 建立有序 rubric。例如Evidence Quality 0 无证据 1 很弱 2 部分支持 3 较强 4 充分支持Jev 的 Score 就是专门针对这种有序评价设计的。(TypeSafe AI)五、哪些场景反而不适合 Jev理解“不该什么时候用”同样重要。如果你的问题是帮我想一个新的产品。为什么这个游戏不好玩研究一下这个行业未来三年的机会。比较五种方案并重新设计一个更好的方案。帮我从这些现象中找出一个我还没想到的问题。这类任务的核心不是测量而是探索 推理 研究 综合 创造这正是 ChatGPT 这类通用模型更擅长的领域。一个简单的区分方式是如果你想问“你怎么看”大概率应该先找通用大模型。如果你想问“按照我已经定义好的标准这个东西是多少”Jev 就开始变得有价值。六、使用 Jev 前一个容易被忽视的问题先校准“尺子”Jev 的结构化输出很容易让人产生一种错觉0.82看起来非常精确。但“数字精确”不等于“概念定义正确”。假设你问“是否存在重复策略”这里至少可能混进三种完全不同的东西操作动作重复 决策模式重复 存在一个通吃策略如果问题本身没有定义清楚再稳定的模型输出也没有意义。因此真正把 Jev 接入生产流程之前更合理的方法是先建立一小组明确正样本 明确负样本 边界样本 容易混淆的反例检查它是不是按照你的业务定义在判断。一旦某一种 evaluator 被验证并冻结就不需要每次调用前重新测试但当 rubric、输入结构、模型版本或者业务领域发生明显变化时应重新运行 regression test。这和测量仪器很相似不是每测一个对象都重新校准而是在建立和修改测量体系时校准。这也意味着在实际项目中Jev 的质量很大程度上取决于你有没有真正想清楚“自己到底要测什么”。七、不要因为能用 AI 判断就把所有判断都自动化这是使用这类工具时很容易犯的另一个错误。如果每天只需要人工判断三五个案例那么人 ChatGPT可能已经足够。为了几个判断再建立Evaluator Regression Dataset API Pipeline 数据库 Decision Engine Monitoring很可能属于过度工程。Jev 真正开始体现价值通常是在下面这种情况下判断次数很多同一个标准会长期重复使用不同案例之间需要可比较结果需要直接进入程序Agent 必须根据判断自动继续工作人工处理已经成为规模瓶颈。因此是否使用 Jev不应该从“它挺新我能不能把它加进项目”开始。更好的问题是“我现在有没有一个高频、稳定、重复的语义判断问题”如果没有就没有必要强行引入。八、Jev 真正值得关注的并不只是一个新模型我认为 Jev 背后更值得关注的是一种新的软件设计方式。过去的软件世界大致分成两部分结构化数据 确定性规则大模型出现以后软件开始能够处理语言 语义 模糊状态 人类判断但如果所有事情都交给一个 ChatGPT 式 Agent 从头推理到尾又会产生另外的问题难测试 难比较 难控制 难复现 难接入确定性系统于是一个新的中间层开始变得重要非结构化世界 ↓ LLM Semantic Evaluation ↓ 结构化概率信号 ↓ 确定性软件Jev 所代表的正是这一层。它既不是传统规则引擎也不是一个试图包办所有事情的通用 AI Agent。它更像一组AI-native sensors。程序过去只能感知数字 时间 状态 事件以后则可能开始感知紧迫 满意 风险 相关 充分 清晰 有价值 值得复核而一旦这些原本只能由人理解的概念能够稳定地变成机器信号很多自动化流程的边界就会发生变化。所以对 Jev 最合适的理解可能不是“它是不是比 ChatGPT 更聪明”而是“哪些原来必须由人完成的语义判断现在可以变成软件系统中的一个变量”如果你能找到这样一个高频、稳定、可定义、可验证的问题那么 Jev 就值得认真考虑。如果找不到继续用 ChatGPT也完全没有问题。这可能才是判断是否需要 Jev 的最好标准。
