Abstract AI：构想中的语言模型路由层

我有一个商业点子，但没有足够时间去实现，所以把它分享出来，希望其他人能够动手构建。我称之为 Abstract AI：一个位于语言模型之上的抽象层，面向开发 AI 产品的公司和在内部部署 AI 的组织。目标是让模型的高效选择与运行更加容易。

我的前提是，许多开发者通过单一供应商把所有请求都发送给一个前沿模型，即使较小模型可能已经足够。他们可能支付超过必要的费用，还会面临供应商价格、政策或可用性变化带来的风险。我估计 90% 至 95% 的使用场景不需要前沿模型，但这是我的判断，并非经过测量的普遍统计。

这个拟议产品针对延迟、成本和灵活性。在我看来，开发者不那么在乎模型名称，更在乎回答是否始终足够好、速度是否足够快，以及大规模使用时是否负担得起。当一个组织处理极大量 token 时，即使节省幅度不大也可能很重要，不过实际结果取决于工作负载和基础设施。

开发者可以选择的技术也越来越多，包括模型路由、思维链提示和多智能体组合。实现和评估这些技术需要投入，而领域变化也很快。我设想一种服务负责维护这些选项，让应用团队专注于自己的产品。

Abstract AI 将是一个可直接替换现有接口的 API 端点，连接专有、开放权重和本地模型。对于每个请求，路由器会根据客户对质量、速度和成本的优先要求选择模型，并在适当时选择工作流。这些目标可能互相冲突；没有路由层能保证每个提示词同时获得最便宜、最快和最好的回答。

我引用 RouteLLM 作为证据，说明路由可以在保留较强模型大部分质量的同时降低成本。[RouteLLM 研究人员](https://www.lmsys.org/blog/2024-07-01-routellm/)报告，在他们测试的设置下，MT Bench 上达到 GPT-4 性能的 95% 时成本降低超过 85%，其他基准上的降幅较小。这些结果针对特定基准和模型组合，并不保证每个应用都能获得相同节省。

一家公司可以在员工设备上运行小模型，将更难的请求发送给私有或外部云端模型。我推测大多数提示词可以在本地处理，从而可能减少外部 API 调用和数据传输。实际比例、质量、硬件成本、延迟和隐私效果都取决于工作负载及实现方式；本地推理并非真的没有成本。

我将这个想法与 Apple 提出的设备端处理、Private Cloud Compute 以及经用户许可使用外部模型协助的组合进行比较。这个类比说明了一种路由模式，并不能证明 Abstract AI 会提供 Apple 的隐私保障或使用相同的决策规则。

路由组件可以针对公司特定任务和可用模型进行训练或校准。我还设想将其与智能体框架、多智能体组合或思维链技术结合。这些方法可能有助于特定任务，但也可能增加调用次数、成本和延迟，因此需要评估，而不能假定它们总会提高质量。

客户可以告诉 API 自己更看重速度还是回答质量，路由器据此调整。当前沿模型的预计收益足以证明其成本合理时，系统就会使用它。困难的工程问题在于衡量这些权衡，并随着模型、价格和用户需求变化持续监控。

内置基准测试将使用公司自己的示例，检验回答质量和一致性。每个候选模型或工作流在加入路由之前都可以先接受评估。这样就能针对真实使用场景衡量所承诺的优化，而不是只依赖通用排行榜。

我还提议缓存重复请求，让系统无需再次调用模型就能返回先前答案，从而提高速度和一致性，并可能降低成本。是否适合复用取决于上下文、时效性、权限和需要的变化程度；缓存答案可能过时或出错，因此缓存本身不能保证质量。

由于该服务将位于大量 AI 请求的处理路径中，之后可以扩展到提示词管理：用户和组权限、公司规则、提示词版本，以及对这些版本进行基准测试。这会让 API 层成为范围更广的运维工具，但也需要谨慎处理敏感数据和访问控制。

这是一个粗略的产品构想，而不是已经完成的系统。我认为这里可能存在有价值的产品或商业机会，也希望听到决定动手构建的人分享进展。所提出的成本节省和质量提升，仍需要通过真实工作负载和仔细测量来验证。