FineVerify: 面向智能体搜索的细粒度自验证测试时计算缩放

TL;DR FineVerify 将问题分解为可检查子问题，通过细粒度自验证从多条搜索轨迹中筛选最优答案，以少量样本即大幅提升代理搜索准确率，且提供可解释的校验轨迹。

问题

在 Agentic Search 场景中，语言模型代理通常需探索多个信息源、完成多步推理，以回答复杂的开放性问题。为提升这类代理的准确率，扩大 Test-Time Compute（例如通过采样多条候选轨迹并从中择优）已被证明是有效途径。然而，现有选择机制在面对稀疏的真值分布时往往失效，导致算力投入与性能提升不成正比。

现有方法的局限

当前主流的选择策略可分为两类：

• 基于自一致性的多数投票：依赖模型多次采样后输出一致性最高的答案，但在代理搜索任务中，正确答案本身占比极低，多数投票容易偏向高频但错误的“幻觉”轨迹。
• 基于模型的评分选择：利用奖励模型或语言模型自身的置信度对候选片段打分，再取最高分答案。这类方法严重依赖 模型校准质量——若模型对不同错误的区分度不足，或对长文本序列的评分存在位置偏差，就会错选不可靠的回复。

问题的核心难点

代理搜索任务的特殊性在于：

1. 答案稀疏性：一次搜索产生的数十条轨迹中，可能仅有一条完全正确，传统聚合手段易被噪声淹没。
2. 细粒度判断需求：单条答案往往包含多个事实点，整体评分难以反映局部细节的正确性，也无法提供可解释的验证依据。
3. 校准不确定性：语言模型的置信度分布会随问题类型、提示格式剧烈变化，难以构造通用且鲁棒的选择器。

这些问题直接阻碍了 Test-Time Compute Scaling 在工业级代理系统中的应用——算力投入很大，但真实收益有限，且缺乏透明、可审计的选优过程。因此，设计一种能够将验证粒度细化到子问题级别、减少对模型本身校准能力的依赖的选择方法，成为业界共同关注的突破口。

行业类比

这与软件工程中 单元测试 (Unit Test) 的理念类似：与其直接评估整个系统的输出，不如将需求拆解为多个可独立校验的子问题，通过逐一验证每个功能点的正确性来确定最终交付质量——这种方式既提升了判断的准确度，也更容易定位失效环节。

核心洞察

• FineVerify 将传统基于单一标量分数的轨迹选择，重构为基于细粒度子问题核查的结构化验证。以往方法依赖语言模型自身校准能力，在稀疏正确答案下易误判；而 FineVerify 事先将复杂问题拆解为一系列可独立检查的子问题，再对每条采样轨迹逐条判断是否满足每项子问题，最终聚合为可解释的得分。这种分解有效降低了单一判断的方差，使得验证过程更加鲁棒，且每项判断都有明确准则，减轻了对模型校准的过度依赖。
• 该工作重新定义了测试时计算扩展的切入点：将算力从生成更多候选轨迹，转移到对少量轨迹的细致验证。在 agentic search 中，盲目增加采样数往往收益递减且代价高昂；FineVerify 用仅 4 条轨迹就让 GPT‑5‑mini 平均提升 8.2 个准确率百分点，12 条时甚至超越前沿模型 GPT‑5。这一范式表明，对已有输出的结构化反思可能比堆叠更多生成尝试更高效，为推理预算有限的生产环境提供了一条高性价比的增强路径。

方法

FineVerify 面向 agentic search 场景，其核心流程遵循“输入分解 → 逐项验证 → 分数聚合与选择”的线索。

输入与问题分解

给定一个复杂信息查询，模型首先生成多条候选搜索轨迹（sampled candidates），每条轨迹包含一系列搜索动作与推理步骤。随后，FineVerify 将原始问题自动分解为一组可独立校验的子问题（checkable sub-questions），每个子问题对应一个明确的验证准则。

细粒度自验证

对每条候选轨迹，框架依次用语言模型判断其是否满足每个子问题的要求。验证过程采用相同模型进行局部二值或分级判断，而非对整体轨迹打分。这通过提示工程实现：为每个子问题构造专门的验证提示，要求模型输出“是/否”或相关程度。验证结果直接转化为该子问题的得分。

分数聚合与候选选择

每候选轨迹的所有子问题得分被聚合为一个标量（如求和或平均值），用于横向比较。系统最终选取聚合得分最高的轨迹作为输出。该过程天然产生可解释的验证痕迹：每个子问题的判定结果与证据片段均可回溯检查。

与同类方法的差异

与标准 test-time compute scaling 中基于模型置信度（score-based selection） 或简单多数投票的方法不同，FineVerify 通过结构化子问题分解将原本稀疏的全局选择转化为多个高密度的局部判断，摆脱了对模型校准度的依赖，并在显式准则下生成可审计的得分，显著提升稀疏正确答案下的选择鲁棒性。

实验

实验设计

FineVerify 在四个 agentic search 基准（含 BrowseComp-Plus）上评估，使用 GPT-5-mini 和 Gemini-3-flash 两个模型。对比基线为标准测试时计算缩放方法（如基于分数的轨迹选择）。设置采样轨迹数 N ∈ {4, 12}，验证方式为将问题分解为可检查的子问题，对每条候选轨迹进行细粒度验证并聚合分数。

关键发现

• 在仅 4 条采样轨迹下，FineVerify 带来显著提升：GPT-5-mini 平均准确率提高 +8.2 个点，Gemini-3-flash 提升 +5.6%（相对提升）。
• 将采样数增至 12 条后，GPT-5-mini 搭配 FineVerify 在 BrowseComp-Plus 上的准确率超越了前沿 GPT-5 模型。
• 验证过程产生可解释的痕迹，可用于审计基准错误，辅助理解模型决策。

与基线对比的深度解读

标准测试时计算缩放（如多数投票或自评分选择）高度依赖语言模型对自身答案的校准能力。当正确答案稀疏时，评分偏差容易导致次优候选被选中。FineVerify 的核心差异在于将全局选择问题转化为多个局部子问题判断：每个子问题按显式标准评分，聚合分数更可靠。这种结构化分解降低了对模型校准的依赖，使得在小样本量下即可获得鲁棒提升。在 BrowseComp-Plus 上超越 GPT-5 的结果表明，推理时的细粒度验证是实现弱模型超越强模型的有效路径，为 agentic search 系统的推理扩展提供了一种实用、可解释的方案。

行业影响

落地场景

FineVerify 的细粒度自验证机制可直接嵌入需要高可靠性信息检索的 agentic 系统：

• 企业级研究助手：处理跨文档、多源比较的复杂查询（如竞品分析、技术趋势综述），用少量轨迹即可提升答案质量，降低对超大模型的依赖。
• 电商搜索与客服 Agent：用户提问常涉及多商品参数对比、政策条款核实，FineVerify 可将问题分解为可逐一检查的子问题，在高候选集上自动筛选最一致的回答，减少人工介入。
• 金融与合规审查：对报告、法规进行多步验证，确保检索到的证据确能支持结论，审计可追溯。

商业价值

• 降本：用 GPT-5-mini 等中小型模型搭配 12 条采样轨迹即可超越 GPT-5 等级别模型的效果，将推理成本大幅压减；验证过程本身是 token 开销，但相比调用超大模型仍具显著成本优势。
• 增收与体验提升：在 BrowseComp-Plus 等高难度基准上的准确率提升（+8.2 点），意味着面向终端用户的高风险问答场景（如医疗信息辅助、法律咨询入口）中，一次就给出可信答案的概率上升，减少用户流失和差评。
• 可解释性溢价：验证轨迹天然可作为合规审计或用户信任背书的依据，对金融、医疗等受监管行业有直接商业转化价值。

与现有产品 / 工作流的接口

FineVerify 是一种与模型无关的选择-验证模块，可无缝集成进现有 agentic search stack：

• 在 RAG 管道末尾增加一个轻量的子问题分解与验证节点，从多路检索结果中筛选最佳答案，无需改动检索或生成组件。
• 与 LangChain / LlamaIndex 等框架结合，通过自定义 Selector + Verifier chain 实现，可直接替换现有的多数投票或困惑度选择策略。
• 生成的细粒度验证日志可回传至观测平台（如 LangSmith / Weights & Biases），用于持续校准检索质量与模型置信度。

具体用例

1. 跨境电商平台复杂问答：用户问“某品牌两款手机在成像、续航和售后政策上有何差异”，系统并行抓取多个产品页和评测，FineVerify 将问题拆为成像、续航、售后三个子问，逐项验证各候选摘要的支撑证据，最终输出证据最一致的回答，减少幻觉和遗漏。
2. 医学文献辅助审查：药企在生成药物警戒报告时，需从大量论文中提取不良反应数据。FineVerify 自动分解“发生率、人群特征、剂量关系”子问题，对多个提取候选打分聚合，确保最终纳入报告的数据有可靠出处，并可追溯验证痕迹供药监审查。

局限

• **子问题生成质量限制**：FineVerify 的效果强依赖于模型将原始问题分解为可验证子问题的能力。若分解不完整或语义偏移，后续细粒度验证的可信度会受损。论文未系统分析子问题生成错误对最终选择准确率的影响，也未对比不同分解策略（如人工编写 vs. 自动生成）的鲁棒性，这在实际部署中可能成为瓶颈。
• **计算开销与可扩展性**：验证阶段需对每条候选轨迹的每个子问题执行一次推理，计算量随候选数 `N` 和子问题数 `M` 线性增长（`O(N*M)`），而标准多数投票仅需 `O(N)`。论文实验上限为 12 条采样轨迹，更大规模的 test-time compute 场景（如 100+ 候选）下，该方法可能因延迟或成本过高而不适用，且未讨论如何通过缓存或并行优化来缓解。
• **模型与基准覆盖不足**：实验仅基于 GPT-5-mini 和 Gemini-3-flash 两个闭源 API 模型，且未在其他开源模型或不同规模模型上验证。此外，四个基准中仅 BrowseComp-Plus 明确聚焦复杂信息搜索，其余基准（如 Natural Questions）更偏事实问答，代理搜索的特征不够强。这限制了结论向一般化代理搜索系统（尤其是基于本地微调模型）的推广。