背景
先说,DeepGraph 整体设计—— 闭环 discovery、SQL signal_harvester 零成本跑信号、meta_learner 从历史自我调整、venue routing 这套都很扎实,而且 evidence_gate、claim_grounding、result_interpreter、require_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 … figure、No in-image title) |
| c |
跨 run 身份串台 |
正文出现非本题的方法名 / 概念(与锁定 topic 不符) |
| d |
模板 boilerplate 重复 |
同一句出现 ≥ 3 次 |
- 收益: 最便宜,当周可上;自动拦住绝大多数"一眼假"产出;
require_submission_ready() 名副其实;CI 自动化,不靠人工 review。
- 代价: 几乎没有,纯确定性检查,误杀率极低。
- 权衡: 近乎全是收益 —— 所以哪怕 1、2 还要讨论,这条可以先合。
建议落地顺序
3 先做(减少明确的浪费)→ 2 → 1(根治)。
当然你们更懂自己的 codebase,顺序和取舍你们定。
Checklist
背景
先说,DeepGraph 整体设计—— 闭环 discovery、SQL
signal_harvester零成本跑信号、meta_learner从历史自我调整、venue routing 这套都很扎实,而且evidence_gate、claim_grounding、result_interpreter、require_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 的题?建议 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、禁止出稿:?、Table ??、Figure ??等未渲染占位Create a … figure、No in-image title)require_submission_ready()名副其实;CI 自动化,不靠人工 review。建议落地顺序
3 先做(减少明确的浪费)→ 2 → 1(根治)。
当然你们更懂自己的 codebase,顺序和取舍你们定。
Checklist
manuscript_generation重构边界require_submission_ready()行为:检测到合成 / 未解析 / 串台内容时硬 fail,而非告警