为什么最近开始关注 JEV？几个实战案例告诉你答案

本文目录

01 JEV 到底是什么？

最近 AI 圈出现了一个挺有意思的新东西：**JEV**。

第一次看到它的时候，我的第一反应也是：

又一个 AI 模型？

但真正了解之后，会发现它和 GPT、Claude 这类模型的思路并不太一样。

LLM 擅长“生成”，而 JEV 更关注“做决定”。

这听起来好像只是换了一个说法，但如果你正在研究 Agent、RAG、AI Coding、AI 应用开发，这个区别其实非常值得关注。

01 JEV 到底是什么？

简单来说：

JEV 是一种面向决策的 AI 模型。

传统 LLM 最擅长的是：

用户问题
   ↓
LLM
   ↓
生成文本

比如：

这个用户是不是高价值客户？

你让 GPT 回答，它可能会输出：

从用户的消费记录、活跃程度以及历史行为来看，
这个用户具有较高的潜在价值……

然后你的程序还得想办法从这段文字里提取：

<span>{</span>
  <span>"is_high_value"</span><span>:</span> <span><span>true</span></span>
<span>}</span>

JEV 的思路则更加直接：

输入数据 + 判断问题
<span>        ↓
       JEV
        ↓
    Decision
</span>

也就是：

是不是？
选哪个？
概率多少？
风险多高？

这些事情交给专门的 Decision Model。

02 为什么需要一个“只会做决定”的模型？

这个问题其实非常关键。

我们现在开发 AI Agent，经常会遇到这种代码：

<span>result</span> = llm.invoke(<span>"""
判断这个请求应该使用哪个工具：
1. search
2. calculator
3. database
"""</span>)

<span># 然后解析 LLM 返回的内容</span>
<span>tool</span> = parse_result(result)

看起来没问题。

但实际上，一个简单的：

“应该选择哪个工具？”

也需要经过一次完整的 LLM 调用。

而且还可能遇到：

输出格式不正确
<span>JSON</span> 解析失败
模型给出解释
模型没有按照要求选择
概率无法直接使用

于是很多 AI 应用最终变成：

<span>LLM</span>
 ↓
<span>Prompt</span>
 ↓
<span>JSON</span>
 ↓
<span>Parser</span>
 ↓
<span>if</span> / <span>else</span>
 ↓
业务逻辑

JEV 想解决的恰恰就是这一层。

03 JEV 最有意思的地方：Typed Decision

JEV 的一个核心思路可以理解成：

让 AI 的输出天然成为程序可以使用的 Decision。

例如：

用户提交了一段代码

问题：
这段代码是否存在安全风险？

得到：

<span>{</span>
  <span>"probability"</span><span>:</span> <span>0.91</span>
<span>}</span>

程序直接：

if probability > <span>0.8</span>:
    <span>require_review</span>()

AI 不再负责“写一段话告诉你应该怎么办”。

而是：

AI → Decision → <span>Code</span>

这其实是一个非常重要的变化。

04 第一个实战：Agent Router

我认为这是 JEV 非常适合的场景。

假设我们做一个 AI 助手。

用户可能提出：

帮我查一下天气

帮我分析这条 <span>SQL</span>

帮我查一下数据库里的订单

传统 Agent：

<span>User</span>
 ↓
LLM
 ↓
Tool Calling
 ↓
Weather <span>/</span> <span>SQL</span> <span>/</span> Database

现在可以增加一个 Decision Layer：

                 ┌── Weather Agent
                 │
<span>User</span> → JEV ──────┼── <span>SQL</span> Agent
                 │
                 └── Database Agent

JEV 不负责完成任务。

它只负责回答：

“这个请求应该交给谁？”

这种任务非常适合 Decision Model。

05 第二个实战：RAG

这可能是我比较关注的一个方向。

我们现在做 RAG，通常是：

Query
 ↓
Embedding
 ↓
Vector Search
 ↓
<span>Top</span> K
 ↓
LLM

但 Vector Search 有一个问题：

相似 ≠ 真正相关。

例如：

Query：
MySQL 为什么出现死锁？

向量搜索可能找到：

MySQL 锁机制
MySQL MVCC
MySQL 性能优化
MySQL 事务
MySQL 索引

这些都“看起来相关”。

但是到底哪个最相关？

这里就可以加入 JEV：

Query
 ↓
Vector <span>Search</span>
 ↓
候选文档
 ↓
JEV
 ↓
相关性判断
 ↓
Ranking
 ↓
LLM

甚至可以让 JEV 对每个文档打分：

Document <span>A</span> → <span>0.91</span>
Document <span>B</span> → <span>0.73</span>
Document C → <span>0.42</span>
Document D → <span>0.18</span>

然后：

<span>documents</span> = sorted(
    documents,
    <span>key</span>=lambda x: x.score,
    <span>reverse</span>=<span>True</span>
)

这就从：

“搜索相似内容”

变成了：

“让 AI 判断哪些内容真正值得进入 Context。”

06 第三个实战：代码 Review

这个场景也很有意思。

比如 Git 提交：

+ <span>user</span> = get_user(id)
+ <span>user.password</span> = request.password
+ save(user)

我们可以问 JEV：

这个代码变更是否存在安全风险？

得到：

0.93

然后：

if risk > <span>0.8</span>:
    <span>block_merge</span>()

整个流程：

Git Diff
   ↓
JEV
   ↓
Risk Score
   ↓
┌──────────────┐
│ > 0.8        │ → 人工 Review
│ 0.5 ~ 0.8    │ → 进一步检查
│ < 0.5        │ → 自动通过
└──────────────┘

这里 JEV 甚至不需要告诉你：

“我认为这段代码可能存在……因此建议……”

它只需要提供一个机器可以消费的判断结果。

07 第四个实战：数据库

更有意思的是，JEV 已经有人尝试和 PostgreSQL 结合。

想象一下以后数据库里可以出现类似这样的逻辑：

<span>SELECT</span> <span>*</span>
<span>FROM</span> tickets
<span>WHERE</span> jev(ticket, <span>'customer is angry'</span>);

甚至：

<span>SELECT</span>
    ticket,
    jev_prob(ticket, <span>'customer is angry'</span>) <span>AS</span> score
<span>FROM</span> tickets
<span>ORDER</span> <span>BY</span> score <span>DESC</span>;

这意味着数据库查询不再只有：

<span>WHERE</span> age <span>></span> <span>18</span>

还可以逐渐出现：

<span>WHERE</span> AI 判断满足某个条件

当然，这种方式到底能不能成为主流数据库能力，目前还需要继续观察。

但从开发者角度看：

这个方向真的很有意思。

08 JEV 和 GPT 到底是什么关系？

我觉得不要把它理解成：

GPT vs JEV

更准确的是：

<span>             AI Application
                    │
          ┌─────────┴─────────┐
          │                   │
       Generate            Decide
          │                   │
   GPT / Claude             JEV
          │                   │
   生成内容、代码          判断、分类
   推理、对话              路由、打分
          │                   │
          └─────────┬─────────┘
                    ↓
                  Agent
</span>

未来一个 Agent 完全可能是：

LLM
 ↓
复杂推理
 ↓
JEV
 ↓
做决定
 ↓
Tool
 ↓
JEV
 ↓
验证结果
 ↓
LLM

也就是说：

LLM 负责“大脑”，JEV 负责大量明确的判断。

09 这可能改变我们设计 Agent 的方式

以前我们很容易形成一种思维：

“有什么问题都丢给 LLM。”

于是：

判断
 ↓
LLM

分类
 ↓
LLM

路由
 ↓
LLM

验证
 ↓
LLM

生成
 ↓
LLM

最终：

一个 Agent 里塞了很多 LLM 调用。

而 JEV 提供了另外一种思路：

复杂任务 → LLM

简单判断 → Decision Model

确定规则 → <span>Code</span>

数据检索 → Search / Database

最终执行 → Tool

这其实更接近传统软件工程的思想：

让不同类型的问题交给不同类型的组件。

10 当然，JEV 现在还远没有到“颠覆一切”的程度

这一点也需要冷静看待。

JEV 目前还是非常早期的技术。

它真正的效果，还需要继续验证：

和传统 LLM Function Calling 相比怎么样？
准确率怎么样？
延迟怎么样？
成本怎么样？
长上下文能力怎么样？
复杂决策能力怎么样？
在真实生产环境中的稳定性怎么样？

这些都需要大量实践。

所以现在更适合把 JEV 看成：

一种值得关注的新 AI Application Primitive。

而不是：

“GPT 的替代品”。

11 我为什么觉得它值得关注？

因为 AI 应用正在发生一个变化。

早期：

<span>AI</span> = Chat

后来：

<span>AI</span> = Copilot

再后来：

<span>AI</span> = Agent

而 Agent 真正进入软件系统以后，会出现大量这样的需求：

是否调用工具？
应该调用哪个工具？
这个结果可信吗？
这个文档相关吗？
这个请求有风险吗？
这个用户属于哪一类？
这个任务应该交给哪个 Agent？

这些问题其实都不是：

“帮我写一段文章。”

而是：

“帮我做一个决定。”

这正是 JEV 试图切入的地方。

12 最后

如果让我用一句话总结 JEV：

LLM 让 AI 学会“说什么”，而 Decision Model 开始让 AI 学会“选什么”。

对于普通聊天应用来说，JEV 可能没有那么重要。

但对于：

AI Agent
RAG
AI Coding
Workflow
自动审核
风险控制
推荐系统
数据库
企业 AI

这种AI + 软件工程的场景来说，它反而可能是一个值得持续观察的方向。

尤其是当未来 Agent 越来越复杂以后，我们可能会发现：

真正需要的不是一个更大的 LLM，而是一套更合理的 AI 决策基础设施。

而 JEV，可能就是这个方向里一个很有意思的尝试。