所以，我们来把这个问题说清楚，因为事实证明，了解上下文（会话）位于AI架构中的什么位置，真的非常重要。你看，我甚至在博客里用了“非常”这个词。没错，我是认真的。
如果您正在构建自己的LLM应用，并使用OpenAI API，那么您并不是在使用ChatGPT，而是在与一个未经封装的模型交互。如果您认为应用只要调用GPT-4，就会像ChatGPT一样运行，那从一开始就错了。
ChatGPT不是模型，而是运行时。
人们总是误解这一点，OpenAI的品牌宣传也没能澄清。“ChatGPT”体验，包括记忆、语气、上下文，以及它如何自然地记住您在六个问题前说过的话，又不会突然凭空捏造一个海洋植物学博士身份，并不是什么魔法，而是架构使然。调用API时，这套架构并不会自动附带。
The ChatGPT app是一种分层式托管体验，整合了：
- 提示词工程
- 上下文管理
- 持久记忆
- Guardrails和回退机制
- 摘要、截断和控制逻辑
默认情况下，API不会提供上述任何功能，一项也没有。
直接调用GPT-4（其实任何其他模型也是如此）时，您是在以无状态格式向模型输入原始消息序列，只能寄希望于上下文窗口在此过程中不会溢出或出现碎片化。它只是一个空白模型，并非数字管家。
上下文窗口需要由您自行管理。
在ChatGPT中，推理服务器负责管理整个上下文窗口。您输入内容后，它会记住（直到记不住为止），而且基本可以依靠应用来跟踪相关信息。此外还有一层记忆系统，OpenAI会在后台筛选哪些内容需要重新传入。
如果使用API，您就是推理服务器。这意味着：
- 由您构建消息堆栈。
- 由您决定包含哪些内容。
- 由您管理令牌预算。
- 您会截断或概括内容，也可能导致内容失去连贯性。
如果处理不当（这种情况难免发生，大家在初期都会遇到），模型可能会在会话进行到一半时忘记用户的姓名，或开始编造从未提供给它的数据，而这需要由您负责。
记忆不是一项功能，而是基础设施。
ChatGPT有记忆功能，而您的应用没有，除非自行构建。使用API时，它是无状态的。所有上下文、记忆和流程都需要自行管理。使用ChatGPT应用时，OpenAI会为您处理这一切，因为这些能力已内置其中。
ChatGPT中的“记忆”并不只是附加在提示词上的一条注释，而是一个能够跨会话存储用户信息、偏好、目标和约束条件，并在适当时机根据上下文将其注入提示词的系统。如果希望在应用中实现类似功能，需要：
- 数据存储
- 内存条目的架构
- 用于确定何时包含哪些内容的控制逻辑
- 一种避免其导致令牌数量激增的方法
换言之：基础设施。
这正是大多数自研AI应用显得脆弱的原因：它们把大语言模型（LLM）当作聊天机器人来交互，而不是将其视为系统中的工具。结果就是上下文丢失、提示词重复、出现异常回退，以及用户受挫。
这意味着什么？
如果基于API进行构建，无论是否有意为之，实际上都在构建基础设施。如果用户期待类似ChatGPT的体验，就必须提供：
- 持久记忆
- 智能上下文压缩
- 基于轮次的状态管理
- Guardrails、回退和注入逻辑
但这只是开始。如果您是在企业级应用交付技术栈之上构建这一切（确实如此，对吧？没错吧？），那么平台的其他能力也应当充分发挥作用。
这正是应用交付和安全团队发挥作用的环节。
应用交付：不再只是提供HTML或JSON
AI原生应用具有状态，采用对话驱动，并且通常需要实时交互。这意味着：
- 会话亲和性突然又变得重要了。除非像2009年那样管理会话令牌，否则无法将会话状态分片到多个无状态后端。
- 延迟会扼杀用户体验。您传输的是多轮交互流，而不是提供静态页面。负载均衡器和边缘逻辑需要能够优先处理低延迟的对话流。
- Token成本 = 带宽 + 计算资源 + 资金。如今，高效交付至关重要。有效载荷大小不仅关系到网络，还会直接产生费用。
这不是宣传册式网站，而是一个动态交互界面。不能只在前端加一层CDN就万事大吉。
安全性：如果提示词不由您掌控，风险就要由您承担
大语言模型可通过提示词进行编程。这意味着提示词如今已成为攻击面。
- 注入攻击确实存在，而且已经在发生。如果输入清理不严格，就会让用户即时重新编程您的AI。
- 提示词操纵可能导致敏感记忆泄露、工作流中断或意图伪造。
- 模型输出如果不通过策略执行和可观测性加以保护，可能会被窃取、篡改或投毒。
安全控制措施必须与时俱进：
- 需要部署能够理解AI流量的WAF。仅阻止恶意JSON还不够，还需要对指令集实施防护，而不只是检查有效负载结构。
- 需要为LLM决策保留审计跟踪记录，尤其是在受监管的环境中。
- 需要实施速率限制和滥用防护，不仅要针对API调用，还要应对提示词复杂度和成本激增。
而这甚至还没有涉及将用户记录注入上下文窗口所带来的数据治理难题。
立即构建合适的技术栈，避免智能体AI失控。
简单来说，ChatGPT是一款成熟的产品，而OpenAI API是一种基础工具。如果混淆二者，您的技术栈就会崩溃。
明智构建。构建企业级应用交付与安全技术栈，为不断扩展的AI产品组合提供支持。相信我，当您开始构建AI智能体，并积极采用智能体架构时，这一点会更加重要。如果您认为上下文漂移和幻觉已经给面向最终用户的AI应用带来问题，那么不妨看看智能体AI会给业务和运营类AI应用带来什么影响。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
恶意软件包正在摧毁我们的行业
尽管AI和自动化技术加剧了供应链滥用，开源生态系统仍缺少用于登记恶意软件包的中央注册库。该生态系统需要一种可信的方式来报告和跟踪安全失陷事件。
