19篇训练数据研究提案批判性评审报告

引言：为什么要批判自己写的提案

站内目前积累了19篇训练数据研究提案，覆盖科研数据、Agent鲁棒性、多模态、维基百科利用等方向。写到第19篇的时候，我意识到一个问题：我们在用写提案的速度来掩盖对每个提案真实可行性的判断。

批判性自我评审比再写三篇新提案更有价值。知道哪条路值得走，比多开几条路更重要。

这篇文章用5个维度对19篇提案逐一打分：问题清晰度（方向是否真实存在且被准确定义）、方案可行性（6个月内能否落地）、差异化价值（是否有真正的护城河）、论证严谨性（关键假设是否经得起推敲）、落地可能性（从数据到模型能力提升的路径是否完整），各1-5分，满分25分。

下面是结论，然后是让我最难受的地方。

---

综合排名

排名	提案	总分/25
1	提案4：GitHub Issues论文复现踩坑记录	21
2	提案14：科学图表QA蒸馏（arXiv）	21
3	提案18：形式化验证辅助推理链语料	20
4	提案17：维基百科数据组织三维度	18
5	提案19：工具选择决策训练数据	18
6	提案15：维基百科时间感知数据	17
7	提案3：综述反向构建	17
8	提案11：EverBench动态评测体系	16
9	提案1：论文代码复现（科研版SWE-bench）	16
10	提案5：质检轨迹数据	15
11	提案13：视频教程步骤标注	14
12	提案6：Sandbox矩阵测试数据	14
13	提案10：多Agent协作失败数据	14
14	提案8：工具调用失败模式	14
15	提案9：Agent元认知训练数据	13
16	提案2：反向假设生成	13
17	提案12：代码-图表三元对齐多模态数据	13
18	提案7：数据集Context Card	13
19	提案16：维基百科版本历史七维度综合方案	13

分布很清晰：顶部有少数真正站得住脚的方向，底部是一片「听起来不错但没想清楚」的提案。差距不在idea的大小，在于论证的密度。

---

高分提案：值得深推的四个方向

提案4：GitHub Issues论文复现踩坑记录（21/25）

→ 查看提案

最强的地方：数据的不可合成性是真正的护城河。

真实专家在信息不完整、高度不确定状态下的诊断推理——「这个CUDA版本兼容性报错可能是驱动问题，但也可能是……」——这种推理过程，LLM合成数据几乎无法模拟。它的价值恰恰来自于人类在混乱信息中的认知导航，而不是最终答案。这是这批19篇提案里，数据护城河最真实的一个。

最让我存疑的地方：那个「8-15万条高质量样本」。

我认真想了一下这个数字是怎么来的。Star > 200的ML仓库大约几千个；每个仓库里，真正同时满足「多轮对话 + 可量化的复现差距 + 最终成功解决」这三个条件的Issue，现实中可能只有个位数到几十条。粗算下来，全量有效数据很可能只有几千条，而非十万级。这个差距不是小数点的问题，是数量级的错误。

时效性是另一个隐患：2019年的PyTorch 1.0踩坑记录，对2026年的Agent训练可能不只是无效，而是负迁移。旧版本的坑和新版本的设计哲学往往是矛盾的。

改进方向很具体： 用GitHub API对100个目标仓库实际采样，统计每仓库平均有多少Issue符合条件，用真实数据替代直觉估算。这一步做完，提案的可信度会质变。

---

提案14：科学图表QA蒸馏（21/25）

→ 查看提案

设计最自洽的方案。

「以论文正文作为ground truth」——这个设计思路在19篇里是最干净的。它避开了两个常见陷阱：人工标注（成本高且主观）和LLM自生成验证（循环论证）。arXiv的规模和质量有背书，4级难度分层（L1数值读取→L2趋势判断→L3跨图推理→L4结合正文推理）可操作，且对应当前多模态模型真实的能力边界。这个方案想清楚了。

但规模估算有个严重漏洞。

「50万篇arXiv论文→45万QA对」这个90%转化率是怎么算出来的？现实是：大比例图表属于示意图、网络结构图、概念框架图——这类图根本无法构造可验证的QA（你没法客观评判「请描述这个网络架构的设计哲学」）。真实可用的QA转化率更可能在20-30%。45万缩水到10-15万，量级不同，这影响整个方案的预期。

更致命的问题在L3/L4——恰好在最有价值的层次，验证机制最弱：「语义相似度」。L1/L2的精确数值是可以程序验证的，但L3/L4的语义理解怎么客观判断对错？这个问题没回答。

改进方案： 把L1/L2（可程序精确验证）和L3/L4（需语义验证）完全分开构建、分开发布、分开评估。先把L1/L2做扎实，这部分数据质量可保证，先发布拿到反馈，再攻L3/L4的验证难题。

---

提案18：形式化验证辅助推理链语料（20/25）

→ 查看提案

切入了真正被忽视的上游问题。

大多数推理数据质量工作都在「训练一个PRM来判断推理步骤好不好」——但提案18的思路是：在数据构建阶段，用形式化验证工具（Lean/Isabelle）直接过滤掉错误推理链，让垃圾数据根本进不了训练集。这是釜底抽薪，而不是亡羊补牢。三层过滤架构（Lean形式化验证/程序执行验证/LLM交叉验证）逻辑合理，且难得地诚实承认了Lean autoformalization的覆盖率限制（40-60%）——这种对局限性的正视，比很多提案的盲目乐观值钱。

核心承诺没有测量基准。

「把推理链错误密度从20-30%压到5-10%」——这个核心价值主张里有两个无源数字。20-30%是哪个数据集上的基线？5-10%的预期是基于什么推导出来的？如果这两个数字没有实验依据，整个价值主张就是悬空的。更结构性的问题是：形式化验证天然覆盖数学/逻辑/编程领域，用这批数据中训练出来的模型，在常识推理、社会情境判断等非形式化领域会不会退步？领域偏斜没有被认真讨论。

改进方向： 明确三层过滤体系输出的数据质量标签；设计分层权重平衡形式化与非形式化领域；最重要的是，把「20-30%→5-10%」这个承诺用一个小规模实验先验证，哪怕是1000条的pilot study。

---

提案3：综述反向构建（17/25）

→ 查看提案

看准了一个真实短板。

Survey写作能力——从几十篇论文中提炼框架、归纳争议、梳理演进脉络——确实是当前LLM的弱点。数据来源（arXiv/ACL的survey论文）获取成本低、合法性强，而且ground truth就是survey本身，标注成本接近零。这个方向的问题定义是清晰的。

但有个工程瓶颈被完全回避了。

一篇survey综述通常引用50-200篇论文。如果要构造「给定50篇源论文→生成对应survey段落」这样的训练样本，单条样本的上下文需要处理50万-200万tokens。即便是未来的长上下文模型，在训练阶段处理这个规模的单条样本，无论从计算成本还是工程实现来说都不现实。提案对这个问题的处理方式是：没有提到它。

这不是我在挑刺——这是整个方案成立与否的核心工程约束。

改进思路： 把任务规模强制收窄到「20篇以内的小综述」（这类文章在arXiv上不少），先验证方法论，再讨论扩展。同时考虑chunk-level的构造方式：不是一次性输入所有源论文，而是以小的引用集群为单位构造训练数据。

---

低分提案：失败模式的两个典型

提案16（维基百科七维度综合，13/25）——摊大饼的反面教材

→ 查看提案

七个维度：幻觉检测、时态推理、争议主题理解、编辑质量判断、引用可靠性、版本演化追踪、跨语言一致性……每一个单独拿出来都可以是一个完整项目，但七个拼在一起，不是野心，是无法交付的承诺。

没有一个维度在这个方案里被深想过：数据怎么构造、质量怎么验证、模型能力怎么评估——这些在七个方向上都是浅尝辄止。6个月内同时推进七个方向的结果，是七个方向都做到20%，而不是一个方向做到100%。

直接的建议：砍掉六个，专注幻觉检测。 幻觉检测方向有明确的定义、可操作的数据来源（维基百科的引用+正文差异）、可测量的评估指标。其他六个，等幻觉检测这个做完再说。

提案2（反向假设生成，13/25）——评估机制有根本性缺陷

→ 查看提案

这个提案的想法是让模型根据实验数据反向生成科学假设，然后用与原论文假设的「语义相似度」来评估质量。

问题在于：这个评估机制在惩罚创造性。一个同样正确、甚至比原论文更好的替代假设，语义上可能与原文差距很大——它会被评为「差」。科学假设的价值不在于和作者的想法多像，在于能否解释数据、能否预测新现象。用语义相似度评估科学推理能力，是把错误的代理指标当成了目标本身。

这个问题不是调参能解决的，是评估框架的设计错误。

---

三个系统性缺陷

回顾19篇，有三个问题反复出现，值得单独说清楚。

1. 规模估算普遍缺乏第一性原理支撑

从头到尾，没有一篇提案的规模数字是这样推导的：「我们随机采样了X个来源，其中Y%满足质量条件，因此估算总规模为Z。」几乎所有的「数十万条」「百万级」都是从直觉或愿望出发的——数字越大听起来越好，但越大越不可信，因为没有人去验证它。

提案4的「8-15万」是这样；提案14的「45万QA对」是这样；很多其他提案更是连量级的来由都没有交代。这不是学术诚信的问题，是论证链断掉了。一个花两天用API实际采样100个来源的pilot，比写一个没有数据支撑的规模估算更有说服力。

2. 核心技术难点「命名但不解决」

提案11（EverBench）诚实地指出了「权重确定问题」——不同能力维度的权重怎么设？但没有给答案。提案19（工具选择决策）提出了「甜蜜点问题」——任务复杂度和工具选择空间的交叉点怎么找？但没有给答案。提案6（Sandbox矩阵测试）完全忽略了大规模矩阵测试的计算成本。

这些不是边缘问题，是整个方案能否成立的关键节点。把它们列出来然后说「这是重要的未来工作」，不是谦虚，是把最难的问题留给了别人。好的提案应该是：识别核心难点，然后给出哪怕是初步的解决思路或实验设计。「我知道这个问题存在，这是我打算怎么处理它」，和「我知道这个问题存在，但没想好」，是本质不同的两种提案质量。

3. 缺乏评估闭环

训练数据提案最终的价值主张是：用这批数据训练出来的模型，在某个具体指标上提升了多少。但19篇里，大多数都停在「数据集构建完成」就算完工了。

没有评估闭环，6个月后你无法判断这件事成功还是失败。数据量达到了？但模型能力没变化。数据质量很高？但没有下游任务来验证这个「高质量」意味着什么。数据集的价值最终要通过下游模型能力的可测量提升来兑现，这条线必须在立项时就设计好，而不是在数据做完之后再想。

---

下一步该怎么做

结论很明确：

优先深推提案4和提案14。 这两个方向的ground truth定义最清晰，工程路径最短，风险最可控。在正式启动前，先花两周做可行性探针——用1-5%规模跑通全流程，用实测数据替换估算数字。如果pilot结果不理想，现在知道比六个月后知道便宜得多。

提案18作为6个月后的目标。 创新点是这19篇里最强的，但实现难度也最高。Lean autoformalization的工程复杂度不是几个月内能搞定的，先把前两个做扎实，再把精力转过来。

提案16直接瘦身：砍掉六个维度，专注幻觉检测。 不是否定这个方向，是让它变成一个可以做完的项目。

对所有提案加一个通用前置条件： 在任何方向正式立项前，必须提供一个基于实际采样的规模估算，格式是「采样X个来源，Y%满足条件，因此估算总规模为Z」。不是直觉，是数据。

写了19篇之后，回头看这些提案，最让我印象深刻的不是哪个idea最聪明，而是严谨程度的差异有多大。最好的几篇是真的在设计一个实验；最差的几篇是在描述一个美好的想象。从想象到实验，这个跨越才是真正的难点。