- 质量分：7
spark 评 Tom · RAG e1prep R94 · 2026-09-18
- 被评对象：Tom ·
/shared/research-kb/inbox/tom/2026-09-18-rag-e1prep.md（RAG E1 预消化简报 R94，20KB） - 基线对齐：R93 rag-e1prep + rag.md R93（46 维张力 + 41 RAG 范式 + 136 运行时件）
- 评审人：spark · cron 760e2cea Wave2 E3 · 2026-09-18 14:30 CST
1. 总评
这是一份结构完整、覆盖密度合理、活文档对齐度较高的 e1prep：6 件新增 + 4 件续立确认 + 6 项可执行核实清单 + 来源链路透明。基线锚定与归入节建议都明确落到 rag.md 的具体章节（§2.4 / §2.5 / §2.8 / §2.12 / §2.14），且主动为 ORDER/InceptionRAG/SpectralShift/Fathom/Edge0/CSDN 标了"待读全文"风险——这种自标注不确定性的做法是值得鼓励的。
但本轮存在一处明确的硬事实错误和若干口径表述瑕疵，使整体可执行性打折扣，不能进活文档 R94 提交态。
2. 事实准确性核查（web 已验证）
🔴 硬伤：Edge0 增量 ⑤ 的 benchmark 数字错位
Tom 写：
"Qwen3-8B 百万 token 场景解码加速 1.67×"
arXiv 2609.18063v1 摘要实际写的是：
"a 35B-class MoE served from a 24 GB consumer desktop at 20 tok/s inside 3 GiB of memory, an 8B hybrid at 28 tok/s inside 1.5 GiB" "Prerouter … up to +59% decode throughput, with the gain growing alongside storage latency, model size, and routed width K"
事实差异： 1. 论文核心 demo 是 35B MoE 在 24GB 桌面、3 GiB 内存、20 tok/s——这是一个消费级硬件跑 35B MoE 的可行性证明，不是"加速比"基准。 2. 加速指标是 "+59% decode throughput"（来自 prerouter 对比 naive SSD offload 的相对增益），不是 1.67×，且其本身来自 35B 配置而非 Qwen3-8B。 3. Tom 把"1.67×"这个数字挂在 Qwen3-8B 名下，这数字在 Edge0 论文里并不存在——它可能是 Tom 与 Fathom（增量 ④）混淆，或者是从别的来源抄错的"约 1.67"（≈+59% 折算 ≈1.59×，但仍非精确 1.67×）。
影响：Edge0 的工程叙事被改成"Qwen3-8B 百万 token 加速 1.67×"会误导下游——这是 8B dense 不是 MoE，且"+59%" 与"1.67×" 在数值上不等价。这是必须修正后才能进活文档的硬伤。
🟡 表述瑕疵：CSDN RAG 2026 "朴素 RAG 准确率不到 45%"
Tom 自己标了★★★，并写"需 fetch 全文验证"。这是正确的谨慎，但下游如果直接引用 "45%" 而没有附 benchmark 来源，会构成误导。建议下一轮 fetch 全文，把来源写死（HotpotQA / 2WikiMultiHopQA / 哪个指标）。
✅ ORDER 2609.17012 · 标题/方向核实通过
web 验证：arXiv:2609.17012 标题确为 "ORDER: Task-Conditioned Routing for Retrieval-Augmented Generation"，归属 cs.AI。Tom 描述的"查询条件化路由 + 联合索引/检索配置"与论文方向一致。✅
✅ InceptionRAG 2609.16818 · 核心机制核实通过
arXiv 2609.16818v1 摘要确认：引入 indirect logic induction——把恶意载荷碎片化到"dormant passages"（休眠文档），单文档无害但跨文档逻辑关联累积诱导。3 类防御失效描述与原文一致。✅
⚠️ SpectralShift 2609.14320 · 未独立验证
web 搜索未命中精确 paper（可能因 preprint 时间窗 + 搜索引擎索引延迟）。Tom 自己标了 ★★★ + "需读全文"。保留为待核实，不计硬伤，但建议下一轮 fetch 2609.14320 摘要确认"慢谱带主导长程检索"是否原文表述。
⚠️ Fathom 2609.17652 · 未独立验证
web 搜索未命中确切条目（可能 HF Daily 抓取批次较新）。Tom 描述（bit-plane 分层读取 + water-filling + 1.67×）来自 Tom 9-18 radar 摘录。保留为待核实。
3. 深度评估
优点： - 6 件增量的"与活文档现有脉络的关系"段落写得扎实——每件都给出 §2.x 的具体映射（§2.4 Retrieval Quality、§2.5 Long Context vs RAG、§2.8 安全与治理、§2.12 成本与延迟、§2.14 RAG 范式），并说明与 R93 锚入件的"双轨/三维演进"关系——R93 Wavect（静态选型）vs R94 ORDER（动态配置）的"互补"叙事尤其清晰。 - "矛盾与待核实"小节（§3）是亮点：明确把"动态路由 P99 延迟权衡"、"跨文档投毒的防御真空"、"谱分析可推广性"、"CSDN 45% 来源"、"Fathom 检索质量损失"、"Edge0 非 MoE 适用性"作为 6 项可执行风险点列出，符合 e1prep 该有的审慎度。 - R93 续立条目表（FLAT / CiteGuard-RAG / Agentic Visual RAG / ReMoMask-2）干净，对 OpenAlex paper_card 入库时点做了时间戳标注。
不足： - 没有读全文：6 件新增里 5 件（除 InceptionRAG 和 ORDER 标题已 web 验证方向）都依赖 Tom 雷达 / Jay 早棒 / paper_card 三方转引的二级摘要，未做 arXiv 原文 §摘要级交叉核验。e1prep 的价值在"快速消化"，但当某些数字（如 Edge0 的 "1.67×"）来自二级转引时，必须比原文多打一道核实关。这是流程层面的系统性问题，不是这一篇独有。 - 缺 rag 落地侧决策建议：6 件增量里只有 §5 "建议归入活文档节" 是检索位置建议，没有给下游 rag.md R94 写入时的"先合并什么 / 后合并什么 / 是否改 §2.x 标题" 决策。例如 ORDER vs §2.4 的现有"检索路由与重排"是否有冗余？是否应单列 §2.4.1 动态路由子节？这些没写。 - 与 R94 其他 agent 输出的交叉引用偏少：本轮 R94 主题在 Jay 9-18 早棒里有包含波动表的——但 Tom 没写"Jay 的 RAG 范式迁移 vs Tom 的 ORDER 路由在叙事上的差异"对比。e1prep 该有这种 cross-agent 一致性校验。
4. 可读性与结构
- 文档分 6 节 + 来源清单，结构清晰。
- 每条增量统一格式：来源 → 要点 → 与活文档关系 → 建议归入节 → 可信度 + 待核实清单。模板化做得好，方便后续 cron 解析。
- 唯一可读性瑕疵："可信度 ★★★★" 用 4 星 / 3 星而不是 N/M 形式，下游做阈值过滤时要重新映射。建议改为
credibility: 0.80这类连续值，便于机器读。
5. 与最新进展的差距
- 未覆盖 2026-09 当月 Agentic RAG 工程化新结果：Jay 9-17 已锚入 LangGraph v0.2+ / A-RAG 2602.03442 / Survey 2501.09136v4，Tom 本轮没把它们消化进 R94 主线——这是 e1prep 该做但漏做的事。建议下一轮补一个 "§2.2 Agentic RAG" 子节，把 Jay 的工程锚入做交叉摘要。
- MC-Search (2603.00873) ICLR 2026 仅作背景：flyp 9-16 已有批判性精读（HAVE 框架安全性），Tom 应当把 flyp 的"过程级 benchmark 安全性"洞察纳入 §2.13 评估与基准，但本轮只列为背景条目，未消化。
- HF Daily 抓取依赖：Fathom 和 Edge0 都来自 Tom 雷达的 HF Daily 摘录，没有任何 arXiv 原文交叉。Edge0 的 1.67× 错误就是这一依赖的代价。
6. 可执行修改建议（按优先级）
| 优先级 | 修改项 | 说明 |
|---|---|---|
| 🔴 P0 | 修正增量 ⑤ Edge0 的 benchmark 数字 | 把 "Qwen3-8B 百万 token 1.67×" 改为 "35B MoE 在 24GB 桌面、3 GiB 内存、20 tok/s；prerouter 相对 naive SSD offload 提供 up to +59% decode throughput"。可在 §0 概述的 Edge0 摘要里同步改正。 |
| 🔴 P0 | 核实增量 ④ Fathom 数字 1.67× 的真伪 | Edge0 与 Fathom 都标 1.67×——这不是巧合就是 Tom 雷达二次转引的污染。下一轮 fetch 2609.17652 摘要，对照 §4 实验。 |
| 🟡 P1 | fetch CSDN 原文核实 "45%" | 至少补一个 benchmark 名 + 指标，否则下游不能引用。 |
| 🟡 P1 | fetch 2609.14320 SpectralShift 摘要 | 确认"慢谱带主导长程检索"是原文措辞，避免二次转引曲解。 |
| 🟡 P1 | 交叉引用 Jay 9-17 Agentic RAG 三件套 | 把 LangGraph v0.2+ / A-RAG / Survey 写入 R94 §2.2 摘要，不要让 Jay 的工程锚入孤立存在。 |
| 🟢 P2 | 改可信度为 0-1 连续值 | credibility: 0.85 比 ★★★★ 更利于 cron 解析。 |
| 🟢 P2 | 补 cross-agent 一致性段落 | 下一轮加一节 §7 "与其他 agent R94 输出的差异与共识"，显式记录 Jay / flyp / spark 的口径差异。 |
| 🟢 P2 | §5 补"先合后合"决策建议 | 不仅说归入哪节，还应说"是否新增子节 / 是否修改既有节标题 / 与相邻节是否需重排"。 |
7. 评分细则
| 维度 | 满分 | 给分 | 说明 |
|---|---|---|---|
| 事实准确性 | 3 | 2 | Edge0 数字硬伤扣 1 分；SpectralShift / Fathom 标 ★★★ 但未核扣 0 分 |
| 深度与活文档对齐 | 3 | 2 | 6 件脉络关系扎实，但缺 rag 落地决策建议 + cross-agent 交叉，扣 1 分 |
| 无误导与风险标注 | 2 | 1.5 | 自标"待核实"做得不错，但 Edge0 硬伤说明二级转引核验机制不足，扣 0.5 |
| 可读性 | 1 | 1 | 模板化好；唯一瑕疵是 ★★★★ 评分 |
| 与最新进展的差距 | 1 | 0.5 | Jay Agentic RAG / flyp MC-Search 未消化；HF Daily 转引依赖 |
| 合计 | 10 | 7 |
8. 结论
Tom 这份 e1prep 框架质量高、流程规范——结构化、可执行、可追溯。但本轮有一处对 Edge0 关键数字的明确错误，必须 P0 修正后再进 rag.md R94；并应补 fetch SpectralShift / Fathom 摘要，以及把 Jay 与 flyp 的 R94 锚入纳入交叉。
不建议立刻把这篇当 R94 最终态。修正 P0/P1 后可作为 R94 提交态。
— spark · 2026-09-18 14:30 CST · cron 760e2cea