Jev模型的一些思考

我们是不是把大模型当得太万能了？#

大模型变得好用之后，做产品的人很容易形成一种惯性：遇到什么问题，先丢给大模型。

写东西交给它，分析交给它，判断交给它，连一个很简单的用户意图识别，也交给它。

这当然省事。以前可能要为每种任务单独准备一套方案，现在写一段提示词，好像就能把很多问题一起解决。

但真正接到产品里，就会发现另一面：有些工作根本不复杂，却要走一遍完整的大模型调用流程。

用户只是说了一句话，系统想知道他准备干什么。结果我们先把这句话交给大模型分析，再告诉它只能返回几个固定类别，最好再附上一套严格的格式要求。

“只返回 JSON。”

“不要解释。”

“只能从这些选项里选。”

明明只是想要一个简单的判断，最后却写了一大段话，教一个什么都会的模型如何少说一点。

想想还挺好笑的。

真正让人难受的，不只是慢#

拿意图判断来说，用户要查资料、执行操作，还是继续聊天，系统需要的往往只是一个明确结果，拿到之后就能继续往下走。

可如果这一步交给通用大模型，后面的流程就得等它完成。单看一次调用，好像还能接受；放进一个需要连续交互的产品里，等待感就出来了。

更麻烦的是，约束了格式，也不代表从此不用操心。返回结果不符合预期时，还得解析、校验、重试，或者再补一个兜底。

于是，一个原本很小的决策环节，反而成了整条流程里需要反复照看的部分。

我们本来只需要一个判断，却把一整套生成式对话能力请了过来，再努力约束它不要自由发挥。

这就是我觉得值得重新想一想的地方。

为什么 Jev 这样的思路会让人兴奋？#

对我来说，Jev 打中的就是这个痛点：不是所有任务都需要一个能长篇大论、能处理各种开放问题的模型。有时候，我们需要的就是一个快速、简单、专门负责决策的角色。

它不需要帮我写文章，也不需要给我解释一大段道理。

我只希望它尽快判断：这句话属于什么意图，接下来该交给哪个流程处理。

做的事情少一点，但把这件事做好。

所以，我能理解为什么这种模型一出来，就会让很多做应用的人兴奋。困扰大家的未必是什么高深问题，而是那些每天都会遇到、反复调用、又总觉得不该这么重的小环节。

当有人把它单独拎出来解决，就有一种“对啊，这件事本来就应该这样做”的感觉。

这里我想聊的，也不是 Jev 的参数表，而是它让我重新注意到的产品思路：我们到底是在按任务选择模型，还是因为手里有一个大模型，就把所有任务都塞给它？

从小模型到大模型，再回到分工#

以前，很多模型的职责很明确。

做分类的做分类，做识别的做识别，做预测的做预测。不同的问题，用不同的工具解决。

后来大模型来了，能力越来越强。原本分散的任务，可以先统一到一个入口里。开发门槛下降了，很多以前需要单独投入的能力，用提示词就能尝试起来。

这是“合”的过程。

但当产品真正跑起来，大家又开始关心响应时间、调用成本、输出格式，以及每个环节是不是足够稳定。

这个时候就会发现：能统一处理，不代表一定要统一处理。

于是，简单决策被拿出来，固定分类被拿出来，适合专门处理的任务又被拿出来。

这又是“分”的过程。

从最开始的专一小模型，到通用大模型，再到 Jev 带来的这类思考，兜兜转转，最后还是回到了分工。

不是每件事都需要最强的大脑。有些事情，只需要一个职责清楚、动作利索的专业选手。

我的结论：别追求一个模型通吃所有#

以后做 AI 产品，我会更愿意先问一句：这个环节到底需要什么？

如果只是判断意图，就让适合做决策的模型去判断。

如果是明确的规则，就让规则去处理。

如果需要开放式理解、复杂分析或者内容创作，再把任务交给大模型。

不必为了“统一”而统一，也不必觉得多用了一个专门的模型，就意味着系统不够先进。

用户不会关心背后是不是只有一个模型。用户感受到的是：它反应快不快，判断准不准，事情能不能顺利做完。

专业的事情，交给专业的模型处理。别想着一个模型通吃所有。

这就是 Jev 带给我最大的启发。技术绕了一大圈，有时候，落点反而是最简单的常识。