多会话评估设计：捕捉随时间推移而恶化的 AI 功能

你的 AI 功能在上线时通过了所有评估。六周后，与其交流最频繁的用户群体的流失率翻了一倍，而你的 CSAT 仪表板却显示出一条无人能解释的平线。提示词（Prompts）没有变，模型没有更换，检索索引增长了，但没人觉得它坏了。上线时的表现第一轮（turn one）很好。真正变质的是在第 400 轮、第 17 次会话、注册三周后发生的事情。

大多数团队的评估套件无法察觉到这种失败。他们测试的是固定数据集上的单轮准确性，如果有追求的话，可能会测试单次会话中的多轮对话，然后就宣布该功能可以上线。真正重要的失败模式——即随着系统积累用户状态而质量下降——存在于评估工具从未设计去覆盖的时间维度中。在记忆研究文献中，研究人员称之为“自我退化”（self-degradation）：在初始阶段之后，受记忆膨胀（memory inflation）和错误记忆累积的驱动，性能出现明显且持续的下降。生产工程师则将其称为留存用户群无声流失的原因。

本文将探讨为了在用户流失前捕捉到这类失败，多会话评估（multi-session eval）究竟需要是什么样子的。简而言之：你需要跨越多次会话的合成用户旅程、质量衰减曲线（而非单一分数的仪表板），以及一种比较随时间演变的分布、而非在冻结数据集上的点准确性的回归方法论。

为什么单次会话评估会系统性地遗漏这一点

默认的评估技术栈——固定提示词、固定输入、判定模型评分——是为可复现性而优化的。每次评估运行都从一个干净的上下文窗口开始，运行一轮或一段简短的对话，然后输出一个数字。这种设计对于比较模型版本至关重要，但它包含了一个对于任何带有记忆（memory）的功能来说都会失效的假设：质量在时间上是静态的。

事实并非如此。积累用户状态的 AI 功能有三个静态评估无法看到的动态部分：

• 记忆存储会发生变化。 每次会话都会增加、更新或衰减事实。到第 30 次会话时，为查询检索到的上下文与第 1 次会话评估时看到的几乎没有任何共同之处。
• 用户在变。 显式偏好变为隐式偏好，修正模式不断积累，用户会根据模型之前的理解来调整自己的措辞。
• 模型的有效上下文在变。 同样的基础模型，在喂入累积的历史记录后，表现会有所不同——通常会变差，正如“迷失在中间”（lost in the middle）的实验结果及其后续研究所示，性能会随着上下文的填满而下降。

像 LoCoMo 和 LongMemEval 这样的基准测试的建立，部分是为了揭示这些问题。LongMemEval 报告称，长上下文 LLM 在多会话召回方面的表现下降了 30–60%，即使是顶尖的商业记忆系统在简化版的基准测试中也仅获得 30–70% 的分数。这些数字来自受控的学术环境——生产环境中的状态更加混乱。如果你的评估套件没有时间轴，你就是在将产品推向衰退，并盯着一个平坦的仪表板。

失败也不仅仅是“检索变差”。它是行为上的。个性化发生偏移，拒绝率（abstention rates）下降（模型不再说“我不知道”，因为记忆中现在有一块看起来相关的、事实形状的模糊块），以及之前的修正在后来的记忆覆盖它们时被默默撤销。这些都不会体现在单轮的 BLEU 分数中。

时间维度评估工具是什么样的

多会话评估工具会重放模拟用户在多次会话中的旅程，并衡量系统的行为在这一旅程中是如何演变的。它包含三个标准评估工具所不具备的组件。

基于人格（Persona）的会话生成。 你不再使用一次性提示词，而是定义一个用户：背景、目标、约束，以及在模拟的数周内展开的时间轴。这就是 LoCoMo 构建其基准测试的方式——基于人格和时间事件图的 LLM 智能体，生成跨越 35 次会话、平均 300 轮的对话。对于产品评估，你不需要 35 次会话；你需要足够多的会话来跨越记忆膨胀开始产生负面影响的阈值，对于大多数助手类功能，这通常在 8 到 20 次会话之间。

运行用户侧的模拟器。 第二个 LLM 扮演用户，遵循其人格和目标，并对系统的回应做出反应。这里的真正挑战在于使模拟器具有真实性——它不是一个回答每个澄清问题的合作型神谕，而是一个有时会忘记告诉你什么、以矛盾的方式重新表述偏好、并测试 LongMemEval 明确探测的“知识更新”行为的用户。Confident AI、Langfuse、DeepEval 以及大多数主要的评估框架都在 2025–2026 年推出了多轮模拟器；基础设施已经不再是难点。

检查点，而不仅仅是最终分数。 评估工具必须在旅程的多个节点对系统的行为进行评分，而不仅仅是在最后。你希望在类似的任务上衡量第 1 轮的质量、第 5 次会话的质量、第 15 次会话的质量。这就是将通过/失败的评估转变为衰减曲线的方法。

有一个诱人的捷径值得一提并予以拒绝。重放真实的生产对话来对新提示词评分听起来很吸引人，但它有一个根本性的缺陷：日志中的对话轨迹是由旧系统产生的，而非新系统。如果没有模拟器，你无法针对修改后的模型重放多轮用户的交互，因为用户的下一条消息取决于系统在前一轮中说了什么。日志重放适用于单轮黄金追踪（golden traces）（即 Google/ADK 重放记录的工具输入和输出的模式）；它不适用于模拟反事实的多会话旅程。应将日志视为测试固件（fixture）的来源，而非模拟的替代品。

质量衰减曲线而非单一评分

多会话评估的核心输出是一个曲线，而不是一个数字。在 X 轴上：会话索引、轮次计数或累积记忆大小。在 Y 轴上：对任务至关重要的任何质量指标 —— 答案正确性、个性化拟合度、拒答正确率、矛盾率。曲线的形状即是诊断。

一个健康功能的曲线大致是平坦或上升的 —— 系统随着对你的了解而变得更好。具有记忆膨胀（memory inflation）特征的功能会显示出特征性的 “自我退化” 轮廓：在前几个会话中达到平台期或峰值，然后持续下降。具有灾难性遗忘（catastrophic forgetting）的功能在某些特定内容被替换时会掉落 —— 通常在知识更新轮次后表现为断崖式下跌。对记忆投毒（memory poisoning）敏感的功能显示出不同群体之间的差异：如果模拟旅程中包含恶意或模糊输入，其曲线会偏离对照组且永远无法恢复。

你在该曲线上跟踪的具体指标应包括：

• 锚点问题的任务准确率。 预先编写那些正确答案取决于早期会话中确立的事实的问题。在随后的多个检查点对它们进行评分。这是你对长程记忆保留的直接衡量。
• 拒答正确率。 系统正确拒绝回答与产生幻觉的比例，分别针对记忆中存在答案与确实不存在答案的问题进行评分。拒答是最高信任度的行为，也是最先被侵蚀的行为。
• 矛盾率。 响应中与系统在早期会话中对同一用户所说内容相矛盾的比例。这是自动化评分成本最低的失败模式（两个模型生成的陈述，一次裁判调用），并且它与用户反馈的 “AI 老是忘事” 投诉强相关。
• 个性化提升率。 RealPref 基准测试的 IR 指标 —— 一个衡量与既定偏好的对齐度是否随对话推进而改善的回归系数。多会话中平坦或下降的 IR 是一个直接的红旗信号。

这些指标不是为了综合优化的计分卡。它们是诊断工具。平坦的任务准确率曲线伴随剧增的矛盾率，告诉你检索仍在工作，但记忆库产生了冲突条目。下降的准确率曲线伴随平坦的矛盾率，告诉你记忆正在流失，而不是被污染。曲线形状让你能够定位问题。

跨版本的回归检测

一旦有了衰减曲线，回归问题就变成了：这次提示词更改或模型更换是否让曲线变差了？这比比较两个数字要难，因为曲线可能有噪声且评估成本很高。在实践中，以下几种模式是行之有效的。

固定画像集和模拟器种子。 在不同版本中使用同一组模拟用户，并使用确定的模拟器响应（固定 Temperature，尽可能记录第一人称话语）。这消除了运行间差异的最大来源。如果没有这一点，同一系统的两次运行将产生不同的曲线，你会徒劳地追逐幻影。

比较分布，而非点。 对于每个检查点（第 5、15 次会话等），你的评估会产生画像集上的评分分布。使用非参数检验比较版本间的分布 —— 例如双样本 Kolmogorov-Smirnov 检验或均值的自助法（bootstrap）置信区间。均值下降 0.03 且方差很大可能是噪声；而所有画像的分布整体左移则是回归。

以最差检查点为门禁，而非平均值。 多会话评估捕捉到的最常见失败模式是：良好的平均分掩盖了糟糕的后期会话尾部。如果第 1 次会话提升了 5%，而第 15 次会话下降了 10%，你的总量看起来没变，但你却发布了一个回归。为每个检查点设置阈值，如果任何检查点退化超过其阈值，则判定发布失败。

按计划运行，而不只是合并前运行。 多会话评估很慢（数十个会话 × 多个画像 × 多个检查点 × 裁判调用）且昂贵。在每个 PR 上运行全套评估很少能负担得起。大多数团队最终采用两层设置：快速的单会话烟雾测试（smoke eval）拦截合并，而全套多会话衰减测试在 main 分支上每晚或每周运行，回归问题的处理方式就像处理不稳定的集成测试一样，而不是作为提交阻断器。成本模型需要接受这种评估是对未来流失率的资本支出，而不是你在每次更改时运行的 CI 门禁。

将合成画像与编写评估的 LLM 画像训练分开。 如果同一个模型生成画像、驱动模拟器并评判输出，你会得到 “裁判-模型合谋”（judge-model collusion）。最简单的缓解措施是为画像生成、用户模拟器和裁判使用不同的模型家族 —— 即使产品模型是第四个系统。这与不让编译器用自己的输出测试自己的原则是一样的，只是应用到了评估中。

这能捕捉到其他方法无法捕捉的问题

多会话评估套件的价值在于它能捕获一类其他测试无法发现的特定 Bug：只有在状态累积后才会出现的回归。以下是该领域中它能揭示的一些典型案例：

• 内存压缩算法的变更导致摘要过于激进，以至于到第 20 个会话时，系统已经丢失了用户的原始偏好，反应得像是在第 1 个会话一样。
• 检索阈值的微调提高了公共基准测试的召回率，但当用户的记忆存储超过几百条记录后，开始检索出矛盾的内容，导致出现“助手不断自我纠正”的故障。
• 安全层的变更使模型更倾向于给出确定的回答，这在“拒绝回答”基准测试中表现良好，但在“矛盾率”曲线上却是灾难性的，因为之前每个“我不知道”的回答现在都变成了有状态的断言。
• 人设调整提高了初次印象的客户满意度（CSAT），但侵蚀了随时间推移的个性化体验——用户更喜欢第一轮对话，但在第五十轮之前就离开了。

单轮评估无法捕获其中的任何一项。所有这些问题都与那种延迟的流失率相关，而产品团队往往在几个月后将其归咎于“市场契合度”或“新手引导”问题。多会话评估为你提供了这种因果链条。

从哪里开始

从零开始构建这套测试框架是一个需要数周的项目。你不需要在第一天就完成它。最小可行的时间维度评估（Minimum Viable Temporal Eval）是：5 个合成人格（synthetic personas），每个角色进行 8 个会话，分别对第 1、4、8 个会话的锚点问题进行评分，并在第 8 个会话与之前的对话记录之间进行矛盾率检查。在任何成熟的评估框架基础上，这只需要一个周末的工作量，它会在一周内告诉你，你的功能是否存在值得关注的衰减问题。

如果曲线是平缓的，说明你已经排除了一类故障，并赢得了自信发布的权利。如果曲线发生偏转，你现在就有了一个可重现的信号，可以用来衡量每一个提示词（prompt）、检索和记忆的变更。那些在没有此类测试的情况下持续发布 AI 功能的团队，在六个月后还在调试流失数据，试图重构是哪个版本搞坏了什么。而拥有它的团队则能在受影响的用户群体完成第二周体验之前，就捕获这些回归。

多会话质量最终就是产品本身。构建一个能观察到它的评估体系吧。