## 01、痛点

我是老李。我们团队去年把一个知识助手接进了 Spring Boot 服务，上线前用 REST Assured 写了一圈测试，断言状态码 200、响应体非空、字段存在，测试全绿。然后上线第二周，用户开始投诉：问“年假怎么算”，它把别的制度编进来了；问“报销发票要求”，它回答得一本正经，但引用条款根本不存在。

这不是个例。生成式 AI 被包成普通 REST 接口后，最常见的误解就是：只要服务返回 200，链路就是通的，功能就是好的。但在生成式场景里，200 只代表模型成功吐出了字符串，不代表这个字符串正确、有依据、相关、没有幻觉。同一个问题问两遍，模型可能给两个不同答案；同一个答案，不同用户看到的问题也完全不同。传统接口测试的确定性假设被打碎了。

为什么现在要讲这件事？因为越来越多团队开始把大模型能力接进业务系统，但质量保障还停留在“上线前人工点一点、上线后看工单”的阶段。Spring AI 官方已经给出了 Evaluation Testing 能力，明确支持使用另一个模型作为评估器。这意味着生成式应用的质量验证，有机会从一次性抽检变成可重复运行的工程闭环。关键是，我们要理解它解决什么、不解决什么，以及为什么不能把另一个模型的判断当成唯一质量标准。

## 02、是什么

Spring AI Evaluation Testing 并不是一个新的测试框架，而是一套面向生成式输出的评估能力。它把“测试一个接口是否正常”扩展成“测试一个生成结果是否合格”。普通 REST 测试看的是协议层结果：状态码、响应头、耗时、JSON 结构。评估测试看的是语义层结果：答案是否正确、是否基于给定上下文、是否与问题相关、是否编造了不存在的事实。

在具体实现上，Spring AI 支持两类评估器。第一类是确定性规则，比如检查输出是否为空、是否包含某些必要字段、长度是否在范围内、是否命中了某个正则。第二类是模型评估器，也就是 LLM-as-Judge。你可以把被测应用生成的回答、参考上下文、标准答案一起交给另一个模型，由它按照你设定的维度打分。比如：正确性 1-5 分，事实一致性 1-5 分，相关性 1-5 分，并输出简短理由。

这里必须澄清一个概念：不是所有测试都能模型化。确定性测试和语义评估要分开。确定性测试负责守住底线，例如接口必须返回 JSON、字段不能缺失、引用编号必须存在；语义评估负责回答“这答案像不像人话、对不对”。如果一个系统只做模型评估，很容易被模型的随机性带偏；如果只做确定性测试，又完全无法覆盖生成质量。两者的关系不是替代，而是组合。

可以用一张表简单对比：

| 维度 | 传统 REST 测试 | Spring AI 评估测试 |
|---|---|---|
| 关注点 | 协议、结构、状态码 | 正确性、事实性、相关性、幻觉 |
| 判定方式 | 断言明确 | 规则 + 模型打分 |
| 稳定性 | 高 | 中，需校准 |
| 适用场景 | 所有接口 | 生成式接口、RAG 应用 |

这个概念不复杂，但落地时最容易犯的错，是把模型评估器当成“万能判官”。下一节我们来说为什么需要完整闭环。

## 03、为什么

生成式输出是非确定的，这使得传统测试的“一次性通过”失去意义。你不能只在发布前一天跑一次测试，因为模型、提示词、切分策略、检索器、嵌入模型任何一个环节变了，输出分布都可能改变。真正可靠的保障，必须是一个可以重复运行的评估系统。

这个话题给出的理论是：建立 Dataset → Generate → Evaluate → Error Analysis → Regression 的闭环。Dataset 是评估数据集，Generate 是运行被测应用拿到输出，Evaluate 是规则和模型共同打分，Error Analysis 是分析错误模式，Regression 是每次变更后重新跑基线。这个闭环的价值不在于某一次跑分有多高，而在于你能持续发现质量回落。

为什么需要这个闭环？因为生成式应用的失败常常不是崩溃，而是“悄悄变差”。换了一个嵌入模型，检索的文档片段从 5 条变成 4 条，整体回答似乎没问题，但某些边界问题的命中率下降；换了一个切分策略，长文档被切碎，导致“跨段落理解”类问题开始出错。这些变化不会被 HTTP 监控发现，只能通过结构化评估暴露。

LLM-as-Judge 在这个过程中扮演重要角色，但它不能成为唯一质量标准。原因至少有四点：第一，评判模型本身有知识盲区，可能把错误答案判为正确；第二，评判结果受评判指令影响很大，同一个答案换一种问法分数可能波动；第三，评判模型对流畅、自信的错误回答容易给高分，因为它分不清“表达好”和“事实对”；第四，模型评估有成本和延迟，无法在每次请求时实时全量执行。因此，评估系统必须采用混合策略：规则兜底、模型评分、人工抽检校准。

## 04、架构

一个可持续运行的 Eval System，至少包含五层。

第一层是数据集层。它存储 Golden Questions，也就是经过筛选和标注的高价值问题。每条数据包含问题文本、期望答案或参考片段、元数据（比如问题类型、难度、涉及文档）。知识助手通常准备 50 到 100 条 Golden Questions 起步，覆盖高频咨询、边界条件、歧义问法和已知易错点。数据集的标注质量直接决定评估结果可信度，所以这一层要有版本管理，记录每条数据是谁、什么时候、基于什么依据标注的。

第二层是生成层。它把数据集中的问题逐条送给被测应用，拿到真实输出。这里要注意版本管理：每次运行都要记录被测应用的版本号、模型名称、提示词版本、切分策略版本和检索器版本，否则出了错也不知道是哪个变量引起的。生成层还要保证运行环境一致，温度、随机种子等参数都要固定，避免噪声影响判断。

第三层是评估层。它由三类评估器组成：确定性规则、语义评估模型、人工抽检。确定性规则跑得快，负责检查格式、引用、长度；语义评估模型负责对答案质量打分；人工抽检从数据集中随机抽样，用来校准语义评估器的判断。三种方式侧重点不同，但输出格式要统一，比如都输出通过/失败、分数、失败原因，方便汇总。

第四层是错误分析层。它把评估结果按问题类型聚类，输出错误分布。比如“幻觉类错误占比 12%”“检索不相关占比 8%”“答案不完整占比 5%”。错误分析的价值在于指导下一步优化方向，而不是只盯着总分。没有错误分析，评估报告就只是一堆分数，团队无法知道该改哪里。

第五层是回归层。它定义触发条件：每次更换模型、修改提示词、调整切分策略、更换检索器或嵌入模型，都必须重新跑评估。回归结果和基线对比，低于阈值则阻止发布。回归层还要保留历史记录，方便追踪质量曲线。

这五层不一定要用微服务实现，小型团队可以在一个模块里完成。关键是分层清晰，数据可追溯，结果可复现。

## 05、实战

假设我们有一个 Spring Boot 知识助手，背后用向量数据库做检索，再调用大模型生成答案。现在要搭建评估闭环，可以分四步走。

第一步，准备 Golden Questions。不要坐在会议室里拍脑袋，要从真实来源提取：用户咨询记录、客服工单、内部 FAQ、文档库中的高频章节。每个问题至少标注一个参考答案或关键事实点。50 到 100 条是合理起步量，太少没有统计意义，太多维护成本过高。可以按类型打标签：政策类、流程类、边界类、多步推理类。标注时不要只写“标准答案是什么”，还要写“哪些事实必须出现”“哪些事实绝对不能出现”。这样后续模型评估才有明确依据。

第二步，拆开评估 Retrieval 和 Answer。很多团队只评估最终答案，忽略了检索环节。RAG 场景下，检索错误会直接导致答案错误，即使生成模型本身没有问题。因此要分别设计指标。

Retrieval 评估关注：检索到的文档是否包含答案依据？相关文档排在第几位？是否混入无关文档？常用指标有 Recall@k、MRR、Context Precision。例如，对每条 Golden Question，我们预先标注了正确文档列表，然后看检索器返回的前 5 条文档命中了多少。如果命中率下降，问题一定出在切分策略、嵌入模型或检索器上。

Answer 评估关注：答案是否正确？是否基于检索到的上下文？是否回答了用户问题？是否编造了不存在的事实？可以用 Spring AI 的模型评估器。把问题、检索上下文、模型答案和参考答案一起交给评估模型，要求它按“正确性、事实一致性、相关性、完整性”四个维度打分，并输出扣分理由。评估指令要固定下来，不要每次临时改，否则分数不可比。

第三步，设置基线和阈值。第一次跑完 100 条 Golden Questions，记录 Retrieval 和 Answer 各维度分数，作为基线。然后根据业务要求设置发布阈值，比如 Answer 正确性平均分不得低于 4.0，幻觉类严重错误不得高于 5%。阈值不是越高越好，太高会卡住迭代，太低会放行劣质版本。可以先从宽松阈值开始，随着评估器校准逐步收紧。

第四步，接入回归流程。每次任何变量变更，都在合并前自动跑一遍评估。如果总分低于基线或低于阈值，直接拦截。回归结果要生成报告，方便追溯：本次变更了什么、哪个指标下降了、哪些问题变差了。

这里给一个简化的评估思路示意：

```
Dataset: 100 条 Golden Questions
Runner: 逐条调用知识助手获取答案
Evaluators:
  - RuleEvaluator: 答案非空、引用格式正确
  - RetrievalEvaluator: Recall@3、MRR
  - AnswerEvaluator: 正确性、事实一致性、相关性
Report:
  - 总体通过率
  - 各维度平均分
  - 失败用例列表
Gate:
  - 通过率 >= 0.9
  - 事实一致性 >= 4.0
```

注意，这个示意不是完整代码，只是帮助理解流程。实际使用 Spring AI Evaluation Testing 时，可以把评估器注册成组件，在测试阶段调用。

## 06、洞见

LLM-as-Judge 为什么不能成为唯一质量标准？因为评估器本身也是生成式模型，它继承了大模型的所有毛病：知识有截止日期，可能不知道最新制度；判断受指令写法影响；对“看起来专业但事实错误”的回答容易误判；不同运行之间可能给出不同分数。它是一个有用的辅助，但不是一个可靠的质量基准。

真正上线 AI 产品需要的，不是“提示词调好了”，而是一个能够持续重复运行的 Eval System。提示词调好只是某个时间点的状态，不能防止未来变差。评估系统则像一条拦河坝，能让每次变更都经过质量闸门。换句话说，评估系统不是上线前的额外步骤，而是上线后的生产设施。

这里有一个认知转变：过去我们测试的是代码逻辑，现在我们要测试的是模型行为。代码逻辑是确定的，所以测试用例可以穷举主要分支；模型行为是概率性的，所以测试策略必须从“覆盖”转向“回归”。评估系统的目标不是证明某个版本没问题，而是快速发现某个版本变差了。

因此，团队里至少要有一个人对评估数据集负责，就像传统团队里有人对单元测试负责一样。Golden Questions 不是一次性产物，它会随着业务变化、用户反馈和错误分析不断更新。这个资产的价值可能比模型本身的参数更重要。因为你换了模型，评估集还能继续用；但如果评估集本身失真，再好的模型也测不出真实质量。

## 07、行动

如果你正在做生成式知识助手，建议从以下几件事开始。

第一，建立最小评估集。先不用追求 100 条，可以从 30 条高频问题开始，但一定要包含真实用户表达方式，不要只有标准问法。每一条标注参考答案和关键事实。

第二，固定评估维度。建议至少评估四个维度：正确性、事实一致性、相关性、完整性。把这四个维度写进评估指令中，固定评估器模型版本，避免同一批数据在不同时间跑出不可比的分数。

第三，让回归成为硬门槛。每次更换模型、提示词、切分策略、检索器或嵌入模型，都必须跑评估。不要把评估放在发布后，要放在合并前。最简单的方式是在持续集成流程中增加一个评估任务，失败就阻止合并。

第四，定期做错误分析。每周看一次失败用例，按错误类型聚类：是检索错了，还是生成错了？是知识库缺失，还是提示词歧义？根据错误分布决定下一轮优化重点，而不是盲目换模型。

第五，坚持人工抽检校准。每月从 Golden Questions 中随机抽 10 到 20 条，人工复核模型评估器的打分。如果发现评估器漏判或误判，就更新评估指令或调整权重。这样评估系统本身才会越来越可信。

这个行动清单不需要一步到位，但每一条都指向同一个目标：让生成式质量从“感觉还行”变成“有数据可查”。

## 08、小结

HTTP 200 只是生成式接口的最低门槛，它告诉你模型说话了，没告诉你它说对了没有。Spring AI Evaluation Testing 提供了一条工程化路径：用规则和另一个模型共同评估生成结果，区分 Retrieval 和 Answer，建立可重复运行的评估闭环。

但这个闭环的关键不在工具，而在意识。你必须承认生成式应用的质量是非确定的，必须用回归测试来对抗这种不确定性。LLM-as-Judge 是重要组件，但不能单独承担质量标准。真正可靠的质量保障，是数据集、生成、评估、错误分析、回归五层持续运转。

上线不是终点，而是评估系统开始工作的时候。

## 09、链接与概念说明

- Spring AI Evaluation Testing：Spring AI 提供的生成式输出评估能力，支持规则评估器和模型评估器，可用于构建测试用例和回归流程。
- Golden Questions：从真实用户问题中筛选出的高价值评估问题集，通常 50 到 100 条，用于稳定衡量知识助手质量。
- LLM-as-Judge：使用一个语言模型对另一个模型生成的答案进行打分的评估方式，适合判断语义质量，但需要校准和人工抽检。
- Retrieval 评估：针对检索环节的评估，关注召回率、平均倒数排名、上下文相关性等指标。
- Answer 评估：针对最终答案的评估，关注正确性、事实一致性、相关性、完整性等维度。
- 回归评估：在模型、提示词、切分策略、检索器等变量变更后，重新运行评估数据集并与基线对比的流程。
- 相关参考可查阅 Spring AI 官方文档中 Evaluation Testing 章节，以及社区中关于 RAG 评估的公开资料。

我是老李。我们团队去年把一个知识助手接进了 Spring Boot 服务，上线前用 REST Assured 写了一圈测试，断言状态码 200、响应体非空、字段存在，测试全绿。然后上线第二周，用户开始投诉：问“年假怎么算”，它把别的制度编进来了；问“报销发票要求”，它回答得一本正经，但引用条款根本不存在。

《Spring AI 2.0实战》第19招 AI测试不能只看200

生成式 AI 接口不能只看 HTTP 200，Spring AI Evaluation Testing 用另一模型做评估器，建立数据集、生成、评估、错误分析与回

架构师

人工智能

测试

后端

SpringAI Evaluation Testing将生成式接口测试从协议层扩展至语义层，通过规则与LLM-as-Judge混合评估器，区分Retrieval与Answer质量，构建数据集生成评估错误分析回归闭环。核心价值在于用可重复回归测试对抗模型输出不确定性，确保每次模型、提示词或检索变更都能被质量闸门拦截，而非依赖单次200状态码。

向量数据库

单元测试

回归测试

代码解释

客服工单

数据库

JSON

2026上云采购 | AI焕新·智启新局

coding

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

SpringAI Evaluation Testing将生成式接口测试从协议层扩展至语义层，通过规则与LLM-as-Judge混合评估器，区分Retrieval与Answer质量，构建数据集生成评估错误分析回归闭环。核心价值在于用可重复回归测试对抗模型输出不确定性，确保每次模型、提示词或检索变更都能被质量闸门拦截，而非...

《Spring AI 2.0实战》第19招 AI测试不能只看200-腾讯云开发者社区-腾讯云

《Spring AI 2.0实战》第19招 AI测试不能只看200

《Spring AI 2.0实战》第19招 AI测试不能只看200

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐