时间窗口对话系统：约束与取舍

这道题其实在问一个挺本质的问题：对话系统怎么处理时间这个维度？说白了就是，系统什么时候该记住，什么时候该忘，以及怎么让用户觉得你既聪明又靠谱。

先说概念区分。时间窗口和时间偏移，很多人混着用，但落地场景差挺多的。时间窗口，比如金融客服只认最近30分钟的对话，适合那种上下文会迅速过期的场景，像查账户余额、查汇率，早几分钟的对话现在可能就没意义了。时间偏移呢，更像是指定第几轮之前的内容，适合多轮任务，比如用户说“按刚才第三轮说的方案来”，这个偏移量是相对于当前轮次，不是绝对时间。真正落地的时候，很少只用一种，往往是窗口加偏移一起上，比如窗口兜底保证上下文长度，偏移用来做精确回溯。

具体到技术实现，核心挑战是上下文管理。我一般会按时间分层：窗口内的热数据全量保留，窗口外但语义相关的用 [[Sliding Window]] 加摘要压缩，再远的就归档或者丢弃。这里有个坑：直接硬截断会让用户觉得系统失忆，所以需要一种渐进式遗忘。比如用户问“我上次说的那个方案”，如果刚好超了窗口，系统不会说“我不记得”，而是说“我记得您之前讨论过方案，但细节可能需要您再确认一下”，这种体验就好很多。

模型推理层面，我会在输入里显式注入时间戳，比如 [2024-01-15 09:23] 用户: ...，让模型感知时间顺序。对于长上下文模型，[[RoPE]] 本身有位置编码，但时间跨度大了之后，位置编码会失效，所以得用一些插值技术，比如 NTK-aware，让模型能处理更长时间跨度的相对位置。

再讲业务落地。拿金融客服举例子，用户问“我上周申请的理赔到哪了”，系统如果只靠窗口内上下文，肯定找不到，因为上周的对话早被截断了。这时候就需要 [[RAG]] 增强，向量检索加时间衰减[[重排]]。具体做法是：先用语义检索找到相关片段，然后按照时间衰减因子重排，比如 score = 语义分 × exp(-λ·时间差)。同时还要注意合规留痕，金融场景要求全量存储不能丢，但推理时又必须限制窗口，所以我会用“全量日志加窗口上下文加按需RAG召回”的三层架构。日志存全量用于审计，窗口上下文用于实时对话，RAG用于回溯历史。

上线前我会特别关注几个风险。一是时间衰减的 λ 参数怎么调，调太大会过滤掉有用的历史信息，调太小又会让窗口失去意义。二是渐进式遗忘的实现，如果用户主动说“记住这个”，系统得有能力突破时间窗口，把那个点标记为持久记忆。三是性能，RAG 检索如果每次都要扫全量日志，延迟会很高，所以得做冷热分离，热数据在内存，冷数据在磁盘。

所以我的判断是，不能把时间窗口当成一个死规则，它更像一个动态的、可配置的软约束。我更倾向把时间感知做成系统的一个可插拔模块，根据业务场景灵活调整。比如客服场景偏重时效性，窗口可以短一点；企业 SOP 问答偏重准确性，窗口可以长一点甚至全量。

另外，这里其实有一个更深的点：时间窗口和用户意图的耦合。有时候用户说“刚才”，但“刚才”到底指多久？可能用户觉得是5分钟前，系统觉得是3轮对话前。这就涉及到时间表达的理解和归一化，我目前的做法是用一个小的 [[NER]] 模型抽取出时间表达式，然后映射到系统内部的时间戳或者轮次偏移。这块如果面试官感兴趣，可以展开讲讲具体怎么对齐。