跳到主要内容
← 交付方法总览
质量体系可泛化原则

确定性验证器 vs LLM 判官

质量

具体说明确定性断言和 LLM 判官各自适用于什么、如何组合。核心判断是:能逐字比对或重新计算的,一律用确定性断言;只有真正存在多种正确表达的部分,才交给判官。

什么时候需要它

  • 写一条测试时不确定该用断言还是判官
  • 判官分数波动大,怀疑是判官被用在了不该用的地方

核心内容

它决定什么

  • 确定性断言的适用面比直觉更大

    字段存在性、枚举取值、数值一致性、单位、引用是否指向真实存在的来源——这些都能确定性判定,不需要判官。先把这部分榨干,判官的负担会小很多。

  • 判官只负责语义判断

    回答是否切题、解释是否合理、语气是否合适。判官擅长的是有多种正确表达的判断,用它做格式检查是浪费且不可靠。

  • 混合断言的组织方式

    一条用例通常同时包含结构断言和语义评分。结构断言不通过就直接判失败,不必再评语义——省成本,也让失败原因更明确。

  • 判官输出要结构化

    判官应当输出分维度的评分与理由,而不是一个笼统的通过与否。理由是后续校准判官本身的依据。

  • 判官不能自己评自己

    用同一个模型既生成回答又评判回答,会带来系统性的偏向。至少要在提示与角色上隔离,必要时换模型。

怎么判断它真的到位

  • 能对每条断言说清为什么它用的是这种判定方式
  • 结构断言先跑、失败即短路,判官只在结构通过后介入
  • 判官输出包含分维度评分与理由,可供事后复核

常见误区

  • 用判官检查 JSON 字段名,既贵又漏
  • 用严格字符串匹配去测开放式回答,测试维护成本失控
  • 生成与评判共用同一套提示,判官系统性偏松

这套方法怎么落到你的项目

这是我们交付生产级 AI Agent 的公开、脱敏方法骨架。真正落地时,从 AI Agent 生产就绪审查与路线图 入手,或先用 生产上线前深检 定位薄弱环节。