面经策

在大模型应用中，通常如何实现长短期记忆机制？ ​

  • 标签：AI、大模型

🏛 业务架构师 ​

长短期记忆机制我按"业务用途"来拆解：

短期记忆（会话内）：就是当前对话的上下文窗口，存最近几轮问答。实现上用消息列表+滑动窗口截断，或超长时做摘要压缩。业务价值是让多轮对话连贯（"他"指谁、"还是那个订单"），成本低但容量有限——对应"这次交互要记的事"。

长期记忆（跨会话）：用户偏好、历史行为、关键事实（客户等级、踩过的坑）。三种主流实现：

  • 向量记忆库：把历史对话要点向量化存库，按当前话题语义检索相关记忆注入上下文——最通用；
  • 结构化档案：用 LLM 定期从对话中抽取"用户画像字段"写入 Profile 表，可控性最强，适合 CRM 类场景；
  • 知识图谱记忆：实体关系式存储，适合需要推理的场景（"他上次推荐的供应商和这次纠纷有关联吗"）。

业务提醒：长期记忆是双刃剑——用户被 AI"记住太多"会恐慌，涉及健康、情绪等敏感信息要给用户查看和删除记忆的入口，这已是 2026 年个人信息保护合规的基本要求。记忆策略要按业务价值裁剪，不是记得越多越好。

🏗 系统架构师 ​

长短期记忆我按存储层次结构设计，本质是给 Agent 加一个"缓存与数据库"分层：

短期记忆（Working Memory）：

  • 载体就是上下文窗口内的对话历史，会话级生命周期；
  • 工程：按轮次/Token 预算滑动窗口截断，关键实体和决策抽取后保留；窗口接近上限触发摘要压缩（Compaction）；
  • 2026 年窗口普遍 128K~1M，但按 token 计费 + lost-in-the-middle 效应意味着"能放"不等于"该放"。

长期记忆（Persistent Memory）：

  • 写入：会话结束时用 LLM 抽取"值得记的"——用户偏好、事实、承诺、任务结论，结构化存储（用户画像表 + 事实三元组 + 向量化的情节记忆）；
  • 读取：检索式——当前 query 嵌入后从记忆库召回相关条目，注入 system prompt，这就是"个人 RAG"；
  • 存储：分层选型——结构化事实进 Postgres，语义情节进向量库，热数据进 Redis。

架构权衡：记忆写入是异步旁路（不阻塞回复），读取增加 50~100ms 检索延迟；记忆要有 TTL、置信度和冲突合并策略（用户改口时新事实覆盖旧事实），否则长期使用后记忆污染会让 Agent"记错事"。这层做扎实，是 Agent 从"工具"变"助手"的分水岭。

💻 全栈开发专家 ​

长短期记忆我按「预算和生命周期」分层实现：

短期记忆（会话内）：就是上下文窗口里的消息历史。策略是裁剪+摘要：最近 N 轮保原文，更早的滚动压缩成摘要放在 system 区。LangChain 的 trim_messages / LangGraph 的 state 里做 compaction 都行。

长期记忆（跨会话）：外置存储 + 检索召回，三种载体按需选：

  1. 向量库（情景记忆）：用户偏好、历史事实存成带 embedding 的条目，每轮对话前按当前 query 检索 top 3 注入；
  2. 结构化表（用户画像）：显式事实（姓名、会员等级、常用地址）存 KV/关系库，规则化读取，最可控；
  3. 图数据库（关系记忆）：用户-人-偏好之间的关联，复杂个性化才需要。
python
# LangGraph Store 一行搞定长期记忆
from langgraph.store.postgres import PostgresStore
store.put(("memories", user_id), key, {"text": "用户偏好京东自提"})
mem = store.search(("memories", user_id), query=当前消息)

踩坑：记忆写入要有门槛（不是每句话都值得记，用 LLM 判断「是否长期有用」）；记忆会过期，要带时间戳做置信度衰减；成品的 Mem0/Zep 已把这整套（抽取-去重-冲突合并-遗忘）做好，自研前先试试。