Spring AI 生产级实战：裁判员

一、为什么需要"裁判员"？

在前面的 Spring AI 生产级实战系列中，我们已经讨论了很多能力：

text 复制代码

Prompt：控制模型输入；
结构化输出：让模型结果可解析；
RAG：让模型基于知识库回答；
Tool Calling：让模型调用外部工具；
Memory：让模型具备上下文连续性；
Agent：让模型参与复杂任务编排。

这些能力解决的是"如何让模型更好地生成结果"。

但是在生产系统中，还有一个非常关键的问题：

模型生成的结果到底好不好，谁来判断？

例如，我们开发一个医学影像报告质控助手，模型返回：

text 复制代码

该报告存在一定风险，建议医生复核肺结节描述。

这句话看起来合理，但系统还需要进一步判断：

text 复制代码

它有没有回答用户的问题？
它是否基于输入内容分析？
它有没有遗漏关键风险点？
它有没有编造不存在的信息？
它是否符合输出格式要求？
它的建议是否清晰、可执行？

如果完全依赖人工评审，准确性较高，但成本高、速度慢、无法大规模覆盖。

如果只依赖传统指标，例如字符串匹配、关键词命中、BLEU、ROUGE 等，又很难评估大模型回答的语义质量。

因为大模型的回答不是标准答案填空题，它通常具有开放性、上下文性和表达多样性。

这时，就需要一种新的评估方式：

text 复制代码

用大模型评估大模型。

这就是 LLM-as-a-Judge，也就是"让大模型当裁判员"。

在 Spring AI 生产级实践中，"裁判员"不是为了替代人，而是为了在系统中增加一层自动质量控制机制，让 AI 应用从"能生成"进一步走向"能评估、能改进、能治理"。

二、什么是 LLM-as-a-Judge？

LLM-as-a-Judge，中文可以理解为：

text 复制代码

大模型作为裁判员。

它的核心思想是：

text 复制代码

让一个大模型根据预设评价标准，
对另一个模型生成的结果进行评分、分类、比较或反馈。

例如用户问题是：

text 复制代码

请总结 Spring AI 中 RAG 的核心流程。

模型 A 生成了一个回答。

然后模型 B 作为裁判员，对模型 A 的回答进行评价：

json 复制代码

{
  "rating": 3,
  "evaluation": "回答基本覆盖了 RAG 的流程，但缺少向量数据库和 Embedding 的说明。",
  "feedback": "建议补充文档向量化、相似度检索和上下文增强步骤。"
}

这里的模型 B 就是裁判员。

它不负责生成最终业务答案，而是负责判断答案质量。

可以简单理解为：

text 复制代码

普通模型调用：
用户问题 → 模型生成回答

LLM-as-a-Judge：
用户问题 → 模型生成回答 → 裁判模型评价回答 → 根据评价决定是否接受或优化

三、为什么大模型可以当裁判员？

这听起来有点奇怪：

如果模型可能会出错，为什么还能让模型来评估模型？

这里有一个重要原因：

text 复制代码

评价通常比生成更简单。

生成一个高质量答案，需要模型同时完成理解、推理、组织语言、满足格式、控制长度、覆盖关键点等多个任务。

而评价一个已有答案，任务更聚焦。

裁判模型只需要判断：

text 复制代码

回答是否相关；
是否完整；
是否准确；
是否遵守指令；
是否表达清晰；
是否基于给定上下文；
是否存在明显错误。

这就像写文章和改文章的区别。

写出一篇好文章很难，但指出一篇文章哪里不完整、哪里表达不清楚，通常更容易。

所以，LLM-as-a-Judge 的核心价值是：

text 复制代码

让模型生成结果之后，再增加一个自动评估环节。

这不能保证绝对正确，但可以显著提升生产系统的质量控制能力。

四、裁判员主要评估什么？

在生产级 AI 应用中，裁判员可以评估很多维度。

常见维度包括：

text 复制代码

相关性：回答是否针对用户问题；
完整性：是否覆盖关键要求；
准确性：是否存在事实错误；
忠实性：是否基于给定上下文或检索资料；
指令遵循：是否按照 Prompt 要求输出；
格式合规：是否符合 JSON、表格、列表等格式；
清晰度：表达是否清楚；
可执行性：建议是否具体；
安全性：是否包含不当内容；
一致性：多次回答是否稳定。

例如在 RAG 系统中，裁判员可以评估：

text 复制代码

回答是否基于检索到的文档；
有没有编造上下文中不存在的信息；
有没有引用错误来源；
是否遗漏了关键文档内容。

在报告质控系统中，裁判员可以评估：

text 复制代码

是否发现了报告中的核心问题；
是否错误扩大了风险；
是否给出了不恰当诊断建议；
是否输出了医生可复核的意见。

在代码生成系统中，裁判员可以评估：

text 复制代码

代码是否满足需求；
是否存在明显编译错误；
是否缺少异常处理；
是否符合 Spring Boot 常见写法；
是否存在安全风险。

五、两种常见评估模式

Spring AI 官方文档中提到 LLM-as-a-Judge 有两类主要评估模式。

1. Direct Assessment：直接评分

直接评分也叫 Point-wise Scoring。

它的做法是：

text 复制代码

给定一个问题和一个回答；
裁判模型根据标准给这个回答打分；
同时给出评价理由和改进建议。

例如评分标准为 1 到 4 分：

text 复制代码

1 分：完全不相关或严重错误；
2 分：部分相关，但遗漏较多；
3 分：基本可用，但仍可改进；
4 分：回答完整、准确、清晰，满足要求。

对应输出可以设计成：

json 复制代码

{
  "rating": 3,
  "evaluation": "回答基本正确，但缺少关键实现步骤。",
  "feedback": "建议补充 Spring AI ChatClient 的调用示例。"
}

这种模式适合：

text 复制代码

单个回答质量评估；
自动重试优化；
回答是否达标判断；
离线测试集评估；
模型输出质量监控。

2. Pairwise Comparison：成对比较

成对比较是让裁判模型在两个候选答案中选出更好的一个。

例如：

text 复制代码

问题：请解释 RAG 的核心流程。

答案 A：......
答案 B：......

请判断哪个答案更好，并说明原因。

裁判模型输出：

json 复制代码

{
  "winner": "B",
  "reason": "答案 B 对检索、增强和生成三个步骤解释更完整。"
}

这种模式适合：

text 复制代码

A/B 测试；
不同模型效果对比；
不同 Prompt 版本对比；
新旧版本回答质量比较；
多候选答案选择。

如果我们在优化提示词，就可以让两个 Prompt 分别生成结果，再让裁判模型比较哪一个更好。

六、Spring AI 如何实现裁判员机制？

Spring AI 官方文档中重点介绍了使用 Recursive Advisors 实现 LLM-as-a-Judge。

Advisor 可以理解为 Spring AI ChatClient 调用链上的增强器。

它可以在模型调用前后做处理。

例如：

text 复制代码

调用前：修改 Prompt、注入上下文、增加记忆；
调用后：检查结果、记录日志、触发重试。

而 Recursive Advisor 更进一步，支持一种循环式调用模式。

它可以实现：

text 复制代码

第一次生成回答；
裁判模型评估回答；
如果评分通过，直接返回；
如果评分不通过，把反馈加入请求；
再次调用模型生成改进版；
再次评估；
直到达到阈值或超过最大重试次数。

流程如下：

text 复制代码

用户请求
  ↓
生成模型生成回答
  ↓
裁判模型评估回答
  ↓
评分达标？
  ├── 是：返回最终回答
  └── 否：把反馈加入 Prompt，重新生成
        ↓
      再次评估
        ↓
      达标或达到最大重试次数

这就是"裁判员"的核心工程化流程。

七、SelfRefineEvaluationAdvisor 的核心思想

官方示例中提到了 SelfRefineEvaluationAdvisor。

可以把它理解为一个"自我优化评估 Advisor"。

它做了几件事：

text 复制代码

1. 调用主模型生成回答；
2. 使用裁判模型对回答评分；
3. 如果评分达到阈值，返回回答；
4. 如果评分不达标，将反馈加入 Prompt；
5. 重新调用主模型生成改进答案；
6. 循环直到达标或超过最大次数。

这其实对应了一个典型的生产级质量控制流程：

text 复制代码

生成 → 评价 → 反馈 → 重试 → 终止

注意，这里的"终止条件"非常重要。

如果没有最大重试次数，就可能出现无限循环。

所以生产环境中必须设置：

text 复制代码

最大重试次数；
成功评分阈值；
超时时间；
失败降级策略；
异常处理机制。

不要让裁判机制无限制运行。

八、结构化评估结果

裁判员的输出最好不要是一段自然语言。

更推荐使用结构化输出。

例如定义一个评估结果对象：

java 复制代码

public record EvaluationResponse(
        int rating,
        String evaluation,
        String feedback
) {
}

其中：

text 复制代码

rating：评分；
evaluation：评价理由；
feedback：改进建议。

裁判 Prompt 可以要求模型返回这样的结构：

json 复制代码

{
  "rating": 4,
  "evaluation": "回答完整、准确，覆盖了用户问题。",
  "feedback": "无需修改。"
}

结构化输出的好处是：

text 复制代码

程序可以判断评分是否达标；
可以自动决定是否重试；
可以记录评估结果；
可以统计不同 Prompt 的质量；
可以做模型效果分析；
可以给人工审核提供参考。

如果裁判员只返回一大段自然语言，系统很难自动处理。

九、裁判 Prompt 应该怎么写？

裁判 Prompt 是 LLM-as-a-Judge 的核心。

它不能写得太模糊。

不建议这样写：

text 复制代码

请评价这个回答好不好。

这样模型会按照自己的理解自由评价，结果不稳定。

更好的方式是明确评价标准：

text 复制代码

你将获得一个用户问题和一个助手回答。
请根据以下标准评价助手回答质量：

评分范围为 1 到 4：
1：回答完全不相关，或严重错误；
2：回答部分相关，但遗漏关键内容；
3：回答基本有帮助，但仍有改进空间；
4：回答完整、准确、清晰，充分回答了用户问题。

请返回：
rating：评分；
evaluation：评分理由；
feedback：如果需要改进，请给出具体建议。

如果是 RAG 场景，还应该增加：

text 复制代码

回答必须基于给定上下文；
如果回答包含上下文中不存在的信息，应降低评分；
如果没有依据却给出确定结论，应降低评分。

如果是医学质控场景，还应该增加：

text 复制代码

不能替代医生诊断；
不能编造影像表现；
不能扩大风险结论；
需要说明是否需要人工复核。

裁判 Prompt 的质量，直接决定裁判结果的质量。

十、为什么最好使用独立裁判模型？

生产系统中，不建议总是用同一个模型既生成答案，又评价答案。

原因是可能存在偏差。

如果一个模型生成了错误回答，它自己再来评价，可能仍然认为回答合理。

所以更推荐：

text 复制代码

生成模型和裁判模型分开。

例如：

text 复制代码

生成模型：负责回答用户问题；
裁判模型：负责评价回答质量。

这样可以降低"自我评价偏差"。

在一些高要求场景中，还可以使用专门的 Judge Model。

也就是说，这类模型本身就是针对评估任务优化过的。

不过实际选型时，还要考虑：

text 复制代码

成本；
延迟；
可用性；
部署方式；
数据合规；
是否支持结构化输出；
是否支持稳定评分。

对于大多数企业系统，可以先用一个稳定的通用模型做裁判，再根据效果决定是否引入专用 Judge Model。

十一、生产级裁判员的常见使用场景

1. RAG 回答质量评估

RAG 系统最怕的是：

text 复制代码

检索到了资料，但模型没有基于资料回答；
模型编造了资料中不存在的信息；
回答看起来合理，但没有依据。

裁判员可以检查：

text 复制代码

回答是否忠实于上下文；
是否遗漏关键文档；
是否存在幻觉；
是否引用错误；
是否回答了用户问题。

适用于：

text 复制代码

知识库问答；
制度问答；
产品手册问答；
技术文档问答；
医学质控规则问答。

2. Prompt 版本评估

当我们优化 Prompt 时，不能只凭感觉判断哪个版本更好。

可以使用裁判员比较：

text 复制代码

Prompt V1 的输出；
Prompt V2 的输出；
Prompt V3 的输出。

然后通过评分和反馈选择更好的版本。

这适合：

text 复制代码

提示词工程优化；
模型切换前后对比；
新旧规则评估；
上线前回归测试。

3. Agent 执行结果评估

Agent 通常包含多个步骤。

例如：

text 复制代码

路由；
检索；
工具调用；
分析；
结构化输出；
任务创建。

裁判员可以在关键节点做质量检查：

text 复制代码

路由是否正确；
工具调用是否合理；
最终结果是否满足任务；
是否遗漏高风险问题；
是否需要人工复核。

这可以让 Agent 不只是"执行"，还具备一定的"自检"能力。

4. 结构化输出质量检查

即使模型返回了 JSON，也不代表业务结果正确。

例如：

json 复制代码

{
  "passed": true,
  "riskLevel": "LOW",
  "problems": []
}

格式是对的，但判断可能是错的。

裁判员可以评估：

text 复制代码

结构化字段是否完整；
风险等级是否合理；
问题列表是否遗漏；
建议是否和问题匹配；
是否符合业务规则。

5. 医学影像报告质控结果复核

在医学影像报告质控系统中，可以让主模型先生成质控结果，再让裁判模型评估。

例如主模型输出：

json 复制代码

{
  "passed": false,
  "riskLevel": "HIGH",
  "problems": [
    {
      "type": "GENDER_LOGIC",
      "description": "男性患者报告中出现子宫相关描述",
      "suggestion": "请医生复核报告模板是否误用"
    }
  ]
}

裁判模型评估：

json 复制代码

{
  "rating": 4,
  "evaluation": "该质控结果明确指出性别逻辑冲突，风险等级合理，建议可执行。",
  "feedback": "可以补充患者性别和原文证据字段，便于人工复核。"
}

这样系统可以进一步判断：

text 复制代码

评分高：自动进入质控结果展示；
评分低：重新生成或转人工复核；
高风险：无论评分如何，都保留人工确认。

十二、裁判员不能替代什么？

LLM-as-a-Judge 很有价值，但不能被误用。

它不能替代：

text 复制代码

人工审核；
业务规则校验；
权限系统；
医学诊断；
法律判断；
金融风控最终决策；
数据库事实校验；
安全合规审查。

尤其在医疗、金融、法律等高风险领域，裁判员只能作为辅助质量控制。

例如医学影像系统中，裁判模型可以判断回答是否清晰、是否遗漏输入内容、是否符合提示词要求。

但它不能替代医生对影像和报告的专业判断。

所以生产级设计应该是：

text 复制代码

模型生成；
裁判模型评估；
规则系统校验；
高风险进入人工复核；
完整审计留痕。

而不是：

text 复制代码

裁判模型说通过，就完全自动通过。

十三、裁判员的偏差与风险

LLM-as-a-Judge 也会犯错。

常见风险包括：

text 复制代码

偏好更长的回答；
偏好表达更自信的回答；
对熟悉风格有偏好；
可能忽略事实细节；
可能被 Prompt 影响；
可能无法识别专业错误；
可能对同一答案评分不稳定。

所以生产系统中需要注意：

text 复制代码

裁判 Prompt 要明确；
评分标准要稳定；
temperature 尽量设低；
尽量使用结构化输出；
关键场景保留人工监督；
对裁判结果也要做监控；
不要把裁判分数当成绝对真理。

裁判员是"辅助评估器"，不是"真理机器"。

十四、为什么要设置 temperature = 0？

裁判模型的任务是评估，不是创作。

我们希望它尽量稳定。

同一个问题和同一个答案，多次评价应该尽量一致。

所以生产环境中，裁判模型一般建议使用较低随机性，例如：

text 复制代码

temperature = 0

这样可以减少评分波动。

对于裁判员来说，稳定性比创造性更重要。

十五、为什么必须设置终止条件？

如果我们使用"生成 → 评价 → 重试"流程，就必须设置终止条件。

例如：

text 复制代码

最多重试 3 次；
评分达到 4 分即通过；
超过 10 秒终止；
连续两次反馈相同则停止；
工具调用失败时停止；
超过成本预算停止。

如果没有终止条件，系统可能陷入循环。

例如：

text 复制代码

生成结果不达标；
裁判给出反馈；
重新生成；
仍不达标；
继续重试；
一直循环。

这会导致：

text 复制代码

成本上升；
响应变慢；
用户体验变差；
系统资源被占用。

所以 Recursive Advisor 一定要配合最大重试次数和降级策略。

十六、裁判员与人类评审的关系

裁判员不是为了取消人工评审，而是为了提高评审效率。

可以这样分工：

text 复制代码

裁判模型：负责自动初筛、质量评分、发现明显问题；
规则系统：负责确定性校验；
人工专家：负责高风险、争议性、专业性判断。

例如：

text 复制代码

低风险 + 高评分：自动通过或抽检；
中风险 + 低评分：重新生成或人工复核；
高风险：强制人工复核；
裁判模型不确定：人工复核。

这种设计比完全人工评审更高效，也比完全自动化更安全。

十七、在 Spring AI 中的工程化设计

一个生产级 LLM-as-a-Judge 流程可以设计为：

text 复制代码

用户请求
  ↓
主模型生成回答
  ↓
裁判模型结构化评分
  ↓
评分是否达标？
  ├── 达标：返回回答
  └── 不达标：加入反馈重新生成
  ↓
超过重试次数？
  ├── 是：返回最后结果并标记质量风险
  └── 否：继续优化
  ↓
保存审计日志

核心数据建议保存：

text 复制代码

用户问题；
原始 Prompt；
主模型名称；
主模型输出；
裁判 Prompt；
裁判模型名称；
评分；
评价理由；
反馈建议；
重试次数；
最终输出；
是否人工复核；
用户反馈。

这些数据后续可以用于：

text 复制代码

Prompt 优化；
模型选型；
质量分析；
人工复盘；
错误样例沉淀；
系统审计。

十八、代码设计思路

可以先定义评估结果对象：

java 复制代码

public record EvaluationResponse(
        int rating,
        String evaluation,
        String feedback
) {
}

再定义一个裁判服务：

java 复制代码

@Service
public class JudgeService {

    private final ChatClient judgeClient;

    public JudgeService(ChatClient judgeClient) {
        this.judgeClient = judgeClient;
    }

    public EvaluationResponse evaluate(String question, String answer) {
        return judgeClient.prompt()
                .user(u -> u.text("""
                        你是一名 AI 回答质量评估员。

                        请根据用户问题和助手回答进行评分。

                        评分标准：
                        1：完全不相关或严重错误；
                        2：部分相关，但遗漏关键内容；
                        3：基本有帮助，但仍可改进；
                        4：完整、准确、清晰，充分回答问题。

                        请返回结构化结果：
                        - rating：1 到 4 的整数；
                        - evaluation：评分理由；
                        - feedback：具体改进建议。

                        用户问题：
                        {question}

                        助手回答：
                        {answer}
                        """)
                        .param("question", question)
                        .param("answer", answer))
                .call()
                .entity(EvaluationResponse.class);
    }
}

业务调用时可以这样组织：

java 复制代码

public String generateWithJudge(String question) {

    String answer = mainChatClient.prompt()
            .user(question)
            .call()
            .content();

    EvaluationResponse evaluation = judgeService.evaluate(question, answer);

    if (evaluation.rating() >= 4) {
        return answer;
    }

    return mainChatClient.prompt()
            .user(u -> u.text("""
                    请根据裁判反馈改进你的回答。

                    原始问题：
                    {question}

                    上一次回答：
                    {answer}

                    裁判反馈：
                    {feedback}
                    """)
                    .param("question", question)
                    .param("answer", answer)
                    .param("feedback", evaluation.feedback()))
            .call()
            .content();
}

这个示例没有完全实现 Recursive Advisor，但表达了基本思想。

实际生产系统中，可以进一步封装成 Advisor，并增加：

text 复制代码

最大重试次数；
评分阈值；
异常处理；
日志记录；
模型隔离；
人工复核标记。

十九、医学影像报告质控场景示例

以医学影像报告质控系统为例，可以设计两个模型角色。

1. 生成模型

负责生成质控结果。

text 复制代码

输入：
报告文本、患者信息、检查信息、RAG 检索规则。

输出：
质控问题、风险等级、复核建议。

2. 裁判模型

负责评价质控结果是否合格。

评估维度包括：

text 复制代码

是否基于报告原文；
是否遗漏明显问题；
是否存在过度推断；
风险等级是否合理；
建议是否可执行；
是否需要人工复核；
是否输出了结构化结果。

裁判 Prompt 可以这样设计：

text 复制代码

你是一名医学影像报告质控结果评估员。
请评估 AI 生成的质控结果是否合理。

重点检查：
1. 是否基于报告原文，不得编造影像表现；
2. 是否覆盖报告中的关键逻辑问题；
3. 风险等级是否与问题严重程度匹配；
4. 建议是否适合医生复核；
5. 是否避免替代医生作最终诊断。

请返回：
rating：1-4；
evaluation：评价理由；
feedback：具体改进建议；
needHumanReview：是否需要人工复核。

对应结构：

java 复制代码

public record QcEvaluationResult(
        int rating,
        String evaluation,
        String feedback,
        Boolean needHumanReview
) {
}

这样系统可以做决策：

text 复制代码

rating >= 4 且 needHumanReview = false：
可以展示为普通 AI 质控建议。

rating < 4：
重新生成或标记质量风险。

needHumanReview = true：
进入人工复核流程。

riskLevel = HIGH：
即使评分较高，也建议人工复核。

这比单纯相信一次模型输出更可靠。

二十、裁判员与模型评估体系

LLM-as-a-Judge 可以用于单次请求的在线评估，也可以用于离线评估。

1. 在线评估

在线评估用于实时控制结果质量。

例如：

text 复制代码

用户请求 → 生成回答 → 裁判评分 → 通过或重试

适合：

text 复制代码

智能客服；
知识库问答；
Agent 执行结果检查；
复杂内容生成；
报告质控建议生成。

优点是能实时提升质量。

缺点是增加延迟和成本。

2. 离线评估

离线评估用于测试集、Prompt 迭代和模型选型。

例如：

text 复制代码

准备 100 条测试问题；
分别用模型 A、模型 B 回答；
用裁判模型统一评分；
统计平均分、失败案例、改进建议。

适合：

text 复制代码

模型选型；
Prompt 版本对比；
上线前回归测试；
知识库更新后评估；
RAG 效果评估。

生产项目中，离线评估非常重要。

它能帮助我们避免"凭感觉调 Prompt"。

二十一、什么时候适合使用裁判员？

适合使用 LLM-as-a-Judge 的场景包括：

text 复制代码

回答质量难以用规则判断；
人工评审成本高；
需要自动化质量控制；
需要多模型或多 Prompt 对比；
需要对 RAG 答案做忠实性评估；
需要对 Agent 输出做自检；
需要对生成内容做上线前评估。

不适合过度使用的场景：

text 复制代码

简单确定性规则；
可以直接用代码判断的问题；
强实时、低延迟接口；
极高风险最终决策；
没有明确评价标准的任务。

例如：

text 复制代码

JSON 是否合法：用代码校验；
字段是否为空：用代码校验；
用户是否有权限：用权限系统校验；
报告是否最终合格：需要医生或业务规则确认。

不要把所有判断都交给裁判模型。

二十二、生产级最佳实践

1. 使用独立裁判模型

尽量不要让同一个模型既生成又评价。

至少在关键场景中，应使用独立 ChatClient 或独立模型。

2. 裁判 Prompt 要标准化

评分标准必须明确，不能只写"请评价好不好"。

3. 使用结构化输出

建议输出：

text 复制代码

rating；
evaluation；
feedback；
pass；
needHumanReview。

4. 设置低随机性

裁判模型建议使用低 temperature，尽量保证评分稳定。

5. 设置最大重试次数

自动优化必须有限制，避免无限循环。

6. 保留人工监督

医疗、金融、法律等高风险场景必须保留人工复核。

7. 不要用裁判替代规则

确定性问题优先用代码、规则引擎或数据库校验。

8. 记录完整审计链路

保存原始问题、回答、裁判评分、反馈和最终结果。

9. 区分在线评估和离线评估

在线评估用于实时质量控制，离线评估用于模型和 Prompt 迭代。

10. 持续维护评估标准

裁判标准也需要版本化、测试和持续优化。

二十三、常见误区

误区一：裁判模型评分高，就一定正确

不是。

裁判模型也可能出错。

评分只能作为参考，不能替代业务事实和专业判断。

误区二：所有请求都要加裁判

不一定。

裁判会增加成本和延迟。

只应在关键任务、高价值任务或质量要求较高的场景使用。

误区三：裁判员可以替代人工审核

不能。

高风险场景仍然需要人工复核。

误区四：裁判 Prompt 不重要

非常重要。

裁判 Prompt 越清晰，评分越稳定。

误区五：无限重试能得到最好结果

不对。

无限重试会导致成本失控。

生产系统必须设置重试上限。

二十四、总结

"裁判员"是 Spring AI 生产级应用中非常重要的质量控制思想。

它解决的是：

text 复制代码

模型输出质量如何自动评估；
Prompt 优化如何量化；
RAG 答案是否忠实于上下文；
Agent 结果是否满足任务要求；
生成结果是否需要重试或人工复核。

LLM-as-a-Judge 的核心流程可以概括为：

text 复制代码

生成结果；
评估结果；
给出反馈；
必要时重新生成；
达到标准或终止。

在 Spring AI 中，可以结合 ChatClient、结构化输出、Advisor、Recursive Advisor 等能力，把裁判机制工程化。

但要始终记住：

text 复制代码

裁判员不是最终真理；
裁判员不能替代人工；
裁判员不能替代业务规则；
裁判员必须有终止条件；
裁判员的判断也需要被记录和评估。

对于生产级 AI 系统来说，裁判员的价值不是让模型完全自我管理，而是在模型生成链路中增加一层自动化质量控制，让系统更稳定、更可观测、更容易持续优化。