研究知识库 · flyP 精读与批判 · 2026-10-21 15:50 班
作者：flyP 清单：3d8f503a-7aeb-4a17-9550-c2514939fbfa（未消费版本，未过期） 本班对象：2 项（1 篇论文 + 1 篇技术评论）
对象一 · Recursive Language Models（RLM）
- 标识：arXiv 2512.24601（v3，2026-05-11）
- 来源：organized/paper_cards/039-2512.24601.md → https://arxiv.org/abs/2512.24601
- 证据边界：摘要级 + arXiv 摘要页核实。未读正文方法与实验章节，未核验任何性能数字的实验设置、基线配置或评测脚本。verification=paper_card_abstract。
- 代码：https://github.com/alexzhang13/rlm（摘要给出，未访问、未运行）
方法拆解（据摘要推断，非全文确认）
核心把长 prompt 从"塞进上下文"改写成"外部环境"。模型不再是把 100K token 一次读完，而是通过程序化接口按需查看、切分、递归调用自身处理片段。三个构件推断为：(1) 环境/工具接口，让模型能按索引或条件取子片段；(2) 分解逻辑，把长输入拆成可独立判定的子问题；(3) 递归调用，即在子问题上再触发一次自身，深度由模型自适应决定而非预先固定。
这本质上是把"上下文窗口容量问题"转化成"测试时计算分配问题"——不是让模型记得更多，而是让它决定何时去看、看哪一段。方向上与 agentic scaffold 一脉相承，论文自比的 CodeAct with sub-calls、Claude Code 就是同赛道对手。
核心贡献
- 范式层面：给出"长输入=环境、模型=递归求解器"的形式化框架，把长上下文从架构问题降级为 inference-time scaling 问题。
- 规模声明：称可处理超出上下文窗口两个数量级的输入，且在更短输入上仍大幅超过 vanilla frontier LLM 与常见长上下文/编码 scaffold（摘要给出 GPT-5 上中位数 +26% vs compaction、+130% vs CodeAct sub-calls、+13% vs Claude Code，跨四类长上下文任务，成本相当）。
- 小规模后训练：RLM-Qwen3-8B 在其上做后训练，平均超底座 28.3%，在三项长上下文任务上接近 vanilla GPT-5。
主要问题
- "两个数量级"是最需要警惕的一句。 长度外推的失败模式通常不是"变差"而是"悄悄退化"——模型在递归深处停止调用、只凭早期片段作答、或输出格式逐层漂移。若评测里没有对抗性长输入（关键信息埋在中后段、单点依赖、需要全局统计的任务），两个数量级就是可预期的上限而非能力。
- +130% vs CodeAct 是最不干净的一个数。 对比对象带 sub-calls，意味着对方本来就在做类似的多调用；差距这么大，通常更可能来自 scaffold 工程细节（终止条件、重试、上下文清理、解析失败率）而非范式本身。需要看到 scaffold 实现对齐程度才能定性。
- 成本"相当"是模糊表述。 递归调用的 token 账单随深度乘性增长。若统计口径只算单次调用或按缓存后计价，"comparable cost"不成立。这是全篇最可能被低估的成本项。
- 四类长上下文任务的选择。 摘要未列任务名。若样本量小、任务同质，中位数提升的说服力会大幅下降。
- v3 已迭代三次（2025-12 → 2026-01 → 2026-05），跨度五个月。 说明结论可能在中途被修正过，但从摘要看不出改了什么、为什么改。这是二读的首要目标。
实验风险
- 后训练基座仅 8B，与 GPT-5 / Claude Code 的前沿对比不在同一能力层，"接近 vanilla GPT-5"需要在哪些任务上达成、其余任务差多少，未知。
- 潜在泄漏：递归 scaffold 天然会把片段内容带入后续调用，评测集污染与答案透传的排查难度高。
- 数字全部来自作者自评，无独立第三方复现（本班未检索复现情况，不做判断）。
复现难度：高
需要自建环境接口 + 递归终止逻辑 + 大量解析容错，再加一套后训练数据管线。代码已开源降低了第一层门槛，但复现论文全部数字仍需重建 scaffold 对照组，工作量按周计。
可信度：中高（对范式主张），中低（对具体幅度）
"长输入应当作为环境而非上下文"这一主张方向清晰、与已知经验一致，可信。对 +26%/+130%/+28.3% 这类具体幅度，在未读实验章节前只能视为作者自报。
后续验证（本班未做，建议列为待查）
- 读正文实验章：四个任务分别是什么、样本量、是否有埋点/对抗长输入设计。
- 核对成本口径：递归总 token vs 基线总 token。
- 查 v1→v3 changelog，确认哪项结论被修正。
- 找第三方复现或批评性讨论。
对象二 · Reflections on DeepSeek Open-Sourcing DeepInfer
- 标识：https://wukong123.substack.com/p/reflections-on-deepseek-open-sourcing
- 来源：organized/indexes/article-evidence/7490f7d3...json
- 证据边界：search_snippet_only（搜索线索级）。excerpt 为片段拼接，段落不连续（"[...]" 处被截断），未读全文。按本班额度未对该来源再做网页核查。文章中出现的所有论断均为作者观点，非事实认定。
方法拆解
非论文，无实验。作者采用的是"参照系对比法"：把 DeepInfer 放在 vLLM/SGLang 这一既有生态坐标里定位，取舍靠功能清单比对（有无 prefix caching、online serving、多模型兼容）而非跑分。这是评论文章的常规手法，不是证据。
核心贡献
- 提出一个可供草根算法工程师参照的判断：DeepInfer 的现实定位是"高标准参考实现"，而非要替换 vLLM/SGLang 的通用框架。
- 指出瓶颈转移判断：下一代推理瓶颈从 HBM 容量转向高速互联与主机-设备带宽，低精度标准化（FP4/FP8/UE8M0）与大规模专家并行（EP64–EP128）成为硬件指标。
主要问题
- 结论先行，证据后置。 "最初派生自 vLLM、核心逻辑全面用 C++ 重写、残留相似度极低"这类断言未见代码级比对依据，可能是印象式判断。
- "不会替代主流框架"是弱可证伪的。 缺失 prefix caching / online serving 可能是暂未实现，也可能是刻意的范围切割。文章没给出依据来源。
- 瓶颈转移论缺数据支撑。 EP64–EP128、FP4/FP8/UE8M0 这些数字读起来像行业共识转述，没有实测或引用。
- 快照时效性。 DeepInfer 若仍在快速迭代，"缺少在线服务"这类判断的保质期可能只有几周。开源推理引擎的结论过期极快。
实验风险
不适用（无实验）。风险在于把评论判断当事实使用——尤其是"派生自 vLLM""瓶颈已转移"这两条，一旦被下游引用成本很高。
复现难度：不适用；可信度：中低（观点有价值，作为事实来源不可直接引用）。
后续验证
DeepInfer 仓库功能现状（prefix caching、online serving 是否已补齐）；C++ 重写程度的代码级判断；是否有官方技术报告佐证瓶颈转移论。本班额度内未执行，标记待补查。
本班证据边界总述
- 对象一：arXiv 摘要 + 摘要页一次核实，未读方法与实验全文，未核实任何性能数字。
- 对象二：仅 search_snippet_only，未读全文，片段存在截断，本班未做额外核查。
- 网页核查次数：1 次（arXiv 摘要页，返回 200）。未抓取 PDF，未扩展搜索。
- 全部数字均来自 arXiv 摘要原文转述，无外部验证。
清单标识与来源
- critical-paper:2512.24601 → https://arxiv.org/abs/2512.24601
- critical-article:https://wukong123.substack.com/p/reflections-on-deepseek-open-sourcing