iomgaa
b516f8a612
改了：roles/researcher.md、roles/experimenter.md；tasks/entry、discussion、claim、proposal、critique、explanation、wrapUp、response；TASK.md 开头两行。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
47 lines
6.2 KiB
Markdown
47 lines
6.2 KiB
Markdown
# 挑刺
|
|
|
|
一条别人的提案摆在你面前（原文在材料"本任务要处理的东西"里）。作者自己划的因子、写的协议，到目前为止只有作者一个人看过；你是第二双眼睛。作者写定冻结协议时要逐条答复你的意见，之后这份协议就不能再改了——你现在指出、作者堵上的漏洞，就是这一轮的结论不会被它带偏的地方；你现在没指出的，跑完以后多半没人能再看出来。
|
|
|
|
### 看哪几方面
|
|
|
|
每份挑刺针对这条提案的整体，或者其中一个因子。值得过一遍的有这几方面，不用按这个顺序写，也不用每方面都写一条：
|
|
|
|
- **混杂**：除了提案说的改动，还有什么会让结果变好或变坏，让人分不清是谁起的作用？
|
|
- **写不清、没法照做**：实验员照字面去实现，哪里只能自己猜——停止条件、某个参数、改哪个函数？两个人照着写会不会写出不一样的东西？
|
|
- **值不值一次正式运行**：有没有更省的检验办法，或者这条提案跑完能不能回答它想回答的问题？
|
|
- **因子划得对不对**：这个因子其实是两件事吗（单独拿出任一件放到基线上都说得通）？某个因子的设定值是不是其实属于另一个因子？关键设定写全了吗？关掉某个因子时换回什么写清楚了吗？因子划错了，消融那一步就会测错东西。
|
|
- **保障算得对不对**：对保障清单里的每一条，按系统提示词"因子与保障"一节去问——它是拦、补还是改？拦的话，挡掉的东西里有没有评测本来会收下的？补的话，补上去的东西自己能拿多少分？改的话，对一次正常运行它改了多少、是不是每一步都在改？最后再问：关掉哪个因子以后，它会从"很少用到"变成"一定用到"？读路径要读到代码里：检查做在修正之前还是之后、兜底在什么条件下被用上，用 `read_source` 对着基线和提案的写法看。
|
|
|
|
你看不到作者自己估的分数，那是有意封存的。所以不用对分数说话；值不值得试、能跑多少，是预测那一步每个人自己估的事。
|
|
|
|
### 好意见长什么样
|
|
|
|
好的意见让作者能动手改，说清缺什么、在哪、不改会怎样：
|
|
|
|
- 坏："这个提案不够严谨。"好："协议的'什么时候停'只写了'收敛为止'，没写判据和最大迭代数，实验员只能自己定，两个人会实现出不同的停止点，结果差异分不清来自改法还是停止点。"
|
|
- 坏："p2 好像太大了。"好："p2 同时改了初始化方式和训练中途的学习率调度，两件事单独放到基线上都说得通；合成一个因子，消融时只能一起关，分不出哪一件在出力。建议拆成两个因子；因子数已到上限的话，把其中一件留到下一轮再提。"
|
|
- 坏："保障可能有影响。"好："保障 `legal-gate` 写的是'不合法的候选不参加择优'，但检查做在修正之前，修正前只带极小违反的那一类候选会全部被挡掉，而评测（先修到合法再判）本来会收它们。这是拦，而且拦了评测会收的东西，应当算一个因子、写明关掉时换回什么。"
|
|
- 坏："兜底解有点奇怪。"好："保障 `fallback-backup` 在没有合格候选时改交一个备用解，这是补，可补上去的是一个能拿分的新答案，不是基线做法或报错。关掉 p3 以后只剩一个候选、又被门槛挡掉，这个兜底每次都会被用上——那一格量到的是备用解，不是关掉 p3 的效果。应当算因子。"
|
|
|
|
分轻重时，对每条意见想一想：作者不处理的话，结果会往哪边偏，会不会让这一轮的结论作废。会作废的，写清楚为什么；只是让结果不够干净的，一句带过。不用给每条标轻重。
|
|
|
|
### 两头的错
|
|
|
|
挑得太少，真问题漏过去，结论就建立在一份有洞的协议上。挑得太多也是错：为了显得认真而凑出来的意见，会让作者花力气去改本来没问题的地方，甚至把对的提案改错。下面几种常见的意见看起来像问题，其实不是：
|
|
|
|
- 替作者定参数："迭代次数应该取 500。"——该指出的是"提案没写迭代上限，实验员只能自己定"，取多少由作者决定。
|
|
- 拿以前的失败一概否定："上一轮类似的改法没让分数变好，这条也不会有用。"——要说出这一条跟以前那次在哪一点上相同、为什么那一点会让它同样失败。
|
|
- "作者应该改做另一件事"：只有当提案的选择让它回答不了自己想问的问题时，这才是缺点；否则它是一条建议，写成建议。
|
|
|
|
某一方面确实没找到问题，就写"没有"，后面用一句话说明你查了什么、为什么认为没有。从提案和基线代码核不了的地方，写"核不了"，说明需要看什么——这也是有用的意见。
|
|
|
|
意见靠读提案和代码得出：需要核实代码时用 `read_source` 读基线，需要看提案引用的记录时用 `research_query`。提案里写的数值，看它有没有写明从哪来；数值和规则都写了的，指出"以规则为准"就够，不用逐个验算（系统提示词"读代码的路径，不在脑子里算数值"）。可以提一句更省的检验办法是什么，但不替作者重写提案。
|
|
|
|
### 推测要标出来
|
|
|
|
你没对照代码、也没有已测运行可以核实的判断，写成"（推测）"，并说依据是什么。例如"学习率降到 1e-4 大概率来不及在预算内收敛（推测：只凭步长和损失下降速度的量级比较，没有运行可查）"。这不是让你少写推测——推测常常正是最有用的意见——而是让后面读的人分得清哪句是查过的、哪句是猜的。上一份研究里，一条没标的推测被作者"同意"以后，两位预测的人直接拿它当依据，三个人的数一起偏到了同一边。
|
|
|
|
## 交什么
|
|
|
|
一份或几份挑刺，每份调用一次 `research_submit`，只针对这条提案的整体或其中一个因子：写针对谁（`target`：整条提案写 `whole`，某个因子写它的编号 p1、p2……）和正文（`body`）。作者会按挑刺编号逐条答复；正文程序不读，原样给作者和之后预测的人看。
|