在使用 OpenAI API 进行同一轮对话时，系统提示的使用并非每次都必须传递。系统提示在对话中类似于一个过滤器，大语言模型在回应新提示前会自动应用。一般来说，系统提示包括任务定义、输出格式和操作边界等部分，以确保大语言模型清楚任务、按要求格式化回答以及明确不应采取的行为。
另外，OpenAI 还推出了 Stateful API，开发者只需传入最新的对话记录，大模型会结合该记录和其维护的历史记录依据上下文产生新内容。Stateful API 的实现机制类似于 KV Cache，能指数级降低大模型应用的开销，提升计算速度。例如，在不使用 cache 的情况下，使用 GPT-2 生成 1000 个 Token 将耗时 56 秒，而使用 cache 的耗时则被降低为 11 秒。可以预期 Stateful API 会采用类似于 KV Cache 的机制，缓存用户对话的历史记录，并在每次 API 调用中，使用增量信息结合服务端的历史记录生成文本，以此降低计算规模。
但关于是否可以利用 session id 来减少系统提示的显示调用，目前提供的知识库中未提及相关内容。
将以ChatGPT为例进行说明。[heading3]关于系统提示的术语解释[content]首先，我们来厘清几个术语：在讨论ChatGPT时，这三个术语“系统提示”、“系统消息”和“自定义指令”几乎可以互换使用。这种用法让许多人（包括我自己）感到混淆，因此OpenAI发表了一篇[文章](https://help.openai.com/en/articles/8234522-chat-completions-api-system-message-vs-custom-instructions-in-ui)，专门解释了这些术语。简要总结如下：“系统提示”和“系统消息”是通过Chat Completions API编程方式交互时使用的术语。而“自定义指令”则是在通过[https://chat.openai.com/](https://chat.openai.com/)的用户界面与ChatGPT交互时使用的术语。尽管这三个术语表达的是相同的概念，但不必因术语的使用而感到困扰。下面我们将统一使用“系统提示”这一术语。现在，让我们一探究竟！[heading3]什么是系统提示？[content]在对话中，每当您提出一个新的提示时，系统提示就像是一个过滤器，大语言模型会在回应您的新提示之前自动应用这一过滤器。这意味着在对话中每次大语言模型给出回应时，都会考虑到这些系统提示。系统提示一般包括以下几个部分：任务定义：确保大语言模型（LLM）在整个对话中清楚自己的任务。输出格式：指导LLM如何格式化其回答。操作边界：明确LLM不应采取的行为。这些边界是LLM治理中新兴的一个方面，旨在界定LLM的操作范围。例如，系统提示可能是这样的：每一部分对应的内容如下图所示：
对于OpenAI，目前的目标很明确：就是all in AGI，一切研究围绕着探索通往AGI的路径。而商业模式上也很简单：SaaS，直接给API，接口设计内部自己决定，付多少钱用多少，不想用就不用，这样省去了很多产品设计，marketing，BD的时间，伺候甲方的时间（有比较可靠的消息称即使Microsoft的Copilot等产品也是直接用的API，没有花功夫做太多的定制），整个公司可以集中精力开发AGI。有人可能说：不是啊，OpenAI不是还有ChatGPT的用户界面，手机端语音聊天，以及GPTs吗？但是仔细想想，这几个部分OpenAI可以说是「非常不用心」了。比如ChatGPT Plus是怎么自动融合搜索，图片生成，代码调用等工具的？单独做了一套深度优化？不，答案是OpenAI给了一个巨大的prompt，让模型自己去选。OpenAI是怎么和各种第三方插件结合的，是单独做了匹配和接口？不，答案是直接让这些plugins描述自己是什么，然后模型自己调用，至于调用得对不对那就是另外一件事情了。这里最典的是最近OpenAI怎么实现「记忆」的，给大家看看OpenAI的完整prompt（李博杰提供的，每个人可以诱导ChatGPT说出这些，OpenAI也不在乎）：OpenAI直接用prompt让GPT-4调用bio这个工具记录需要记忆的内容（「to=xxx」是调用内部工具的语法，比如"to=python"是GPT调用code interpreter的方式）。然后每次新的对话开始时，在prompt的最后直接加上所有之前的记录的内容（## Model Set Context）。就是这么简单粗暴。
而使用Stateful API，开发者只需要传入最新的对话记录，大模型会结合该记录和其维护的历史记录，依据上下文产生新的文内容（图3）。Altman表示，基于Stateful API，用户不用再“Pay for the same tokens from the same conversation history again and again”。图3:Stateful OpenAI API其次，Stateful API的实现机制应类似于KV Cache。在Statful API的信息披露之后，X(Twitter)上就有开发者马上意识到Stateful API，类似于KV Cache机制，将有可能指数级（O(N^2 => O(N)）降低大模型应用的开销（图4）。图4 Stateful API类似于KV CacheKV Cache旨在提升大模型的计算速度。在Transformer中，Key和Value用于计算“scaled dot-product attention”，其以矩阵的形式存在。在以GPT为代表的Decoder大模型中，没有KV Caching的情况下，每次计算新attention都会重复计算该token前面所有tokens的attentions，导致算力和时间的浪费。而KV Cache的作用就是缓存前面的计算结果，让大模型专注于新token的计算，下图详细比对了无/有KV Caching的计算过程（图5）：图5:没有KV Caching vs有KV Caching**KV Cache对计算速度提升明显，例如，在不使用cache的情况下，使用GPT-2生成1000个Token将耗时56秒，而使用cache的耗时则被降低为11秒。可以预期的是，Stateful API应该会采用类似于KV Cache的机制，缓存用户对话的历史记录，并在每次API调用中，使用增量信息结合服务端的历史记录生成文本，并以此降低计算规模（图6）。图6:计算规模，Stateful vs Stateless