跳到主内容Deep Research 评估为什么不能只看最终答案，过程合理又该怎么量？ · AlgoMooc边界意识检查推断、建议、冲突与证据不足是否明确标注。
可读性不能抵消事实错误。高风险事实、虚构引用和越权等适合设硬门，而不是只做加权项。
过程质量应该拆成哪些维度？
工具选择检查当前状态是否真的需要 Search、Visit、calculator 或直接完成。
证据增益检查每一步是否新增有效信息、排除候选或解决冲突。
来源策略检查是否进入原文、是否识别同源转载、是否处理版本与时效。
恢复能力检查超时、空结果和权限失败后是否重试、换源或降级，而不是伪造 observation。
停止质量检查证据足够后是否结束，证据不足时是否继续或明确部分完成。
效率检查动作、token、延迟和成本，但只有在结果质量过门后才比较。
过程指标要来自真实 Trace，不从最终报告反推模型“应该做过什么”。
先有任务 Contract，评估才有意义
用户只问稳定概念，直接回答合理；用户要求最新官方出处，就必须外部检索。
任务 contract 至少包含对象、时间范围、交付、来源要求、允许工具、风险级别和预算。
开放设计题还要写明评价标准，例如约束覆盖、取舍与风险，不要求唯一结论。
无答案题要定义允许搜索的来源与范围，否则无法判断是合理拒答还是搜索失败。
评估器读取 contract 后再检查结果与过程，不能用一套固定 rubric 机械评价所有任务。
主张与证据怎样对齐？
每条事实主张绑定一个或多个 evidence ID，定位到 observation 中的具体来源与片段。
评估器检查来源存在、时间适用、片段语义和主张强度是否匹配。
页面说“支持某功能”，不能推出“在所有条件下性能最好”；搜索摘要也不能替代原文限制。
计算主张要保留输入证据和方法。建议可以没有直接来源，但支撑它的事实与约束必须可追溯。
若答案没有主张级映射，引用质量只能靠 Judge 猜，准确性和可复现性都会下降。
步骤与信息缺口怎样对齐？
在每个 action 前，状态应表示当前已知、未知和下一步目标。
Action 之后，observation 是否填补了目标缺口，状态是否发生变化。
重复搜索近义词却没有新增证据，步骤数增加但过程质量下降。
遇到来源冲突后再查官方资料，即使步骤更多，也可能是必要成本。
可以为每步记录 purpose、result status、evidence delta 与 next decision。purpose 不需要暴露私有思维，只要是可审计任务标签。
这让评估器能判断动作是否推进，而不是按轨迹长度猜勤奋程度。
从任务 contract 到主张证据和步骤缺口，最后再汇总与归因。
哪些用规则，哪些用 LLM Judge？
格式合法、JSON、引用 ID、URL 可达、计算复算、重复调用和工具状态适合规则。
开放问题的覆盖、取舍、结构和解释质量更适合 rubric 加 LLM Judge。
高风险事实、争议结论与 Judge 分歧需要人工复核。
规则先处理确定性硬门，减少 Judge 负担；Judge 对剩余维度输出结构化分数与证据；人工抽查校准偏差和更新 rubric。
Judge 不能看到不该使用的参考答案或隐藏标签，否则会产生泄漏。
评估结果保存 evaluator、Prompt、rubric 和规则版本，确保每版可以重算。
多维分数应该怎样汇总？
虚构关键事实、引用不存在、权限越界和任务完全未完成可以直接判不通过。
总分用于排序和看趋势，但诊断必须保留各维度。若只保存加权总分，引用退化可能被可读性提升抵消。
权重来自任务风险，不是教程中的教学数字。不同任务族可以有不同配置。
评分前还要定义每档锚点和例子，减少 Judge 和人工理解差异。
权重或 rubric 更新后，历史结果标记版本，必要时对固定样本重算，不能直接拼接两套分数。
开放答案没有唯一标准，怎么评？
先检查任务约束是否覆盖，再检查支撑事实、比较口径、取舍逻辑、风险和未决问题。
两份答案可以给出不同建议，只要都基于证据并适配不同假设。
参考答案更适合作为可能要点与证据示例，不应变成必须复述的固定文本。
Pairwise 比较可以帮助判断两版谁更好，但要打乱位置、控制长度和处理 Judge 自我偏好。
对于重要任务，保留人工可接受答案集合与失败锚点，定期校准 Judge。
多次运行为什么必须保留分布？
一次答对不能证明稳定，一次工具超时也不一定代表策略退化。
同一问题可运行多次，保存成功、部分、失败、质量维度、步骤与成本分布。
比较模型版本时使用相同时间窗、工具与环境，或者对环境错误单独剔除并报告。
Pass@k 关注多次尝试中是否至少一次成功，但不适合单独代表用户一次运行体验。
平均分也会掩盖长尾。应同时观察中位、低分位、失败类型和跨运行一致性。
材料提出多次运行取平均，工程上还应保存原始样本结果，不能只留平均数。
固定基准与真实任务怎样结合？
SimpleQA、HotpotQA 可以用于简单验证，GAIA、FRAMES、BrowseComp 和 HLE 等基准覆盖不同难度与能力。
公共基准便于横向比较，但未必代表自己的工具、权限和业务任务。
还需要私有或内部评测集，覆盖真实问题类型、来源限制、异常和风险边界。
问题族、共享证据和改写应放在同一切分，避免训练测试泄漏。
公开基准名称来自材料，正文不声称现有项目已经取得任何分数。
过程指标为什么也会被刷？
奖励交叉验证，模型可能访问多个转载同一原文的页面。
因此过程指标要验证语义：引用是否支持主张，步骤是否新增证据，来源是否独立，停止是否满足 contract。
指标一旦进入训练 reward，就要用对抗样本和人工抽检检查 Goodhart 风险。
过程评估的目标是解释可靠性，不是制造一套容易迎合的仪式。
环境失败怎样从模型能力中分离？
Search 超时、网页变更、权限限制和解析器故障会影响结果。
Trace 记录工具请求、状态、重试、版本和 observation。评估器先判断环境是否提供了合理完成条件。
若环境故障，单独标记，不把它直接当模型事实错误；同时评估模型是否正确恢复或降级。
模型利用不存在的工具结果仍然是错误，即使环境先失败。
比较版本时环境失败率也要报告。某模型调用更多工具，暴露在环境故障中的机会不同。
可重放模拟环境适合策略对比，真实环境用来验证迁移与工具变化。两类结果不能混为一个分数。
怎样从评估结果定位到具体修复？
例如动态比较题的引用准确低，继续下钻到 Search、Visit、时间范围和证据映射。
若格式错误，修模板、数据角色或解析器；若工具选择错，补成对边界数据；若来源冲突处理弱，补对应轨迹与评测；若环境失败多，修工具服务。
每个失败关联 task Trace、问题族、模型、Prompt、工具、数据和 evaluator 版本。
修复后加入回归集，并在独立问题族复测。不能把同一失败样本同时补进训练和测试。
按问题类型和质量维度下钻，才能知道该修数据、模型、工具还是评估器。
一条评估记录至少要保存什么？
任务侧保存 eval case ID、问题族、contract、参考证据与风险级别。
运行侧保存 run ID、模型、Prompt、工具、环境、采样、预算和时间。
结果侧保存最终答案、原子主张、evidence ID 与各维度分数。
过程侧保存步骤、工具状态、evidence delta、重试、停止原因和成本。
评估侧保存规则、rubric、Judge、评判 Prompt、人工复核和版本。
若做 A/B 比较，还要保存候选展示顺序与是否交换位置。
每个分数附带理由和引用到被评对象的具体位置。只有“引用准确 4 分”却没有证据，后续无法复核。
这些字段让评估可以断点续跑、重新计算和审计。版本变更时也能判断是模型变化还是尺子变化。
Pointwise 与 Pairwise 怎样选择？
Pointwise 让评估器按 rubric 独立评价一份结果，适合保存绝对维度和发布门槛。
Pairwise 让 Judge 比较 A 与 B，往往更容易回答“哪一个更好”，适合版本对比。
Pairwise 有位置偏好，应交换 A/B 顺序重复判断，并记录分歧。
它也容易受长度影响。更长答案可能看起来覆盖更多，因此 rubric 要明确相关性、简洁与证据，不奖励灌水。
两种方法可以结合：先用 pointwise 硬门排除事实和引用错误，再用 pairwise 比较通过样本的覆盖、结构与效率。
若两版都不合格，pairwise 选出的“更好”也不能解释成可以上线。相对胜出与绝对达标是两件事。
部分完成怎样评价？
长任务可能在预算或工具限制下只完成部分 contract。
评估时先确认系统是否明确标注完成范围、未决问题与失败原因。
已经交付的主张仍需通过事实与引用硬门，不能因为是部分结果降低真实性要求。
覆盖分按实际完成的子任务计算，同时保留总体 contract 完成度。
如果任务本来允许分阶段交付，部分完成可以是合法状态；如果模型只是遇到困难就缩小范围，则过程和完成度都要扣分。
部分完成不能与完整成功混在同一成功率里，也不能与彻底失败完全等同。
这类标签还能帮助服务团队区分预算设计、工具环境和模型策略问题。
评估怎样进入发布门禁？
代码或模型候选先跑小型快速回归，检查格式、关键事实、工具协议和已知事故样本。
通过后运行完整结果与过程评估，包括多次采样、真实或可重放工具环境和人工抽查。
门禁应同时包含绝对硬门与相对回归。关键事实错误不能因为平均分上升而通过，已有稳定能力也不能大面积退化。
动态来源失败与基础设施异常单独报告，不能悄悄从分母移除。
候选通过离线门后再做受控流量验证，继续观察任务、证据、失败和用户反馈。
发布记录绑定模型、Prompt、工具、环境和 evaluator 版本。出现事故时能回到当时完整组合，而不只回滚模型权重。
本文提供门禁设计，不声称现有系统已经达到某个通过率或自动发布效率。
人工抽检应该抽哪些样本？
随机样本用于估计日常整体情况，但仅随机可能漏掉高风险长尾。
还应抽取分数提升最大、Judge 分歧、引用冲突、无答案、部分完成、工具异常、成本异常和新问题族。
对高风险事实与安全任务提高人工比例，低风险稳定格式可以更多依赖规则。
人工评审者看到明确 contract、rubric、答案、证据与 Trace，不需要猜模型私有思维。
多人标注分歧不是简单取多数。先区分 rubric 含糊、证据变化和真实价值判断，再更新锚点。
人工结果用于校准 Judge 和规则，但不能把新标注者与旧版本分数直接混合。评审指南、培训与一致性同样需要版本化。
怎样写一份能推动修复的评估报告？
首页给出版本、数据范围、环境状态和硬门结论，不先堆一个总分。
第二部分展示结果与过程维度分布、问题类型矩阵和多次运行稳定性。
第三部分列出环境错误、Judge 分歧、数据泄漏检查和未评范围。
第四部分给出 Top 失败类型，每类附代表样本、Trace 与可能归因。
第五部分提出下一轮动作：补哪类数据、修哪个工具、改哪条规则，以及对应回归题。
所有结论区分事实、推断和待验证假设。比如“Visit 超时与低覆盖同时出现”是观察，“修复 Visit 就会提高覆盖”仍是假设。
一份好报告让负责人知道下一步做什么，也让审查者知道哪些结论还没有证据。
一次可执行的评估发布流程
冻结任务集、contract、工具环境、rubric、规则和 Judge 版本。
运行模型并保存完整 task Trace，不只保存最终答案。
先跑规则硬门，再跑结果和过程 Judge，分歧与高风险样本进入人工复核。
生成维度分布、失败类型、环境错误、多次运行稳定性和成本报告。
对比基线时做 paired 分析，保存每道题的变化，不只看平均总分。
抽查分数提升最大的样本，排除更长、堆引用或评估泄漏造成的假进步。
评估产物版本化并可断点续跑，失败样本进入修复队列，修复后新建回归版本。
材料提供评估维度与流程方向，没有现有生产评测收益或通过率，正文不作此类声明。
面试官继续追问，怎么接？
追问一：最终答案正确为什么还要看过程？
它可能靠记忆或运气答对。过程能证明工具、证据和恢复策略是否可复现。
追问二：过程合理但答案错误，算成功吗？
不算完整成功。保留过程合格、结果失败的分层标签，用于定位计算、覆盖或综合问题。
追问三：步骤越少是不是过程越好？
不是。效率只在任务质量过门后比较，必要核验不能为了少步骤被删除。
追问四：开放任务没有标准答案怎么打分？
按约束、事实证据、覆盖、取舍、风险和边界评估，允许多个合理结论，不做固定文本匹配。
追问五：你们评估后提升了多少？
材料没有可核验生产评测结果。应展示评估设计、版本和样本证据，不能虚构收益。
从结果到过程，完整回答这样组织
Deep Research 要同时评结果和过程。结果层看任务完成、主张正确、引用支持、覆盖、边界和可读性；过程层看工具选择、参数、证据增益、冲突处理、恢复、重复和停止。高风险事实与权限设硬门，其他维度结构化打分，保留分项而不是只留总分。
评估从任务 contract 出发，把答案拆成主张并绑定 evidence ID，把每个步骤绑定当前信息缺口和 evidence delta。规则检查格式、引用与计算，LLM Judge 处理开放 rubric，人工抽检校准。多次运行保留分布，环境失败单独标记，固定基准与真实任务集共同使用。
最后按问题类型乘质量维度定位缺口，并关联 task Trace 判断该修数据、模型、工具还是评估器。指标也会被刷，所以引用数、步骤数和调用数都不能直接当质量。相关材料给出评估框架、基准和流程，没有现有生产通过率或收益，不能编造提升数字。
评估体系落地前的证据清单
选一条评测失败样本，从最终主张倒查到过程 Trace，确认这套指标真的能指向可修复的问题。
- 是否从任务 contract 分别定义结果与过程质量？
- 是否把答案主张绑定证据，把步骤绑定信息缺口？
- 是否用硬门防止可读性和效率抵消事实错误？
- 是否记录规则、Judge、rubric、工具与环境版本？
- 是否保留多次运行、环境失败和分项结果，而不只留平均总分？
- 是否明确没有虚构现有生产评测收益、通过率或基准分数？
