传统软件是可预测的：输入A加上函数B总是等于输出C。这种确定性使工程师能够开发稳健的测试。然而，生成式AI是随机的且不可预测——完全相同的提示在周一和周二往往会产生不同的结果，打破了工程师们熟悉和依赖的传统单元测试模式。要交付企业级AI产品，工程师不能仅仅依赖“感觉检查”——今天通过但明天客户使用时就可能失败。产品构建者需要采用一个新的基础设施层：AI评估栈。

确定性断言：第一道防线

令人惊讶的是，大量生产环境中的AI故障并非语义“幻觉”，而是基本的语法和路由故障。确定性断言作为流水线的第一道关卡，使用传统代码和正则表达式来验证结构完整性。

这些断言不询问回答是否“有帮助”，而是提出严格的二元问题：模型是否生成了正确的JSON键/值模式？它是否调用了正确的工具调用并带有必需的参数？它是否成功填充了有效的GUID或电子邮件地址？

在架构上，确定性断言必须作为流水线的第一层，以计算成本低廉的“快速失败”原则运行。如果下游API需要特定模式，格式错误的JSON字符串就是致命错误。通过在此层立即失败评估，工程团队可以防止流水线触发昂贵的语义检查或浪费宝贵的人工审查时间。

基于模型的断言：LLM评审员的力量

当确定性断言通过后，流水线必须评估语义质量。由于自然语言是流动的，传统代码无法轻松断言回答是否“有帮助”或“有同理心”。这就引入了基于模型的评估，通常被称为“LLM-as-a-Judge”。

虽然用一个非确定性系统来评估另一个看似矛盾，但对于需要细微差别的用例来说，这是一种极其强大的架构模式。写一个可靠的正则表达式来验证回答是否“可操作”或“礼貌”几乎是不可能的。人工审查员擅长这种细微差别，但无法扩展到评估数万个CI/CD测试用例。因此，LLM评审员成为人工判断的可扩展代理。

基于模型的断言只有在LLM评审员配备了三个关键输入时才能产生可靠数据：最先进的推理模型、严格的评估标准，以及作为“答案钥匙”的人工验证黄金输出。

离线与在线评估流水线

稳健的评估架构需要两条互补的流水线。在线流水线监控部署后的遥测数据，而离线流水线提供基础基线和确定性约束，以安全地评估随机模型。

离线流水线的主要目标是回归测试——在投入生产之前识别故障、漂移和延迟。在没有门控离线评估套件的情况下部署企业级LLM功能是一种架构反模式，相当于将未编译的代码合并到主分支。

离线生命周期始于策划“黄金数据集”——一个包含200到500个测试用例的静态、版本控制仓库，代表AI的完整操作范围。每个用例将精确的输入负载与预期的“黄金输出”配对。关键在于，这个数据集必须反映预期的真实流量分布。虽然大多数用例覆盖标准的“正常路径”交互，但工程师必须系统性地包含边缘情况、越狱尝试和对抗性输入。

在线评估：部署后的守护者

在线流水线是部署后的遥测系统，其目标是监控真实世界行为，捕获离线流水线无法预测的漂移和异常。在在线环境中，延迟和成本约束通常排除了对每个请求运行完整的LLM评审员评估。取而代之的是，团队实施采样策略——随机选择一定百分比的生产请求进行深度评估，同时对其余请求运行轻量级确定性检查。

对于企业级应用，基线通过率通常必须超过95%，对于严格合规或高风险领域则需达到99%以上。任何系统修改都需要完整的回归测试。由于LLM本质上是非确定性的，旨在修复特定边缘情况的更新很容易在其他方面造成意想不到的退化。

建立AI评估栈不仅仅是技术投资，更是组织能力的建设。从确定性检查的快速反馈循环到语义评估的细微判断，再到在线监控的持续守护，每一层都为AI系统的可靠性和可信度贡献着不可替代的价值。