01

60 秒回答模板

我会把这里的记忆限定为 AI 面试系统运行中的会话状态，而不是长期人格记忆。Redis 适合保存低延迟、带 TTL 的短期上下文，例如最近 N 轮问答、当前题目、追问状态、已提取的候选人回答摘要、评分中间状态、模型请求 trace 和限流锁。数据模型上可以按 tenant、userId、sessionId、roundId 设计 key，使用 list/stream 保存轮次消息，用 hash 保存会话元数据，用 sorted set 或 stream 保存时间序列事件。每个 key 必须设置 TTL，并在会话结束、用户主动删除或隐私策略触发时清理。隔离上要避免不同用户、不同面试场次、不同租户共享上下文，模型组装 prompt 时只读取当前授权会话的数据。工程上还要处理并发写入、幂等 roundId、上下文截断、摘要压缩、Redis 故障降级和必要的持久化落库。核心思路是 Redis 管热状态和短期记忆，数据库或对象存储管需要审计和复盘的持久记录，两者职责不要混。

考点 短期记忆
难度 真实面经题
回答目标 讲清设计、取舍和边界
02

深入解析

01

先限定记忆范围

AI 面试系统的多轮记忆主要是当前面试场次内的短期状态，例如已问问题、候选人回答、追问依据、上下文摘要和评分过程。不要把它和跨月长期用户画像混在一起，否则隐私、权限和过期策略都会变复杂。

02

Redis 负责低延迟热状态

Redis 适合存储正在进行的会话上下文、最近轮次、临时摘要、题目状态、限流计数和分布式锁。它的价值是读写快、支持 TTL、易于按会话清理，适合模型每轮请求前快速装配上下文。

03

Key 和结构要可隔离

Key 应包含租户、用户、会话和轮次维度，例如 interview:{tenant}:{user}:{session}:turns。轮次消息可用 list 或 stream，会话元数据可用 hash，状态版本和锁可单独存储。这样能避免串 session，也方便按 session 删除。

04

上下文要截断和摘要

不能把所有历史轮次无限塞给模型。通常保留最近几轮原文、关键事实摘要、当前题目状态和未完成追问；更早内容做结构化摘要或落库归档。这样既控制 token，也降低 Redis 内存和隐私暴露面。

05

TTL 和生命周期要明确

创建会话时设置 TTL，活跃会话可续期，结束后转入 completed 状态并清理热 key。异常断开要有过期回收，用户删除或合规要求触发时要同时清 Redis 和持久层关联数据。TTL 不是唯一安全机制，还要有显式结束清理。

06

可靠性要防并发和丢状态

多端连接、语音转写、模型回答和评分可能并发写入同一场次，因此需要 roundId 幂等、版本号、Lua/事务或锁控制顺序。Redis 故障时要能从数据库恢复必要会话记录，或降级为无历史/少历史模式并明确标记。

03

易错点

  • 把 Redis 记忆答成泛泛的 Agent 长期记忆，没有聚焦 AI 面试会话状态。
  • 没有 sessionId、userId、tenant 等隔离维度，容易出现上下文串场。
  • 只说设置 TTL，不说明会话结束、异常断开和用户删除时的生命周期清理。
  • 把完整历史无限存入 Redis 和 prompt，忽略 token、内存和隐私成本。
  • 不处理并发写入和轮次幂等，语音、模型和评分链路可能覆盖状态。
  • 把 Redis 当唯一数据源，忽略需要审计、复盘或恢复的持久化记录。
04

面试官追问

为什么不用数据库直接存所有对话记忆？

数据库适合持久化和审计，但每轮模型请求都读写完整历史会增加延迟和压力。Redis 更适合热状态和 TTL 会话缓存，持久层保存必要记录即可。

Redis 里的对话历史太长怎么办？

保留最近轮次原文，把早期内容压缩成结构化摘要，只留下当前题目、候选人关键信息和未完成追问。模型上下文和 Redis 内存都要有预算。

如何避免两个面试场次串上下文？

Key 必须包含 sessionId 和用户/租户维度，读取时校验授权，模型上下文装配只使用当前 session 的数据，并在测试里覆盖并发多会话场景。

Redis 宕机时面试系统怎么处理？

如果有持久化对话记录，可以恢复最近必要状态；如果恢复不了，应降级为少上下文模式或提示重试，不能悄悄把空记忆当完整上下文继续评分。