---
title: "给 AI 回答做判断，再决定要不要展示"
description: "在回答到达用户之前，先按标准打分并检查它是否有原文支撑。类型化判定、可设阈值的概率，以及低置信度时转人工的路径。"
canonical: "https://system-one.dev/zh-CN/use-cases/answer-judging"
language: "zh-CN"
---

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

**要点**

1. 判卷需要两样生成式打分给不了的东西：跨样本可比的判定，以及可以设阈值的概率。
2. 问窄问题——是否有支撑、是否切题、覆盖多少——并各自按你定义的量表打分，而不是让它给一个笼统的“质量分”。
3. 低置信度的判定交给更强的模型或人；决策模型只承担它有把握的那部分。

## 为什么先用类型化判定

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

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

## 问题形状

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

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

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

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

```ts
import { 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 当裁判](https://system-one.dev/zh-CN/blog/llm-as-a-judge-alternative)。

## 判定不告诉你的

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

## 费用

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

新账号注册即送 100 积分，积分不会过期。详见 [定价](https://system-one.dev/zh-CN/pricing)。

[在线试用判卷示例（需登录）](https://system-one.dev/zh-CN/demo/llm-judge)，用示例数据看同一组问题。


## 常见问题

### 决策模型能取代 LLM 裁判吗？

对于可检查的窄问题，它能承担大部分负载。数学、代码、逻辑这类需要推导的评估，仍然要更强的模型或人。

### 阈值怎么定？

先自己标注一批样本，按你能接受的错误代价选出阈值，再在留出样本上确认。在一个模型上调好的阈值不能直接搬到另一个模型上。

### 能用在检索流水线里吗？

可以：把检索到的段落作为参考，把生成的回答作为候选，在展示之前问那道支撑问题。

### 判定结果放在哪里？

在你的代码里。模型返回概率和选中的选项；通过、修改、转人工这些动作由你实现。