让我们理清楚这个问题,因为准确理解上下文(会话)在 AI 架构中的作用极其关键。 你知道我这么说,因为我在博客里用了“dang”这个词。 没错,我是认真的。
如果您正在构建自己的 LLM 驱动的应用程序并使用 OpenAI API 来执行此操作,那么您就不会使用 ChatGPT。 您正在和一个模特说话。 原始的。 如果你认为你的应用程序会像 ChatGPT 一样运行,仅仅因为它调用了GPT-4 ,那么你已经偏离了轨道。
人们经常误解这一点,部分原因是 OpenAI 的品牌定位没有帮助。 “ChatGPT”的体验——记忆力、语气、上下文,以及它优雅地追踪你六个问题之前的对话而不会突然出现“海洋植物学博士”般的幻觉——这不是魔法。 这是一种架构设计。 而当你使用API时,这种架构并非免费提供。
ChatGPT app 提供分层且可管理的体验。 它将以下内容整合在一起:
API 默认不会为您提供以上任何功能。完全不会。
当你直接调用GPT-4(或任何其他模型)时,你提供的是无状态的原始消息序列,必须确保上下文窗口不会溢出或分散。 它是一个空白的模型,不是数字助手。
在 ChatGPT 中,推理服务器负责管理整个上下文窗口。 您输入内容后,系统会记忆(直至记忆到限度),您可以信赖应用程序大致跟踪所有相关信息。 我们还在其上层构建了记忆系统,OpenAI 会谨慎筛选哪些内容被传回。
您正在使用 API 吗? 您就是推理服务器。 这意味着:
如果你出错了(早期我们都会),当模型在会话中途忘记用户姓名或开始生成你未提供的数据时,责任就在你身上。
ChatGPT 有记忆功能。 而你没有。 除非你主动构建。 使用 API 时,它是无状态的。 你负责管理所有上下文、记忆和流程。 使用 ChatGPT 应用时,OpenAI 会帮你全部处理。 这已内置完成。
ChatGPT 中的“记忆”不仅仅是附加在提示上的便签。 它是一个系统,在多次会话中存储用户的事实、偏好、目标和限制,并在恰当时机将这些信息有针对性地注入提示中。 如果你想在应用中实现类似功能,需要:
换句话说:基础设施。
这就是大多数自主开发的人工智能应用显得不稳定的原因。 因为你把大语言模型当成聊天机器人来使用,而不是系统中的一个工具。 后果呢? 线程丢失、反复提示、异常回退,用户因此感到挫败。
无论您是否有意,只要基于 API 构建,就在打造基础设施。 如果用户期待类似 ChatGPT 的体验,您必须实现:
但这只是开始。 如果你是在企业级应用交付堆栈之上构建——你是真的,是吧? 走着瞧——那么整个平台的其他部分也得跟上。
应用交付和安全团队将在这里发挥关键作用。
AI 原生应用具有状态性、以聊天为核心且常实现实时交互。 也就是说:
这不是一个普通的宣传网站。 这里是一个动态交互界面。 您不能简单地在它前面加个 CDN 就算解决了。
我们可以通过提示来编程大型语言模型(LLM)。 因此,提示本身成了新的攻击入口。
安全控制需要不断进化:
更别提将用户记录注入上下文窗口时带来的数据治理噩梦了。
ChatGPT 本质上是一款经过打磨的产品。 OpenAI API 则是一种基础工具。 如果搞混它们,你的系统就会崩溃。
明智构建。 打造企业级应用交付与安全堆栈,助力您快速发展的 AI 生态。 相信我,当您开始构建 AI 代理,并积极采纳代理架构时,这将变得尤为关键。 因为,如果您觉得上下文漂移和幻觉是面向最终用户的 AI 应用中的问题,那请等着看代理 AI 将怎样影响您的业务和运营级 AI 应用。