尧图网站建设 
为什么logprob分布比单一分数更准LLM-as-a-Verifier细粒度奖励的核心原理【免费下载链接】llm-as-a-verifierLLM-as-a-Verifier is a general-purpose framework that provides fine-grained feedback for any agent without requiring additional training. It achieves SOTA performance across coding, robotics, and medical agentic benchmarks.项目地址: https://gitcode.com/gh_mirrors/ll/llm-as-a-verifierLLM-as-a-Verifier 是一个通用的智能体Agent验证框架它不让大模型只给出一个单一分数而是读取模型打分时logprob 概率分布的完整形态用期望值算出 0~1 之间的细粒度奖励fine-grained reward从而实现对任意 Agent 的精准评估——无需任何额外训练。下面用 4 个部分讲清楚它为什么比传统的 LLM 打分方式更准。为什么单一分数不够LLM 评估的第一个陷阱传统的LLM-as-a-Judge做法是让评审模型输出一个离散标签比如 1~10 分里的某个整数然后直接采信。问题在于信息被强行压缩模型内部其实对这个答案值 12 分还是 15 分存在真实的犹豫输出单一整数时这份犹豫被丢掉了。边界情况被误判一个差一点点就全对的轨迹和一个完全跑偏的轨迹可能被粗暴地打成相邻的两档却看不出差距到底是 1 分还是 5 分。无法连续比较单一分数是阶梯状的做强化学习信号或进度监控时粒度太粗会导致训练信号稀疏。LLM-as-a-Verifier 的关键洞察是模型对每个候选分数的概率本身就是它最诚实的判断。与其让它二选一地落子不如把整条概率分布读出来。核心原理读取评分 token 的完整 logprob 分布整个框架的数学核心只有一句话对评分 token 集合求概率加权期望$$ R(x, \tau) \frac{1}{CK} \sum_{c1}^{C} \sum_{k1}^{K} \sum_{g1}^{G} p_{\theta}(v_g \mid x, c, \tau),\phi(v_g) $$各符号含义很直白符号含义直觉理解C评估标准数把对不对拆成多个独立标准分别打分K重复验证次数多次采样取平均抑制随机波动G评分 token 数粒度默认 20 档A~T 字母p(v_g)模型给某档分数的概率分布而不是单点φ(v_g)把评分 token 映射为标量值A20 分 … T1 分关键实现在 extract_score()它定位到模型回答中评分标签如score_A之后的那个 token 位置取出该位置的 top-20 候选 token 及其 logprob做 softmax 归一化后计算加权期望最后把结果线性缩放到 [0, 1]。如果某个后端拿不到 logprob才退化为解析文本里的字面字母——也就是说分布优先、单值兜底。为什么用 A~T 字母而不是数字 1~20评分标尺定义在 fine_grained_reward.py 的 SCALEA~T 共 20 个字母每个字母在主流分词器tokenizer里都是独立的 token因此每个档位都能单独拿到 logprob而1020这类多位数字往往被切成多个碎片 token分布就取不干净了。档位语义明确分级A完全成功H~M不确定区间T彻底失败进度跟踪场景方向相反A0% 进度T100%。提示词里明确要求模型先推理、最后才输出评分行让分布建立在完整分析之上。再配合一个工程细节 prefill 评分技巧对开源模型框架会先把score_A标签预填进对话再用结构化输出约束该位置只能落在这 20 个字母上——这样读到的 top-logprob 就是在评分尺度上重新归一化的真实分布不受无关 token 干扰。细粒度奖励的四根支柱分解、重复、粒度、不确定性单看分布只是第一根支柱。框架把准拆成了四个可叠加的杠杆对应总览图中 Verification Scaling Framework 的四个模块分解Criteria Decomposition评估标准不是一句好不好而是写在 criteria/ 目录 下的独立条目如是否修了根因是否跑了验证。每条标准单独打分再平均避免一个优点掩盖另一处硬伤。标准文件由 load_prompts() 解析可直接照 TEMPLATE.md 复制改写。重复Repetition每对比较重复 K 次评分取均值。有意思的是奇数次重复会自动交换 A/B 槽位顺手抵消了模型的位置偏置。粒度Granularity就是本文主角——20 档分布期望而非 1 档单值。不确定性Uncertainty直接建模模型自己有多确定分布越尖锐分数越可信分布弥散则说明模型真的拿不准。四者相乘奖励从粗糙的档位变成了连续、可微、可比较的 [0,1] 标量。细粒度奖励能干什么Best-of-N 选型与实时进度追踪用 O(Nk) 成本从 N 条轨迹里挑出最好的拿到连续奖励后选最优轨迹不再需要 O(N²) 的全两两比较。Probabilistic Pivot TournamentPPT 分三步随机环上一圈粗排 → 选出 top-k 个轴心候选 → 只让其余候选与轴心比。每场比较的胜负用 Bradley-Terry 软投票p sigmoid(R_a − R_b)见 bradley_terry()连续奖励在这里变成软胜率——这正是单一分数做不到的0.62 对 0.60 和 0.9 对 0.2 的赢法完全不同。实测效果在 Terminal-Bench 2.1 上Best-of-5 细粒度验证达到88.0%远超基线 Pass1 的 78.7%SWE-Bench Verified 上从 76.1% 提到 78.2%。连续分数画出的进度曲线是分布更准最直观的证据用 track() / ProgressTracker 给一条执行轨迹的每一步打分得到的不是一串跳变的档位而是一条平滑连续曲线。下图是 Terminal-Bench 任务pytorch-model-cli的两次运行成功运行的分数随步骤单调爬升到 1.0失败运行的分数在错误路径上持续走低——如果只有单一分数这种差距在逐步拉大的信号根本看不到。复现脚本terminal_bench_progress.py。快速上手三步跑通 LLM-as-a-Verifier 细粒度奖励pip install llm-verifier配置好任一支持 logprobs 的后端如 vLLM 本地服务、DeepSeek、Vertex Gemini后几行代码即可体验import llm_verifier result llm_verifier.select( problemWrite a function that reverses a string., candidates[traj_1, traj_2, traj_3], criteria{Correctness: Does the code actually reverse the string?}, ) print(result.index, result.scores) # 最优候选及每个候选的连续奖励想要复现论文表格里的基准成绩直接运行 scripts/run.pypython scripts/run.py terminal_bench python scripts/run.py swe_bench基准注册表在 benchmarks.py各基准的轨迹数据随仓库提供data/目录。常见问题LLM 验证与 logprob 奖励 FAQ问为什么不用更大范围比如 1~100 分的标尺答档位越细越准但受限于 top-logprobs 接口上限OpenAI 系 API 封顶 20 个候选 token20 档是当前接口下的最优粒度且 20 档对区分优劣已绰绰有余。问logprob 分布取的是哪一步的答模型回答中评分标签后的那个位置且取最后一次出现避免模型在分析中引用格式时误采。问这个方法需要微调模型吗答完全不需要。它只依赖推理时接口返回的 token 级 logprob对 Gemini、DeepSeek、vLLM 部署的开源模型通用。问细粒度奖励能直接当强化学习的 reward 吗答可以。连续 [0,1] 信号比 0/1 稀疏奖励更适合做 RL 的 reward shaping这也是框架宣传的三个落地场景之一测试时扩展、进度追踪、强化学习。小结单一分数是模型判断的投影logprob 分布才是它的原像。LLM-as-a-Verifier 用 20 档字母标尺 分布期望 标准分解 重复验证把 LLM 评审从拍脑袋打档升级为连续、可解释、免训练的细粒度度量——这就是它能在编程、机器人、医疗等多个智能体基准上稳定超过基线的原因。【免费下载链接】llm-as-a-verifierLLM-as-a-Verifier is a general-purpose framework that provides fine-grained feedback for any agent without requiring additional training. It achieves SOTA performance across coding, robotics, and medical agentic benchmarks.项目地址: https://gitcode.com/gh_mirrors/ll/llm-as-a-verifier创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 为什么logprob分布比单一分数更准？LLM-as-a-Verifier细粒度奖励的核心原理
为什么logprob分布比单一分数更准LLM-as-a-Verifier细粒度奖励的核心原理【免费下载链接】llm-as-a-verifierLLM-as-a-Verifier is a general-purpose framework that provides fine-grained feedback for any agent without requiring additional training. It achieves SOTA performance across coding, robotics, and medical agentic benchmarks.项目地址: https://gitcode.com/gh_mirrors/ll/llm-as-a-verifierLLM-as-a-Verifier 是一个通用的智能体Agent验证框架它不让大模型只给出一个单一分数而是读取模型打分时logprob 概率分布的完整形态用期望值算出 0~1 之间的细粒度奖励fine-grained reward从而实现对任意 Agent 的精准评估——无需任何额外训练。下面用 4 个部分讲清楚它为什么比传统的 LLM 打分方式更准。为什么单一分数不够LLM 评估的第一个陷阱传统的LLM-as-a-Judge做法是让评审模型输出一个离散标签比如 1~10 分里的某个整数然后直接采信。问题在于信息被强行压缩模型内部其实对这个答案值 12 分还是 15 分存在真实的犹豫输出单一整数时这份犹豫被丢掉了。边界情况被误判一个差一点点就全对的轨迹和一个完全跑偏的轨迹可能被粗暴地打成相邻的两档却看不出差距到底是 1 分还是 5 分。无法连续比较单一分数是阶梯状的做强化学习信号或进度监控时粒度太粗会导致训练信号稀疏。LLM-as-a-Verifier 的关键洞察是模型对每个候选分数的概率本身就是它最诚实的判断。与其让它二选一地落子不如把整条概率分布读出来。核心原理读取评分 token 的完整 logprob 分布整个框架的数学核心只有一句话对评分 token 集合求概率加权期望$$ R(x, \tau) \frac{1}{CK} \sum_{c1}^{C} \sum_{k1}^{K} \sum_{g1}^{G} p_{\theta}(v_g \mid x, c, \tau),\phi(v_g) $$各符号含义很直白符号含义直觉理解C评估标准数把对不对拆成多个独立标准分别打分K重复验证次数多次采样取平均抑制随机波动G评分 token 数粒度默认 20 档A~T 字母p(v_g)模型给某档分数的概率分布而不是单点φ(v_g)把评分 token 映射为标量值A20 分 … T1 分关键实现在 extract_score()它定位到模型回答中评分标签如score_A之后的那个 token 位置取出该位置的 top-20 候选 token 及其 logprob做 softmax 归一化后计算加权期望最后把结果线性缩放到 [0, 1]。如果某个后端拿不到 logprob才退化为解析文本里的字面字母——也就是说分布优先、单值兜底。为什么用 A~T 字母而不是数字 1~20评分标尺定义在 fine_grained_reward.py 的 SCALEA~T 共 20 个字母每个字母在主流分词器tokenizer里都是独立的 token因此每个档位都能单独拿到 logprob而1020这类多位数字往往被切成多个碎片 token分布就取不干净了。档位语义明确分级A完全成功H~M不确定区间T彻底失败进度跟踪场景方向相反A0% 进度T100%。提示词里明确要求模型先推理、最后才输出评分行让分布建立在完整分析之上。再配合一个工程细节 prefill 评分技巧对开源模型框架会先把score_A标签预填进对话再用结构化输出约束该位置只能落在这 20 个字母上——这样读到的 top-logprob 就是在评分尺度上重新归一化的真实分布不受无关 token 干扰。细粒度奖励的四根支柱分解、重复、粒度、不确定性单看分布只是第一根支柱。框架把准拆成了四个可叠加的杠杆对应总览图中 Verification Scaling Framework 的四个模块分解Criteria Decomposition评估标准不是一句好不好而是写在 criteria/ 目录 下的独立条目如是否修了根因是否跑了验证。每条标准单独打分再平均避免一个优点掩盖另一处硬伤。标准文件由 load_prompts() 解析可直接照 TEMPLATE.md 复制改写。重复Repetition每对比较重复 K 次评分取均值。有意思的是奇数次重复会自动交换 A/B 槽位顺手抵消了模型的位置偏置。粒度Granularity就是本文主角——20 档分布期望而非 1 档单值。不确定性Uncertainty直接建模模型自己有多确定分布越尖锐分数越可信分布弥散则说明模型真的拿不准。四者相乘奖励从粗糙的档位变成了连续、可微、可比较的 [0,1] 标量。细粒度奖励能干什么Best-of-N 选型与实时进度追踪用 O(Nk) 成本从 N 条轨迹里挑出最好的拿到连续奖励后选最优轨迹不再需要 O(N²) 的全两两比较。Probabilistic Pivot TournamentPPT 分三步随机环上一圈粗排 → 选出 top-k 个轴心候选 → 只让其余候选与轴心比。每场比较的胜负用 Bradley-Terry 软投票p sigmoid(R_a − R_b)见 bradley_terry()连续奖励在这里变成软胜率——这正是单一分数做不到的0.62 对 0.60 和 0.9 对 0.2 的赢法完全不同。实测效果在 Terminal-Bench 2.1 上Best-of-5 细粒度验证达到88.0%远超基线 Pass1 的 78.7%SWE-Bench Verified 上从 76.1% 提到 78.2%。连续分数画出的进度曲线是分布更准最直观的证据用 track() / ProgressTracker 给一条执行轨迹的每一步打分得到的不是一串跳变的档位而是一条平滑连续曲线。下图是 Terminal-Bench 任务pytorch-model-cli的两次运行成功运行的分数随步骤单调爬升到 1.0失败运行的分数在错误路径上持续走低——如果只有单一分数这种差距在逐步拉大的信号根本看不到。复现脚本terminal_bench_progress.py。快速上手三步跑通 LLM-as-a-Verifier 细粒度奖励pip install llm-verifier配置好任一支持 logprobs 的后端如 vLLM 本地服务、DeepSeek、Vertex Gemini后几行代码即可体验import llm_verifier result llm_verifier.select( problemWrite a function that reverses a string., candidates[traj_1, traj_2, traj_3], criteria{Correctness: Does the code actually reverse the string?}, ) print(result.index, result.scores) # 最优候选及每个候选的连续奖励想要复现论文表格里的基准成绩直接运行 scripts/run.pypython scripts/run.py terminal_bench python scripts/run.py swe_bench基准注册表在 benchmarks.py各基准的轨迹数据随仓库提供data/目录。常见问题LLM 验证与 logprob 奖励 FAQ问为什么不用更大范围比如 1~100 分的标尺答档位越细越准但受限于 top-logprobs 接口上限OpenAI 系 API 封顶 20 个候选 token20 档是当前接口下的最优粒度且 20 档对区分优劣已绰绰有余。问logprob 分布取的是哪一步的答模型回答中评分标签后的那个位置且取最后一次出现避免模型在分析中引用格式时误采。问这个方法需要微调模型吗答完全不需要。它只依赖推理时接口返回的 token 级 logprob对 Gemini、DeepSeek、vLLM 部署的开源模型通用。问细粒度奖励能直接当强化学习的 reward 吗答可以。连续 [0,1] 信号比 0/1 稀疏奖励更适合做 RL 的 reward shaping这也是框架宣传的三个落地场景之一测试时扩展、进度追踪、强化学习。小结单一分数是模型判断的投影logprob 分布才是它的原像。LLM-as-a-Verifier 用 20 档字母标尺 分布期望 标准分解 重复验证把 LLM 评审从拍脑袋打档升级为连续、可解释、免训练的细粒度度量——这就是它能在编程、机器人、医疗等多个智能体基准上稳定超过基线的原因。【免费下载链接】llm-as-a-verifierLLM-as-a-Verifier is a general-purpose framework that provides fine-grained feedback for any agent without requiring additional training. It achieves SOTA performance across coding, robotics, and medical agentic benchmarks.项目地址: https://gitcode.com/gh_mirrors/ll/llm-as-a-verifier创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考