怎么在llm的上下文里放verifier？什么是好的verifier？

回复 群友 7532： 先说结论：verifier 放进上下文有两种完全不同的放法，混在一起想会一直绕不出来。 一种是把"什么算合格"事先写进上下文。做法是把验收标准写成清单随任务一起给它：要满足哪几条、以什么形式交付、跑什么命令必须过。这层本质是提示词工程，成本最低，但容易退化成模型自己给自己打分——它既写答案又判卷，天然偏松。 另一种是把验证结果事后注入上下文，这才是真·verifier 的位置：产出物先落到手边，外部检查一遍，再把结论塞回上下文让它改。工程上一般这么接： 把验证做成它必须走的一道关卡，而不是它自愿调用的工具。阶段结束自动跑一次，结果以结构化形式回来——哪项过了、哪项没过、证据是什么（报错原文、失败的测试名、对不上的字段）。然后带着这份反馈回到修复循环，设重试上限，比如三轮，还不通过就转人或降级交付。 优先用能跑的检查，而不是能说的检查。跑测试、类型检查、schema 校验、真把视频压一遍看体积和音轨——这些是硬证据，机器可读，几行就说完，还不会说谎。模型评分留给没法编程验证的部分，比如文档语气、方案合理性。Anthropic 那个 skill-creator 里就写明了这条原则：能用程序断言的别让模型目测。 要独立，这是最容易被忽略的一条。同一个模型、同一份上下文、还带着自己的推理过程自评，结论基本是"我做得挺好"。所以要换模型，或者至少换一份干净上下文；只给它产物，不给它的解释（判卷老师只看答案，不听考生讲思路）；多个候选对比时把顺序打乱，否则它偏爱排在前面的那个。 上下文卫生也得管。反馈要短、要指到具体位置，比如"第 3 行的字符串没转义，这条命令会复现报错，改完这个测试应该过"，而不是"逻辑有点问题"。已经解决掉的旧失败记录要清出去，不然它会顺着无关节制一路改；也不要把满分夸奖留着，那只会让它更自信。 再说什么是好的 verifier。判断标准其实就一句：它能不能把正确答案从一堆候选里挑出来，同时不把错的放过去。展开是几条。 宁可误杀，不可放过。放走一个错误答案的代价通常远大于误杀一个对的——误杀还能靠重采样补救，放过就直接交付了。所以要看假阳性率，不是只看总体准确率。 分数得有区分度。只输出 0/1 的模型评委在大问题上会大面积平局，挑不出好坏。斯坦福那套 LLM-as-a-Verifier 的做法是打分时取分数的期望而不是离散选项，再把评价标准拆开、多评几次取平均，分离度会明显变好。 能给出可行动的信息，而不只是一个结论。它的价值一半在判断，一半在告诉对方怎么改。 便宜、稳、可复现，而且知道自己有多可信。验证成本是要乘在候选数和重复次数上的，很容易反超生成本身。Weaver 那篇的思路可以借鉴：同时用一堆弱验证器（模型评委、奖励模型）加权融合，权重靠一小撮带答案的样本估出来，能把 8B 到 70B 的模型拉到接近 o3-mini 的水平；再把整个集成蒸馏成一个小的 cross-encoder，保留九成八以上的收益，验证成本降三个数量级。另外它得能估出自己的准确率——一个不知道自己什么时候会错的 verifier，你没法判断该不该信它。 最后别被表面特征带跑：写得长的、格式漂亮的、语气自信的容易被给高分，这是模型评委的通病，跟答案对不对无关。 一句话收口：好的 verifier 不是最会讲道理的那个，而是最不容易被讲道理说服、并且能拿出证据的那个。