day12-大模型-多轮对话,上下文管理
一、多轮对话背景：为什么"上下文"这么重要
1.1 单轮 vs 多轮的本质区别
维度 | 单轮对话 | 多轮对话 |
上下文 | ❌ 每次独立 | ✅ 保留历史消息 |
用户体验 | "金鱼脑"，聊两句就失忆 | "老朋友"，能聊一整天 |
Token 消耗 | 低（只看当前问题） | 高（每次都带历史） |
实现复杂度 | 简单 | 中等（要���理会话状态） |
典型场景 | 翻译、摘要、抽取 | 客服、辅导、AI 助手 |
1.2 现实场景为什么离不开多轮
如果只有单轮，第 2 轮用户就不知道"我"是谁了，AI 只能干瞪眼。
多轮对话的核心：让 AI "记住"前面聊过什么。
二、多轮对话的工作原理
2.1 大模型本身"没有记忆"
任何大模型（GPT、Qwen、DeepSeek…）都是无状态的：
所以"多轮"不是模型的能力，而是调用方（你的程序）的责任。
2.2 多轮 = "把历史消息打包一起发
关键结论：多轮对话 = 每次都把完整对话历史发给模型。
2.3 多轮对话系统的三件套
三、多轮对话的入门案例：手写一个最小可运行版本
3.1 用 Python 字典模拟（不依赖任何外部存储）
✅能跑，但重启就丢数据。生产环境必须用持久化存储 → 这就是 Redis 登场的原因。
四、Redis 对多轮对话消息的存储
4.1 为什么选 Redis 而不是 MySQL？
多轮对话的消息读写非常频繁（每发一条都要读 + 追加），用 Redis 性能更优。
4.2 数据结构设计（Key-Value 约定）
设计要点：用:分隔的层级结构，方便按前缀查询和清理。
4.3 Redis 客户端初始化（Python）
4.4 消息的存储格式
每条消息用JSON 字符串存到 Redis List：
ensure_ascii=False是关键 —— 不然中文会被转成\u4f60\u597d，调试时很难看。
4.5 常用 Redis 操作一览
五、创建会话与会话列表
5.1 接口设计
5.2 创建会话（完整代码）
5.3 查询会话列表
5.4 一个细节：自动用首条消息更新标题
效果：用户发了"帮我优化一份 Python 后端简历"后，会话标题自动变成"帮我优化一份…"。
5.5 前端效果
六、发送消息与查询消息
6.1 完整流程图
6.2 发送消息接口
6.3 查询消息接口
6.4 为什么要跳过第 0 条？
- 第 0 条是
system prompt（给模型看的，不该给用户看）
- 返回给前端时从
LRANGE 1 -1跳过它即可
七、多轮对话优化：你会遇到的所有坑
7.1 坑 1：消息越长，调用越慢、越贵
💥必须做上下文管理，否则用户聊到 50 轮就崩了。
7.2 坑 2：JSON 解析失败导致整条消息丢失
7.3 坑 3：Redis 内存无限增长
会话和消息没有过期时间 → 用久了内存爆炸。
7.4 坑 4：并发写入冲突
两个用户同时发消息 →LRANGE+RPUSH之间可能丢数据。
方案：用 Redis 事务或分布式锁。
7.5 坑 5：异步任务阻塞 HTTP 请求
send_message同步等大模型返回 → 客户端 HTTP 超时。
方案 1：让前端用异步轮询
方案 2：用 WebSocket 或 SSE 推结果
八、滑动窗口 + 历史压缩：上下文管理的两把利剑
8.1 为什么需要上下文管理？
大模型的context window（上下文窗口）是有限的：
超过这个长度，模型要么报错，要么"忘记"最早的内容。
现实业务中我们不可能让用户聊到上限才动手，必须提前压缩。
8.2 滑动窗口：保留最近 N 条
最简单粗暴：只保留最近的 10 条消息。
优点：实现极简、速度快。缺点：前 N-10 条的上下文彻底丢失，AI 会"突然失忆"。
8.3 历史压缩：让大模型自己"总结"
更聪明的做法 ——让大模型把早期对话压缩成一段摘要，再和最近的消息一起发给模型
8.4 效果对比
只滑动窗口：
8.5 进阶：三级压缩策略
效果：聊到几百轮也几乎不丢上下文。
8.6 压缩策略选型表
九、把整套流程串起来
9.1 完整系统架构
9.2 完整调用链路（一次 send_message）
9.3 一次完整会话的 Redis 数据演变
十、总结：一张图看懂多轮对话学习路径
一句话总结
多轮对话 = 每次把历史 messages 一起发给模型，会话和消息存 Redis，长了用"滑动窗口 + 历史压缩"控制成本。