三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

大模型无状态架构解析：从原理到实战，构建有记忆的AI应用

发布时间：2026/8/16 23:12:42 三亩地 编程学习日记
大模型无状态架构解析：从原理到实战，构建有记忆的AI应用

1. 项目概述：从“健忘”的对话说起

你有没有过这样的体验？和某个AI助手聊得正欢，你告诉它你叫张三，喜欢打篮球，住在北京。聊了十几句后，你问它：“那我刚才说我叫什么名字来着？”它很可能一脸茫然地回答：“抱歉，我无法访问之前的对话信息。”或者更直接地告诉你：“我是一个AI模型，没有记忆能力。”这种瞬间“失忆”的体验，就是大模型“无状态”（Stateless）特性的直接体现。这并非程序员的疏忽，而是当前绝大多数大语言模型（LLM）服务在设计之初就遵循的核心架构原则。简单来说，每次你向模型发起一次请求（比如问一个问题），模型都像是第一次见到你，它只处理你这次发送的文本（即“提示词”或“上下文”），而不会记住上一次、上上次你们聊了什么。这种设计，与我们人类，或者与传统的、有状态的服务器应用（比如你的微信，能记住你的登录状态和聊天记录）形成了鲜明对比。

理解“无状态”不仅是理解大模型工作原理的钥匙，更是我们有效使用和开发大模型应用的基础。它直接决定了对话体验的连续性、个性化服务的实现方式，以及整个应用架构的设计思路。无论是普通用户想更好地与ChatGPT、文心一言等产品交互，还是开发者计划基于API构建自己的AI应用，都必须先过“无状态”这一关。否则，你可能会陷入“为什么它总记不住我”的困惑，或者在技术选型上走弯路。本文将深入拆解大模型“无状态”背后的技术原理、设计考量、带来的挑战以及业界是如何通过“打补丁”的方式来解决“记忆”问题的。我们会从一次典型的API调用开始，一直讲到构建有状态应用服务层的实战方案。

2. 无状态的核心原理与设计考量

2.1 什么是“无状态”：一次请求，一次计算

在计算机科学中，“无状态”（Stateless）指的是服务器不保存客户端请求之间的任何状态信息。每一次请求都必须包含处理该请求所需的全部信息，服务器处理完毕后，不保留任何与该次请求相关的“记忆”，以备下次使用。

把这个概念映射到大模型上，就变得非常直观。以调用OpenAI的GPT-4 API为例：

import openai # 第一次请求 response1 = openai.ChatCompletion.create( model="gpt-4", messages=[ {"role": "user", "content": "我叫李雷，我的爱好是编程和登山。"} ] ) print(response1.choices[0].message.content) # 模型可能会回复：“你好李雷，很高兴认识你！编程和登山都是很棒的兴趣爱好。” # 第二次请求（完全独立） response2 = openai.ChatCompletion.create( model="gpt-4", messages=[ {"role": "user", "content": "我刚刚告诉你我的爱好是什么？"} ] ) print(response2.choices[0].message.content) # 模型大概率会回答：“抱歉，我无法访问之前的对话信息。在我们的这次对话中，你还没有告诉我你的爱好。”

在上面的代码中，response1和response2是两个完全独立的HTTP请求。对于API服务器背后的GPT-4模型来说，它处理response2时，根本“不知道”世界上存在过response1这次请求。它看到的只是一个孤零零的问题：“我刚刚告诉你我的爱好是什么？”，而这个问题本身缺乏必要的上下文，因此模型无法给出正确答案。

为什么设计成无状态？这背后有深刻的技术和工程考量：

  1. 简化与纯净的计算模型：大模型的核心是一个极其复杂的数学函数（一个拥有数百亿甚至上万亿参数的深度神经网络）。它的设计目标非常纯粹：给定一段输入文本（上下文），预测下一个最可能的词（Token），并循环此过程生成完整回复。这个函数本身不包含“记忆”机制。保持无状态，意味着每次推理（Inference）都是一次独立的、纯净的函数计算，避免了状态管理带来的复杂性污染核心算法。

  2. 水平扩展与负载均衡：无状态是构建高可扩展、分布式系统的黄金法则。想象一下，如果模型需要记住每个用户的对话历史，那么当用户下次请求到来时，就必须被路由到之前处理过该用户请求的、存有其历史的那台特定服务器上。这被称为“粘性会话”（Sticky Session），会严重限制系统的弹性。而无状态设计下，任何一次请求都可以被负载均衡器发送到集群中的任何一台模型实例上处理，极大地提升了系统的吞吐能力和可靠性。

  3. 资源隔离与安全性：无状态意味着请求之间完全隔离。一个用户的错误输入或恶意攻击不会影响到其他用户的会话。模型实例在处理完一个请求后，其内部的计算状态（如注意力机制的中间结果）会被释放，不会泄露给下一个请求，这从某种程度上提供了基础的安全和隐私保障。

  4. 降低服务端复杂性：管理海量用户的对话状态是一个巨大的工程挑战。需要设计高可用、低延迟的分布式存储系统来保存这些状态，并处理状态的创建、读取、更新和删除（CRUD）。对于追求极致推理速度和大规模并发的模型服务提供商来说，将状态管理剥离出核心推理服务，是更明智的架构选择。

注意：这里说的“状态”主要指对话历史状态。模型本身的参数权重（即它学到的知识）是持久化存储的，这是它的“长期记忆”或“固有知识”。而我们讨论的“记不住你是谁”，指的是它缺乏“短期记忆”或“情景记忆”。

2.2 上下文窗口：无状态下的“临时工作区”

既然模型本身无状态，那么我们常听到的“上下文长度”（Context Length）又是什么呢？比如GPT-4 Turbo支持128K上下文。这其实是模型“无状态”特性下的一个关键补偿机制。

你可以把“上下文窗口”想象成模型每次处理请求时，你提供给它的一个“临时工作白板”。这个白板的大小是固定的（比如128K个Token）。你可以在这块白板上写下本次请求需要的所有信息：系统指令（System Prompt）、之前的对话历史、用户当前的问题、以及相关的知识文档片段等等。模型在生成回复时，只能“看”这块白板上的内容。

关键点在于：这块白板的内容完全由调用方（你）来管理和填充。API服务器不会在两次请求之间帮你保存白板上的内容。如果你希望下一次对话能延续上一次的内容，你就必须手动地把上一次的对话记录（包括你的提问和模型的回答）都抄写到新的白板上，连同你的新问题一起，作为新的请求发送给模型。

# 模拟一个连续对话，需要手动维护上下文 conversation_history = [] # 第一轮 user_input_1 = "我叫李雷，我的爱好是编程和登山。" conversation_history.append({"role": "user", "content": user_input_1}) response1 = openai.ChatCompletion.create( model="gpt-4", messages=conversation_history # 此时history里只有用户的第一句话 ) assistant_reply_1 = response1.choices[0].message.content conversation_history.append({"role": "assistant", "content": assistant_reply_1}) # 现在history里有了：[用户说A， 助手回复A] # 第二轮 user_input_2 = "我刚刚告诉你我的爱好是什么？" conversation_history.append({"role": "user", "content": user_input_2}) # 现在history里是：[用户说A， 助手回复A， 用户说B] response2 = openai.ChatCompletion.create( model="gpt-4", messages=conversation_history # 将完整的对话历史作为上下文发送 ) # 这次模型就能正确回答了，因为它“看到”了白板上的整个对话记录。

因此，上下文窗口的大小，直接决定了你能在单次请求中提供给模型的“临时记忆”容量。但这也带来了两个实际问题：

  1. 成本与性能：上下文越长，模型处理所需的计算量越大，生成速度越慢，API调用费用也越高（通常按输入+输出的总Token数计费）。
  2. 历史截断：当对话轮数很多，总长度超过上下文窗口时，你必须决定舍弃哪部分历史。常见的策略是“滑动窗口”，只保留最近N轮对话，或者更智能地压缩/总结早期历史。

3. 构建“有状态”体验的实战方案

理解了无状态的本质和上下文窗口的机制后，我们就能明白，要让大模型“记住”我们，关键不是在模型层面做改动，而是在应用层构建一个“状态管理”层。这个层负责持久化存储用户与模型的交互历史，并在每次用户发起新请求时，智能地组装出合适的上下文，发送给无状态的模型。以下是几种主流的实现方案。

3.1 方案一：朴素对话历史拼接

这是最简单直接的方法，适用于对话轮次较少、上下文长度充裕的场景。

实现步骤：

  1. 为每个用户或每个会话（Session）创建一个唯一的标识符（如session_id）。
  2. 在后端数据库（如Redis、PostgreSQL、MongoDB）中，以session_id为键，存储一个消息列表（List），格式与OpenAI API的messages参数一致（包含role和content）。
  3. 用户每次发送新消息时： a. 从数据库取出该会话的所有历史消息。 b. 将新消息追加到历史消息列表末尾。 c. 检查整个列表的Token总数是否超过模型上下文限制。 d. 如果超过，则按策略截断（如从最旧的消息开始删除），确保在限制内。 e. 将处理后的消息列表作为messages参数，调用大模型API。 f. 将模型的回复也追加到消息列表中，并写回数据库。

实操要点与避坑指南：

  • 存储选择：对于需要快速读写的对话场景，Redis是极佳选择。如果对话历史很长且需要复杂查询，可以考虑MongoDB或PostgreSQL的JSONB字段。
  • Token计数：必须准确计算消息列表的Token数。不要简单地用字符串长度除以4来估算，对于中文混合文本误差很大。务必使用模型对应的Tokenizer（如OpenAI的tiktoken， Hugging Face的transformers库）进行精确计数。
    import tiktoken encoding = tiktoken.encoding_for_model("gpt-4") def count_tokens(text): return len(encoding.encode(text))
  • 截断策略：简单的“丢弃最旧消息”可能丢失重要信息（如系统指令或早期设定的用户偏好）。更好的策略是：
    • 优先级保留：永远保留系统指令（role: system）。
    • 总结压缩：当历史过长时，可以调用一次模型，让它自己总结之前的对话核心内容，然后用总结文本替换掉大段历史。
    • 向量检索（进阶）：将历史对话切片存入向量数据库，每次只检索与当前问题最相关的片段放入上下文。这引出了我们的下一个方案。

3.2 方案二：外挂记忆库与向量检索

当对话历史非常长，或者你需要模型记住大量背景知识（如公司产品文档、个人笔记）时，朴素拼接就不够用了。这时需要引入“外挂记忆库”，核心是向量数据库（Vector Database）。

核心思路：将需要记忆的文本信息（无论是对话历史还是知识文档）通过嵌入模型（Embedding Model）转换成高维向量（Vector），存储到向量数据库中。当用户提出新问题时，将问题也转换成向量，然后在向量数据库中搜索与之最相似的文本片段（即“记忆”），将这些片段作为上下文的一部分送给大模型。这样，模型每次都能“回忆”起最相关的内容，实现“长期记忆”。

技术栈与流程：

  1. 嵌入模型：将文本转换为向量。可以选择OpenAI的text-embedding-ada-002，或开源的如BGE、Sentence-Transformers模型。
  2. 向量数据库：存储和检索向量。常用选择有Pinecone（云服务）、Weaviate（开源）、Qdrant（开源）、Milvus（开源）等。
  3. 流程： a.记忆存储：用户每说一段有意义的话，或当对话进行到一定阶段，将这段文本通过嵌入模型向量化，连同原始文本一起存入向量数据库，并关联用户ID。 b.记忆检索：用户发起新查询时，将查询文本向量化，用该向量在向量数据库中搜索与该用户相关的、最相似的K条记忆（比如余弦相似度最高的Top 5）。 c.上下文组装：将检索到的这K条记忆文本，以“以下是相关背景信息：...”的格式，插入到本次请求的上下文（messages）中，通常放在系统指令之后，用户当前问题之前。 d.调用模型：将组装好的上下文发送给大模型API获取回复。

实操心得：

  • 分块（Chunking）策略：存入向量数据库的文本不能太长或太短。太长则包含信息不聚焦，检索精度低；太短则缺乏上下文。一般200-500字为一个块（Chunk）比较合适。可以使用重叠滑动窗口来分块，避免在块边界切断重要信息。
  • 元数据过滤：除了向量相似度，检索时还应结合元数据过滤，比如时间（优先检索最近的记忆）、记忆类型（是事实、观点还是待办事项？）。这能大幅提升记忆的相关性。
  • 记忆的更新与遗忘：不是所有对话都需要永久记忆。可以设计规则：只有用户明确要求“记住这个”，或者模型判断某信息非常重要（可通过让模型对对话片段打重要性标签实现）时，才存入长期记忆库。同时，可以设置记忆的“过期时间”或“衰减因子”，模拟人类的遗忘曲线。

3.3 方案三：智能体（Agent）与工具调用

对于更复杂的、需要执行多步骤任务或与外部系统交互的场景，“智能体”架构成为实现有状态体验的更高级范式。智能体本身是一个有状态的程序，它以大模型为“大脑”，通过“工具调用”（Function Calling）来感知和操作外部世界，并维护自己的任务执行状态。

在这种架构下，记忆分为多个层次：

  1. 对话历史：仍由应用层管理，作为上下文的一部分。
  2. 智能体状态：智能体当前的目标、已完成的步骤、下一步计划等，存储在后端的状态机或数据库中。
  3. 工具执行结果：调用搜索引擎、数据库、API等外部工具返回的结果，这些结果可以作为新的上下文输入给模型，影响其后续决策。
  4. 长期知识：通过向量数据库存储的领域知识。

一个典型的智能体工作流（以订机票为例）：

  1. 用户说：“我想下周五从北京飞往上海。”
  2. 应用层将用户消息和简短对话历史发送给大模型（配置了tools参数，描述了“查询航班”的工具）。
  3. 大模型分析后，决定调用“查询航班”工具，并返回结构化的调用参数（{“departure”: “北京”， “destination”: “上海”， “date”: “下周五”}）。
  4. 应用层（智能体框架）执行工具调用，访问航班API，拿到航班列表结果。
  5. 应用层将工具执行结果作为新的上下文，连同原始对话，再次发送给大模型。
  6. 大模型根据航班结果，生成回复：“找到以下航班：A航空9:00起飞... B航空14:00起飞... 您选择哪个？”
  7. 用户做出选择，循环继续，直到完成订票、付款等所有步骤。

在整个过程中，智能体框架需要维护“用户正在订票”这个任务状态，记住用户已选择的航班、座位等信息，并在每一步将必要的历史和状态信息组装进上下文。这实现了超越简单对话的、有状态的复杂交互。

4. 本地部署大模型中的状态管理实践

上述方案主要针对调用云端API。对于在本地部署开源大模型（如使用Ollama、vLLM、Llama.cpp等工具）的开发者，状态管理的原理相通，但实践细节有所不同。

4.1 本地模型服务的无状态性

像Ollama、通过vLLM或Transformers库部署的模型服务，其无状态特性与云端API一致。每次向localhost:11434（Ollama默认端口）或你的API端点发送POST请求，模型都是独立处理该次请求的上下文。Ollama的/api/chat接口在设计上就要求你将整个对话历史放在messages里。

本地部署的优势在于：你可以完全控制整个技术栈，因此可以更灵活、更深度地定制状态管理逻辑，而无需担心云端API的调用限制和费用。

4.2 使用LangChain、LlamaIndex等框架简化开发

对于快速构建应用，不建议从头造轮子。像LangChain和LlamaIndex这类框架，其核心价值之一就是提供了强大的状态（上下文）管理抽象。

  • LangChain：提供了ConversationBufferMemory、ConversationSummaryMemory、ConversationBufferWindowMemory等多种记忆组件。它们本质上都是帮你管理那个“消息列表”，并提供了自动的Token计数、历史总结、滑动窗口等功能。你可以轻松地将这些记忆组件与链（Chain）或智能体（Agent）结合。

    from langchain.memory import ConversationBufferMemory from langchain.llms import Ollama from langchain.chains import ConversationChain llm = Ollama(model="llama3") memory = ConversationBufferMemory() # 创建一个对话记忆体 conversation = ConversationChain( llm=llm, memory=memory, # 链会自动使用和管理这个记忆体 verbose=True ) conversation.predict(input="我叫李雷。") conversation.predict(input="我刚刚说我叫什么？") # 这里能正确回答，因为memory保存了历史

    LangChain的记忆体后端可以是内存、Redis或数据库，方便持久化。

  • LlamaIndex：更侧重于对私有数据的索引和检索。它的ChatEngine可以与向量数据库无缝集成，非常适合于构建基于知识库的、有记忆的问答机器人。你可以将每次有意义的问答对也索引到向量库中，作为未来检索的“记忆”。

实操建议：如果你是初学者，想快速搭建一个能记住对话历史的本地AI应用，Ollama + LangChain是一个极佳的组合。Ollama负责模型的拉取和运行，LangChain负责对话流程和状态管理，几行代码就能搭出原型。

4.3 性能与成本的权衡

在本地部署场景，状态管理带来的主要挑战是显存（GPU Memory）压力。

  • 长上下文消耗显存：当你将很长的对话历史塞进上下文时，模型在进行注意力计算（Attention）时，需要为上下文中的每个Token两两计算关联度，这会产生一个(序列长度 x 序列长度)的矩阵，消耗O(n²)的内存。128K的上下文会占用巨大的显存。
  • 解决方案：
    1. 使用支持长上下文的优化模型和推理引擎：例如，使用基于FlashAttention、PagedAttention（vLLM使用）等优化技术的模型。这些技术通过算法优化，大幅降低了长序列注意力计算的内存开销。
    2. 使用较小的模型：7B、13B参数的模型比70B的模型处理长上下文所需的显存小得多。在显存有限的情况下（如消费级显卡），这是最实际的選擇。
    3. 更激进的历史压缩：不仅要在应用层做截断，可以训练一个小的“总结模型”，或者使用大模型自身的总结能力，将冗长的历史压缩成几个关键要点，再用要点作为后续对话的上下文。

5. 常见问题与高级技巧实录

在实际开发和调试中，你会遇到各种各样关于“记忆”的问题。下面是一些典型场景和解决思路。

5.1 为什么模型有时好像“记得”，有时又“忘了”？

这通常不是模型的错，而是上下文管理出了问题。

  • 检查Token计数和截断：最可能的原因是对话历史超过了上下文限制，导致最早的关键信息（比如你的名字）被截断丢弃了。务必在每次组装请求前精确计算Token数，并确认你的截断策略没有误删重要信息。
  • 系统指令（System Prompt）被覆盖：如果你在每次请求中都发送系统指令，并且历史过长时从中间截断，可能会导致系统指令被移除。最佳实践是永远将系统指令固定在上下文的最开头，并在截断逻辑中将其排除。
  • 向量检索的“幻觉”：如果使用向量检索作为记忆，检索到的片段可能不准确或不完整，导致模型基于错误的信息回答。可以尝试：
    • 调整检索的相似度阈值，过滤掉低分结果。
    • 使用“重排序”（Re-ranking）技术，对检索到的Top K个结果用更精细的模型进行相关性排序。
    • 在提供给模型的上下文中，明确标注检索来源的可信度。

5.2 如何让模型记住复杂的、结构化的信息？

简单的对话历史是线性的文本。但如果你想让它记住“我的偏好是：咖啡加糖不加奶；每周三下午3点开会；最喜欢的颜色是蓝色”这类结构化信息，直接堆在对话历史里效率很低。

  • 创建“用户档案”摘要：定期（比如每10轮对话后）或由用户触发，让模型根据最近的对话历史，总结或更新一份结构化的用户档案（JSON格式）。将这个档案文本单独存储。
  • 在系统指令中动态注入：每次请求时，将这份最新的用户档案作为系统指令的一部分，或者放在系统指令之后、对话历史之前。例如：
    [系统指令] 你是一个有帮助的助手。以下是当前用户的已知信息：{用户档案JSON字符串}。请参考这些信息进行回复。
  • 使用函数调用更新档案：当用户在对话中透露新的结构化信息时（如“把我刚才说的开会时间改成周四”），可以让模型调用一个“更新用户档案”的函数，由后端程序来精确修改档案数据库。

5.3 处理多轮任务与状态保持

对于“帮我写一份报告，先列大纲，再写第一章，再修改...”这类多轮协作任务，仅仅记住对话历史是不够的，需要维护任务状态。

  • 定义任务状态机：为你的应用可能处理的复杂任务设计一个状态机。例如，写报告任务可能有状态：IDLE->OUTLINING->WRITING_SECTION_1->REVISING->COMPLETED。
  • 将状态信息纳入上下文：将当前任务状态、已完成的步骤、下一步建议等，以清晰、结构化的文本描述，放入每次请求的上下文。可以放在系统指令或一个专门的role: system消息中。
    （系统消息）当前任务：撰写季度报告。状态：正在撰写第一章。已完成：报告大纲已确认。下一步：完成第一章初稿。用户提供的材料链接：...
  • 让模型感知状态：在系统指令中明确告诉模型：“你正在协助用户完成一个多步骤任务。请关注当前任务状态，并引导用户进入下一步。”模型在生成回复时，就会考虑到这个状态，从而做出连贯的行为。

5.4 记忆的隐私、安全与清理

为用户保存记忆带来了隐私和责任问题。

  • 加密存储：所有存储在数据库或向量库中的用户对话历史和记忆，都应该进行加密（至少是字段级加密）。密钥由用户自己管理（在可行的情况下）或由应用安全保管。
  • 提供记忆管理界面：像ChatGPT一样，提供“查看记忆”、“关闭记忆”、“删除特定记忆”的功能。这是对用户权利的尊重，也是合规（如GDPR）的要求。
  • 设置自动清理策略：并非所有对话都需要永久记忆。实现自动清理策略，例如：
    • 对话结束后X天删除原始日志。
    • 只保留被标记为“重要”的记忆向量。
    • 定期运行一个清理任务，删除长时间未激活用户的记忆数据。

理解大模型的“无状态”特性，不是学习的终点，而是构建真正实用、智能应用的起点。它迫使我们将“记忆”和“推理”这两个功能解耦，从而催生了更灵活、更强大的应用架构。从简单的手动历史管理，到基于向量的智能检索，再到拥有复杂状态机的智能体，我们正是在为这个“健忘”的超级大脑，一步步搭建起属于它的“外接硬盘”和“事务备忘录”。

编程学习 学习日记 实战经验
← 返回列表