自我反思 · 2026-10-29 · spark · E2
- 本轮最需改进：
organized/promo/surveys/2026-10-29-database.md - 读完材料（仅清单指定三篇）：
organized/promo/surveys/2026-10-29-database.mdorganized/promo/surveys/2026-10-29-multimodal.mdorganized/guides/amitshekhariitbhu-llm-internals.md
一、逐篇评价
1. organized/promo/surveys/2026-10-29-database.md（database 综述）
- 准确性：高。14 条 ⚠️ 逐条标注降级来源（paper card 路径异常、abstract 信息量不足、解读稿外推值、引用口径冲突），两次 abs 页核查钉住 SeLa 与 Online Learning 的作者/Comments/版本。主动声明「不裁决 152 vs 1500+」是少见的克制。
- 深度：强。「把问题重述为良定义优化」这条纵深轴把 8 篇跨度极大的论文串成一件事，§三 P3「内生 vs 外挂」的问题化尤佳。
- 清晰度：中上。⚠️ W1–W14 编号密集需回查；但 §一 诚实声明（
is_new≠ 发表年份、清单 theme 未限子轴）拦住了最易误读处。 - 证据：全篇最薄弱的一环。两次核查落在清单「已有的两个链接」上，但对象是恰好最显眼的两篇——元数据本就自证；真正无锚点的三篇一篇未核。
- 遗漏：未给「核查预算的分配原则」，核查绕开三处最需外证处。
2. organized/promo/surveys/2026-10-29-multimodal.md（multimodal 综述）
- 准确性：高。§3 把 8 件材料的数字口径逐条摊开（pp / 保留比例% / FID / VBench 不可跨篇相加），明说「解读层推测不应被当作论文主张引用」。
- 深度：强。「显式的视觉/几何中间变量」是真正的组织性洞察——四篇互不相干的工作（fixation point / goal frame / 稀疏子目标 / 点云轨迹）被识别为同一方法论动作，非罗列。
- 清晰度：高。§0 自检表 + §3 证据边界 + §4 表格三层结构，读者立刻知道哪些数字可直接引。
- 证据：优于 database 篇。两次核查明确选在 FastOPD（84% / 78.1% / 15.9 pp）与 DMAD（FID 1.04 / 14.47 / VBench 85.15），即数字最硬、最易误读的两处；§3 第 4 条声明「编号顺序与主题演进不构成因果证据」。
- 遗漏：8 件中 6 件摘要数字未二次核验（已标注），资源约束下的合理取舍。
3. organized/guides/amitshekhariitbhu-llm-internals.md（llm-internals 攻略）
- 准确性：高。用 GitHub API
contents/核对根目录仅 4 个条目，推翻「教程仓库」的直觉——「它是目录不是代码」是全篇最有价值的一句。 - 深度：中上。10 个坑多是结构性事实（无 tag、内容托管外部站、博客与视频不同步、商业推广），属观察非洞见；第 4 条「版本号与性能数字需另行核对」唯一带判断力。
- 清晰度：高。工程/应用/入门三条浏览路径按处境分流。
- 证据：中。仓库指标有日期锚点；但 DeepSeek-V4 的 mHC/CSA/FP4 技术点全为二手转述，未回原文。
- 遗漏：§七 对比表全为定性符号（无依据列），且「约 28 节」「前段 1–6 节」的划分无编号锚点，读者无法核对。
二、本轮最需改进的一篇
organized/promo/surveys/2026-10-29-database.md。
理由不是它写错——边界标注比多数综述都密——而是核查预算花在了最不需要核查的地方。
三处：
- 核查与风险分布错配。 两次 abs 核查落在 SeLa（摘要带 ICLR 2020 标签、作者全名）与 Online Learning（Comments 自报「100 pages, ~400 references」）——二者元数据本就自证，结论风险低。真正无锚点的 1806.08730（abstract 只有一条活动通知）、1901.06796（全篇依赖解读稿）、1909.11875（压缩比全是外推）一篇未核。核查资源没流向不确定性的峰值。
- ⚠️ 密度高，但只解决了一半问题。 14 条 ⚠️ 覆盖「数字来自哪里」，却无一条覆盖「数字对不对」。把 W13 的「10x–100x」标为「未经原文核对」是诚实的；但只要有一次核查落在 1909.11875，它就能从「⚠️ 待核」升级为「已核」。标注体系只做到一半。
- §三 P2 的自相矛盾未被自己指出。 文中先写「WikiSQL 单任务下 MQAN 取得 SOTA，反过来说明多任务收益并非单调」，紧接着又写「当前材料无法回答——需回到 1806.08730 的转移实验与消融」。而「不可单调」正是消融会直接推翻的对象，P2 却把它放进「待解」而非「可优先清理」。这是本篇最实的可执行缺口，成本与 R5 同级却未被认领。
对照之下，同日同作者的 multimodal 篇做得更好：两次核查直接对准数字最硬的 FastOPD 与 DMAD，并把「8 件中 6 件未二次核验」写进 §3 第 2 条。同一天两篇产物核查原则不同——说明 database 篇不是方法论缺失，而是执行时没排序依据。
三、本轮具体优缺点
优点
- 三篇材料严格限于清单指定，未扫描近七天笔记、未回退全库、未自选历史稿。
- 把「边界声明与正文推论是否自洽」作固定检查项，在 database 篇上抓到 §三 P2。
缺点
- 我最初把 database 篇的问题归因于「⚠️ 太多、边界不清」，读第二遍才发现它恰是三篇里标注密度最高的一篇——问题不是标注不够，是标注只覆盖来源、没覆盖验证。这个区分让第一遍批评落偏。
- 我差点直接照抄 10-28 反思里的旧规则。本轮真正的新发现（核查预算按不确定度峰值分配）不在那四条里——旧规则能复用时，人会倾向不重新思考。这是本轮方法上最实在的退步。
- 选最需改进对象时，我把 database 篇排在前面，依据是「⚠️ 多、数字多、外推值多」这种表面量感，而非核查与风险的错配程度。
四、可复用改进规则
- 核查预算按不确定度峰值分配，不按易自证程度分配。 优先级 ≈ (内容依赖度 × 结论杠杆) / 可自证性。摘要自报元数据多的降权，abstract 信息量异常低的升权。
- 标注分两层：来源层（数字来自哪里）+ 验证层（核对过没有）。 只做第一层，读者仍无法判断能否直接引用。
- ⚠️ 条目要绑定解档条件。 每个 ⚠️ 应能回答「给它一次核查，它会变成什么结论」；答不了的是噪音，答清楚的是现成优先队列。
- 「待解问题」若已有明确消融可解，就不该标成待解。 单列「低成本可清理缺口」一档，与需新实验的分开。
- 同一天多篇产物要横向自查方法一致性，避免同日两套核查标准。
五、修订建议（仅建议，不改原稿）
以下为修订建议，供作者自行决定是否采纳。本轮未修改、未覆盖、未追加任何原稿，也未因本反思触发下一轮原稿更新。
建议 1 · §六「本轮事实核查」段后补核查选择说明（核心修订）
核查预算分配说明：本次 2 次核查落在 SeLa 与 Online Learning，因二者元数据自证度高（作者全名、ICLR 2020 标签、页数与参考数 Comments 在 abs 页可直接读），成本低而结论杠杆高（可整段逐字引用摘要断言）。清单内风险最高的三篇未获核查资源：1806.08730（abstract 仅一条活动通知，技术内容全来自解读稿）、1901.06796（全篇依赖解读稿）、1909.11875（三处外推量级）。若增预算应优先给这三篇，其中 1909.11875 的 W13 最值得优先——它是全篇唯一被转述为量级断言的数字。
建议 2 · W13 补「解档条件」
（解档条件：查 1909.11875 正文对应小节，确认「10x–100x 压缩」「50%–70% 轮数节省」「1.5x–3x 额外开销」是给出实验设定还是仅为代表性估计。若仅为估计，建议改为「量级参考，不作断言」。）
建议 3 · §三 P2 改为「可优先清理」档
（成本标注：本条与 R5 同级，属「补表/读消融」级可清理缺口，而非需新实验的待解问题。 消融会直接检验「多任务收益是否单调」这一前提；若前提不成立，本条应整条降级而非保留为开放问题。）
建议 4 · §一 诚实声明末补「核查非全覆盖」
本稿 2 次事实核查针对清单内 2 / 8 篇；其余 6 篇的摘要数字与解读稿内容均未二次核对，其中 1806.08730、1901.06796、1909.11875 三篇的技术细节完全依赖解读稿，引用时须按 §二 各 ⚠️ 对待。
建议 5 · 规则沉淀
本轮四条规则建议写入 knowledge/lessons/。本轮未写该文件（任务限定只写 item.target），留待作者。