{ "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" } } } ]}
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())
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)
现有的监控、模型路由和提示管理架构尚不足以应对挑战。
让我们来谈谈现在的情况。在大语言模型的操作流程中，正逐渐出现一个新概念：AI 代理中间件。
AI 代理中间件是一种特殊的服务，它作为桥梁连接着您的应用程序和模型推理提供商，比如 OpenAI、Hugging Face 等。这种中间件在生成式 AI 开发流程中扮演着关键角色，负责整合以下几个重要步骤：
- 使用统一的 API（通常是改编了
openai.chat.completionsAPI，加入了自定义的baseUrl）来调用各种不同的模型，如 LLaMA、GPT 系列、Mixtral。 - 监控使用情况、响应时间、成本等。
- 对推理请求进行缓存和流量控制。
- 管理用于模型推理的 API 密钥。
然而，我们认为这种架构并非解决这些问题的最佳方案。相反，我们提出了一个观点 — 并通过实践证明 — 这些中间件所提供的功能，可以通过避开中间件、采用更为优雅的框架和协议来实现。
AI 代理中间件面临的问题
AI 代理尝试解决的动机问题是既实际又重要的：
-
关注点分离： 将模型特定逻辑从应用程序代码中分离出来。
让应用程序可以通过相同统一的 API 接口调用不同的模型，避免了处理特定于模型的 API 的需要。这样，开发者可以在同一个应用程序流程中调用不同的模型，同时使用相同的 API（例如，使用 GPT-4 处理复杂的提示，使用 LLaMA 或 Mixtral 处理简单的提示）。 - 监控 应用程序使用生成式 AI 的情况、响应时间和成本。
- 缓存 推理请求，采用语义缓存，并控制请求频率。
- 管理不同推理服务提供商的 API 密钥
把这些功能集成到一个代理中间件中，引入了一系列新的且可避免的问题：
- 单体设计 – 监控、可观测性和缓存在现有的软件开发流程中已经是独立的、成熟的概念，每个领域都有其专用的系统。它们不应该被一个代理服务所整合。
- 安全风险：在应用程序与模型提供商之间增加了这一不必要的服务层，导致了额外的安全隐患，需要通过加密请求和用户特定数据来解决。
- 延迟和难以调试：代理使得与大语言模型 (大语言模型) 提供商的通信需要两次跳转，可能会导致性能下降。此外，一旦出现问题，调试的可见性也非常有限。
- 本地与远程的差异：这个服务层对本地运行的模型不适用，而随着模型越来越小且效率更高，本地模型的重要性正逐渐增加。
更重要的是，许多这类代理中间件是由第三方提供商作为封闭的管理服务提供的。这就形成了一个关键的外部依赖，而且没有备用策略。
更佳选择 —— 框架替代代理
我们认为，可以用一个开源的 AI 框架和存储格式来取代 AI 代理层。这样不仅能提供一个统一的 API，还能连接到相关服务以分别处理监控、缓存和密钥管理。
为此，我们推出了 AIConfig —— 一种以配置文件为核心的框架，用于管理提示、模型和推理设置，这些设置都是可以通过 JSON 格式序列化的。
这些配置文件是应用程序中生成式 AI 的关键组成部分，可以进行版本控制、评估、监控，并且能在一个像笔记本一样的实验环境中进行编辑。换言之，它们能够无缝融入当前开发者的工作流程中。
尽管市场上存在其他 AI 框架，但 AIConfig 的两个主要特点是：
- 提示、模型和推理设置被存储为配置文件，而不是代码。
- 它采用了一个与模型无关且支持多种模式的通用存储格式，使得在不同模型间的切换变得简单直接。
与代理中间件的对比
我们来重新审视一下代理中间件的功能，并尝试在不借助中间人的情况下实现相同的功能。具体来说，我们将采用不依赖单体架构的方法来完成这一目标。
将单体服务分解为其组成部分后，您可以利用现有的服务提供商来进行数据推断、监控、缓存和密钥管理系统（KMS）等操作。
✅ 关注点分离 — 从应用程序代码中分离出模型特定逻辑。
AIConfig 的设计允许您将提示的存储和迭代过程与应用程序代码分开进行。它为任何模型和各种形式提供了统一的 API 接口。
例如，这个 aiconfig 利用 Gemini 和 GPT-4 创建了一个旅行规划应用程序：
您可以通过同一个 API 调用任何一个模型：
✅ 监控
该框架提供了回调处理程序，用于注册使用情况跟踪。
其核心理念是，对生成式 AI 的监控并不与监控其他服务有太大的不同。生成式 AI 的监控应当简单地融入到您对应用程序其他部分的监控体系中（如 datadog、cloudwatch、prometheus 等）。
现有监控服务可以轻松集成到各种框架中
✅ 缓存
例如 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 正是朝这一方向迈出的一步，我们期待与社区合作，共同推动这一进程。
