敖特_Aute: 同事问我对 Jev 在 Broswer use 领域的应用有什么看法？ 答（一些比较初步的感受，不代表未来观点不会变）： Jev 我理解是以输出通用且有限的分类为目标所训练与架构的，在类似任务下相对自回归生成结构化文本的 LLM 有很大速度优势。 目前看起来有几个限制： 第一，每次调用前需要准备好候选选项，虽然可以动态生成，但候选难以枚举或者数量太多时，就需要额外处理，常规的文本生成更不是它的适用范围； 第二，分类不是百分之百准确的，和 LLM 一样，也受限于模型规模、训练质量等影响； 所以具体到 Broswer use 这样的通用任务，我觉得还是要讨论讨论。 具体可以从两个维度分析：单次动作的可选范围，以及单次动作的推理难度。 从可选范围来看，一个页面的可交互元素，乘以每个元素的可交互方式，比如点击、输入、拖拽等，如果全部平铺，很容易把选项撑爆。Jev 目前单个 Choice 最多支持 255 个选项。把操作和目标拆开可以缓解，但某一类操作的目标仍然可能太多。 从推理难度来看，浏览器任务里有大量操作，单步推理难度是不高的。Jev 更适合的 System 1 任务，我凭感觉可能占很大比例，大多数情况下应该超过 90%。 举个例子，在网页上购物，商品、金额等都已经确认，走到结算这一步，页面上有个支付按钮，需要点它，确实就只是 System 1 难度的动作。 但换个例子，页面上有一道复杂的数学选择题，只有三个选项。这时候选谁，就无法离开 System 2 进行推理。选项少，不代表问题简单。 当然，Jev 分类这种输出形式本身不意味着没有推理能力。但 Jev 官方确实列出了多跳推理、精确数值处理等弱项。考虑到浏览器是一个通用容器，需要调动 System 2 能力的任务一定是无法避免的。 那么，选项撑爆和 System 2 介入这两个问题要如何解决？ 选项撑爆 可以通过工程手段把候选分页，留出“下一页”“上一页”；也可以逐级选择，比如先选页面区域，再下钻到具体元素，最后选择操作。还可以先给候选打分，筛选后再做最终选择。这些方式可以配合使用。 System 2 介入 可以给模型一个类似“不确定”的选项，或者根据概率和置信度，让 LLM 接管。理论可行，但可靠性需要验证 另外，动作拆分的粒度也很重要。如果把鼠标操作拆成方向加步长，靠多轮交互逐步修正，点一个按钮可能要来回很多轮，不一定比 LLM 更快。 公司里应该有部分同事，包括我，是从上一个时代的 AI 公司过来的。我们当时做的很多工作，核心就是训练模型做分类，所谓的模式识别。 因此上面列出这些问题，大都在上一代模型和系统里就有一些解决思路，总体上就是先缩小候选范围，再逐级细分。我个人其实觉得这些方案并不优雅，因为分组、筛选、纠错、升级的复杂度最后还是落到了外围工程上。 相较于传统分类模型，Jev 当然有巨大进步，可以理解自然语言描述，处理运行时定义的候选，还能并行回答多个问题。但在具体任务上的表现，是否能追平专门为该任务训练的分类模型，我持怀疑态度。对于方向加步长这样的低层控制任务，我也没有看到足够的公开评测来证明它的泛化表现。 具体到 Broswer use，如果既要维护分类模型的候选空间，又要编排它和 LLM 的分工，处理不确定性、模型切换和失败恢复，这种组合，在我看来，似乎不如直接用一个速度很快的 LLM 来得优雅。 当然，架构是否优雅不优先于实际业务表现。多模型组合省下的推理时间，能不能覆盖候选处理、额外轮次和模型切换的开销，最终还是要看任务成功率、总延迟和总成本。