LLM-as-a-Verifier 是最近讨论度很高的一类做法不让大模型只负责生成最终答案而是额外给它布置验证任务自己看一遍、换提示词再看一遍、甚至让多个模型交叉检查直到满足条件才输出。标题里提到的斯坦福论文以及 DeepSeek 自验证对比 Fable5 的具体数字我没有拿到可以完整复现的实验物料所以这篇文章不逐条转述评测结论重点把方法论讲透再拆开落地时最常见的参数、代码和报错。适合正在做 Agent 开发、RAG 结果校验、代码审查和批量数据抽取的工程师。最值得先想清楚的一点是Verification 也能 Scaling但 scaling 的是验证预算、验证轮次和验证者数量不是简单把提示词写长一点。1. 先想清楚 LLM-as-a-Verifier 解决的是哪一层问题1.1 生成模型的自检为什么经常不可靠大模型在生成答案时本质是逐 token 按概率采样。它并不是先确认“这个结论正确”再把它写出来。所以当你直接问模型“你确定吗”它大概率会回答“我确定”因为继续生成“确定”是概率上最顺滑的路径。在 Agent 场景里这个问题会被放大。你让模型写一段代码、抽取一批结构化数据、做一个多步判断如果只看第一轮输出就直接交付错误率往往比想象中高。尤其是涉及工具调用结果、外部文档摘要、多条证据合并时模型很容易把看起来合理但实际错误的内容混进答案。LLM-as-a-Verifier 的思路就是换一个角色把“生成器”和“验证器”分开。哪怕底层是同一个模型只要在验证阶段使用不同的职责、不同的提示词、不同的检查标准结果就会比单纯问“你确定吗”可靠得多。关键不是模型不聪明而是验证任务需要独立的上下文和评分标准。1.2 Verification 的 Scaling 到底怎么体现很多人一听到 Scaling第一反应是堆更多 GPU、更大模型、更多训练数据。但验证维度的 Scaling 不是这个意思它指的是运行时可以按比例增加验证资源增加验证样本数量让生成器一次输出多个候选答案验证器逐个打分筛选。增加验证轮次第一轮验证发现问题后让生成器带着问题清单重新生成再验证一遍。增加验证者数量不只一个 LLM 当验证官可以多个角色、多个提示词甚至两个不同模型交叉验证。引入规则验证器JSON 格式检查、字段数量校验、代码能否编译、SQL 能否执行、长度是否合规。分层验证先用轻量规则筛掉明显不合格的输出再让 LLM 做语义级检查。这样既省成本又能覆盖深层问题。为什么这套能 scaling因为任务越复杂验证预算越值得投。写一句自我介绍不需要验证但生成一份合同摘要、一段自动化脚本、一组财务抽取结果多花一轮验证的边际收益其实很高。这也是最近几类论文和开源项目都在强调“验证比生成更值得投入”的原因。不过要提醒一句验证不是免费午餐。每多一轮验证延迟、token 成本、失败重试概率都会增加。做 Agent 开发时验证预算要当成和采样温度、并发数一样的参数来管理不能只加不减。2. DeepSeek 自验证和 Agent 工作流是什么关系2.1 自验证不是模型特性是编排出来的流程从标题看DeepSeek 自验证听起来像一个模型内置功能。实际落地时更准确的理解是DeepSeek 作为底层模型被编排进一套“生成 - 验证 - 修正 - 再验证”的流程。模型负责理解和生成外层流程负责控制。DeepSeek 的优势在于几点中文理解能力强、上下文窗口够大、部分版本带思考模式适合承担验证这类需要细看的任务。但真正决定效果的是你怎么定义验证标准、怎么传上下文、怎么处理失败。同一套模型验证提示词写得好和写得差效果能差出一大截。至于“超过 Fable5”这类结论我建议先问三个问题测试集是什么类型验证轮次和采样数是多少对比的是哪个模型版本如果没有这些细节单看一个名字下结论很危险。把它当作讨论引子可以当作采购依据不行。2.2 Agent 里适合放验证节点的位置我的经验是不是所有环节都需要 LLM 验证。下面几个位置收益最明显工具调用结果确认模型调用搜索、数据库、代码执行器后返回结果是否符合预期。代码和配置生成生成完先做静态检查再进入执行步骤。信息抽取从长文档里抽字段需要检查字段是否存在、格式是否统一、有没有凭空补全。多步规划结果Agent 最终决策是否符合用户约束比如预算、时间、权限范围。对话摘要和报告生成不能漏重要信息也不能加入原文没有的信息。在这些节点上验证器拿到的输入应该是“候选答案 验证规则 可参考的原始材料”。验证器输出的不是简单“对/错”而是“通过 / 不通过 问题列表 修改建议”。修正阶段再把问题列表喂回生成器让它在原答案基础上改而不是从头再写。2.3 接入方式先选一种官方 API 还是本地模型开发阶段优先用官方 API因为接口简单、不需要考虑显存和部署。OpenAI 兼容格式可以直接用openaiPython SDK 接入。本地部署适合数据敏感、调用量非常大、或者需要长期跑批量任务的场景常见路径是 vLLM 或类似推理框架起一个兼容接口然后同样按 OpenAI 格式调用。本地部署时要注意三个条件显存要能装下模型权重加推理缓存磁盘要留足权重和临时文件空间并发数和响应超时要做单独的压测。低配置机器也能跑小模型验证但不要一上来就开高并发。先跑单条确认响应正常再加并发。3. 从零搭一个生成 - 验证 - 修正的最小验证器3.1 环境准备先确认 Python 版本和建议的依赖。3.10 以上基本没问题。需要安装 OpenAI SDK或者直接用 requests 也可以。pip install openai调用 DeepSeek 官方接口时配置如下。模型名和接口地址以你拿到的官方文档为准这里给的是通用示例from openai import OpenAI client OpenAI( api_key你的APIKey, base_urlhttps://api.deepseek.com, )如果没有 API Key本地部署一个兼容接口后把base_url指向本地服务地址即可。开发阶段建议先在控制台打出一条测试响应确认连通性。3.2 三套 Prompt生成、验证、修正验证流程要设计三套不同职责的 Prompt三者的 system 角色和评价标准必须区分。生成 Prompt{ role: system, content: 你是资深分析师。请根据用户提供的材料生成答案只输出结论不要解释过程。 }验证 Prompt{ role: system, content: 你是严格的质量验证员。检查候选答案是否满足以下标准1. 是否有原文依据2. 是否遗漏关键信息3. 是否存在逻辑矛盾或凭空补全4. 输出格式是否符合要求。输出格式PASS 或 FAIL。如果是 FAIL请列出具体问题编号和修改建议不要直接改写答案。 }修正 Prompt{ role: system, content: 你是分析师。下面是验证员给出的问题清单请基于原问题和材料修改答案。只输出修改后的答案不要解释。 }三套 Prompt 分开的目的是让模型在验证阶段不是“顺着原答案往下编”而是用另一套标准去挑毛病。很多自验证效果差就是验证阶段没有独立标准模型只是在重复生成一遍。3.3 最小 Python 流程下面是一个可以跑通的最小流程。先定义三个函数生成、验证、修正。def generate_answer(messages, materials): resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: GENERATOR_PROMPT}, {role: user, content: f材料{materials}} ], temperature0.3, ) return resp.choices[0].message.content def verify_answer(answer, materials, rules): resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: VERIFIER_PROMPT}, {role: user, content: f候选答案{answer}\n材料{materials}\n验证规则{rules}} ], temperature0.0, ) return resp.choices[0].message.content def revise_answer(answer, verification_feedback, materials): resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: REVISER_PROMPT}, {role: user, content: f原答案{answer}\n问题清单{verification_feedback}\n材料{materials}} ], temperature0.3, ) return resp.choices[0].message.content主流程控制最大轮次避免无限循环answer generate_answer([], materials) for i in range(2): # 最多修正两次 feedback verify_answer(answer, materials, rules) if feedback.strip().startswith(PASS): break answer revise_answer(answer, feedback, materials) print(answer)这段代码的关键点有两个。第一验证阶段把温度设成 0让验证结果尽量稳定。第二修正轮次限制在 2 到 3 次超过后即使没 PASS 也要输出当前结果。实际任务里如果 3 轮都验证不过大概率是生成阶段的问题不是验证器的问题。3.4 怎么看验证是否真的通过不要只检查字符串里有没有 PASS。因为模型有时会输出“PASS但需要修正”这种自相矛盾的内容。判断标准应该是验证输出是否明确以 PASS 开头。PASS 之后是否还附带修改意见。如果有视为未通过。2 到 3 次验证结果是否一致。同一个答案连续验证两次都 PASS才算可靠。格式类的验证尽量用规则检查不要交给 LLM。例如 JSON 能否解析、字段是否齐全直接用代码判断。4. 验证参数怎么调轮次、温度、采样数和并发预算4.1 验证轮次不是越多越好我有一次把验证轮次设成 5以为会更稳。结果成本翻了一倍多延迟从 3 秒涨到 12 秒正确率并没有明显提升反而出现一种现象生成器在第二次修正后改过头把原本正确的部分也改错了。验证轮次和效果不是线性关系。对多数任务来说1 轮生成加 2 轮验证修正就够了。第一轮抓明显问题第二轮处理剩余细节第三轮再不过说明要么材料不完整要么生成模型本身能力不够。轮次过多还会让模型越改越偏离原始材料。4.2 温度和采样数怎么配合验证场景里生成器和验证器的温度策略应该分开初稿生成温度 0.3 到 0.7。太低容易复读模板太高容易跑偏。验证器温度 0.0 到 0.2。验证要求稳定不需要创造性。修正器温度 0.3 左右。既要保留原答案又允许局部修改。采样数如果希望提高最终质量可以一次生成 3 到 5 个候选答案逐个验证后选评分最高者。这里有一个容易踩的坑验证器给候选答案打分时不同候选之间的分数差异可能很小。如果你用“选分数最高”的方式很可能选到一个分数高但完全不合规的答案。我一般会让验证器先做 PASS/FAIL 判断只对 PASS 的候选再比较质量。如果全部 FAIL就直接走修正流程不做硬选。下面是一个参数参考表参数新手建议进阶调整方向主要影响验证轮次23超 3 必须查生成质量延迟、token 成本、发散风险验证温度00.2 以内验证稳定性初稿温度0.30.5 到 0.7 配合多候选初稿多样性采样候选数13 到 5需控制成本最终答案质量上限单任务超时30 秒长材料可放宽到 60 秒批量任务稳定性批量并发4先压测再提升到 10接口限流、GPU 占用4.3 批量任务的并发、超时与失败重试把单个验证器跑通之后自然要面对批量任务。多文件抽取、多文档摘要、批量代码审查都需要处理输入列表和输出目录。批量处理的三个要点输入列表要带唯一 ID。输出命名用 ID 加时间戳不要用模型生成的标题命名。失败任务单独记录不要中断整个队列。某一条超时或报错先跳过最后统一重试。并发不要一开始就拉满。先用并发 4 跑 20 条样例观察平均耗时、失败率和日志。如果失败率超过 5%先把并发降下来再排查是限流、超时还是 prompt 问题。多线程或异步实现时注意给每个任务设置独立的timeout。我见过不少 Agent 项目卡住半天不是模型不响应而是默认没有超时请求一直挂在连接池里。5. 跑自验证最容易踩的坑和排查顺序5.1 DeepSeek 思考模式下的 reasoning_content 报错如果你用 DeepSeek 带思考模式的模型做验证并打开多轮对话很容易遇到下面这类 400 报错接口返回提示reasoning_content必须原样回传。这个报错不是模型不能用而是多轮请求时上一轮 assistant 消息里包含思考内容下一轮必须把它一起带上否则服务端无法恢复对话上下文。我踩过一次。第一次验证调用正常第二次把历史和验证结果一起传回去时报错 400日志里没有详细信息排查了很久才发现是 reasoning_content 处理少了。正确做法是把响应里的content和reasoning_content都保存下来并在下一轮请求中一起放回 assistant 消息。completion client.chat.completions.create( modeldeepseek-reasoner, messagesmessages, ) assistant_msg { role: assistant, content: completion.choices[0].message.content, reasoning_content: completion.choices[0].message.reasoning_content, } messages.append(assistant_msg)具体字段名以官方文档和当前 SDK 版本为准。关键是整个对话上下文要对齐。遇到这类报错不要第一时间怀疑模型能力先看 messages 里 assistant 消息是否缺少字段。5.2 Agent 执行器超时的排查链路超时是 Agent 场景最常遇到的问题。现象是任务一直转圈最后报“执行器没有在限定时间内响应”。我一般按下面顺序排查先看网络。API endpoint 是否能连通代理设置是否正确。不要跳过网络直接改代码。再看请求内容。prompt 是否过长上下文是否超过模型限制。长材料一次性塞进去首字延迟会明显变长。然后看模型行为。是不是进入了循环调用、错误重试死循环。在日志里打印每次调用的输入长度和耗时。最后看超时和重试配置。单次请求超时、总任务超时、重试次数要分开设置。重试次数不要设成无限否则失败任务会拖垮整个队列。输出为空也是类似思路。先确认输入格式和 prompt再确认是否有内容被系统过滤最后看是不是验证器把 PASS 消息截断了。5.3 证书、代理和环境校验问题要按合规方式处理有时控制台会报 verification failed、证书校验失败或者环境检测不通过。这些通常不是 LLM 验证器的问题而是运行环境本身的问题。正确做法是更新系统证书链、指定正确的 CA 路径、检查代理变量是否指向可用的内部代理。不要为了一时省事去关闭证书校验也不要引入禁用安全校验的配置。开发和测试环境可以用白名单域名测试连通性生产环境必须走正式的证书和认证流程。这类问题一旦通过关闭校验绕过去短期能跑长期会在安全审计和生产故障里加倍还回来。排查时先确认报错来自哪一层模型接口调用、工具执行器、还是系统环境检测。用最小请求逐层测试比直接翻日志猜要快。6. 我的建议哪些场景值得接入自验证6.1 适合自验证的四种任务从实际收益看四类任务最值得接入 LLM-as-a-Verifier。第一代码和配置生成。生成之后用规则做语法校验再用 LLM 验证逻辑是否符合需求最后才执行。第二结构化信息抽取。从合同、简历、论文、聊天记录里抽字段验证器重点检查字段是否齐全、是否来自原文、有没有格式错误。第三RAG 答案校验。模型根据检索内容回答后验证器检查回答是否严格基于检索结果有没有混入模型幻觉。第四多步 Agent 决策。模型做计划后验证器对照用户约束检查每一步是否合法避免 Agent 在工具调用里越走越偏。这类任务的共同点是错误代价高、答案可以评价、有相对明确的验证标准。自验证的收益远大于额外的那点 token 成本。6.2 不建议硬上的场景不是所有场景都适合。低延迟实时对话不适合。每一轮都跑生成加验证延迟会翻倍用户交互体验很差。简单知识问答也不适合模型直接回答即可没必要做两轮校验。输出格式完全稳定的场景更不需要比如固定模板生成用代码模板比用 LLM 再验证快得多。还有一个容易被忽视的场景验证标准本身不明确的开放性问题。让模型评价一篇文案写得好不好结果往往只是换个说法再说一遍。没有明确评价标准时LLM 验证的可靠性很低。这种情况应该先把标准拆成可判断指标再接入验证。6.3 下一步可以怎么演进验证器跑稳之后可以往几个方向扩展。一是引入多验证者投票。同一个答案交给不同角色验证比如一个查事实、一个查格式、一个查逻辑最后汇总。二是把规则验证器和 LLM 验证器分层。规则处理快、成本低能过滤掉大部分问题LLM 只处理规则过滤不了的高层语义问题。三是对验证结果做缓存。相同材料相同问题的验证结果可以复用减少重复调用。四是记录完整验证日志包括每一轮的 PASS/FAIL、修改内容、耗时和 token 消耗。这些日志对后续调参和排查都很有用。就我自己的体验来说这类方案真正落地时最该盯住的不是模型排名或者论文标题而是输入格式、验证标准、失败重试和成本控制。先把单条任务跑稳再把批量、并发、日志一层层加上去。等这些基础都扎实了自验证给 Agent 带来的稳定性提升才会真正显现。