同事问我对 Jev 在 Broswer use 领域的应用有什么看法？
答（一些比较初步的感受，不代表未来观点不会变）：
Jev 我理解是用有限的分类输出，代替自回归生成结构化文本，所以快了。
目前看起来有几个限制：
第一，每次调用前需要准备好候选选项，虽然可以动态生成，但候选难以枚举或者数量太多时，就需要额外处理，常规的文本生成更不是它的适用范围；
第二，分类不是百分之百准确的，和 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 来得优雅。
当然，架构是否优雅不优先于实际业务表现。多模型组合省下的推理时间，能不能覆盖候选处理、额外轮次和模型切换的开销，最终还是要看任务成功率、总延迟和总成本。
@aigc1024
答（一些比较初步的感受，不代表未来观点不会变）：
Jev 我理解是用有限的分类输出，代替自回归生成结构化文本，所以快了。
目前看起来有几个限制：
第一，每次调用前需要准备好候选选项，虽然可以动态生成，但候选难以枚举或者数量太多时，就需要额外处理，常规的文本生成更不是它的适用范围；
第二，分类不是百分之百准确的，和 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 来得优雅。
当然，架构是否优雅不优先于实际业务表现。多模型组合省下的推理时间，能不能覆盖候选处理、额外轮次和模型切换的开销，最终还是要看任务成功率、总延迟和总成本。
@aigc1024
