在AI对话系统开发中，我们面临一个经典的矛盾：记忆越多，AI表现越"聪明"，但记忆多了又会触发Token上限。
|
很多开发者会说：“我已经用Redis/数据库存储所有对话历史了。” 但这只解决了服务端存储性能问题，并没有解决核心矛盾——当对话记录积累到一定程度，依然会超过模型的上下文窗口限制。
|
我们恰恰希望存储更多的聊天记录，因为只有这样，AI才能真正做到"像人一样"对话。问题的本质是：不是存不存得下，而是“传给模型”时受限于Token上限。
人类大脑处理记忆的方式给了我们启发：不是所有信息都需要时刻在"工作台"上，记忆应该分层管理，按需调取。由此，我们设计了一个三层记忆架构。
| 第一层：近期记忆 (Short-term)策略：保留最近的 10 条对话，维持即时连贯性。 |
| ↓ |
| 第二层：中期记忆 (Mid-term)策略：通过 RAG 检索与当前最相关的 5 条历史对话。 |
| ↓ |
| 第三层：长期记忆 (Long-term)策略：固化总结关键信息，形成用户画像/知识摘要。 |
2.1 第一层：近期记忆 (Short-term Memory)
|
这是AI的"工作记忆"，通过一个固定大小的滑动窗口（如最近10轮对话）来维持对话的流畅性。超出部分自动"降级"到中期记忆。
// 使用Spring AI的ChatMemory
MessageChatMemory chatMemory = new InMemoryChatMemory();
chatMemory.add(new UserMessage(userInput));
chatMemory.add(new AssistantMessage(aiResponse));
if (chatMemory.get().size() > 10) {
archiveToMidTerm(chatMemory.get(0)); // 异步转存
}
|
2.2 第二层：中期记忆 (Mid-term Memory)
|
核心是RAG（检索增强生成）。它不按时间顺序，而是按"语义相似度"从海量历史中检索出最相关的5条记录，从而破解时间限制，节省Token。
2.3 第三层：长期记忆 (Long-term Memory)
|
这一层不是存储对话原文，而是存储**精华的结构化总结**，类似于人类的"长期记忆"。我们提供两种实现方式：
通过定时任务（如每天凌晨）批量处理对话，提炼用户偏好和关键事实。这种方式成本低，适合大规模处理。
@Scheduled(cron = "0 0 2 * * ?") // 每天凌晨2点
publicvoidbatchProcessMemory() {
List<Conversation> conversations = getRecentConversations();
String summary = llm.call("分析对话，提取偏好...");
longTermMemoryRepo.save(summary);
}
|
在对话中实时识别关键信息点（如用户明确表达偏好、提供个人信息），并立即提取存储。这种方式响应快，用户体验好。
|
触发器示例：
用户说：“以后回答我时都用代码示例。”
系统立即触发，更新长期记忆中的规则：`response_format: code_examples`。
|
|
|
| ↓ |
| ① 加载近期记忆
|
| ↓ |
| ② RAG检索中期记忆
|
| ↓ |
| ③ 读取长期记忆
|
| ↓ |
|
|
| ↓ |
|
|
|
Token估算：近期(~1500) + 中期(~800) + 长期(~200) ≈ 2500 Tokens。远低于上限，且信息高度相关！
|
多层次记忆架构的核心思想是：模拟人类记忆的分层特性，让AI在有限的Token预算内，拥有近乎无限的记忆能力。
这不仅是技术问题的解决方案，更是AI从"对话工具"向"智能伙伴"进化的关键一步。
