大模型系列之-OpenAI的Assistants API,一个开箱即用的RAG

1,349 阅读8分钟

前言

在大模型系列,我之前的一篇文章,大模型之带你了解plugins、GPTs的前生今世,GPT-4 turbo何以让众多创业者一夜无眠,及主要应用:RAG、Agent

在这篇文章中,我们提到在GPT4.0 turbo发布时,GPTs和Assistants API的出现使得众多创业者一夜无眠。当时看完之后就被我丢到一边,并没有太多关注,随着我们对RAG和Agent的不断深入了解,蓦然回首,越发感受到了他的好用。

u=2753254869,451155373&fm=253&fmt=auto&app=120&f=JPEG.webp

Assistants API 的主要能力

像GPTs和Assistants API的出现都是为了降低开发门槛。

GPTs能够让众多非技术背景的人员做自己的大模型应用,而要更大自由度,需要用 Assistants API 开发。

Assistants API目前支持的能力

  1. 创建和管理 assistant,每个 assistant 有独立的配置

  2. 支持无限长的多轮对话,对话历史保存在 OpenAI 的服务器上

  3. 通过自有向量数据库支持基于文件的 RAG

  4. 支持 Code Interpreter

    1. 在沙箱里编写并运行 Python 代码
    2. 自我修正代码
    3. 可传文件给 Code Interpreter
  5. 支持 Function Calling

  6. 支持在线调试的 Playground

在最近我们大模型文章RAG阶段,还在研究他的文档切片,向量化等等,而OpenAI的Assistants API帮我们完成了RAG,我们只管准备我们的垂域学习材料就好。

而且未来还会继续扩展它的能力:

  1. 支持 DALL·E
  2. 支持图片消息
  3. 支持自定义调整 RAG 的配置项

当然,我们也要关注他的收费情况:

  1. 按 token 收费。无论多轮对话,还是 RAG,所有都按实际消耗的 token 收费
  2. 如果对话历史过多超过大模型上下文窗口,会自动放弃最老的对话消息
  3. 文件按数据大小和存放时长收费。1 GB 向量存储 一天收费 0.10 美元
  4. Code interpreter 跑一次 $0.03

只要不是我们面对需要极致调优的场景,Assistants API真的是功能齐全,开发简单!

如何使用 Assistants API

我们可以通过Assistants Playground或者代码来创建我们的assistant。

根据OpenAI 给的介绍,使用Assistants API的步骤分为总体如下四步:

  1. 创建Assistants实例。
  2. 创建对话线程Thread
  3. 根据问题创建信息Messages
  4. 在线程中运行(run)Assistants,获得结果。

openai在官网给了一个回答数学问题的Assistant创建方法,该案例使用的能力是自动编辑和运行代码。我们接下来基于python来简单介绍使用方法。

准备工作-完成openai-python的环境安装

这里不做描述,可以参考之前写的一篇文章:python调用GPT-API(交互式,支持多轮对话)

step-1.创建*Assistants

助手代表一个实体(Assistant),可以配置它以响应用户的消息,使用以下几个参数:

  • 指令(instructions):助手和模型的行为或响应方式
  • 模型(model):您可以指定任何 GPT-3.5 或 GPT-4 模型,包括微调模型。检索工具需要使用 gpt-3.5-turbo-1106 和 gpt-4-1106-preview 模型。
  • 工具(tools):API 支持由 OpenAI 构建和托管的代码解释器和检索工具。
  • 函数(funtions):API 允许您定义自定义函数签名,具有类似于我们的函数调用功能的行为。

代码示例:

assistant = client.beta.assistants.create(
    name="Math Tutor",
    instructions="You are a personal math tutor. Write and run code to answer math questions.",
    tools=[{"type": "code_interpreter"}],
    model="gpt-4-1106-preview"
)

step-2.创建对话线程*Thread

Thread 代表一次对话。建议在用户发起对话时为每个用户创建一个 Thread。通过创建消息将任何特定于用户的上下文和文件传递给此线程。

代码示例:

thread = client.beta.threads.create() 

Thread 没有大小限制。您可以向 Thread 添加任意数量的消息。助手将确保向模型传递的请求适应于最大上下文窗口

step-3.将信息Messages 加入Thread

消息包含文本,并可选择允许用户上传的文件(见支持的文件格式)。消息需要添加到特定的 Thread中。目前不支持通过消息对象添加图像

message = client.beta.threads.messages.create(
    thread_id=thread.id,
    role="user",
    content="I need to solve the equation `3x + 11 = 14`. Can you help me?"
)

step-4.运行(run)Assistants

为了使助手响应用户消息,您需要创建一个 Run。这使助手阅读 Thread,并决定是否调用工具(如果启用),或者仅使用模型来最佳回答问题。随着运行的进行,助手将以role="assistant"的身份向 Thread 追加消息。助手还将自动决定在模型的上下文窗口中包括哪些先前的消息。这既对定价有影响,也对模型性能有影响。当前的方法是基于在构建 ChatGPT 过程中所学到的内容进行了优化,并且可能会随着时间的推移而发展。

您可以在创建 Run 时可选地传递其他指令给助手,但请注意,这些指令会覆盖助手的默认指令。

run = client.beta.threads.runs.create(
  thread_id=thread.id,
  assistant_id=assistant.id)

step-5.运行结果

当开始运行后,可以查看运行的状态,如果状态为completed,则表示运行结束了,可以在thread中得到运行的结果了。

run = client.beta.threads.runs.retrieve(
  thread_id=thread.id,
  run_id=run.id
)

while run.status != "completed":
    print(run.status)
    time.sleep(60)  # 等待60秒
    run = client.beta.threads.runs.retrieve(
    thread_id=thread.id,
    run_id=run.id
    )       

messages = client.beta.threads.messages.list(
  thread_id=thread.id
)

print(messages.data)

4b4eb682d84b073942c91c0a745fd471.gif

总结

我们可以看到,Assistants API 的内置工具支持了代码解释器、知识库检索以及函数调用,允许接入外部知识(文档)、使用更长的提示和集成各种工具。它能够帮助开发者分担繁重的工作,并构建高质量的 AI 应用。

  • 代码解释器允许助手API在受限执行环境中编写和运行Python代码。该工具可以处理具有不同数据和格式的文件,并生成带有数据和图像的文件。代码解释器允许助手迭代运行代码以解决复杂的代码和数学问题。
  • 函数调用( Function Calling) 允许您向助手描述函数,并智能返回需要调用的函数及其参数。助手API在调用函数时会暂停执行当前运行,您可以将函数调用的结果提供回来以继续运行执行。
  • 这里重点说一下知识检索能力

知识检索

目前在解决大模型幻觉和构建垂域大模型能力的背景下,RAG大火。

OpenAI提供的知识检索,可以为助手提供来自其模型外部的知识,例如专有产品信息或用户提供的文档。一旦上传并传递文件给助手,OpenAI将自动对您的文档进行分块、索引和存储嵌入,并实现向量搜索以检索相关内容以回答用户查询。

甚至“OpenAI 力挺 RAG,向量数据库失宠了?”等话题一度成为了讨论的热点。

同时,Assistants API是AI Agent技术下智能体产品,这在国内当时还鲜有人知 AI Agent 概念时就推出的王炸。

让我们都可以构建自己的智能体产品。

暂时还存在的局限性

之所以说是暂时,是因为这些局限,一旦OpenAI想,就可以解决的。

限制 1: 可扩展性

OpenAI Assistants 内置检索对文件大小和数量都有限制。这些限制不利于大型文档仓库:

每个 Assistant 最多支持 20 个文件

每个文件最大为 512 MB

我们在测试中发现了关于 Token 的隐藏限制——每个文件最多 200 万个 Token

每个企业账号下文件大小总和最多 100 GB

限制 2: 无法定制检索

虽然 OpenAI Assistants 的内置检索是一套开箱即用的解决方案,但它无法根据每个应用的特殊需求(如:搜索延时、索引算法)进行定制。使用第三方向量数据库,可以帮助开发者灵活配置、调优检索过程,从而满足生产环境中的各种需求,提升应用的整体效率。

限制3 :缺乏多租户支持

OpenAI Assistants 中内置的检索功能绑定 Assistant,每个知识库产生的费用按 Assistant 个数成倍增长。如果开发者的应用需要为数百万用户提供共享文档,或者为特定用户提供私人化的信息,OpenAI Assistants 的内置检索功能就无法满足需求了。

选择自己合适的

在了解了OpenAI Assistants的功能、特性和他的局限性,我们可以在自己的实际应用场景中,灵活选择使用OpenAI Assistants还是自己建设RAG。

tips,想了解自定义RAG的,可以移步:大模型应用RAG系列3-1从0搭建一个RAG