通用分类器Jev：用起来越成功，越容易被专用分类器换掉

“System One”模型（如Jev）是快速的通用分类器。分类器自1958年以来就已存在，但必须针对特定任务进行训练：如果你构建一个识别狗图像的分类器，它无法用来告诉你路灯是否红灯，或一封信是否紧急。与LLM一样，Jev可以针对各种任务进行提示，从邮件分类到玩Doom。

我认为这类模型将会变得重要。许多任务，LLM在理论上可以完成，但在实践中太慢且太昂贵（例如，阅读Slack[1]中的每条新消息并决定是否通知你）。虽然你可以为这些任务训练一个特定分类器，但这有两个主要问题：

* 尽管这是一个被充分理解的机器学习问题，但训练一个定制分类器超出了大多数普通工程团队的能力范围。
* 训练分类器需要组装大量数据集。

Jev显然解决了第一个问题。任何工程团队都可以接入一个System One模型，并提示如“根据{标准列表}，是否应通知用户此消息？”但我认为它也能解决第二个问题。

对于严肃的工作，一个特定的手工构建分类器总是比Jev更便宜、更快。通用分类器必须在权重中编码各种无关事物的知识，以便处理许多不同的任务。这使它们更大、更慢、运行成本更高。幸运的是，用一个手工构建的分类器替换一个Jev实例将会出奇地容易。

一旦你对你的Jev分类器的表现满意——可能你已经花了几天调整提示——你就能轻松地收集它的输入和输出数据。就Slack通知器而言，那就是Slack消息（加上任何上下文）和是否通知的最终决定。一旦你保存了足够的数据，你就能在这些数据上训练你自己的分类器[2]。

它不会像Jev那样是通用分类器，但应该在特定任务上表现良好，并且快得多。当然，这会需要一些机器学习专业知识，但一旦你验证了该功能值得构建，开发（或租用）这种专业知识就会更容易。

换句话说，由于Jev必须针对特定任务进行提示，因此应该容易将任何成功的Jev用法提炼为一个特定分类器。如果System One模型流行起来——我希望它们如此——我预计这会成为一种常见模式。

[1] 在写这篇文章时，我在想象你可以用LLM轮询和批处理的方式来实现这一点。如果你愿意换一个例子，可以把“立即通知”替换为更高容量的事件源。

[2] 你已经可以用LLM标注大量数据，无需使用Jev，但当你还不确定功能是否有效时，这是相当昂贵的一步。