会话边界问题：计费、评估和记忆的对话终点在哪里

三个团队正在查看同一个事件流，每个团队都有一个名为 session_id 的列，但每个团队对什么是“会话”都有不同的定义。计费（Billing）继承了来自认证库的 30 分钟空闲窗口。评估（Eval）从聊天机器人框架中继承了“直到用户说‘再见’或停止打字 10 分钟为止”的定义。记忆（Memory）则使用 UI 在用户点击“开启新聊天”时生成的线程 ID —— 而大多数用户从不点击这个按钮。三列数据，三种语义，一个汇总仪表盘，以及三个共用一个根因但互不相关的 Bug。

这就是会话边界问题（session boundary problem）。它看起来像是一个埋点琐事，但实际上是一个披着基础设施外衣的产品问题：一段对话在哪里结束？坦诚的回答是没有单一的标准答案 —— 计费会话、评估会话和记忆会话并不是同一种对象 —— 如果一个团队选择了一个默认定义并让另外两个团队继承它，那么他们交付的就是具有相同根因的计费纠纷、评估偏见和内存泄漏。

隐藏在一个列中的三种定义

生产遥测中的“会话”就像“用户”一样被过度负载了 —— 每个人都认为自己知道它的含义，且每个人使用的定义都与其邻居略有不同。最重要的三个调用端各自的需求都不一样。

计费（Billing） 想要一个能对应到价值单位的成本单位。对于按对话计费的定价层（某些支持平台每次解决问题收费 0.49–0.99 美元），边界必须与客户感知的单次交互一致 —— 否则，一个关闭标签页去喝杯咖啡并在 15 分钟后回来的用户，要么会因为同一个任务被计费两次，要么会停留在一个永不结束的“会话”中导致收入统计不足。对于透传给客户的按 Token 计费层，边界决定了哪些输入计入哪个预算、哪个代理承担成本以及月度账单如何切分。

评估（Eval） 想要一个任务完成的单位。最有参考价值的多轮指标是对话完整性 —— 用户的意图是否得到满足 —— 这需要评估流水线知道哪些轮次属于哪个意图。如果一个用户在早晨计划旅行，午饭时休息了一下，然后回来询问不相关的事情，那么将两者混为一谈的评估流水线会将原本成功的旅行计划交互标记为不完整，因为那个不相关的后续问题从未得到解决。2025 年的研究发现，前沿模型在多轮设置下的性能比单轮设置下降了约 39% —— 如果针对不匹配实际任务的会话边界来衡量这种下降，这个数字将毫无意义。

记忆（Memory） 想要一个相关性的单位。这里的框架是：当用户询问“我们上周讨论的那个项目”时，模型应该回忆起什么 —— 答案取决于记忆的作用域是按会话（用户必须在同一个线程中）、按参与者（跨所有线程的用户）还是按主题（跨参与者和线程的聚类）。这三种选择都是合理的，但每种都需要不同的边界，而强行将这三种需求压缩到每个请求一个 ID 的系统，要么会过度召回（将无关的上下文泄露到 Prompt 中并虚增 Token），要么会召回不足（模型“忘记”了用户期望它知道的信息）。

同一个事件流必须支持所有这三者。陷阱在于假设一个 ID 可以胜任这三项工作。

30 分钟超时是默认值，而非决策

大多数生产环境下的聊天机器人继承了来自聊天平台的会话边界空闲超时 —— 通常是 30 分钟，有时可以配置，但几乎从未被 AI 团队明确选择过。这个默认值来自一个时代，当时“会话”意味着“用户现在就在键盘前”，30 分钟的间隔是他们离开的强烈信号。对于由 LLM 驱动的产品，这个信号不再具有相同的含义。

一个使用 AI 旅行代理规划多日行程的用户，可能会在另一个标签页对比航班时空闲一小时。一个与编程助手进行结对编程的用户，可能会离开去参加一个 90 分钟的会议，然后回来继续同一个任务。一个起草合同的用户可能会将工作分摊到三天。在每种情况下，用户的心理模型都是“我们仍在处理同一件事” —— 而锚定在 30 分钟空闲计数器上的系统心理模型，已经将其拆分为两到三个会话。

第一个症状通常出现在计费上：处理长流程业务的企业客户抱怨说，他们感知的连续操作被收取了“新对话”的费用，或者反之 —— 一个计费周期跨越了他们认为的三个独立交互。第二个症状是评估漂移：任务完成评分器将一个会话判定为不完整，因为用户第二天回来完成了请求，而评分器只看到了被弃用的那一半。第三个症状是记忆溢出：模型在用户认为是重新开始的情况下回忆起（或未能回忆起）细节，而召回机制使用的分组与用户的预期不符。

“开启新对话”按钮救不了你。大多数用户从不按它。那些提供该按钮的平台发现，只有不到 5% 的活跃用户会使用它，且大多是已经理解其控制逻辑的工程师和高级用户。剩下的 95% 只是直接关闭标签页。

用户感知与系统建模之间的差距

在设计解决方案之前，先对这种差距进行埋点。最廉价的诊断方法是建立一个对照表：对于每个事件流，记录系统建模的 session_id（无论平台默认是什么）和用户感知的会话边界（通过意图转变、主题切换或明确的“新对话”操作来推断）。然后计算两者的偏离程度。

你会发现三种模式。第一种，系统合并而用户拆分：平台将用户感知的多个独立任务归类为一个长会话。这在用户进行爆发式聊天且空闲计数器从未触发时很常见。第二种，系统拆分而用户合并：平台将用户感知的一个任务碎片化为多个会话。这在用户离开时间超过空闲窗口时很常见。第三种，漂移：平台的归类在开始时是一致的，但随着对话的演进产生偏离 —— 用户在同一个平台会话中在心理上“启动了三次新主题”，而这些主观的重置在数据中都不可见。

加载中…