Jev 与可视化

最近 Jev 很火，火到 Reddit 和 X 上到处都是讨论。我第一时间申请了 waitlist，第二天就通过，把它实际用了起来。它和我们熟悉的 GPT、Claude、Gemini 很不一样：不会写文章，不会写代码，甚至不会真正意义上“回答问题”，只干一件事情——判断。

比如问它“比较贵州茅台和五粮液过去五年的营收变化，该用折线图、柱状图、饼图还是散点图”，它返回的不是一段分析，而是类似“折线图 0.86、柱状图 0.10、散点图 0.03、饼图 0.01”这样的带分数排序，程序拿到就能直接消费。

TypeSafe 把这一类模型称为 System One Model：面向快速、结构化决策，而不是开放式生成。按官方的描述，它把非结构化状态直接转换成软件可以消费的概率决策，技术栈围绕新的模型架构、并行采样和 RLCD（Reinforcement Learning for Calibrated Decisions）构建。

如果一定要用一句话描述 Jev，我更愿意叫它 Semantic IF，一个懂语义的 if。

---

一、Jev 是什么？

传统程序非常擅长这种判断：

if (value > 100) {
  // ...
}

但它不擅长这种：

if (这个用户更想看趋势而不是精确数值) {
  // ...
}

因为后者不是一个简单的数学条件，而是一个语义判断。过去我们通常把这种事交给 LLM：输入丢进去，拿回一篇长篇分析，再解析成 JSON 给程序用，链路拉得很长。Jev 想做的就是把中间这段砍掉：状态进去，Choice / Score / Probability 出来，程序直接消费。

所以 Jev 最适合的问题通常有两个特点：答案空间已经知道，但又没法用简单规则判断。比如这段日志有没有价值（YES / NO）、这个请求属于什么意图（查询 / 比较 / 解释 / 预测）、下一步该调用哪个工具（Tool A / B / C）、几个候选结果里哪个最好。这些都是典型的 Jev 问题。

---

二、Jev 不是什么？

理解 Jev，更重要的是理解它不是什么。

Jev 不是 LLM 的替代品

如果问题是“为什么这个系统出现了性能问题”，那需要理解代码、分析因果关系、构建假设再验证假设。这是 reasoning model 的活，不是 Jev 的。

Jev 不是 Agent

Browser Use 最近开源的 jev-ultrafast 很容易让人误以为 Jev 是一个超快 Browser Agent，实际上不是。它的做法是先读取网页 DOM、把可交互元素编号，然后由 Jev 判断这一步做什么、操作哪个元素，最后交给 Browser 执行；如果判断需要输入文字，再另外调一个小型 LLM 来生成内容。也就是说，Jev 是决策层，Browser Harness 是执行层，LLM 是文本生成层，Code 是控制层，几层拼起来才是一个 Agent。

Browser Use 的公开实现里，Google Flights 示例耗时约 7.073 秒；一次实验中 Jev 调用的中位延迟约 178ms；优化版本相比基线，整体任务中位耗时下降约 25%。不是“整个 Agent 快 200 倍”。模型判断快，并不等于整个系统同比例变快。

Jev 也不等于“不会犯错”

所谓结构化输出，甚至宣传里的 “Zero Hallucination”，更准确的理解是它不会生成候选空间之外的答案。你给 A / B / C，它不会突然返回 D，但完全可能正确答案是 A 而它选了 B。所以结构可控不等于判断一定正确，Jev 解决的是输出空间的问题，不是“智能永远正确”的问题。

---

三、Jev 能解决什么，又不能解决什么？

可以粗略分成下面几类。

问题类型	是否适合 Jev
意图分类	很适合
候选项选择	很适合
相关性判断	很适合
简单质量判断	很适合
Agent Router	很适合
工具选择	很适合
日志筛选	很适合
图表候选排序	可以
复杂方案设计	不适合
开放式代码生成	不适合
多步复杂推理	不适合
数学和确定计算	应该交给 Code
创造一个全新的视觉方案	不适合

因此一个非常实用的原则是：可以精确计算的交给 Code，能明确写成规则的交给 Rule，需要语义理解但答案空间有限的交给 Jev，需要复杂推理或生成的交给 LLM，涉及关键价值判断的留给人。

---

四、Jev 为什么和“可视化”看起来特别契合？

Jev 出来以后，我一直在想它到底适合什么场景。最先想到的是需求澄清：这个环节里有很多“是否”要确认，看起来正是 Jev 擅长的有限答案空间判断。但后来分析下去发现，这些确认直接让一个经验丰富的人制定一张表单、新人照着填写，也能达到效果，甚至更好，所以这个场景似乎也没有 Jev 的用武之地。再往后我把重点放到了可视化开发上，因为这里面其实充满了大量“小判断”。例如用户问“对比宁德时代、比亚迪和亿纬锂能过去五年的营收和净利润变化”，系统在真正开始绘图之前，要连续判断用户是在看趋势还是截面比较、有没有时间维度、是一个指标还是多个指标、多指标是否同量纲、实体数量多少、应该优先表格还是图、数据量要不要降采样、值不值得再生成第二张图；真要画图，还得在折线图、分组柱状图、多图、组合图之间选。

这些事情并不需要 GPT 写一篇分析报告，它们更像大量、高频、有限答案空间的语义判断——这恰好是 Jev 的舒适区。

---

五、Jev 在可视化里比较适合做什么？

1. 图表候选选择

例如当前数据是 2 个公司、1 个指标、20 个时间点，用户意图是比较长期趋势，候选有 Line、Grouped Bar、Scatter、Table。Jev 给出的排序可能是 Line 0.89、Grouped Bar 0.07、Table 0.03、Scatter 0.01，这比让一个大型 LLM 输出几百 Token 的分析明显轻得多。

2. Fast / Slow Path Router

判断这个需求能不能直接用标准组件完成：能就走 Fast Path，不能再交给 LLM 或 Agent。对 AI 可视化系统来说，这是个非常典型的应用。

3. 可视化结果质量 Gate

当前结果是否明显违反用户意图？是否遗漏关键指标？要不要再补一张图？是否值得升级给更强的模型检查？这些判断并不一定需要完整的大模型。

4. 候选组件 / 模板召回后的排序

假设组件库已经召回了 Template A 到 D，Jev 可以负责判断当前上下文里哪个最匹配。这里它更像一个轻量 Ranker。

---

六、但是：图表推荐真的应该用 Jev 吗？

这里需要冷静一点。假设目标非常明确：根据用户问句和数据特征，决定应该使用什么图表。如果这是一个长期存在、高频调用、有大量领域经验积累的核心能力，我反而认为 Jev 很可能不是最终形态。

原因在于这个任务有几个很明显的特点：图表类型相对稳定，数据结构相对稳定，有大量可积累的历史案例，可视化领域的规则又非常多；同样的判断每天会重复发生大量次，而且我们希望模型真正学习自己的可视化经验。这种任务天然适合训练自研领域模型。

---

七、Jev VS. 自研领域小模型

这是两者真正的区别。

Jev：运行时理解规则

可以把 Jev 理解成“通用语义能力 + 当前上下文 + 当前候选项 + 当前判断标准”，拿到以后直接判断。优势是不用训练，马上就能用。

自研领域模型：把经验训练成本能

例如我们有大量这样的知识：什么时候该用折线图、什么时候柱状图更好、多少条序列以后该避免多折线、什么时候用户真正关心的是排名而不是具体数值、什么时候事实卡或者表格比图更合适、金融指标之间有什么特殊语义。这些知识可以通过大量训练数据进入模型，最终的形态就是 query、data profile、business context 进去，Visualization Model 出来一份 chart ranking。

换句话说，Jev 是临场看着规则做判断，领域模型是把规则练成了条件反射。

---

八、两者的核心差异

维度	Jev	自研领域小模型
启动成本	很低	高
是否需要训练数据	不需要	需要
新增任务	很方便	可能需要重新训练
候选空间变化	灵活	相对麻烦
领域知识	运行时注入	可以进入模型权重
领域能力上限	受通用模型能力限制	有机会更高
本地部署	受服务形态限制	可以
延迟	毫秒到数百毫秒级	本地可做到更低
大规模边际成本	低	可以非常低
调试成本	低	更高
模型维护	简单	需要完整训练体系
产品策略变化	非常灵活	不能全部训进模型

所以这不是谁一定比谁好的问题，而是任务处在哪个阶段。

---

九、对于图表推荐，我更倾向自研领域模型

如果一个判断只是偶尔出现，比如“这张图是不是应该展示 Tooltip”，没必要训练模型，Jev 非常合适。但如果每一条用户问句进来都要决定推荐什么图表，这实际上已经是系统的核心能力。这种情况下我们真正需要的是一个 Visualization Ranking Model，而不是一个通用的 Jev 调用。

---

十、甚至未必需要 1.5B / 2B 模型

这是另一个容易走入的误区，因为图表推荐不等于文本生成。如果前面已经把输入程序化整理成：

{
  "intent": "trend_comparison",
  "entityCount": 3,
  "metricCount": 2,
  "hasTime": true,
  "timePointCount": 20,
  "xType": "temporal",
  "yType": "quantitative"
}

那后面实际上只剩一个问题：哪个图表最适合？这是典型的 Classification / Ranking 问题，完全可以从规则模型、LightGBM / XGBoost、小型 Encoder、Learning-to-Rank、几百 M 参数模型开始尝试，而不是一上来就“我要训练一个 2B LLM”。

一个很重要的工程原则：模型大小应该是实验结果，而不是架构前提。如果一个 200M 模型已经达到 95% 准确率，就没有理由上 2B。

---

十一、真正推荐的可视化架构

对于 AI 可视化系统，我更倾向于下面这种设计：

                 用户问题
                    │
            ┌───────┴────────┐
            │                │
       语义理解          数据程序化解析
            │                │
            └───────┬────────┘
                    ↓
              Feature Schema
                    │
                    ↓
              Hard Rules
                    │
         排除明显错误的图型
                    ↓
              Candidate Set
                    │
                    ↓
        Visualization Ranker
                    │
          TopK + Confidence
                    │
        ┌───────────┴───────────┐
        │                       │
   高置信度                  低置信度
        │                       │
   直接生成                 Jev / LLM
                                │
                              复核

Jev 在这里并没有消失，只是从核心决策器变成了长尾判断器、快速 Judge 和 Fallback。我认为这是更合理的位置。

---

十二、可视化经验也不应该全部训练进模型

另一个常见错误是：既然要训练领域模型，就把所有经验都塞进去。实际上不同的知识应该放在不同的层。

确定性原则 → Code

例如“没有 part-to-whole 关系，就不推荐饼图”。规则已经足够明确的东西，就不应该让模型去“猜”，直接写成代码。

稳定但模糊的领域经验 → Model

例如“这个问题表面上在问数据，但真正想比较的是长期趋势和稳定性”。这种需要语义理解的知识适合训练。

经常变化的产品策略 → Config / Prompt / Jev

例如“当前版本优先减少生成图数量”。这是产品策略，不应该训练进模型，否则每次策略调整都要重新训练。

按这个分法，Jev 适合待在 Model 和 Config 之间，负责那些动态但又需要语义判断的问题。

---

十三、Jev 最大的优势，其实是探索阶段

如果今天突然有人提了一个新判断，比如“我们要判断一张表是不是值得生成图”，直接自研模型的话，要先定义任务、收集数据、标注、训练、评测、上线，成本很高。而 Jev 只要定义好候选、调 API，就能开始跑真实流量。

于是我们很快就能知道：这个判断到底值不值得做？判断标准稳不稳定？数据分布是什么样？误判集中在哪里？到这一步，Jev 的价值非常大。

所以一个很合理的演进路径是：先用 Jev 或大模型快速验证问题，再收集真实数据和专家反馈，形成稳定的 Eval，然后训练领域小模型，最后让小模型承担主流量，Jev 和 LLM 处理长尾。换句话说，Jev 适合去发现哪些判断值得做成模型，真正把它规模化还是要靠领域小模型。

---

十四、真正应该比较的不是 Jev 和 1.5B

最后再回到一个更本质的问题。真正不该问的是“Jev 和 1.5B 模型哪个强”，该问的是：这个判断是否已经稳定到值得训练一个模型？

如果今天才想到这个判断，而且规则以后很可能变化，用 Jev。如果它是核心业务能力，每天几十万次调用，手上已经有几万条高质量历史样本，训练领域模型。如果这个规则其实可以直接写成代码，那两个都不要用。

---

十五、结语：不要让一个模型解决所有问题

过去的 AI Agent 有一个很明显的问题：所有问题都塞给一个大模型。但一个成熟的软件系统不应该这样设计。更合理的分工是：能精确计算的交给 Code，能写成明确规则的交给 Rule；临时、动态、答案空间有限的语义判断交给 Jev；长期、高频、稳定的领域判断交给 Domain Model；复杂推理和开放生成交给 LLM；最终执行结果再交给 Verifier 复核。

对可视化尤其如此。图表推荐、组件召回、数据解释、布局策略、质量检测，看起来都属于“AI”，但它们本质上不是同一种问题。

Jev 的真正价值不是替代 GPT，也不是替代领域模型。智能不一定要以“生成文字”的形式存在，很多时候我们需要的只是在正确的时间，快速做一个足够好的判断。

而对于那些真正决定可视化产品竞争力的、长期稳定的领域判断，最终仍然应该把自己的专家经验变成规则、数据、模型和 Eval。Jev 可以是这条路上很好用的一块积木，但它不应该成为整栋房子。