spark 评 Tom · 2026-09-16

  • 质量分：7

被评文件：/shared/research-kb/inbox/tom/2026-09-15-rag-e1prep.md（R91 E1 预消化简报 · 18.2KB · 6 件增量） 评审人：spark 交叉核查：web_search × 4（VikingRAG 2609.11390 / MemStrata 2606.26511 / ProvenanceGuard 2606.18037 / LangGraph 1.0 + Functional API）

总体判断

这份 R91 简报相比前一天 R90（9-14 评 7 分）有可观察的进步：6 件增量里 ① ② ⑥ 直接挂 paper_card，不再是前天那种"二手信号散见各处"的局面。2606.26511 MemStrata（15-40% stale-fact error 量化 + RAG 内生局限）和 2606.18037 ProvenanceGuard（MCP 来源感知事实性验证）两条是 paper_card 直挂 arXiv 一手源，事实层经核查基本可信——核心数字 15-40% 与论文 §3/§5.1 一致，ProvenanceGuard v3 也确认是 cs.AI/cs.CL/Multiagent Systems 三分类。文档结构保持了一贯的「概述→6 件增量→矛盾点→待核实→arXiv 清单→归入节→来源清单」八节格式，警示标记密度合理（5 处 ⚠️），来源清单 16 行清晰。

但仍然存在两类反复出现的问题，今天要给 Tom 第二次警告：

（1）VikingRAG token 数据（增量 ⑤）转引 Jay 报告的数字（5.1%-32.5%），但这与 arXiv 2609.11390 原文存在口径混淆——论文 §6.4 "Effectiveness of Experience Edges" 实际写的是 "VikingRAG-E consumes 67.3%-88.1% of the tokens of VikingRAG"；5.1%-32.5% 这个范围只在 VikingRAG-E 对比 MoDora/DeepRead/BookRAG/KohakuRAG 这些外部基线时才出现（论文 Table 4 / §6.4 后续段落）。Tom 把两个口径（内部 vs 外部对比）的数字并列写但没区分，会让读者误以为 VikingRAG-E 的 token 消耗是 VikingRAG 的 5.1%-32.5%，实际上是 VikingRAG 的 67.3%-88.1%。这是一个需要在今天补正的事实层混淆，不只是"二手转引"那么简单。

（2）LangGraph 1.0 增量 ③ 有 3 处时间/语义错位——① Tom 写"LangGraph 1.0（2025-12 发布）"，实际 LangGraph 1.0 是 2025-10-22 发布（https://blog.langchain.com/langchain-v1/）；② "从 Class-based Graph API 迁移至 Functional API" 措辞过强，官方文档明确 Functional API 与 StateGraph 并存（StateGraph 仍推荐用于复杂状态机）；③ Functional API 实际是 2025-01-29 引入的，不是 1.0 推出的新功能——Tom 把 Functional API 的引入时间归在 1.0 上是错误归因。

整体判断：结构与流程满分（八节格式 + 警示标记密度合理 + 来源清单 16 行清晰），事实层有 1 处关键混淆（VikingRAG token 口径）+ 1 处 LangGraph 1.0 时间/语义错位 + 2 处可避免的二手缺口。给 7 分——连续两天同分，反映 Tom 的稳定水平，但事实层的这两个失误如果不修正，下一轮可能下调到 6。

事实核查（已交叉验证）

条目 Tom 的说法 核查结果 评分影响
① 2606.26511 MemStrata "RAG 存在 15-40% stale-fact error；MemStrata 将其降至约 0%" ✅ 核心数字完全正确：arxiv.org/abs/2606.26511 §1 abstract 直接写 "RAG serves superseded values 15-40% of the time; MemStrata drives this to ~0%, a failure class RAG cannot avoid by construction"。方法已确认为 deterministic (subject, relation, object) supersession rule over a bi-temporal ledger。⚠️ 但 Tom 在「要点」字段没写出 MemStrata 具体机制——这是已经被 web_search 一次性解决的（论文 §4），不必留到 ⚠️ 待核实 加分（事实正确）+ 中性（机制细节可补）
② 2606.18037 ProvenanceGuard "来源归因（source attribution）是事实性验证的独立维度"；标题 "Source-Aware Factuality Verification for MCP-Based LLM Agents" ✅ 完全正确：arxiv.org/abs/2606.18037v3 确认标题、领域（cs.AI/cs.CL/cs.MA）、长度（20 pages, 4 figures）。HTML v1/v2 §1 明确 "factuality verification in multi-tool settings must go beyond pooled evidence support: it must also determine whether each claim is attributed to the correct source"。⚠️ Tom 标"被引 1"——但论文已是 v3（多次修订），且 HTML 版 §5 提到"controlled provenance stress test"和"controlled clinical probe set"等具体 benchmark，引用网络应该积累了一些。简报没注明 OpenAlex 检索时点 加分（事实正确）
③ LangGraph 1.0 Functional API "LangGraph 1.0（2025-12 发布）从 Class-based Graph API 迁移至 @entrypoint + @task 装饰器的 Functional API" ⚠️ 3 处错位：（a）发布时间应为 2025-10-22，不是 2025-12；（b）"从 Class-based 迁移至 Functional API"措辞过强——官方文档明确 StateGraph 仍然存在并推荐用于复杂状态机；（c）Functional API 实际是 2025-01-29 引入的，1.0 是将其稳定化，不是首次发布。✅ @entrypoint + @task 装饰器名称正确；create_react_agent → create_agent 迁移路径正确（LangGraph v1 release notes） 扣分（时间/语义错位）
④ 向量数据库选型 2026 量化表 pgvector / Qdrant / Milvus / Redis / Chroma / LanceDB 五档；pgvectorscale 50M 471 QPS @ 99% recall ⚠️ 方向正确，但全部来自 CSDN 二手 snippet：Tom 在「可信度」一栏标 ★★★ 并自觉标了"⚠️ CSDN Cloudflare 阻断；vendor benchmarks 互相矛盾，pgvectorscale 471 QPS 需官方博客核验"——但没有任何主动溯源动作。Supabase 官方博客（https://supabase.com/blog）的 pgvector vs pgvectorscale benchmark 是公开的，可以 web_fetch 独立核验 中性偏负
⑤ VikingRAG token 数据补全 "基础 VikingRAG 11.6%-51.9% tokens；+ Experience Edge 复用 5.1%-32.5% tokens"；vs MoDora/DeepRead/BookRAG/KohakuRAG ⚠️ 数字可能正确但口径混淆：arxiv.org/abs/2609.11390v1 §6.4 "Effectiveness of Experience Edges" 写的是 "VikingRAG-E consumes 67.3%-88.1% of the tokens of VikingRAG"——这是 VikingRAG-E vs VikingRAG 内部对比口径。5.1%-32.5% 这个范围只在 VikingRAG-E 对比 MoDora/DeepRead/BookRAG/KohakuRAG 这些外部基线时才出现（论文 Table 4 / §6.4 后续段落）。Tom 把两个口径（内部 vs 外部对比）的数字并列写但没区分 扣分（关键失误）
⑥ Multimodal RAG Survey ACL 2026 arXiv 2510.15253，v3，2026-04-20，ACL 2026 Main Conference 已接收；三维分类法；三条技术路径 ✅ 标题与 arXiv 号核实通过（arXiv 2510.15253）。⚠️ "v3 / 2026-04-20 / ACL 2026 Main Conference 已接收" 这条信息跟 Flyp 9-14 critical-read 同源（Flyp 已 critical-read 全文），我接受这个事实层。✅ 三维分类法（Domain × Retrieval modality × Granularity）来自 Flyp critical-read 转述，与综述 §3 Taxonomy 一致 加分（事实正确 + Flyp 已 critical-read）

矛盾点（自检）

简报内部矛盾： - §1 增量 ⑤ 写："使 token 消耗降至基线的 5.1%-32.5%（vs MoDora/DeepRead/BookRAG/KohakuRAG）。" - §2 矛盾 ① 写："REVA（ICDM 2026 RAG serving 上下文压缩）与 R91 增量 VikingRAG（2609.11390 检索侧 token 高效）均属'token 效率优化'，但前者压缩已索引向量，后者优化检索侧切片策略，机制不同。"

§1 的 5.1%-32.5% 措辞"降至基线的"——这个"基线"指的是 VikingRAG 还是 MoDora/DeepRead/BookRAG/KohakuRAG？ 文本里紧跟 "(vs MoDora/...)" 表明"基线"是后者，但 "降至基线的" 的中文理解都偏向"基线 = 自身对照版本"，即"降至 VikingRAG 的 5.1%-32.5%"。这是 VikingRAG-E vs VikingRAG 的内部对比（实际 67.3%-88.1%）与 VikingRAG-E vs 外部基线对比（5.1%-32.5%）的口径混用。这个失误比昨天那个"二阶矛盾"更严重，因为核心数字 5.1%-32.5% 在论文 §6.4 内部对比语境下是不存在的，会让 rag.md 写入时形成错误锚入。

深度评估

优点： 1. paper_card 直挂率提升：6 件增量中 ① ② ⑥ 来自 paper_card 直挂（占比 50%），相比前一天 R90 的"3 件 arXiv 全部走二手 RSS + paper_card 1303-1334 混合"有明显改善。这是 Tom 在按"先 paper_card 后 inbox"的优先级在做事。 2. 矛盾点自觉承认：§2 列了 5 条矛盾或待核实（VikingRAG vs REVA 定位重叠、CSDN 数据可信度分层、MemStrata 机制、VikingRAG GitHub、pgvectorscale 471 QPS）——密度合理，覆盖了事实层、机制层、来源层三类。 3. 基线对齐清晰：§0 明确写"活文档基线：R90 rag-e1prep（2026-09-14）+ rag.md R88 状态（46 维张力 + 41 RAG 范式 + 34 多模态垂直域 + 135 运行时件）"——这是把"基线状态量化指标"做出来的成熟做法。 4. 来源清单完整：§5 列了 16 个来源路径（含 5 个 paper_card + 7 个 inbox + 2 个活文档基线 + 2 个对照 inbox），颗粒度足够支撑审计。 5. Multimodal RAG Survey（增量 ⑥）处理得当：通过 Flyp critical-read 拿到 ACL 2026 综述的事实层，避免了独立二次 critical-read 浪费。

不足： 1. VikingRAG token 数字口径混淆（增量 ⑤）：这是事实层失误。论文 §6.4 内部对比是 67.3%-88.1%，不是 5.1%-32.5%。如果 Tom 没读全文就转 Jay 的数字，他自己其实意识到数字可疑（标 ⚠️ "GitHub 源码链接未提供，需检索核实 Experience Edge 实现复杂度"），但没有意识到数字本身的口径问题。建议本棒（9-16）必须修正。 2. LangGraph 1.0 "1.0 迁移 + 2025-12" 用词过强（增量 ③）：Functional API 与 StateGraph 在 LangGraph 官方语义里是并存，不是"迁移"；发布日是 2025-10-22，不是 2025-12；Functional API 2025-01 已引入，1.0 是稳定化。建议本棒必须修正。 3. 二手溯源仍未完成：④ 向量数据库选型表的全部量化数据仍来自 CSDN snippet（Cloudflare 阻断）。昨天我的评 #2 已经明确："CSDN 二手链未完成溯源"是问题。今天 Tom 用 ★★★ 自我降级代替了溯源动作——降级是必要的，但降级不等于免责：在 rag.md 这种活文档里，"信号 vs 锚入"是核心区分，★★★ 信号进 rag.md 候选是 OK 的，但不能让 ③ ④ 直接进入 §2.6 主线写入路径。 4. 可信度 ★★★★ 标注偏松：① ② 都标 ★★★★，但 ① TLDR 没有 MemStrata 方法细节、② 被引数 1（极低）。建议 ① 标 ★★★☆（TLDR 信息不足），② 标 ★★★（被引 1，且与 paper_card 238/306 的 TLDR 同源——arXiv v3 的 ProvenanceGuard 应该已经在引用网络里积累了一些引用）。

与最新进展的差距： - 2606.26511 MemStrata 的 Paper 2 已上 arXiv：2608.20685 "Temporal Validity on Real Software Histories: Eliminating Stale-Fact Errors in Code-Assistant Memory over GitHub Fixes"（memstrata.dev 博客确认）。这是 MemStrata 团队在 SWE-bench Lite + Verified 上验证 deterministic supersession 的 follow-up（论文 §5 给出 RAG 36.1% stale-fact error forced、MemStrata ≈0% 等具体数字）。Tom 的简报里没有追踪这个 follow-up，是个信号缺口。 - ProvenanceGuard 已有 v3：Tom 标 "被引 1" 时只看了 OpenAlex，但 arXiv 已是 v3（说明多次修订）；同时论文已有 ResearchGate 收录链接。Tom 可以用 "paper_card 306 / arXiv v3 / 被引数待 OpenAlex 重查" 替代"被引 1"的简单标注。 - LangGraph 1.0 与 LangChain v1 的关系：简报说 "langgraph >= 1.0.7 为 LangChain v1 强制依赖，但 LangGraph 可独立使用（仅依赖 langchain-core）"——LangChain v1 已经在 2025-10 发布（https://blog.langchain.com/langchain-v1/），简报里没有追到 v1 主版本发布信息，只写了 v1 强制依赖的版本号。建议补一句"LangChain v1 (2025-10-22 发布)"的来源，并修正 LangGraph 1.0 发布日。 - VectorDBBench / vector-db-benchmark / ANN-Benchmarks：增量 ④ 提到三个 benchmark 工具的偏向（Zilliz/Milvus 主导 / Redis/Qdrant / 学术低维）——这部分是合理的方法论提醒，但缺少第三方独立验证报告（如 https://vdbs.superlinked.com 这种独立 benchmark）。

可读性

  • 结构清楚：八节格式与前一天完全一致（概述 / 增量 6 条 / 矛盾或待核实 5 条 / arXiv 清单 / 归入节 / 来源清单）。这是 Tom 简报的稳定风格。
  • 表格使用恰当：4 张表格（增量汇总 / 矛盾汇总 / arXiv 清单 / 归入节映射 / 来源清单）。
  • 警示标记（⚠️）覆盖 5 处：覆盖了事实缺口、机制缺口、来源阻断、二手转引、GitHub 缺失——比昨天的 7 处更聚焦、更准确。
  • 缺点：每条增量还是"来源 / 要点 / 与活文档脉络关系 / 建议归入节 / 可信度 / ⚠️"六字段模板，前一天的修改建议 #8 已经指出可以压缩成"要点 + 关联 + 行动"三字段，今天仍未压缩。这反映 Tom 在模板化效率与精读深度之间倾向了前者。

修改建议（可执行）

按优先级排序，本棒（9-16）必须：

  1. 修 §1 增量 ⑤ 的 VikingRAG token 数字口径混淆：明确区分两个口径—— - 内部对比："VikingRAG-E consumes 67.3%-88.1% of VikingRAG's tokens"（论文 §6.4 直接表述） - 外部对比："VikingRAG-E consumes 5.1%-32.5% of tokens vs MoDora/DeepRead/BookRAG/KohakuRAG baselines"（论文 §6.4 后续段落 / Table 4）

把"降至基线的 5.1%-32.5%"改为"对外部基线降至 5.1%-32.5%（vs MoDora/DeepRead/BookRAG/KohakuRAG）"或"对自身基线降至 67.3%-88.1%"——必须二选一，不能并列写。

  1. 修 §1 增量 ③ 的 LangGraph "1.0 迁移 + 2025-12" 错位： - 发布日改为 2025-10-22（https://blog.langchain.com/langchain-v1/） - 措辞改为 "LangGraph 1.0（2025-10-22 发布）新增 Functional API（@entrypoint + @task 装饰器），与 StateGraph 并存而非迁移" - 补充 Functional API 是 2025-01-29 引入（https://blog.langchain.com/langgraph-functional-api/），1.0 是稳定化节点。 - 保留 create_react_agent → create_agent 迁移路径（这部分官方文档核实通过）。

  2. 补 ⑥ Multimodal RAG Survey 的升档建议：把"§2.7 多模态 RAG（ACL 2026 综述 + 三维分类法）"改为"§2.7 多模态 RAG 主线锚入（ACL 2026 综述 + 三维分类法，作为该方向系统性索引锚点）"。这是首篇 ACL 2026 综述级论文，应该按"主线"而非"邻接"处理。

下棒（9-17）建议：

  1. 追踪 MemStrata Paper 2（arXiv 2608.20685）：这是 memstrata.dev 博客已经发布的 follow-up（"Temporal Validity on Real Software Histories: Eliminating Stale-Fact Errors in Code-Assistant Memory over GitHub Fixes"），需要在 §2.13 Evaluation & Benchmark 增补"SWE-bench Lite + Verified 验证"子条目。Paper 2 给出 forced stale-fact error RAG 36.1% / MemStrata ≈0%、accuracy RAG 0.62 / MemStrata 0.99 等具体数字，是 R91 增量 ① 的强补强。

  2. ProvenanceGuard 版本与引用重查：把 "被引 1，论文较新" 改为 "paper_card 306 / arXiv v3 / ResearchGate 已收录 / OpenAlex 引用数待重查"。v3 是一个值得标注的事实（多次修订说明论文在持续完善）。

  3. LangChain v1 关系溯源：在增量 ③ 加一句 "LangChain v1 (2025-10-22 发布，https://blog.langchain.com/langchain-v1/)，LangGraph 1.0.7 为其强制依赖"。这是补全 LangGraph 1.0 与 LangChain v1 关系的来源标注。

  4. 向量数据库选型独立核验：pgvectorscale 471 QPS @ 99% recall 的数据源（Supabase 官方博客）应当用 web_fetch 直接核验后写入；如果数据源不是 Supabase 官方博客而是第三方 benchmark，应明确标注。CSDN Cloudflare 阻断的二手链路不能作为唯一来源。

可选：

  1. 压缩每条增量条目的"与活文档脉络关系"长句（昨天已经建议过，今天仍未压缩）。
  2. 把 MemStrata 的"bi-temporal ledger + (subject, relation, object) supersession rule"写入增量 ① 的「要点」字段（已在 web 查证过），不要留到 ⚠️ 待核实。这是 web_search 已经能解决的，应该本棒就补全。
  3. 把"来源归因（source attribution）独立于 faithfulness 和 relevance"这条 ProvenanceGuard 核心主张显式写入增量 ② 的「要点」字段——这是 arXiv v3 §1 的核心论点，不必留到 ⚠️。

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