为什么AI应用需要持续评估

摘要

在本系列的前两篇文章中，我们分别讨论了为什么AI应用需要新的质量保障体系（RP-AQE-001），以及AI质量工程与传统软件测试的本质区别（RP-AQE-002）。其中一个关键判断是：AI应用的质量生命周期从"测试-发布"的门禁模式，走向了"持续评估-持续优化"的循环模式。

本文聚焦于这一转变中最核心的概念——持续评估（Continuous Evaluation）。我们将回答一个看似简单但实际被普遍误解的问题：持续评估到底在评估什么？它和自动化回归测试有什么不同？为什么企业需要一个专门的持续评估体系，而不是在现有CI/CD流程中增加几个测试用例？

核心观点是：持续评估不是重复测试。持续评估是持续验证AI应用是否仍然满足质量目标。

一、软件测试为什么可以结束

要理解持续评估的必要性，首先需要理解为什么传统软件测试可以有一个明确的终点。

1.1 测试完成的判断标准

在传统软件工程中，测试活动有清晰的完成条件。这些条件可能包括：

• 所有测试用例通过，覆盖率达到预定阈值
• 缺陷发现率下降到可接受水平
• 风险评估确认剩余风险在可容忍范围内
• 利益相关方签字确认质量验收标准已满足

无论采用哪种标准，核心逻辑是相同的：在某个时刻，团队可以做出"质量已达到发布标准"的判断，并据此结束测试活动。

1.2 为什么这个判断是可靠的

这一判断之所以可靠，建立在软件行为的确定性前提之上。

传统软件的业务逻辑由代码显式定义。一旦代码被冻结并部署，在同一运行环境下，系统的行为是固定的。测试阶段验证了"这组代码在这组条件下产生了这组预期结果"——只要代码不变、环境不变、输入范围不变，这一验证结论就持续有效。

上线后的运维关注的是异常：服务是否宕机、响应时间是否异常升高、错误率是否突增。这些都是可观测的运行态指标，而非功能正确性的持续验证。没有人会在每次部署后重新运行全部功能测试，因为代码没有变化，行为就没有变化。

1.3 "测试可以结束"的工程价值

"测试可以结束"这一特性对软件工程具有重要价值。它意味着：

• 质量保障的成本可以被清晰界定和预算
• 发布决策可以基于明确的通过/不通过标准
• 团队可以将注意力从已完成的质量验证转移到新功能的开发

这不是软件测试的局限，而是它的工程优势。确定性带来了可预测性，可预测性带来了可控的成本和可管理的风险。

二、AI应用为什么不会停止变化

当我们将上述分析应用于AI应用时，一个根本性的差异浮现出来：AI应用的行为在上线后并不会保持静止。

2.1 变化的来源并非代码

需要澄清一个关键点：这里所说的"变化"，指的并不是应用代码的变更。传统软件在代码不变时行为不变——这一规律在AI应用中仍然成立，但它只覆盖了AI应用行为决定因素的一部分。

AI应用的行为由以下层次共同决定：

  应用代码（确定性逻辑）
       ↓
  Prompt模板（语义指令）
       ↓
  模型推理（概率计算）
       ↓
  外部知识/工具（环境数据）

即使应用代码和Prompt模板完全不变，模型推理层和外部知识层也会发生变化——而这些变化足以改变应用的最终行为。以下逐一分析。

2.2 模型层的持续变化

大模型不是静态的。模型提供商会持续更新模型版本，这些更新可能改变模型的能力分布：

• 能力提升：新版本在某些任务上表现更好，但也可能在另一些任务上出现退化
• 行为偏移：对同一Prompt的响应风格、详略程度、格式偏好可能发生变化
• 知识更新：训练数据的时间窗口变化可能导致模型对事实的判断不同

关键是，这些变化通常不是模型提供商公告中列出的。公告可能说"推理能力提升20%"，但它不会告诉你"对特定格式的JSON输出的遵循度下降了3%"。而这个3%的下降，可能恰好导致你的应用在生产环境中出现格式解析失败。

2.3 知识层的持续变化

对于依赖外部知识库的AI应用（如RAG系统），知识内容的变化是常态而非例外：

• 文档更新、新增或废弃
• 知识库结构调整
• 检索索引重建导致召回结果变化

一个在上线前验证过的问答对——"用户问A，系统检索文档B，模型生成回答C"——在知识库更新后可能变为"用户问A，系统检索文档D，模型生成回答E"。这个新的回答E从未被评估过，它的质量是未知的。

2.4 环境层的持续变化

AI应用运行在一个动态的信息环境中：

• 用户提问的方式和领域可能随时间演变
• 新的对抗性输入模式可能出现
• 真实世界的事实发生变化（如政策、产品信息），而模型训练数据未覆盖

这些变化不会触发任何告警——系统运行状态完全正常，CPU使用率平稳，错误率为零——但输出质量可能在静默中下降。

2.5 变化不是因为"出bug了"

有必要反复强调一个关键区分：

AI应用的质量变化，往往不是因为系统出了故障，而是因为系统正常运行但其行为分布发生了漂移。

传统软件的行为异常通常意味着某个组件出了问题——代码bug、硬件故障、网络中断。而AI应用的行为变化，可能是模型版本更新这一正常运维操作的结果，可能是知识库更新这一预期行为的结果。

这意味着，你不能用"监控异常"的方式来发现AI应用的质量下降。你需要的是在系统正常运行的表象之下，持续验证输出质量的机制。

三、哪些变化会导致质量下降

上述变化来源在什么情况下会实际导致质量下降？理解这些机制，才能有针对性地设计持续评估策略。

3.1 模型更新的不可预期影响

模型版本更新是最典型的触发因素。问题不在于模型会变差——大多数情况下新版本整体能力确实更强——而在于变化的分布是不均匀的。

具体而言，模型更新可能导致：

这些变化不是整体性的——你不能通过几个测试用例的通过/失败来判断模型更新是否"安全"。你需要的是覆盖关键任务类型的、具有统计意义的评估。

3.2 知识库演化的覆盖盲区

知识库更新引入的风险更加隐蔽。新增的文档可能质量参差不齐——内容准确但格式不规范、信息完整但时效标注错误——而系统在检索到这些文档时，模型生成的结果质量就会受到影响。

此外，知识库的结构性变化——如分块策略调整、嵌入模型切换——可能导致检索结果的系统偏移。原本排名第一的文档降到第三，而新的第一名文档与问题的相关性有细微差异。这种差异未必导致"错误回答"，但可能导致"不够好的回答"——而这种退化在缺少持续评估的情况下几乎不可能被发现。

3.3 Prompt退化的累积效应

Prompt退化是一个被讨论较少但实际存在的问题。长时间运行的Prompt模板可能因为以下原因逐渐偏离设计意图：

• 为修复某个边界问题而添加的指令，意外影响了正常场景的表现
• 累积的上下文示例逐渐过时，与当前知识库不匹配
• 多人协作维护Prompt时，不同维护者的修改意图叠加导致不可预期的交互

每次Prompt修改的初衷都是好的——修复一个问题、优化一个表现——但在缺少持续评估的情况下，无法验证修改是否在所有场景下都达到了预期效果。

3.4 用户行为分布的变化

AI应用上线后，用户实际使用的方式可能与开发阶段的预期不同：

• 用户发现了一些开发团队未曾考虑的使用场景
• 用户提问的措辞习惯与评估数据集中的表述方式不同
• 随着时间推移，用户开始提出新的问题类型

这些变化意味着：上线前构建的评估数据集，可能逐渐与生产环境的实际分布产生偏差。如果不持续更新评估数据和评估维度，评估体系的有效性会随时间衰减。

四、持续评估到底评估什么

经过以上分析，问题自然转向：面对这些动态变化，持续评估具体在评估什么？

4.1 持续评估的核心定义

持续评估是一个持续运行的质量验证过程，其目标是回答一个基本问题：

我的AI应用现在——在此刻——是否仍然满足既定的质量目标？

这个定义有几个关键要素：

"现在"意味着实时性。 不是上次测试时，不是模型刚上线时，而是当前生产环境中正在运行的系统。

"质量目标"意味着有标准可对照。 持续评估的前提是已经建立了质量目标和评估指标——这些指标的选取和设计本身就是AI质量工程的重要工作。

"仍然"意味着对比。 持续评估隐含了一个基线——上线前验证通过时的质量水平——后续的每次评估都在与这个基线（或上一次评估结果）进行对比。

4.2 持续评估评估的是"质量变化"而非"功能正确性"

这可能是持续评估与传统测试最根本的差异。

传统回归测试验证的是：改动后的代码是否仍然通过原有的测试用例？ 这是一个基于断言的、结果是二元的验证过程。

持续评估关心的则是：系统的质量指标是否发生了需要关注的偏移？ 这不是一个通过/不通过的二元判断，而是一个基于统计比较的趋势分析。

具体来说，持续评估关注以下几个维度的变化：

4.3 持续评估不是自动化测试的简单复制

一个常见的误解是将持续评估理解为"把测试用例设置成定时运行"。这种理解忽略了持续评估的核心特征：

第一，评估依据是统计分布而非离散结果。 单次评估中某个测试用例失败，不代表质量下降——可能是概率性的正常波动。持续评估需要积累足够样本后进行统计判断，而非基于单个断言做决策。

第二，评估数据集需要持续演进。 静态的测试数据集会随生产环境变化而失效。持续评估包含对评估数据本身的健康度检查——评估覆盖度是否仍然足够、是否需要补充新的场景类型。

第三，评估结果触发的是分析而非修复。 传统测试失败触发的是代码修复流程。持续评估检测到质量偏移时，触发的首先是分析——是模型问题还是知识库问题？是Prompt退化还是用户行为变化？然后才是针对性的干预。

五、持续评估与自动化回归有什么区别

这是一个值得专门展开讨论的问题，因为将二者混淆会导致工程实践上的方向性错误。

5.1 五个维度的对比

5.2 为什么不能用CI/CD中的回归测试替代持续评估

在CI/CD流程中增加AI测试用例（如"部署前运行50个Prompt测试用例"），能够解决一部分问题——它可以验证"这次部署不会明显破坏基本功能"。但它无法解决以下问题：

无法检测静默退化。 如果模型提供商的API在两次部署之间发生了行为变化（这在SaaS化的模型服务中是常态），CI/CD流程不会触发——因为没有新的部署——但应用质量可能已经在生产环境中下降了。

无法处理非代码触发的质量变化。 知识库更新、用户行为变化、真实世界事实变化——这些都不伴随代码提交，因此不会触发CI/CD流程中的测试。

无法提供趋势分析。 单次评估的通过/失败无法揭示质量指标的时间趋势。准确率从95%缓慢下降到90%——每次单独看都"还可以接受"，只有持续追踪才能发现问题正在累积。

5.3 二者的关系：互补而非替代

自动化回归测试和持续评估不是二选一的关系，而是不同层次的质量保障手段：

  发布门禁                          持续保障
  ┌──────────┐                    ┌──────────────┐
  │ CI/CD    │                    │ 持续评估      │
  │ 回归测试  │ ←── 部署 ───→     │ 质量监测      │
  │          │                    │              │
  │ 验证：    │                    │ 验证：        │
  │ 这次变更  │                    │ 现在仍然      │
  │ 没有破坏  │                    │ 满足质量      │
  │ 已有功能  │                    │ 目标吗？      │
  └──────────┘                    └──────────────┘

自动化回归测试保障的是"变更安全"——每次变更后系统的基本功能仍然可用。持续评估保障的是"运行时质量"——系统在持续运行过程中，其输出质量是否仍然符合预期。二者共同构成了AI应用的质量保障闭环。但在当前行业实践中，绝大多数团队只做到了前者，而缺少后者。

六、企业为什么需要持续评估体系

6.1 持续评估不是一个功能，而是一项能力

将以上讨论落实到企业实践中，一个关键认知是：持续评估不是一个可以一次性配置然后遗忘的功能，而是需要持续投入和维护的工程能力。

它与传统测试自动化的关系，类似于监控系统与一次性日志检查的关系。你可以手动查看一次日志来排查问题，但只有建立了系统化的监控体系，才能在问题出现时第一时间发现和响应。同样地，你可以在上线前做一次全面评估，但只有建立了持续评估体系，才能在质量偏移发生的早期识别并干预。

6.2 没有持续评估的企业面临什么风险

缺少持续评估体系的AI应用，实际上处于一种"质量盲飞"状态：

这些风险的共同特征是：它们不会触发任何告警，但会持续侵蚀AI应用的业务价值。 等到问题最终以用户投诉的形式浮出水面时，损伤已经发生。

6.3 持续评估体系的关键要素

建立一个有效的持续评估体系，至少包含以下要素：

第一，质量基线的建立。 在上线前，需要完成一次全面的质量评估，建立起质量指标的基线值。这个基线是后续所有持续评估的参照系。没有基线的持续评估，像是在没有零点标记的刻度尺上读数——你看到了变化，但不知道这个变化意味着什么。

第二，评估数据集的持续管理。 评估数据集不是一成不变的。需要定期分析生产日志，补充新的场景类型，淘汰已不再出现的过时场景，确保评估集与生产分布保持一致。评估数据集本身的质量管理，是持续评估体系的元问题。

第三，质量偏移的检测与响应机制。 当持续评估检测到质量指标出现统计显著的偏移时，需要有一套预定义的响应流程：确认偏移的真实性 → 分析偏移的来源（模型/知识库/Prompt/外部因素）→ 判断是否需要干预 → 执行针对性优化 → 重新评估确认恢复。

第四，评估结果的可视化与可追溯。 质量指标的历史趋势应该对所有相关方可见——不是某一时刻的"通过/失败"状态，而是质量指标随时间的变化轨迹。这种可视化不仅用于问题发现，也用于建立团队对AI应用质量的共同认知。

6.4 从"做AI测试"到"建立AI质量能力"

对于落地AI应用的企业，建议从以下视角理解持续评估的定位：

持续评估不是AI项目中的一项任务，而是AI质量工程能力的基础设施。

正如持续集成（CI）改变了软件开发的协作方式，持续评估（CE）将改变AI应用的质量管理方式。它不是解决某一个问题，而是提供了一个持续发现问题的机制——而这个机制的存在本身，就是质量保障能力成熟的标志。

七、九维创智观点

7.1 行业判断

当前行业对AI应用质量的关注正在从"上线前测试"向"运行时质量保障"延伸。但大多数讨论仍停留在工具层面——"用哪个平台评估模型""用什么指标衡量回答质量"——而较少关注持续评估的工程体系建设。

我们观察到几个值得注意的趋势：

• 评估活动正在从一次性事件转变为持续性过程。 越来越多的团队意识到，AI应用的质量保障不能以上线为终点。但如何将这一认知转化为工程实践，仍缺少成熟的方法论指导。
• 评估数据管理正在成为一个独立的质量问题。 静态评估数据集的生命周期管理——版本控制、覆盖度检查、场景更新——开始受到重视，这与传统软件测试用例管理的理念一脉相承但更加复杂。
• 质量指标的可视化需求日益突出。 企业需要看到的不是"测试通过率"，而是质量指标的时间序列趋势。这要求持续评估体系天然具备数据积累和分析能力。

7.2 九维创智的实践方向

九维创智技术团队在软件质量工程和AI应用实践方面有持续积累。在持续评估方向，我们关注的不是某一个具体工具，而是以下几个方面：

第一，持续评估的方法论框架。 将持续评估从概念转化为可操作的工程实践——包括质量基线的建立方法、评估频率的确定原则、质量偏移的判定标准、评估数据的管理策略。这些方法论层面的问题，比工具选型更根本。

第二，评估体系的工程化设计。 持续评估不是"定时运行一组脚本"，而是一个需要工程化设计的系统——评估任务的调度与编排、评估结果的存储与查询、质量指标的计算与可视化、偏移告警的触发与升级。这些工程要素的设计质量，直接决定了持续评估体系的可用性。

第三，团队质量能力的建设。 帮助企业技术团队建立对AI应用质量的系统性认知——不仅会使用评估工具，更理解持续评估的工程逻辑，能够在日常工作中维护和改进评估体系。这种能力不是一次培训可以建立的，需要在实践中持续积累。

八、结语

本文的核心观点可以总结为以下几条：

第一，AI应用的质量不是静态的。 模型更新、知识库演化、用户行为变化、Prompt退化——这些因素使得AI应用的质量在上线后持续变化，而变化的方向不总是向好。

第二，持续评估不是重复测试。 它不是在CI/CD中增加几个AI测试用例，而是一个独立的质量保障层次——关注的是质量随时间的变化趋势，而非单次发布的通过/失败。

第三，持续评估与自动化回归测试是互补关系。 前者保障"变更安全"，后者保障"运行时质量"。二者缺一不可，但后者在当前行业实践中普遍缺失。

第四，持续评估是一项需要系统建设的工程能力。 它不是一次性配置，而是需要持续投入的基础设施——包括质量基线的建立、评估数据的管理、偏移检测与响应机制的设计。

回到本文标题所提出的问题——为什么AI应用需要持续评估？

答案不是因为AI应用比传统软件"更难测"，也不是因为需要"更多自动化"。而是因为：在AI应用的质量会持续变化这个事实面前，任何一次性的质量验证都无法提供持久的质量保障。 持续评估是直面这一事实的唯一工程手段。

当软件行为的确定性被概率性取代时，质量保障的时间维度也被根本性地改变了。测试可以结束，但评估不能停止。