AI 代理中间件：不完美的临时解决方案 [译]

原文：AI proxy middlewares are a hack
作者：

Sarmad Qadri

现有的监控、模型路由和提示管理架构尚不足以应对挑战。

让我们来谈谈现在的情况。在大语言模型的操作流程中，正逐渐出现一个新概念：AI 代理中间件。

AI 代理中间件是一种特殊的服务，它作为桥梁连接着您的应用程序和模型推理提供商，比如 OpenAI、Hugging Face 等。这种中间件在生成式 AI 开发流程中扮演着关键角色，负责整合以下几个重要步骤：

  • 使用统一的 API（通常是改编了 openai.chat.completions API，加入了自定义的 baseUrl）来调用各种不同的模型，如 LLaMA、GPT 系列、Mixtral。
  • 监控使用情况、响应时间、成本等。
  • 对推理请求进行缓存和流量控制。
  • 管理用于模型推理的 API 密钥。

AI 代理中间件位于你的应用和模型推理服务提供商之间。
AI 代理中间件位于你的应用和模型推理服务提供商之间。

然而，我们认为这种架构并非解决这些问题的最佳方案。相反，我们提出了一个观点 — 并通过实践证明 — 这些中间件所提供的功能，可以通过避开中间件、采用更为优雅的框架和协议来实现。

AI 代理中间件面临的问题

AI 代理尝试解决的动机问题是既实际又重要的：

  1. 关注点分离： 将模型特定逻辑从应用程序代码中分离出来。 让应用程序可以通过相同统一的 API 接口调用不同的模型，避免了处理特定于模型的 API 的需要。这样，开发者可以在同一个应用程序流程中调用不同的模型，同时使用相同的 API（例如，使用 GPT-4 处理复杂的提示，使用 LLaMA 或 Mixtral 处理简单的提示）。
  2. 监控 应用程序使用生成式 AI 的情况、响应时间和成本。
  3. 缓存 推理请求，采用语义缓存，并控制请求频率。
  4. 管理不同推理服务提供商的 API 密钥

把这些功能集成到一个代理中间件中，引入了一系列新的且可避免的问题：

  • 单体设计 - 监控、可观测性和缓存在现有的软件开发流程中已经是独立的、成熟的概念，每个领域都有其专用的系统。它们不应该被一个代理服务所整合。
  • 安全风险：在应用程序与模型提供商之间增加了这一不必要的服务层，导致了额外的安全隐患，需要通过加密请求和用户特定数据来解决。
  • 延迟和难以调试：代理使得与大语言模型 (大语言模型) 提供商的通信需要两次跳转，可能会导致性能下降。此外，一旦出现问题，调试的可见性也非常有限。
  • 本地与远程的差异：这个服务层对本地运行的模型不适用，而随着模型越来越小且效率更高，本地模型的重要性正逐渐增加。

更重要的是，许多这类代理中间件是由第三方提供商作为封闭的管理服务提供的。这就形成了一个关键的外部依赖，而且没有备用策略。

更佳选择 —— 框架替代代理

我们认为，可以用一个开源的 AI 框架和存储格式来取代 AI 代理层。这样不仅能提供一个统一的 API，还能连接到相关服务以分别处理监控、缓存和密钥管理。

为此，我们推出了 AIConfig —— 一种以配置文件为核心的框架，用于管理提示、模型和推理设置，这些设置都是可以通过 JSON 格式序列化的。

这些配置文件是应用程序中生成式 AI 的关键组成部分，可以进行版本控制、评估、监控，并且能在一个像笔记本一样的实验环境中进行编辑。换言之，它们能够无缝融入当前开发者的工作流程中。

尽管市场上存在其他 AI 框架，但 AIConfig 的两个主要特点是：

  1. 提示、模型和推理设置被存储为配置文件，而不是代码。
  2. 它采用了一个与模型无关且支持多种模式的通用存储格式，使得在不同模型间的切换变得简单直接。

与代理中间件的对比

我们来重新审视一下代理中间件的功能，并尝试在不借助中间人的情况下实现相同的功能。具体来说，我们将采用不依赖单体架构的方法来完成这一目标。

将单体服务分解为其组成部分后，您可以利用现有的服务提供商来进行数据推断、监控、缓存和密钥管理系统（KMS）等操作。

✅ 关注点分离 — 从应用程序代码中分离出模型特定逻辑。

AIConfig 的设计允许您将提示的存储和迭代过程与应用程序代码分开进行。它为任何模型和各种形式提供了统一的 API 接口。

例如，这个 aiconfig 利用 Gemini 和 GPT-4 创建了一个旅行规划应用程序：

{  "name": "NYC Trip Planner",  "description": "Intrepid explorer with ChatGPT and AIConfig",  "schema_version": "latest",  "metadata": {    "models": {      "gemini-pro": {        "model": "gemini-pro"      },      "gpt-4": {        "model": "gpt-4",        "max_tokens": 3000,        "system_prompt": "You are an expert travel coordinator with exquisite taste."      }    },    "default_model": "gemini-pro"  },  "prompts": [    {      "name": "get_activities",      "input": "Tell me 10 fun attractions to do in NYC.",      "metadata": {        "model": "gemini-pro"      }    },    {      "name": "gen_itinerary",      "input": "Generate an itinerary ordered by {{order_by}} for these activities: {{get_activities.output}}.",      "metadata": {        "model": "gpt-4",        "parameters": {          "order_by": "geographic location"        }      }    }  ]}

您可以通过同一个 API 调用任何一个模型：

import asynciofrom aiconfig import AIConfigRuntime, InferenceOptionsasync def main():  # Load the aiconfig  config = AIConfigRuntime.load('travel.aiconfig.json')  # Run a Google Gemini prompt (with streaming)  inference_options = InferenceOptions(stream=True)  await config.run("get_activities", options=inference_options)  # Run a GPT-4 prompt (same API!)  await config.run("gen_itinerary", options=inference_options)asyncio.run(main())

✅ 监控

该框架提供了回调处理程序，用于注册使用情况跟踪。

其核心理念是，对生成式 AI 的监控并不与监控其他服务有太大的不同。生成式 AI 的监控应当简单地融入到您对应用程序其他部分的监控体系中（如 datadog、cloudwatch、prometheus 等）。

from aiconfig import CallbackManager, CallbackEventimport pprintasync def custom_callback(event: CallbackEvent) -> None:  """    This is a custom callback that prints the event to stdout.    Args:        event (CallbackEvent): The event that triggered the callback.  """  print(f"Event triggered: {event.name}")  pprint.pprint(event, width = 150)callback_manager = CallbackManager([custom_callback])config.set_callback_manager(callback_manager)

现有监控服务可以轻松集成到各种框架中

✅ 缓存

例如 GPTCache，这样的优秀解决方案已经存在于语义缓存领域。与代理相比，框架允许您直接并轻松地与最适合的工具集成，以实现最佳效果。

✅ API 密钥管理

我们认为管理 API 密钥并不是一个新的问题 — 已经有了很好的密钥管理服务（KMS）可供使用，这些服务也可以用于管理推断端点的密钥。

框架扩展

除了以上内容，还有一些其他关键部分在生成式 AI 工作流程中对构建生产级应用程序至关重要。框架使得使用现有工具来分析和处理这些部分成为可能：

评估

开发者通过创建一个专门的配置文件，可以为其定义评估标准，并且每当配置发生变化时，自动在持续集成/持续部署 (CI/CD) 流程中启动这些评估。

更多关于生成式 AI 评估的信息，请参阅 这里。

本地实验

一个框架能够把生成式 AI 的试验和产品化过程整合到一个流程中。比如，aiconfig 既可以在类似于笔记本的交互式编辑环境中使用，进行视觉编辑和快速原型设计，也可以在应用程序代码中发挥作用。

治理与版本控制

作为一种版本控制工具，aiconfig 能够确保应用中生成式 AI 部分的重现性和来源可追溯性。

更多关于基于框架和配置驱动的 AI 应用开发的详细信息，请查看这个指南。

了解更多：https://github.com/lastmile-ai/aiconfig

为什么存在这么多代理中间件？

如上所述，代理中间件旨在解决当前生成式 AI 工作流程中存在的实际问题。它们也是生成式 AI 开发过程中一个关键环节的便捷接入点。在竞争激烈的市场中，这是一种创建“黏性”依赖的方式。

但如果仅从开发者的视角来看，这些代理所提供的功能理应被拆分为更具扩展性的框架，从而可以连接到外部服务。

重视协议，超越框架

本文的核心观点是，我们需要建立一个标准的交互模型。这个模型应明确规定应用程序在不同模型提供者之间的工作方式、生成式 AI 组件的评估方法、监控方式等（本文还没有涉及智能体交互的内容）。

将这种交互模式标准化为一种协议，将使开发者的整体工作流程更加高效，促进生成式 AI 领域的开发者生态系统更加开放。我们最初的想法是受到了电子邮件的 SMTP 协议和 IDE 中的 LSP（语言服务协议） 的启发。

我们需要一个专门的生成式 AI 协议，它应包括：

  • 提示、模型和推理设置的统一存储格式
  • 运行推理的统一 API，包括路由处理
  • 评估生成式 AI 组件的标准
  • 监控和回调机制
  • 数据缓存
  • 实验和用户体验优化

AIConfig 正是朝这一方向迈出的一步，我们期待与社区合作，共同推动这一进程。

See all posts