OpenAI 模型可以在其架构范围内处理和利用上下文，但它们并不像人类那样“理解”上下文。 这些模型通过跟踪给定输入中 token（单词或子词）之间的关系来分析文本序列。 它们使用诸如注意力层之类的机制来权衡先前 token 在生成响应时的重要性。 例如，在像“用户：法国的首都是什么？ 助手：巴黎。 用户：它离伦敦有多远？”这样的对话中，该模型识别出“它”指的是巴黎，并使用该上下文来回答距离问题。 然而，这是一个统计模式匹配过程，而不是真正的理解。
上下文处理的有效性取决于模型的设计和限制。 像 GPT-3.5 或 GPT-4 这样的模型具有固定的上下文窗口（例如，GPT-3.5 为 4,096 个 token），这意味着它们只能引用该窗口内的文本。 如果对话超过此限制，则会删除较早的交互。 例如，在讨论软件架构的漫长聊天会话中，该模型可能会丢失 5,000 个 token 之前提到的设计决策。 开发人员必须构造输入以优先考虑相关上下文，例如总结过去的交互或明确重述关键细节。 此外，模型有时可能会过度索引最近的上下文，如果在同一窗口中出现冲突信息，则会导致不一致。
对于开发人员来说，管理上下文是一项实际挑战。 在构建应用程序时，您可以将对话历史记录作为 API 有效负载的一部分传递，以保持连续性。 例如，聊天机器人可能会将先前的用户和助手消息存储在列表中，并在将其发送到 API 之前附加每个新的交流。 但是，您需要实施截断或总结以避免超过 token 限制。 像 tiktoken 这样的工具可以帮助计算 token 以保持在范围内。 测试边缘情况也很重要，例如突然的主题变化或模棱两可的引用，以确保模型的响应与预期相符。 虽然 OpenAI 模型擅长模式识别，但它们缺乏真正的记忆，因此需要长期上下文（例如，用户偏好）的应用程序必须通过数据库或缓存在外部处理。