Skip to content

下一个改进方向的建议:严格产出完整性 —— 可验证性准入 + 结果绑定 + 提交硬校验 #21

@Protocol-zero-0

Description

@Protocol-zero-0

背景

先说,DeepGraph 整体设计—— 闭环 discovery、SQL signal_harvester 零成本跑信号、meta_learner 从历史自我调整、venue routing 这套都很扎实,而且 evidence_gateclaim_groundingresult_interpreterrequire_submission_ready() 这些 grounding / gate 模块该有的都有。框架是有潜力的。

读了代码、也看了几篇产出之后,有一个观察想和你们商量。

观察

这些门目前像是 "建好了但没真正实质闭环" —— 产出里偶尔出现合成数字、未解析引用(? / Table ??)、自相矛盾的正文,而这些本应被 require_submission_ready() 拦住(README 里写的是 "synthetic data never reaches a manuscript bundle")。

下面三条是我的建议(供讨论,不是结论),每条把收益和代价都列出来,方便你们权衡。


建议 1 | 选题层加"可验证性准入"

观察: paper_idea_agent / idea_route 目前似乎不区分"结果能否机器判定"。

提议: 是否可以考虑 —— 每个 idea 必须自带一个可执行 verifier(solver / exact-match / 可复算 ground-truth),evidence_gate 在立项处直接拒掉没有 verifier 的题?

  • 收益: 从源头消灭幻觉结果。生成层有了硬锚就编不动;每篇产出自带可复现验证,系统可信度上一个台阶,reviewer 和用户的信任才建立得起来。
  • 代价: 选题空间收窄,一部分宏大但暂时无法验证的方向得先放。
  • 权衡: 短期少做题,长期每篇都立得住。这条最深,也最需要你们自己拍板,所以放第一个一起讨论。

建议 2 | 结果强绑定稿件,写作层从"作者"变"播报员"

观察: real_experiment_runner / result_interpreter 都在,但稿件里出现过账本里不存在的数字(例如标题数字全文找不到、abstract 与表格对不上)。

提议: manuscript_generation 是否只允许引用 run artifact 的字段、任何数字都可回溯账本,并让 result_interpreter 的 verdict(refuted / supported)强制约束 abstract / conclusion 的措辞?

  • 收益: 数字永远自洽可回溯,"标题数字全文找不到"这类硬伤彻底消失;稿件可信度 = 实验可信度,没有写作层的额外失真;出问题也好定位。
  • 代价: manuscript_generation 要从"写数"重构成"取数",前期有中等改动量。
  • 权衡: 一次性改造,换长期免去无穷的事后核对。

建议 3 | 把 require_submission_ready() 变成真 block,补四个确定性检查

最便宜、当周可上,建议先做。

观察: format_linter 具名检查偏排版(字体、间距、引用密度),没覆盖真正出事的点。

提议: 加四个硬检查,任一命中即 fail、禁止出稿:

# 检查 命中条件
a 未解析引用 正文 / 参考出现 ?Table ??Figure ?? 等未渲染占位
b 生图脚手架泄漏 caption 含生图指令原文(如 Create a … figureNo in-image title
c 跨 run 身份串台 正文出现非本题的方法名 / 概念(与锁定 topic 不符)
d 模板 boilerplate 重复 同一句出现 ≥ 3 次
  • 收益: 最便宜,当周可上;自动拦住绝大多数"一眼假"产出;require_submission_ready() 名副其实;CI 自动化,不靠人工 review。
  • 代价: 几乎没有,纯确定性检查,误杀率极低。
  • 权衡: 近乎全是收益 —— 所以哪怕 1、2 还要讨论,这条可以先合。

建议落地顺序

3 先做(减少明确的浪费)→ 2 → 1(根治)。

当然你们更懂自己的 codebase,顺序和取舍你们定。

Checklist

  • 建议 1(可验证性准入)方向是否认可,一起讨论选题空间的取舍
  • 建议 2(结果绑定)改造范围,确认 manuscript_generation 重构边界
  • 建议 3 的四个确定性检查 —— 是否接受 PR
  • 确认 require_submission_ready() 行为:检测到合成 / 未解析 / 串台内容时硬 fail,而非告警

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions