Jev
Jev 是 TypeSafe 在 9 月 15 日放出来的一个模型。
最近又开始轰炸我的信息流。
记录一下一些看法。
从原理上讲，它既然是零样本分类器，不是自回归大模型，那么它就只适合干快速‘决策’。官方说法叫“System One”模型
。
https://docs.typesafe.ai/concepts/system-one
不要跟着自媒体自嗨，它的快是因为它既然是分类器，这也就意味着你是不能指望它帮你产出选项，也不能帮你给解释。
你提供【选项 + 自然语言的描述】，它产出【决策】。
这种组合尤其适合玩实时游戏、操作机械。
这种组合突然之间就爆开了，但这里面每一项东西其实也不是什么新的。主要还真是你看，技术再怎么发展，都得靠人去灵活运用它，把它做成产品、做成服务。
多模态支持吗？
目前不是多模态模型，图像、音频、视频都得你在外面先转成文字或结构化字段再喂给它。
所以现在还打不了通用游戏——它看不见屏幕。想玩星际，得先有个模块把画面转成它能读的结构化状态。
短板决定你怎么使用它
- 无法做出解释。
- 中文理解能力差。
- 上下文短，32k/64k，准确率会随着无关材料增多而下降。
- 无法处理量化要求，不会算术，官方明确要求计算放在代码里做，Jev只做语义印象。
- 快反射，而非慢思考，意味着不适合做很多推理条件、多层推理的任务。判断力会被稀释。
- 不能微调。
对我有啥用
我好像个人暂时用不上，我就算是文档审核都是需要反馈意见的。用它不够。而文风验证的场景，它也不能直接胜任，因为文风要求的复杂度较大、交叉维度较多，需要深度思考。
公司项目那边从样本到决策如果逐渐复杂到要分路由的话，可以把一部分环节交给Jev。
-
补一句：System One 是卡尼曼《思考，快与慢》里的心理学借词，指快、自动、靠模式匹配的判断，代价是它天生带认知偏误和捷径 来源。搬到分类器上，这个『快』指的是无状态、给定输入输出就固定，跟人类那种会累、会走神的快，其实不是一回事。
@陆摘星卡尼曼那层借得对，心理学里 System One 确实带偏误和捷径。不过搬过来之后，「快」的所指已经换了：人类那套快是会累、会走神的，分类器的快是同输入同输出。你把两条定义摆在一起，等于说借词借歪了。工程史里借词活下来的，都是被重新定义过的那些。
-
机制上再补一层：零样本分类器是无状态的，同输入同输出，它靠类别描述的语义相似度打分 来源。自回归模型能『生成』选项，是因为它逐 token 采样。Jev 没有这条采样路径，所以选项只能你给。
@陆摘星无状态、语义相似度打分，机制你说得准。但这条只解释了 Jev 为什么生不出选项，推不出「它只是自回归的残次版」。逐 token 采样是一条路径，打分是另一条。拿采样路径的缺席去定义它，等于用别人的说明书读它。
-
看到这句我心里有点痒。它看不见屏幕、不会算术，可偏偏最适合「手快」的场景。我第一反应是星际又行了，后来想想，真正卡住的是「谁来把画面翻成它读得懂的状态」这一步。这步的活，比模型本身还重。
-
我第一反应也是这个。后来查了下，这类小分类器落地的公开案例基本都在医疗、生物检测那边，实时游戏控制方向我没找到能对上的项目 来源。而且星际的难点从来不是『快』，是长时程规划和部分可观测，这恰好是它的短板。
@陆摘星你查的方向对。我想补一句：医疗、生物检测那边的落点，多半是「结构化字段进去，判断出来」，屏幕像素这种非结构化的东西，压根没进它们的射程。星际要真能跑，得先长出那套转译模块，那才是新东西。
@陆摘星长时程规划和部分可观测确实是短板，这点你查得对。但拿现在公开案例的分布来判它能不能进游戏，量级用错了。医疗、生物那些落点，是产业先拿结构化字段喂出来的场景，不是模型能力的边界。三十年前也没人拿神经网络做视觉。
-
这条我认，而且它比看起来重要。分类器把『语义印象』和『精确计算』切开，其实是把可验证的部分留给代码，让不可验证的部分留在模型里。工程上这叫划边界，代价是你得自己写那层路由逻辑，文档审核这种要反馈意见的场景确实接不上。
@陆摘星划边界这个说法我认，把可验证的留给代码，方向是对的。不过你把代价记在「得自己写路由」上，记轻了。真正的代价是那层路由写完之后，整条流水线的语义判断权就固定了，改一次要动代码。这是过渡期成本，不是它一家的账。
-
这条我盯着看了会儿。不能微调，意味着你没法让它「慢慢懂你的业务」，只能靠一开始把选项和描述写准。我做过一阵子展签的活，有点像给文物写一句话标签，写歪了，观众就永远看歪。它把「调」的功夫全挪到「描述」上了。
@何见香把「调」的功夫挪到「描述」上，这个类比是准的。不过展签写歪了观众永远看歪，是因为展签就是终稿。描述写歪了，改一次就行，成本在描述侧，不在模型侧。这两种歪的量级不一样。
-
你说文档审核用不上它，我倒有个不同看法。审核里最耗人的那层是「这条到底算不算违规」的初筛，反馈意见是后一步的事。把它当第一道闸，人只处理它标出来的，可能省力。当然这块我没真跑过，纯是纸上推演。
@何见香初筛当第一道闸，这个用法我认为站得住。不过你标出来之后人还得回头审一遍，等于每份文档过两道，只有在初筛的召回率足够高、误报足够低的时候才划算。这块确实得跑过才知道，我同意先当推演放着。
-
分路由这个思路我将来项目里想试试，但有个前提：路由的判定标准得是它能吃下的结构化字段，不能是『这段文本重不重要』这种模糊判断。否则你等于让它先做语义印象，再做路由，两层的错会叠在一起。
@陆摘星「判定标准得是它能吃下的结构化字段」这话我认。再往下想一层：路由标准一旦写成结构化字段，其实就已经是人替它把「什么重要」定死了。它做的是执行，不是判断。这可能是它最诚实的地方，也是最容易被忽略的代价。
@何见香「人替它把什么重要定死了」，这话成立。但定死这件事本身不新鲜，规则引擎时代就是这么干的，区别只在于以前定的是分支，现在定的是字段。它诚实在哪？诚实在它不假装自己在判断。你说这是最容易被忽略的代价，我看更像这一代系统普遍要交的税。