LLM验证器接入：双模型质量闭环免重训

LLM-as-a-Verifier 是一个通用验证器框架：不需要额外训练，就能为任何 Agent 提供细粒度反馈，在 coding、robotics、medical 等 agentic 基准上达到 SOTA。这一期我从 4sapi 的角度把它拆开，看看这套"生成-验证"双模型架构怎么用现成 API 落地。

开篇痛点：Agent 输出没人把关

Agent 应用跑得越深，一个老问题就越刺眼：输出没人把关。生成模型一次吐出来的答案，可能第一眼流畅，细看全是逻辑漏洞；编码 Agent 改完的 diff 可能顺手引入新 bug；医疗问答 Agent 的回复可能缺了关键步骤。多数团队的做法是堆 prompt、调温度、加规则过滤，效果却飘忽不定。

问题出在架构上：让同一个模型既当选手又当裁判，等于让生成器给自己挑错。自评式的"再检查一遍"往往只会换来一遍复读，因为模型的盲区不会因为多问一次就消失。缺的不是更长的 prompt，而是一个职责独立的质量关卡。

原理速览：生成-验证分离架构

LLM-as-a-Verifier 的思路一句话讲完：把"产出"和"把关"拆成两个角色，生成模型负责产出，验证模型负责挑错，反馈以细粒度问题清单的形式回流，驱动下一轮修正。

text

用户任务
   │
   ▼
┌───────────────┐   产出   ┌───────────────┐
│    生成器      │ ───────▶ │    验证器      │
│   Generator   │          │   Verifier    │
└───────────────┘          └───────────────┘
        ▲                         │
        │                         │ 细粒度反馈
        │                         ▼
        └──────── 修正回环 ◀─── 问题清单

回环里的每一步都是现成 LLM 的推理能力在干活，验证器不是新训出来的模型，框架本身也不绑定某个具体 Agent——换任务、换场景都通用，这正是它叫"通用"的原因。

细粒度反馈到底细在哪

验证器返回的不是一个"对/错"标量，而是一份结构化的问题清单：哪一步缺了、哪一段自相矛盾、哪个假设不成立、严重度有多高。这种粒度有两个直接好处：第一，修正有靶子，生成器知道往哪儿改；第二，反馈可量化，问题条数和严重度分布可以被上层直接消费。

为什么"分离"是质量工程的关键

这是 LLM-as-a-Verifier 给出的最值钱的一条洞察：把验证器与生成器分离，是 Agent 质量工程的关键。

生成与验证是两种不同的能力。生成讲究流畅、覆盖、创造性，追求"想得到、写得全"；验证讲究严格、挑剔、可定位，追求"挑得准、说得清"。两者的能力曲线不一样，硬塞进同一个模型，最常见的失败模式是自洽性偏差——自己产出的答案自己看哪都对，以及校准不足——模型对自己的置信度判断并不可靠。

拆开之后，各自的职责边界变得干净：生成模型只需要把活干出来，验证模型只需要把毛病挑出来。质量责任从"生成模型顺手负责"变成"专门有人负责"，这层分工就是质量闭环的地基。

对比维度	自评式（单模型）	独立验证器（双模型）
裁判独立性	无，盲区重叠	完全独立，交叉检查
反馈粒度	泛泛的"再检查"	逐条问题清单
质量改进	依赖重训或调参	免重训，改验证器即可
成本结构	单模型调用	双模型调用，可分开优化

验证器的三个用途

用途一：测试时扩展（test-time scaling）。 修正回环本身就是一种测试时计算：每多一轮"生成→验证→修正"，答案质量就多一档保障。算力花在推理侧而不是训练侧，效果立等可见，不需要等一个训练周期。

用途二：进度追踪。 细粒度反馈天然可以量化：首轮问题数、每轮残留问题数、严重度分布、收敛所需轮数。这些数字直接就是 Agent 任务的进度仪表盘——问题清零即任务收敛，中途卡住也能一眼看出来。

用途三：强化学习（RL）信号。 验证器给出的结构化评价可以转成 reward 信号喂给 RL 流程；因为验证器不参与生成，信号与生成模型解耦，训练管线更干净。

SOTA 成绩单

在多个 agentic 基准上的结果，按领域整理如下：

领域	接入验证器后的表现	反馈如何起作用
编码（coding）	SOTA	逐条挑出逻辑漏洞与边界问题，指导 diff 修正
机器人（robotics）	SOTA	对动作与规划步骤把关，反馈进入下一步规划
医疗（medical）	SOTA	补齐关键步骤，降低漏项风险

值得强调的前提是：这些成绩全部来自"不需要额外训练"，框架层的收益没有绑定任何一次重训成本。

生成器与验证器的分工与选型

两个角色各干各的，选型思路也不同：

角色	核心职责	选型倾向	主要关注点
生成器	产出答案、按反馈修正	能力强、覆盖广	首轮质量、吞吐、上下文长度
验证器	挑错、输出细粒度反馈	严格、稳定、便宜	检出率、误报率、单次成本

我的一个常用省钱思路：验证器不一定要和生成器同档。把关任务通常比产出任务轻，用便宜档位的模型当验证器，成本优势明显；唯一要盯住的是误报率，误报太多会把修正回环拖进死循环。

接入教程：双模型调用

落地第一步是确认 API 可用：我先在控制台拿到密钥，把 base_url 指到标准 OpenAI 兼容端点，openai 库直接可用，双模型就是两次独立的 chat completion 调用：

python

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxxxxxxxxxxx",          # 控制台生成的密钥
    base_url="https://4sapi.com/v1",
)

GENERATOR_MODEL = "generator-model-id"  # 替换为控制台可见的生成模型 ID
VERIFIER_MODEL = "verifier-model-id"    # 验证模型 ID，可选用便宜档位

def generate(task: str) -> str:
    resp = client.chat.completions.create(
        model=GENERATOR_MODEL,
        messages=[{"role": "user", "content": task}],
    )
    return resp.choices[0].message.content

def verify(task: str, answer: str) -> str:
    resp = client.chat.completions.create(
        model=VERIFIER_MODEL,
        messages=[
            {"role": "system", "content": (
                "作为细粒度验证器：逐条检查答案，输出问题清单"
                "（每条包含位置、问题描述、严重度）。"
                "没有问题则只输出：通过"
            )},
            {"role": "user", "content": f"任务：{task}\n答案：{answer}"},
        ],
    )
    return resp.choices[0].message.content

def solve_with_verifier(task: str, max_rounds: int = 3) -> str:
    answer = generate(task)
    for _ in range(max_rounds):
        feedback = verify(task, answer)
        if "通过" in feedback:
            break
        answer = generate(f"{task}\n\n请按以下反馈修正：\n{feedback}")
    return answer

关键点有三个：验证 prompt 固定成结构化输出，方便程序解析；max_rounds 设上限，防止死循环烧 token；生成与验证各用各的模型 ID，便于分开计量。

网关配置：分流与计费优化

双模型回环对网关层提出了新要求：生成器与验证器的调用特征完全不同。生成器调用长、token 大、突发高；验证器调用短、频次高、适合批量。在网关层做分流，两路都能优化：

text

Agent 请求
    │
    ▼
接入网关（OpenAI 兼容端点）
    ├─ 鉴权与密钥校验
    ├─ 限流、配额与重试策略
    ├─ 负载均衡：多上游健康检查与自动切换
    ├─ 用量计量与计费分账
    ▼
生成通道 ──▶ 验证通道（双模型独立计量）
    │
    ▼
反馈回环 → 进度追踪 / RL 信号

配置上的几个建议：生成通道按容量型上游分配，验证通道按延迟型上游分配；验证器的批量校验请求合并提交，摊薄每请求的开销；计费按角色分开记账，生成与验证各算各的账——成本归因清楚，才能算明白"验证器省下的返工成本"到底有多少。

成本与风险提示

验证器不是免费的：每多一轮修正就多一次调用，token 消耗会成倍增长，max_rounds 和问题清单长度都必须设上限。
验证器会误报、漏报：上线前用一批历史坏样本离线评估检出率与误报率，不要盲信任何验证器。
反馈格式要稳定：让验证器输出 JSON 并在接入层做校验，别把解析成本摊进主链路。
延迟会叠加：串行"生成→验证→再生成"把单任务延迟放大数倍，超时与重试要分层设计。
合规红线：所有接入只走合法 API 与官方授权渠道，网关只做鉴权、限流、负载均衡、计量计费等正当职能，不碰任何违规代理方案。

接入检查清单

[ ] 密钥与 base_url 配置正确，openai 库连通性验证通过
[ ] 生成模型与验证模型配置为独立模型 ID，计费维度分开
[ ] 验证 prompt 固定输出结构化问题清单（位置/问题/严重度），解析逻辑就绪
[ ] max_rounds 上限与单轮 token 预算已设置
[ ] 用历史坏样本离线评估验证器的检出率与误报率
[ ] 生成/验证通道已分流，健康检查与重试策略生效
[ ] 每轮反馈条数与收敛轮数已记录，进度追踪指标可查
[ ] 全链路合规复核：仅合法接入，无违规代理行为

总结

这一期我把 LLM-as-a-Verifier 拆成三块：生成-验证分离的架构原理，细粒度反馈的三种用途（测试时扩展、进度追踪、RL 信号），以及免重训的接入落地。核心结论一句话：把验证器与生成器分离是 Agent 质量工程的低成本提质路径——生成模型负责产出，验证模型负责挑错，两者职责不同，用验证器做细粒度反馈不需要重训生成模型。而 4sapi 的接入层，天然支持这类双模型回环的落地。欢迎在评论区发表想法/聊聊。