我们为什么做
Assistants API？
MiniMax 坚信 AI Agent 会给各行各业带来革命性的改变，其中，Assistants API 是实现 AI Agent 最好的载体。今天，我们想在这里和大家分享一个好消息：2024 年 1 月 5 日，MiniMax 推出国内首个 Assistants API。 也想和大家聊一聊，MiniMax 团队对 AI agent 的理解，以及我们为什么认为 Assistants API 是实现 AI Agent 最好的载体。
我们对于 AI agent 的理解
首先定义什么是 AI agent。简单来说，我们把 AI agent 当成一个人——大语言模型是这个人的大脑。大脑驱动人自主调用不同的工具去完成复杂的任务。
如何构建好的 AI agent ？在回答这个问题之前，我们需要理解 AI Agent 解决了什么问题—— AI Agent 希望解决现阶段单一 LLM （大语言模型）无法解决的复杂任务。例如，如果一项任务需要包含检索文字、数据分析以及用代码生成图表等多个任务时，现有的 LLM 可能就无法很好的处理。
在 OpenAI 推出 Assistants API 之前， 包括 Langchain 和 AutoGPT 在内，业界做了很多通过构建 AI agent 解决复杂任务的努力。但这类工具本身不提供模型，通过接入第三方大模型实现流程会导致工作流程（具体任务）和模型是分离，无法基于现有模型，做针对特定流程和任务的 alignment。
从使用门槛上来说，用户在这个过程中不仅需要自己维护和模型的交互行为，调试过程中出现的多个 prompts，做多种工具的对接和适配。还需要对大模型和相关工具链有足够的理解。
从效果上来说，虽然可以通过调试流程中的 prompt，在一定程度上提升任务的准确性，但调试 prompt 带来的提升远没有通过 alignment 的提升显著。此外，由调试 prompt 带来的提升在模型版本的迭代中，难以保持稳定。
Assistants API：
从 Build Agent 到 Agent as API
我们认为，好的 AI agent = Agent as API，就是说把 agent 以 API 的形式提供给用户。我们基于现有模型，做针对通用任务和工具使用的alignment，让用户通过更简洁的对话交互，实现更稳定的效果。
过去，用户需要自己把不同的功能构建成一个完整的 agent，并不断调整和维护这个流程。现在，我们把完整的 agent 以 API 的形式给到用户，大大降低用户使用 agent 的门槛和维护成本。用户不需要关注流程过程构建和细节，只需要关注定义任务，把精力放在如何使用 agent 解决好业务问题上。
Q&A
Q1
MiniMax Assistants API 是什么？
A： 是基于大语言模型构建的、具备多种工具链能力支持的有状态API；和 Chat completion API 相比，最大的区别是交互的维度从单轮对话，变成了更完整的一个事件、一次行为。
Q2
我们实现 Assistants API 的原理是什么？
A： 如图所示：
之前 Chat Completion API 的原理是基于对话的形式，由大语言模型直接对用户的提问进行回答。
现阶段 Assitants API 的原理是：基于对话的形式，大语言模型根据模型本身的能力，以及可供选择的各类工具——Retrieval, Code Interpreter, Search Engine, Function calling ， 通过多轮迭代，解决复杂问题。
- Retrieval: 针对大规模文本内容进行检索的工具。基于 Retrieval 能力，Assistants API 支持由用户主动提供大量文字资料，作为大语言模型的参考信息，在不大量消耗上下文窗口的情况下，实现了足够的知识/记忆补充。
- Code Interpreter: 代码解释器。提供了代码执行的环境，大语言模型可以自行判断是否需要通过代码解决问题，在必要的情况下，可以通过 Code Interpreter 执行代码，将执行结果作为中间信息或结果。
- Search Engine: 搜索引擎，提供获取互联网资讯的能力，模型根据需求，调用搜索引擎搜索相关的信息。
- Function calling: 提供自定义的工具能力定义，由用户来提供额外的工具供模型选择使用。
Chat Completion API vs Assistants API 运行原理
我们对 Assistanst API Function Call 能力以及 Retrieval 能力都分别做了测评。细节如下：
Function Calling
用什么测：
我们采用 toolbench 测评集测试 Function Calling 能力。选择 toolbench 是因为这个数据集采集了1.6 万个真实 API，并围绕这些 API 构造了人类指令，模拟了很多真实使用场景 。
测试结果：
我们构造了专门的 Functionl Calling 能力评测数据集。评测结果达 80% 准确率。这个结果说明 MiniMax Assistants 可以满足不少真实场景的使用需求。
Retrieval
用什么测：我们基于 SQuAD（Stanford Question Answering Dataset）2.0 对 retrieval 能力进行了评测。SQuAD 2.0 由斯坦福大学计算机系 Pranav Rajpurkar, Robin Jia, Percy Liang 三人在论文Know What You Don't Know: Unanswerable Questions for SQuAD中提出。SQuAD 2.0 构建了一个包含十万个问题的大规模机器阅读理解数据集，选取超过 500 篇的维基百科文章。数据集中每一个阅读理解问题的答案是来自给定的阅读文章的一小段文本。
测试结果：为了评测 retrieval 的整体能力，同时考虑到实际应用场景以及SQuAD 2.0 test 集的私有性，我们对 SQuAD 做了一定形式的改造。我们从 validation 集中抽取了20篇文档作为 retrieval 的文本底库，并筛选出323 道与选用文档相关且含义完整的问题作为实际的测试集。
评测标准使用 correctness（正确性）与 relevancy （相关性）两个指标：
- 正确性代表模型在回答问题时的准确性，即是否能够正确识别和提取文本中的信息来回答问题。
- 相关性则关注模型在 retrieval 过程中选取的文本是否与实际问题紧密相关，从而确保模型在应用场景中的实用性。回答无关的内容或者未完整回答问题，相关性得分将更低。
测试结果如下：
Retrieval 能力的评估表明，MiniMax Assistants的正确性得分为 0.7546，表现相对稳定和可靠；相关性得分 0.8920 ，显示出在 retrieval 过程中选取的文本与实际问题相关性大，提高了应用场景中的实用性。
举个例子：智能客服
看完测评能力，让我们来看一个 MiniMax Assistants API 具体应用在客服场景的例子吧。
场景： 某用户在直播间下单后，发现购买的食品已过期。跟客服反应，要求退货/退款。
传统客服应用会：通常需要额外开发一套流程管理工具，设计复杂的处理流程，要求用户填写和选择各种选项来解决问题。对公司来说，开发成本高。消费者体验也不好。
基于 MiniMax Assistants API 开发的智能助手则会：在理解用户意图后，agent 会自主引导用户提供订单号码，并调用 function calling，自主核验订单细节，生成客诉单号和链接。满足用户诉求（即发送退款/退货链接）。对企业和消费者而言，处理客诉效率大大提高。
智能客服 Demo
来官网申请内测吧！
目前，MiniMax Assistants API 已进入内测阶段，已有少量头部客户接入业务场景使用。欢迎感兴趣的开发者和企业客户在我们的官网申请内测。如有任何问题或建议，欢迎通过邮箱联系我们。 我们的邮箱是：open-platform@minimaxi.com。 期待与你们一同解锁更多的应用场景。
保持耐心，不断进化。
Intelligence with everyone.
点击查看官网