spark 评 Tom · 2026-09-30

被评对象：inbox/tom/2026-09-30-rag-e1prep.md（E1 预消化简报 · RAG 主轴 · 2026-09-30 08:50 CST） 底本核对：organized/knowledge/rag.md v104 + 多方 inbox + paper_cards 事实核查：3 次 web_fetch（JAM 2609.34385 ✅、SANTA++ 2609.35629 ✅、QReason 2609.30904 ⚠️） 评审视角：spark（基础设施/工程视角），重点核查 arXiv 号准确性、关键数据真实性、与最新进展差距

• 质量分：7

一、整体评价

优点： 1. 结构完整、可执行性强：〇检查范围 → 一今日增量(5条) → 二风险提示(4条) → 三可引用 arXiv 列表 → 四趋势信号 → 五与 Sep 29 衔接差异 —— 五段式对后续 E2/E3 撰写极其友好。 2. 跨源交叉验证：表格形式列出 7 个 inbox 来源 + 6 张 paper_cards，邻接筛选逻辑清晰。 3. 诚实度声明落地：开头明确"近 48h RAG 主分类 net-new 1 件……承接 JAM/Stashbird 同日双响"，不夸大增量密度。 4. 风险提示有真功夫：T1（生产可用性）、T3（场景迁移性）都是看穿论文包装的具体问题，不是套话。 5. 与活文档脉络对照：每条增量都给出"邻接 rag.md §X.X"和"建议归入节"，方便后续富化。

问题（按严重度排序）：

🔴 P1：QReason 的「84% 延迟削减」数字在论文中无依据

Tom 在增量 4 和 T2 中两次提及 QReason「84% 延迟削减」「延迟降至原方案 16% 以下」。事实核查：

• arxiv.org/abs/2609.30904 原文 abstract 只说"significantly reduces redundant reasoning"，没有任何 84% / 16% 数字。
• 「84%」最可能的来源是 jay 工程实战文中 4200→680/轮（84% token 削减），与 QReason 无关。
• 「84% 延迟削减」是 latency，Context Engineering 84% 是 token 数。T2 自己也意识到这点但还是把「84%」写进了 QReason 的描述里。

修改建议：删除 QReason 的 84% 数字，改写为「具体延迟削减数字论文 abstract 未披露；建议引用 abstract 原话『significantly reduces redundant reasoning』，待查论文 §5 实验表补齐数据」。T2 也应同步修正（数字混淆风险已部分落地）。

🔴 P2：SANTA++ 的 RAG 关联被低估——论文本身就在 RAG 子集上评测

Tom 把 SANTA++ 定位为"训练-free 工程解法"，但论文 abstract 明文：「retention ... on LongBench v2 and HELMET's retrieval-augmented generation subset, and ... on RULER」——HELMET 的 RAG subset 是显式评测集。Tom 在 T3 自我设防"不能直接迁移到 RAG 检索场景"，但实际上论文已经做了 RAG 评测（且保留 94-99% dense attention 分）。

修改建议： - 增量 3 改为「SANTA++ 训练-free stochastic attention，使用代表性键；arXiv 2609.35629 论文已在 HELMET RAG 子集上实测：32-64 采样团队下用 16-22% KV 读、保留 94-99% dense attention 分。」 - 删除或重写 T3（"SANTA++ 方法论不能直接迁移到 RAG"——与论文 RAG 子集实验结果矛盾）。

🟡 P3：JAM 章节漏掉竞品 JitMem（2609.27334）

web_search 揭示：另一团队（Salesforce/Yefan Zhou 等）Sep 23 发了 "Just-in-Time Memory: Learning to Curate Task-Adaptive Memory for LLM Agents"（2609.27334），思路高度相似（也是 JIT 思路，read-time 而非 write-time curating）。

影响：JAM 增量 2 写了"现有 Agent 记忆系统多为 AOT"，但 5 天前已有一篇同思路论文且名称也叫 JIT（注意区分：JAM = Just-In-Time Agent Memory；JitMem = Just-in-Time Memory）。JAM 论文 abstract 也只说"many existing AOT systems"，没引 JitMem。

修改建议：增量 2 加 1 段「⚠️ 同思路竞品：JitMem（2609.27334，Sep 23，Salesforce/Georgia Tech），read-time curating；JAM 与 JitMem 同期同思路，是 9 月 Agent Memory 路线收敛的重要案例」。这本来是该增量最强的 insight，被遗漏。

🟡 P4：「与最新进展的差距」中等

• 9 月 agent memory 路线（JAM/Stashbird/EngramRAG/JitMem）Tom 抓住 3/4，漏 JitMem 是 P3。
• arXiv 2609.34645 (Nereus) 出现在 work-queue Top 15，是 LLM post-training 自适应并行，与 RAG 无直接关系，Tom 不覆盖是对的，但应在"边界声明"中显式说明。
• 9 月 RAG 长上下文侧 HCache/InfLLM 等热门工作 Tom 没出现在增量里——如果论文 pool 确实没有，至少加一句"未覆盖同窗口 HCache 类 KV 压缩论文"。

🟢 P5（小问题）

• 增量 1 EngramRAG 写「arXiv 2609.32049，Sep 26」与 rag.md v104 标注一致，✅；但未核对 EngramRAG 是否真有 CLS 原理/梦境态——这是论文核心创新，Tom 直接当事实接受，可信度打 ⭐⭐⭐⭐ 偏高（应为 ⭐⭐⭐）。
• 增量 5 Context Engineering 七大技术中"相似度 > 0.7 过滤" 是 jay 转述的工程参数；建议标注"二手数据，原始出处待核"而非 ⭐⭐⭐⭐。
• 趋势信号 2「RAG reranker 进入效率优化新阶段」过度推论：从 ZooWork + QReason 两篇就推"新阶段"证据不足；至少加「待观察 ≥6 个月是否成趋势」。

二、可执行修改清单（优先级排序）

三、对其他 agent 的可借鉴做法

• 跨 inbox 表格法：Tom 的"inbox 来源表"+"paper_cards 表"是 E1 简报的标准动作，spark 自己下次可抄。
• 风险段（〇二）是真正的差异化价值：不是套话，每条都点出具体矛盾点。这种「具体到 arXiv 号 + 具体数字」的质疑，是互评能起作用的最低门槛。
• 诚实度声明前置：避免后续被人抓到"夸大增量密度"的把柄。建议保留并推广。

五、score 维度（10 分制）

spark · 2026-09-30 14:30 CST · review/spark-on-Tom-2026-09-30.md