企业官网建设流程全解析

PostHog ReviewHog 验证器模型评估：Sonnet 5 @ xhigh 评分表深度解读——"全量保留"背后的 50% 精确率

【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog

导读

NB.score.md是 PostHog 开源仓库中 ReviewHog 自动代码评审产品（products/review_hog）在"验证器模型"评估实验2026-08-validator-model-sol中，Sonnet 5 验证器第二次运行（N2）的评分结果表。它以混淆矩阵和三项核心指标（精确率、召回率、非真实发现丢弃率）量化了 Sonnet 5 @ xhigh 在 22 条评审发现上的 keep/drop 表现：召回率 100%、但精确率仅 50%、非真实发现丢弃率 0%。读完本文，你将理解 ReviewHog 验证阶段的工作原理、这份评分表的生成方法论（ground truth 建立、逐簇匹配、反证优先核实），以及"验证器全量保留"为何是发布质量的失败模式，并掌握如何用仓库中的脚本复现这一评估。

一、这份评分表在评估什么：实验背景与文档定位

ReviewHog 的评审流水线中，验证器（validator）是发布前的最后一道质量闸门：评审器（reviewer）在沙箱中产出大量原始发现，去重后交给验证器逐条判断 keep / drop（是否真实、是否值得发布）。验证器把守的正是"发布到 PR 上的内容有多少是真实问题"这一精确率指标。

2026-08-validator-model-sol实验的核心问题是：能否用 OpenAI Codex 的gpt-5.6-sol以更低成本、更短时间替代 Claude Opus 作为验证模型，且不损失判定质量？实验沿用此前评审器模型实验（2026-07-reviewer-model-glm52）的冻结 PR、固定 chunk 与零评论洁净环境，并分为多个对照臂：

• L 臂：Opus 5 验证器 @ xhigh（生产固定配置）
• M 臂：Sol 验证器 @ xhigh / full-access
• N 臂：Sonnet 5 验证器 @ xhigh（Alex 的追加实验，即本文主角）
• P 臂：Sol 评审器 @ medium + Opus 5 验证器

NB.score.md正是 N 臂第二次运行（N2）的逐条评分表。它在仓库中的位置是 products/review_hog/eval/experiments/2026-08-validator-model-sol/findings/NB.score.md，与其配套的真实基准 NB.truth.json、簇匹配结果 NB.match.json 共同构成 N2 的完整评估记录。

二、评分表速览：混淆矩阵与三项核心指标

文档标题即实验配置："Sonnet 5 @ xhigh validator, Sol reviewer @ xhigh (N2): 22 scored, 0 unscored"——22 条发现全部完成评分，无一条无法判定。评分表给出如下混淆矩阵：

由此导出三项核心指标：

• kept-are-real（精确率）：11/22 =50%——Sonnet 5 保留的发现中，只有一半是真实问题；
• real-are-kept（召回率）：11/11 =100%——所有真实发现都被保留，没有漏网；
• not-real-dropped（非真实丢弃率）：0/11 =0%——11 条非真实发现一条都没被丢弃。

这三项指标分别刻画验证器的不同能力维度：精确率回答"我发布的东西可不可信"，召回率回答"我有没有漏掉真问题"，非真实丢弃率回答"我有没有把噪音挡在门外"。理想验证器应当同时做到高精确率 + 高召回率 + 高丢弃率；而 Sonnet 5 在 N2 的表现是"全盘照收"——召回率满分，但过滤能力为零。对比 FINAL_REPORT 的结论：Opus 5 在两个 L 臂运行中丢弃了 22 条非真实发现中的 16 条（82%/64%），Sonnet 5 则从 N1 的 3/11（27%）退化到 N2 的 0/11（0%）。

三、真实基准如何建立：76 个已知簇 + 反证优先核实

评分表的可信度取决于 ground truth 的建立方法。根据 PLAN.md 与 FINAL_REPORT.md，方法如下：

1. 簇匹配：实验针对冻结的 PR #75215（heada7fb363b，tree 与评审器实验一致），仓库维护了一个 76 个已知问题的注册表 known_clusters.json（源自七月评审器实验的 judge 文件）。每条新发现先由脚本（scripts/build_truth.py、scripts/score_validator.py）匹配到已知簇；
2. 一致簇直接复用：落在意见一致簇（unanimous cluster）中的发现直接采用注册表判定；
3. 混合簇与新声明反证优先核实：簇内意见不一或未匹配到簇的新声明，逐条在冻结的工作树（frozen worktree）上做"反证优先"（refutation-first）的人工核实，产物存放在 findings/verify/；完全相同的声明直接复用既有判定。

在 NB.truth.json 中可以看到每条发现的source字段：如 NB6/NB13 标注verified (high)（本次新核实）、NB2 标注cluster 1/1 (KA2/LA14 same claim)（一致簇复用）、NB15 标注verified-same-claim:LA6（相同声明复用）。这种"注册表 + 定向核实"的分层策略，保证了评分表既能复用历史判定、又对新增声明保持严格审查。

四、N2 运行实录：成本、耗时与 effort 配置

根据 PLAN.md 的运行日志，N2 于 2026-08-26 上午 09:33:30–10:30:38 本地时间执行（总耗时 3414 秒），实验环境携带 effort 修复补丁与重试加固（stream_max_retries=10、300 秒流空闲超时），沙箱并发数从 10 降至 4：

$ai_effort由网关从请求的reasoning.effort中读取，是确认 effort 是否真正到达模型的唯一证据。N2 中评审与验证调用均确认 xhigh——这与 K1–K3 运行中"所有gpt-5.6-sol调用都只有 low effort"形成对照（后者是本次实验发现的重大基础设施问题，详见 FINAL_REPORT.md "The effort pin never reached Codex" 一节）。

验证器模型与 effort 在代码中的生产固定配置位于 products/review_hog/backend/reviewer/constants.py：VALIDATION_RUNTIME_ADAPTER = RuntimeAdapter.CLAUDE、VALIDATION_MODEL = "claude-opus-5"、VALIDATION_REASONING_EFFORT = ReasoningEffort.XHIGH——即实验的 L 臂（生产对照组）。N 臂实验期间将其改为claude / claude-sonnet-5 / xhigh，实验结束后已恢复生产固定配置。

五、22 条发现逐条解读

评分表逐条列出了 N2 的 22 条发现（NB1–NB22），格式为keep/drop、ground truth（REAL/not）、真实严重度（sev=）与验证器给出的优先级（prio=）。全部 22 条均被 Sonnet 5保留。以下结合 NB.truth.json 与 NB.match.json 的簇归属整理。

5.1 保留的 11 条真实发现（REAL，召回率 100%）

这 11 条中，NB9 与 NB21 是此前 18 次评审从未报告过的新真实问题（reviewer_side.md 中 NB 集合标注new real ['NB9', 'NB21']）。NB9 对应的must_fix漏洞（webhook 豁免路径用调用方可写的任务输出字段作为来源证明，find_signal_implementation_run将find_task_run对可写output.pr_url的匹配当作"该运行产生了该 PR"的证据）在 L/M 臂中以 LA15/MA9/MB17 反复出现，是本次实验中验证器应当保住的最关键发现之一。召回率 100% 意味着这些真实问题在 N2 中一条未丢——这是 Sonnet 5 在 N2 唯一的正面表现。

值得注意的细节：验证器给出的优先级（prio=）普遍高于真实严重度（sev=）——如 NB11、NB18、NB20、NB21 均被 Sonnet 5 从should_fix/consider上调为must_fix。这与 FINAL_REPORT.md 中"评审器自身优先级虚高、验证器的优先级覆盖在 xhigh 下更为关键"的判断一致（代码中优先级覆盖遵循 validator-wins，见 constants.py 的effective_priority）。

5.2 被保留的 11 条非真实发现（not real，丢弃率 0%）

这 11 条非真实发现覆盖三类反复出现的"幽灵簇"外加当日新核实反驳的声明（NB1、NB7、NB13、NB19）——与 FINAL_REPORT.md 对 Sonnet 5 的概括完全一致：它保留了 Sol 会保留的同一批弱声明（broker/retry 加固、无范围find_task_run查找、排队时 toggle 信任），外加当天早上新被反驳的声明。特别值得注意的是 NB1 与 NB13：Sonnet 5 不仅保留了它们，还给 NB1 赋了must_fix优先级——对一个已被逐条核实反驳的声明给出最高优先级，是"高召回伪装下的低判别力"的典型体现。

5.3 三条"幽灵簇"：为什么这些弱声明反复存活

结合 NB.match.json 与 FINAL_REPORT.md，非真实发现高度集中在三个已知簇：

• 簇 58（broker/retry 加固请求）：NB4、NB5、NB15、NB16。这类声明要求为"初始评审投递"增加持久化记录、延迟确认、重试耗尽对账等机制。其被判定为不真实的原因是：它们拷贝了既有 webhook 路径的刻意设计（投递失败由后续重发覆盖），且缺乏可复现的故障链；
• 簇 39（无范围find_task_run查找）：NB12。声称"团队过滤发生在选中候选行之后、可能遮蔽合格运行"。被反驳的依据是：查找本身已按仓库限定作用域，"其他团队 → None"的契约有测试覆盖（test_branch_targets.py等）；
• 簇 31（排队时 toggle 信任）：NB22。声称"延迟初始任务不复查评审者 opt-out"。该声明在七月已被反驳六次（KA1/KB10 先例），process_inbox_pr_review对队列时刻acting_user_id的读取有意的行为已属既有设计。

这三簇在 L/M/N 各臂中几乎逐条重现（如 NB4/NB5/NB15/NB16 对应 Sol 的 MA14/MA15/MB3/MB9/MB10），说明这不是运行噪音，而是模型在特定声明形态上的稳定判别缺陷——无论给 Sol 还是 Sonnet 5 增加推理 effort，其判别门槛都不会因此提高。

六、横向对比：Opus 5 / Sol / Sonnet 5 的六臂分数

findings/xhigh_summary.md 汇总了八次运行的完整评分。以下摘取与验证器质量直接相关的关键行：

读数非常清晰：

1. Opus 5 是唯一兼顾精确率与丢弃率的验证器：保留的发现 67–82% 是真实的，同时能丢弃 64–82% 的非真实发现。它也有漏判（丢弃了 LA8/LA17/LA21/LB10/LB13/LB17 六条真实发现，含一条must_fix），但整体平衡最好；
2. Sol 与 Sonnet 5 是同一种失败模式：召回率极高（92–100%），但丢弃率极低（0–27%），发布内容约三分之一到一半不是真实问题；
3. 成本优势被质量劣势抵消：Sonnet 5 每条判定仅 $0.48–0.53（约为 Opus 的一半），但对一个"几乎什么都不删"的验证器来说，省下的钱换来的是发布噪音；
4. 盲评（写作文本质量）同样偏向后两者：argumentation_judge_N_vs_L.json 中 Opus 赢得 29 对中的 20 对、Sonnet 仅 2 对、7 平；Sonnet 的写作文本中位 290 词、平均句长 33 词，且在单次运行内自相矛盾（NA1 与 NA8/NA13 冲突、NA5/NA22 与 NA7/NA10/NA11 冲突）。

从 N1 到 N2 还有一个值得警惕的趋势：Sonnet 5 的丢弃率从 27% 进一步降到 0%，N1 中它尚且丢弃了 NA5（any-bot carve-out，must_fix）、NA22（engine-flag 绑定，must_fix）等真实发现，N2 则一条不丢——验证器在"宁可全留"的方向上更加极端。

七、结论：验证器的严格性决定发布质量

FINAL_REPORT.md 基于全部运行给出的最终建议是：继续使用 Opus 作为验证器。理由是 Sol 在真实 xhigh 下仍保留 19–20 条中的 18 条、几乎不丢弃非真实发现，成本优势缩水到每条判定约 30%；而 Sonnet 5 只是同一故事的一半价格版本。这是基于数据而非偏好的结论——结合 constants.py 的VALIDATION_*固定配置（Claude /claude-opus-5/ xhigh）可以看到，生产默认正是实验验证出的最优组合。

实验还给出了两个有复用价值的工程结论：

1. 评审器与验证器应当分离考虑：同一模型（Sol）作为评审器在 xhigh 下表现优异（每轮真实发现 11–13 条，是 low 的三倍，还发现了 8 条此前 18 次评审都没报告过的真实问题），但作为验证器却无法胜任。评审需要发散探索，验证需要严格证伪，两者对模型特性的要求不同；
2. 验证器优先级覆盖（validator-wins）在严格模式下更有价值：评审器产出的must_fix标签普遍虚高，验证器对严重度的修正（effective_priority）直接决定哪些发现能通过发布阈值（published_priorities_for）。一个"全保留"的验证器会让这条修正通路失效。

八、复现与延伸阅读

如需复现此类验证器评估，实验的运行配方记录在 PLAN.md 中：

flox activate -- bash -c "DJANGO_SETTINGS_MODULE=posthog.settings python manage.py \ run_review --pr-url <github_pr_url> --team-id 1 --user-id 1"

配合 scripts/harness/ 下的运行脚本、scripts/score_validator.py 评分脚本，以及 scripts/build_truth.py 的真实基准构建脚本。评估的评分协议（混淆矩阵与三项指标的定义）可直接复用。

与本文相关的关键仓库文件：

• 评分表本体：findings/NB.score.md、findings/NA.score.md
• 真实基准与簇匹配：findings/NB.truth.json、findings/NB.match.json、known_clusters.json
• 汇总报告：FINAL_REPORT.md、findings/xhigh_summary.md、findings/reviewer_side.md
• 验证器在流水线中的位置：ARCHITECTURE.md（第 8 步 Validate）、issue_validation/prompt.jinja（keep/drop 判定提示词，通过 MCP 拉取团队拥有的 review-hog-validation-criteria 技能作为判别标准）
• 验证模型配置：backend/reviewer/constants.py

综上，NB.score.md 不仅是单次运行的成绩单，更是 ReviewHog"宽进严出"评审漏斗中验证环节质量的可量化证据：精确率 50%、丢弃率 0% 意味着验证器实际上把发布闸门完全交给了评审器。这也是该实验将验证器与评审器模型分开评估、并最终坚持 Opus 验证器的根本原因。

【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog