给 AI 回答做判断，再决定要不要展示

为什么先用类型化判定

LLM 裁判会写理由再给个分。两次运行可能不一致，分数也不带不确定性，所以流水线只能照单全收。决策模型每次都回答同一批窄问题，并为每个选项返回概率。

这让判定在样本之间可比，也让你能在代码里选阈值。它不保证判断正确——阈值仍要来自你自己标注的样本。

问题形状

三个问题覆盖大多数判卷场景：

• supported（Noul）：答案里的每条事实陈述是否都能在参考文本中找到支撑？
• relevance（Score）：答案覆盖了用户问题的多少？
• verdict（Choice）：通过、修改，还是转人工？

把指令写窄、写具体：“仅根据参考文本，评估每条陈述”和“这是一段好回答吗”是两个不同的问题，前者才可测量。

示意代码，未经过实际运行测试。阈值只是占位。

tsimport { booleanQuestion, choice, score } from '@system-one-ai/core';
import type { EvaluationClient } from '@system-one-ai/core';

export const judgeQuestions = {
  supported: booleanQuestion(
    'Is every factual claim in candidate_answer supported by reference?',
  ),
  coverage: score('How much of user_question does candidate_answer address?', {
    none: 'Does not address the requested information',
    partial: 'Addresses some of the request but omits a required part',
    full: 'Addresses the request completely',
  }),
  verdict: choice('What should happen to this answer?', {
    ship: 'Supported and complete',
    revise: 'Fixable gaps',
    escalate: 'Needs a person or a stronger model',
  }),
};

export async function judgeAnswer(
  client: EvaluationClient,
  input: { question: string; reference: string; candidate: string },
) {
  const result = await client.evaluate({
    state: input,
    questions: judgeQuestions,
  });
  return {
    supported: result.answers.supported.probability,
    coverage: result.answers.coverage.score,
    verdict: result.answers.verdict.choice,
    confidence: result.answers.verdict.confidence,
  };
}

按成本排序，而不是按重要性排序

先跑便宜的那道检查，只把活下来的往上升级：

1. 支撑检查：每条回答都跑。它只有一个是非问题，却能拦住检索流水线里最要命的失败。
2. 覆盖打分：只对通过支撑检查的回答跑。完全有支撑的回答也可能只回答了一半。
3. 更强的模型或人：任何一道没过，或置信度偏低时交给他们。

关于这种分工的研究局限，见 用 Score 替代 LLM 当裁判。

判定不告诉你的

• 它不是正确性证明。 参考文本本身错了，有支撑的回答照样是错的。
• 它不评风格。 语气或格式重要，就单独问一个问题。
• 它不解释理由。 需要给人看的原因时，搭配一个生成式模型。

费用

每 4KB 算一块，不足 4KB 也按一块。费用 = 块数 × 问题数 × 模型单价。本页的请求在 Jev 上问三个问题（每个问题每块 1 积分）。

新账号注册即送 100 积分，积分不会过期。详见 定价。

在线试用判卷示例（需登录），用示例数据看同一组问题。