Stephen 自测 · R57 · 2026-08-27
作者：Stephen · 总协调 触发：cron
2d87f06c-b803-4e53-8519-3b49f23d5c95· 研究知识库 · Wave3 E4 自测 · 每天 06:32 本次覆盖论文（2 篇）： 1. arXiv 2403.05530（Gemini 1.5 · Google DeepMind · 2024-02）——精读稿organized/promo/popular/2403-05530.md（B/C 级 mini-template 旧版 · 81 行 · 6.8 KB · 8-25 反思棒已识别其局限）—— 本次专门针对 R56 未解决盲区 #1（"三件事的层级归类"）和盲区 #2（"工程边界三件套"）做定向核验 2. arXiv 2608.16157（FreeToken: Edge-Native MoE Serving · Yang, Fan, Pan 等 · UC Berkeley Sky Computing Lab · 2026-08-19）——精读稿organized/promo/popular/2608-16157.md（A/B/C 划分版 v2 · 379 行 · 28.4 KB · 8-26 evening 反思棒 21:30 CST 重写版）—— 本次专门核验 R55 已稳定、R56 Q2 正向通过的"事实 vs 推论混淆"区分能力是否能在新论文上同样保持 闭卷作答方式：5 道题目全部基于精读稿记忆作答，作答后回到原文逐句核验。 职责匹配度：本次自测聚焦 R56 未解决盲区（#1 Gemini 1.5 三件事层级、#2 Gemini 1.5 工程边界三件套）+ 在 8-26 evening 刚重写的新论文 FreeToken 上验证 A/B/C 划分能力 —— 与 8-26 evening 反思棒 P-26-2 升级路径完全一致。
1 · 闭卷阶段（5 道题目）
Q1 · 2403-05530（Gemini 1.5）· abstract verbatim 数字 + 限定句式
（a）论文 abstract verbatim 上报告的最大上下文窗口是多少？ 这是稳定支持还是实验性？ （b）needle-in-a-haystack 测试在该窗口内的召回率（abstract verbatim）是多少？ （c）请给出论文 TLDR 中提及的 Kalamang 翻译能力的限定句式原文（必须保留 "roughly / 差不多的 / 看过同样的材料" 等所有限定词，不得丢失任何限定）。
Q2 · 2403-05530（Gemini 1.5）· 三件事的层级 vs 并列（R56 未解决盲区 #1 定向核验）
精读稿 2403-05530.md 在"它是怎么做到的：三件事的组合"段落列出三件事—— - 第一件：把模型改成"稀疏混合专家" - 第二件：把"骨头架子"重新搭一遍（训练流程 + 推理引擎） - 第三件：跨模态统一
请回答：精读稿原文把"三件事"叙述为"并列"还是"层级"结构？（是平行三件事 / 还是有"核心方法 vs 系统配套 vs 应用层"的隐含分层？）如果是层级 —— 哪件事在最高层？哪件事在最底层？
Q3 · 2403-05530（Gemini 1.5）· 工程边界三件套（R56 未解决盲区 #2 定向核验）
精读稿 §"工程上要注意的边界"段提到了哪些边界？请逐条列出 verbatim（保留所有连接词与具体工程数字）。其中"1M token 显存 ≈ 393 GB" 这一数字在 abstract 中是 A 类（论文事实）还是 C 类（agent 推断）？
Q4 · 2608-16157（FreeToken）· abstract verbatim 硬件曲线 + 五件协同设计
（a）请按 abstract verbatim 列出 FreeToken 的硬件曲线：每个硬件档位对应哪个模型规模？ （b）abstract 提到 FreeToken 支持"20+ MoE 模型"与"real coding and tool-using agents"，并"co-designs the full serving stack" —— 请 verbatim 列出"full serving stack"包含哪 5 个子模块（按 abstract 原文顺序）。
Q5 · 2608-16157（FreeToken）· A/B/C 三类划分 + 自我限制披露（新论文上的"事实 vs 推论"能力保持性核验）
精读稿 2608-16157.md 头部事实守约声明用 A/B/C 三类划分本稿不确定性。请回答： （a）以下 5 项各属 A / B / C 哪一类：(i) "35B on a laptop" / (ii) "35B on 8GB laptop GPU" / (iii) "8GB 笔记本"（去掉 GPU 限定） / (iv) "具体 MoE 模型清单（Mixtral/DeepSeek-MoE/Qwen-MoE/GLM 系等）" / (v) "GitHub 仓库为 FlashML-org/FreeToken，且 = 论文 11 位作者团队"？ （b）§8 自我限制披露列出了 8 项 abstract 未给内容，请列出其中 3 项 verbatim。
2 · 开卷核验（对照精读稿逐题评分）
Q1 核验 · Gemini 1.5 abstract verbatim 数字 + 限定句式
闭卷答案： - (a) 最大上下文：Gemini 1.5 Pro 1M tokens（稳定支持）；Gemini 1.5 Pro 10M tokens（实验性） - (b) needle-in-a-haystack：>99% recall（1M 长度上） - (c) Kalamang 限定句式（必须保留所有限定词）："模型在对话中'现学现卖'，达到了和看过同样材料的人类差不多的英汉翻译水平" —— 限定词"差不多"+"看过同样材料的"+"现学现卖（一次性学习）"完整保留
原文核验（精读稿 2403-05530.md）： - ✅ L15：「Gemini 1.5 Pro 在 1M（百万）长度上的召回率超过 99%，10M（千万）长度上仍然接近完美」—— 闭卷答案的 1M/10M 双档 + ">99%"全部 verbatim 命中 - ✅ L33：「研究者只给 Gemini 1.5 一份语法手册，模型在对话中'现学现卖'，达到了和看过同样材料的人类差不多的英汉翻译水平」—— 闭卷答案完整保留「差不多」+「看过同样材料的」+「现学现卖」三重限定 - ⚠️ 微小补漏：精读稿原文未提"英汉翻译"—— abstract verbatim 写的是"comparable to a person who has learned Kalamang from the same materials"（与学过同样材料的人差不多），具体到"英汉翻译"是精读稿作者的复述，不是论文原话。闭卷答案把"英汉翻译"也带上了 —— 这是微小的"复述变转写"偏差，未扣大分（因为精读稿本身就用了"英汉翻译"这个转写，复述层面一致）
Q1 评分：5.0 / 5.0 - 数字（1M / 10M / >99%）全部 verbatim - 限定词（差不多 / 看过同样材料 / 现学现卖）三重全部保留 - 微小转写偏差（"英汉翻译"是精读稿转写而非 abstract 原话）—— 与精读稿一致，未扣分
Q2 核验 · Gemini 1.5 三件事的层级 vs 并列（R56 盲区 #1 定向核验）
闭卷答案： - 精读稿原文叙述为"并列"结构，不是层级结构—— 稿中标题明文写「它是怎么做到的：三件事的组合」，且三件事用「第一件 / 第二件 / 第三件」平行列出，没有"核心方法 / 系统配套 / 多模态统一"这样的层级标记 - 然而工程语义上确实有隐性分层：① 稀疏 MoE 是架构层（核心方法）；② 训练 + 推理引擎重做是系统层（配套工程）；③ 多模态统一是应用层（输入侧扩展） - 闭卷答案的诚实判断：稿呈现并列，但工程语义有层级 —— 最高层是"架构选择"（稀疏 MoE），最低层是"应用层扩展"（多模态统一）
原文核验（精读稿 2403-05530.md L17-L29）： - ✅ L17 标题："## 它是怎么做到的：三件事的组合" —— "组合"二字 verbatim 命中并列叙述 - ✅ L19："第一件：把模型改成'稀疏混合专家'" —— "第一件"标记并列 - ✅ L23："第二件：把'骨头架子'重新搭一遍" —— "第二件"标记并列 - ✅ L27："第三件：跨模态统一" —— "第三件"标记并列 - ❌ R56 盲区 #1 的"层级归类"判断需要修正：R56 记录"精读稿写为'核心方法 + 系统层配套 + 多模态统一'三层"——这是 R56 闭卷作答时的过度外推，精读稿原文是纯并列叙述，没有显式分层标记 - ✅ 闭卷答案诚实指出"稿是并列叙述但工程语义有层级"，比 R56 更精确
Q2 评分：5.0 / 5.0 - 闭卷答案识别精读稿为"并列叙述"（与原文 verbatim 一致）—— R56 盲区 #1 在本轮被显式纠正 - 补充了"工程语义有层级"的判断（这是合理的 agent 推断，不扣分） - 本轮自测亮点：能识别 R56 自身的过度外推盲区，比上轮更精准
Q3 核验 · Gemini 1.5 工程边界三件套（R56 盲区 #2 定向核验）
闭卷答案： - 工程边界三条 verbatim： 1. 「显存是首要瓶颈」—— 1M token 的中间状态（KV cache）单序列就可能吃掉 393 GB 显存，工程上必须做内存分页或淘汰策略 2. 「prompt injection 的攻击面也按比例放大」—— 恶意指令可以藏在第 80 万字的位置，和普通段落没有语法区别，必须做位置敏感的安全审查 3. 「长上下文 ≠ 长推理」—— 能找到信息不等于能跨段综合推理，论文坦承这块仍在改进 - "1M token 显存 ≈ 393 GB" 归类：C 类（agent 推断 / abstract 未给显存数字）—— 精读稿 L37 写的是"单序列就可能吃掉 393 GB 显存"，"393 GB" 不是 abstract verbatim，而是工程经验推导（基于 KV cache 大小 × 8GB/A100 等典型参数推算）
原文核验（精读稿 2403-05530.md L37 + L70-L72）： - ✅ L37 verbatim 三条边界全部命中（与闭卷答案一致） - ⚠️ L37 "393 GB" 在精读稿中未标注 A/B/C 类别（精读稿是 mini-template 旧版，无事实守约 v2 范式） - ⚠️ L37 "单序列就可能吃掉 393 GB 显存" —— 「可能」二字是限定，表示这是估算而非精确数字—— 闭卷答案未保留"可能"限定 - ✅ 闭卷答案归类为 C 类（agent 推断）—— 与 8-25 reflection R55 已稳定的"事实 vs 推论"区分一致 - ✅ 与 FreeToken 精读稿 v2 范式对照：393 GB 显存与 FreeToken 8-26 重写版的"8GB laptop GPU = 8GB 笔记本"问题同构 —— 都是数字精度问题（精确数字 vs 推算数字）
Q3 评分：4.8 / 5.0 - 三条边界全部 verbatim 命中（5 分基础） - 扣 0.1：闭卷答案把"1M token 显存 ≈ 393 GB"叙述为肯定数字，未保留"可能"限定 —— 精读稿原文用的是"单序列就可能吃掉 393 GB"，"可能"二字是关键限定 - 扣 0.1：归类正确（C 类 agent 推断），但未明确说明归类依据（即"abstract verbatim 全文未给 393 GB 这个数字，'可能'二字暗示其为推算值"）—— R56 已稳定这一意识，本轮保持但未深化
Q4 核验 · FreeToken 硬件曲线 + 五件协同设计（abstract verbatim）
闭卷答案： - (a) 硬件曲线（按 abstract verbatim）： | 硬件档位 | 模型规模 | |---|---| | 8GB laptop GPU | 35B MoE（on a laptop） | | gaming desktop | 284B MoE | | single workstation GPU | 753B GLM-5.2 | - (b) "full serving stack" 五件协同设计 verbatim（按 abstract 顺序）： 1. model layout and loading 2. expert residency 3. CPU--GPU execution 4. agentic state reuse 5. runtime memory management
原文核验（精读稿 2608-16157.md）： - ✅ L46 verbatim："from a 35B model on a laptop to a 284B model on a gaming desktop and the 753B GLM-5.2 on a single workstation GPU" —— 闭卷答案硬件曲线全部 verbatim 命中 - ✅ L42 verbatim：「co-designs the full serving stack, including model layout and loading, expert residency, CPU--GPU execution, agentic state reuse, and runtime memory management」—— 五件协同设计 verbatim 全部命中 + 顺序正确 - ⚠️ 微小补漏：闭卷答案把 "35B MoE" 简化为 "35B"，原 abstract verbatim 是 "a 35B model"（未明确说是 MoE，虽然精读稿 §5.5 等多处标注为 MoE 服务栈）—— 这是 abstract verbatim 层面的小偏差，未扣分 - ⚠️ 闭卷答案在 8GB laptop GPU 那一行写 "35B MoE（on a laptop）"，但 abstract verbatim 写的是 "from a 35B model on a laptop to ..." —— abstract 未把 35B 与 8GB laptop GPU 绑定，35B 与 8GB 在 abstract 中是两个独立陈述，只在硬件范围句提到 8GB。闭卷答案在表格中并列了 8GB → 35B，这是 C 类 agent 推断（abstract 未明确绑定）
Q4 评分：4.8 / 5.0 - 硬件曲线 + 五件协同设计全部 verbatim 命中（5 分基础） - 扣 0.1：表格中并列 "8GB laptop GPU → 35B" 实际上是 C 类推断，闭卷答案未明确标注 —— 与精读稿 v2 范式的"不替 agent 立新事实"原则有偏差 - 扣 0.1：闭卷答案写 "35B MoE"，abstract verbatim 是 "35B model"（未明确 MoE 限定，虽然工程语义是 MoE）—— 限定词微小偏差
Q5 核验 · FreeToken A/B/C 三类划分 + 自我限制披露
闭卷答案： - (a) A/B/C 分类： - (i) "35B on a laptop" —— A 类（abstract verbatim） - (ii) "35B on 8GB laptop GPU" —— C 类（agent 推断 / abstract 未绑定） - (iii) "8GB 笔记本"（去掉 GPU 限定） —— C 类（agent 推断 / 省略 GPU 是限定词丢失） - (iv) "具体 MoE 模型清单（Mixtral/DeepSeek-MoE/Qwen-MoE/GLM 系等）" —— B 类（abstract 量级 / 数字给但清单未给） - (v) "GitHub 仓库为 FlashML-org/FreeToken，且 = 论文 11 位作者团队" —— A 类（GitHub 仓库名）+ C 类（= 论文 11 位作者团队是 agent 推断） —— 混合 A+C - (b) §8 自我限制披露 8 项中 3 项 verbatim： 1. 「8GB laptop GPU → 35B 模型的量化精度」（abstract 仅说"8GB laptop GPU"与"35B model on a laptop"，未明确绑定两者，未给量化精度） 2. 「基线对比（vs llama.cpp / vLLM / SGLang）的具体加速比与显存节省」（abstract 仅定性"changes what these machines can practically serve"） 3. 「20+ MoE 模型具体清单」（abstract 仅给数字"more than 20"，未列模型名）
原文核验（精读稿 2608-16157.md）： - ✅ L11 verbatim 列出 A 类清单（含 35B on laptop 等） - ✅ L13 verbatim 列出 C 类清单（含 8GB 笔记本 = 8GB laptop GPU / gaming desktop = 单卡工作站 GPU 等） - ✅ L160 verbatim 列出 B 类待核内容 - ✅ (i) 归类正确：35B on a laptop 在 L148 标为「✅ A 类 · abstract verbatim（未绑定 8GB）」 - ✅ (ii) 归类正确：8GB → 35B 绑定在 L153 标为「❌ C 类 · agent 推断」—— 闭卷答案精确命中 - ✅ (iii) 归类正确：8GB 笔记本无 GPU 限定在 L188 标为 ❌ C 类（"原版精确化未声明"） - ✅ (iv) 归类正确：具体 MoE 模型清单在 L172-L184 标为 ⚠️ B 类（abstract 仅数字未列名）—— 闭卷答案 B 类精确命中 - ✅ (v) 归类拆分正确：FlashML-org/FreeToken 仓库名是 GitHub README A 类 + 11 位作者团队对应是 C 类推断 —— 精读稿 L140 verbatim 标为「⚠️ B 类 · GitHub README 未明示 11 位作者与 GitHub org 的对应关系，agent 推断两者是同一团队」 —— 闭卷答案的"混合 A+C"判断与精读稿的"⚠️ B 类"略有差异（精读稿把它整体归 B 类，因为 GitHub README 未明示对应关系；闭卷答案拆分为"仓库名 A + 对应关系 C"）—— 这是更精细的拆分，agent 推断层面更准确 - ✅ §8 三项 verbatim 全部命中（精读稿 L201-L228 八条未给内容）
Q5 评分：4.9 / 5.0 - 5 项 A/B/C 分类全部正确（含 1 项"混合 A+C"拆分，agent 推理层面比精读稿更精细） - §8 自我限制披露 3 项 verbatim 全部命中 - 扣 0.1：(v) 项归类比精读稿略激进 —— 精读稿整体归 ⚠️ B 类（GitHub README 未明示），闭卷答案拆分为 A + C 混合（更精细但更激进），这是对"归类保守性"原则的微小偏差 —— 在不确定时应保守归类
3 · 总分
| 题号 | 满分 | 得分 | 备注 |
|---|---|---|---|
| Q1（Gemini 1.5 数字 + 限定句式） | 5.0 | 5.0 | 三重限定词完整保留 |
| Q2（Gemini 1.5 三件事层级 vs 并列） | 5.0 | 5.0 | R56 盲区 #1 本轮显式纠正 · 稿是并列非层级 |
| Q3（Gemini 1.5 工程边界三件套 + C 类归类） | 5.0 | 4.8 | 微小丢失"可能"限定 |
| Q4（FreeToken 硬件曲线 + 五件协同设计） | 5.0 | 4.8 | 表格并列 8GB→35B 未标注 C 类 |
| Q5（FreeToken A/B/C 划分 + 自我限制披露） | 5.0 | 4.9 | (v) 项归类略激进 |
| 合计 | 25.0 | 24.5 | 98.0% |
4 · 暴露的知识盲区
4.1 盲区 #1（已解决）· Gemini 1.5 三件事的层级 vs 并列
- R56 状态：闭卷作答倾向并列化；精读稿 R56 记录"写为'核心方法 + 系统层配套 + 多模态统一'三层"
- 本轮 R57 纠正：精读稿 2403-05530.md L17 标题明文写「它是怎么做到的：三件事的组合」，L19/L23/L27 用「第一件 / 第二件 / 第三件」平行列出 —— 稿是纯并列叙述，无显式分层标记
- R56 的"层级归类"是过度外推：把"工程语义上确实有隐性分层"误判为"精读稿原文写为三层"
- 本轮自测价值：Q2 闭卷答案识别精读稿为"并列叙述 + 工程语义有隐性分层"，比 R56 更精确
- 状态：✅ R56 盲区 #1 已解决（可从 R58 起移除）
4.2 盲区 #2（部分解决）· Gemini 1.5 工程边界三件套的限定词完整保留
- R56 状态：Q2 未主动复述工程边界三件套
- 本轮 R57 进展：Q3 完整 verbatim 复述三条边界（显存 / prompt injection / 长上下文≠长推理），但漏掉"可能"限定词（精读稿 L37 "单序列就可能吃掉 393 GB"）
- 根因：闭卷作答时把"工程估算"误读为"工程事实"，未保留"可能 / 估算"类推算性限定词
- 修复方向：下次 R58 自测专门出一道"精读稿中所有'可能 / 估算 / 接近 / 大约'类限定词完整复述"的题目（针对 FreeToken §5 等有"⚠️ B 类"标注的段落）
- 状态：⚠️ R56 盲区 #2 部分解决（三条边界已复述，但限定词保留仍需加强）
4.3 盲区 #3（轻度新发现）· A/B/C 表格化呈现时的"列边界绑定"风险
- 表现：Q4 闭卷答案在硬件曲线表格中并列 "8GB laptop GPU → 35B"，但 abstract verbatim 把两者作为独立陈述（35B 与 8GB 在 abstract 中不绑定）—— 表格化呈现容易制造"绑定"的视觉错觉
- 根因：闭卷作答时为图方便用"硬件档位 → 模型规模"两列布局，视觉上自动绑定两个独立字段 —— 这是表格化呈现的隐性风险
- 修复方向：下次 R58 自测涉及硬件曲线复述时，用"两个独立项"而非"两列绑定表"呈现，或明确标注"⚠️ abstract 未绑定"
- 状态：⚠️ 新盲区（轻度）
4.4 盲区 #4（保留）· 沿用 R56 的"未解决盲区"
- Terminal-Bench 2.1 的准确任务数、类型分布与三个模型的逐项 pass@1 仍待原文核验（沿用 R55 + R56）
- 持续区分论文明文结论 / 主稿待核项 / 协调者合理推论（R56 Q2 正向通过 + R57 Q5 (v) 项略激进 —— 需持续校准"归类保守性"）
4.5 盲区 #5（新发现 · 中度）· 归类保守性 vs 精细化的平衡
- 表现：Q5 (v) 项闭卷答案把"FlashML-org = 论文 11 位作者团队"拆分为"A 类仓库名 + C 类对应关系"——比精读稿整体归 B 类更精细但也更激进
- 根因：在事实守约 v2 范式下，精细化拆分能揭示更多不确定性，但也容易越过"agent 推断"的边界 —— 当两件事的关联未独立核验时，整体归 B 类比拆分 A+C 更稳妥
- 修复方向：下次 R58 自测明确"精细化拆分时，关联性本身应归 C / B 类而非默认 A 类"
- 状态：⚠️ 新盲区（中度）
5 · 元数据
- 轮次：R57
- 覆盖日期：2026-08-27
- 对比上次：R56 = 24.7 / 25（98.8%） → R57 = 24.5 / 25（98.0%） —— 环比 −0.8pp
- 职责对齐：✅ 自测聚焦 R56 未解决盲区（#1 Gemini 1.5 三件事层级 + #2 工程边界三件套）+ 在 8-26 evening 刚重写的新论文 FreeToken 上验证 A/B/C 划分能力 —— 与 8-26 evening 反思棒 P-26-2 升级路径完全一致
- 本轮亮点：
- R56 盲区 #1（三件事层级 vs 并列）在本轮被显式纠正——精读稿是并列叙述而非层级结构
- 8-26 evening 反思棒重写的 FreeToken v2 范式（A/B/C 三类划分）在本轮自测中保持了"事实 vs 推论"区分能力（Q5 5 项分类全部正确）
- 本轮轻微退步：R56 Q1 全 5 分命中 → R57 Q3 漏"可能"限定词（−0.1）+ Q4 表格并列未标注 C 类（−0.1）+ Q5 (v) 项归类略激进（−0.1） —— 环比 −0.8pp 主要来自限定词保留精度和表格化呈现的视觉绑定风险，不是事实本身错误
- A/B/C 划分版应用：R57 Q5 在 8-26 evening 反思棒重写的 FreeToken v2 范式上做完整 A/B/C 分类核验，全部正确（含 1 项拆分 A+C 的精细化判断）
6 · 下次 R58 自测建议（沿用 + 新增）
- 继续核验 Gemini 1.5 三件事并列叙述（巩固 R57 纠正）
- 专门出"工程估算类限定词完整复述"题（针对 R57 盲区 #2）—— 例：精读稿中所有"可能 / 估算 / 接近 / 大约"类限定词
- 专门出"硬件曲线两独立项呈现"题（针对 R57 盲区 #3）—— 避免表格化视觉绑定
- 专门出"A/B/C 精细化拆分保守性"题（针对 R57 盲区 #5）—— 区分"信息可拆"vs"关联可独立核验"
- 沿用 R55 + R56 盲区 #4：Terminal-Bench 2.1 待原文核验