大模型应用里的会话状态应该如何管理?
简化版
会话状态管理要区分短期上下文、摘要状态、长期记忆、业务状态和审计日志。不能把所有历史原样塞进 prompt,而要按 token 预算、相关性、权限和新旧冲突进行压缩与检索。
详细版
- 短期上下文保存最近交互,适合当前连续对话。
- 摘要状态把长历史压缩成可恢复的任务信息。
- 长期记忆保存用户偏好、项目事实等可复用信息,但要可删除。
- 业务状态来自订单、工单、数据库等权威系统,不能被模型随意覆盖。
- 状态拼装前要做权限过滤、过期判断和冲突处理。
完整版教学
记忆钩子:上下文是“这次要看的材料”,状态管理是“决定哪些材料能上桌”。
一、这题真正考什么
记忆钩子:上下文是“这次要看的材料”,状态管理是“决定哪些材料能上桌”。
面试官真正想看的是你有没有生产工程视角:能不能把模型能力、业务流程、用户体验、成本和风险放在同一张图里思考。回答时不要只停留在工具名,而要讲出边界、链路和验收方式。
二、核心原理和工程边界
LLM 每次请求只看到当前输入 token,因此会话状态本质上是应用层在请求前拼装上下文。好的状态管理会把历史消息、摘要、长期记忆和业务事实分开存放,并在每次请求前按任务意图检索。这样能降低成本,也能减少旧信息误导模型。
LLMOps 的难点在于模型行为不是传统函数调用,输入稍变、模型版本稍变、上下文稍变,都可能让输出分布变化。因此工程系统必须把“可变的模型行为”包进“可管理的发布、监控和回滚流程”。
三、带数字的工程算例
用户连续聊了 50 轮,原始历史有 45000 token,而模型窗口只有 16000 token。系统可以保留最近 4000 token、摘要 1000 token、检索 6 条相关记忆共 1200 token,再给当前问题和输出预留 4000 token。
这个算例的作用不是追求精确到小数,而是帮助你在面试中建立量级感。只要能估出 token、并发、延迟、成本或错误率的数量级,你的回答就会从概念题变成工程题。
上下文预算 = 窗口上限 - 系统提示 - 工具说明 - 当前输入 - 输出预留
历史压缩率 = 摘要 token / 原历史 token
状态可信度:业务数据库 > 工具返回 > 长期记忆 > 用户口述历史
四、典型链路怎么跑
可以把这类问题拆成下面的链路来理解:
新请求进入
|
读取最近消息
|
加载摘要状态
|
检索长期记忆
|
查询业务事实
|
权限过滤与冲突解决
|
拼装 prompt
链路图的价值在于暴露责任边界:哪一步做权限,哪一步算成本,哪一步可重试,哪一步必须审计。面试时能画出链路,通常就能自然回答故障排查和系统设计追问。
五、方案对比和选择标准
| 状态类型 | 来源 | 处理方式 |
|---|---|---|
| 短期上下文 | 最近对话 | 截断或窗口保留 |
| 摘要状态 | 历史压缩 | 持续更新并校验 |
| 长期记忆 | 外部存储 | 检索、过期、可删除 |
| 业务状态 | 权威系统 | 工具查询,不靠模型猜 |
选择方案时要先说评估维度,再说取舍。LLMOps 面试很看重这种思维,因为真实系统没有银弹,只有在质量、成本、延迟、安全和维护成本之间做平衡。
六、上线后最容易出问题的地方
- 旧状态和新指令冲突时,要明确优先级,否则模型可能沿用过期偏好。
- 长期记忆涉及隐私,必须有用户可见、可改、可删的产品机制。
- 只在少量 demo 上验证会低估风险,真实流量中的长尾输入、权限组合和外部依赖更复杂。
- 没有版本记录时,线上问题很难复现;prompt、模型、知识库、工具和配置都要纳入发布记录。
七、常见误区与追问
- 误区:多轮对话就是把历史全拼上。 要补充适用条件、失败模式和工程兜底,避免把局部经验讲成绝对规律。
- 误区:摘要状态一定不会丢关键信息。 要补充适用条件、失败模式和工程兜底,避免把局部经验讲成绝对规律。
- 误区:模型记忆可以替代业务数据库。 要补充适用条件、失败模式和工程兜底,避免把局部经验讲成绝对规律。
- 追问:状态过期应该怎么设计? 先给判断标准,再从数据、链路、权限、监控或评测角度说明落地方案。
- 追问:如何处理用户纠正旧信息? 先给判断标准,再从数据、链路、权限、监控或评测角度说明落地方案。
- 追问:为什么状态管理会影响幻觉率? 先给判断标准,再从数据、链路、权限、监控或评测角度说明落地方案。
八、加强记忆
按“短期、摘要、长期、业务、审计”五类记。回答时强调状态不是越多越好,而是相关、可信、合规、可控。
复习 LLMOps 题时,可以固定用“目标、链路、预算、风险、观测、回滚”六步组织答案。这样既能回答原理,也能自然延伸到生产系统设计。