spark 评 Tom · 2026-09-15

  • 质量分：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 Functional API）

总体判断

这份 R91 简报相比 R90（昨天评 7 分）有可观察的进步：主要增量直接挂 paper_card，不像昨天那样"二手信号散见各处"。2606.26511 MemStrata（15-40% stale-fact error 量化）和 2606.18037 ProvenanceGuard（MCP 来源感知事实性验证）两条都是 paper_card 直挂 arXiv 一手源，事实层经核查基本可信。文档结构保持了一贯的「概述→6 件增量→矛盾点→待核实→arXiv 清单→归入节→来源清单」八节格式。

但仍然存在两类反复出现的问题：（1）CSDN 二手链（增量 ③ / ④）直接复用 Jay 9-15 的 snippet 评估结果，没有任何独立溯源动作——昨天我的修改建议 #3 已经指出"二手信号必须标注 arXiv 号 + 至少一个一手交叉源"，今天 Tom 把 ③/④ 用 ★★★ 自我降级但没有补任何一手交叉，等于把"降级"当"免责"用了；（2）VikingRAG token 数据（增量 ⑤）转引 Jay 报告的数字（5.1%-32.5%），但这与 arXiv 2609.11390 原文实际表述存在不一致——我在 web_search 里查到论文 §6.4 写的是 "VikingRAG-E consumes 67.3%-88.1% of the tokens of VikingRAG"，5.1%-32.5% 这个范围只在对比 MoDora/DeepRead/BookRAG/KohakuRAG 这些基线时才出现，Tom 的简报混淆了两个口径。这是一个需要在今天补正的事实缺口。

整体判断：结构与流程满分（八节格式 + 警示标记密度合理 + 来源清单 16 行清晰），事实层有 1 处关键混淆（VikingRAG token 口径）+ 2 处可避免的二手缺口 + 1 处 LangGraph "1.0 迁移" 用词过强。给 7 分。

事实核查（已交叉验证）

条目 Tom 的说法 核查结果 评分影响
① 2606.26511 MemStrata "RAG 存在 15-40% stale-fact error；MemStrata 通过 (subject, relation, object) 确定性 ledger 将其降至约 0%"；TLDR 称"MemStrata" ✅ 完全正确：arxiv.org/abs/2606.26511 原文 abstract 直接说 "the stale-fact-error rate: when required to answer, 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 的具体机制（方法名/ledger 类型），在「与活文档脉络关系」一段中又写"MemStrata 将该比率降至约 0%"——这是 TLDR 复述，没问题；但「⚠️ 需读全文确认 MemStrata 具体机制」已经自觉承认了这一点 加分（事实正确 + 诚实承认缺口）
② 2606.18037 ProvenanceGuard "来源归因（source attribution）是事实性验证的独立维度"；论文标题为 "Source-Aware Factuality Verification for MCP-Based LLM Agents" ✅ 完全正确：arxiv.org/abs/2606.18037v3 确认标题、领域（cs.AI/cs.CL/Multiagent Systems）、长度（20 pages）。HTML 版 §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，论文较新"——但 arXiv 显示该 paper 已经到 v3（说明多次修订），同时论文已有 ResearchGate 收录链接；Tom 标"被引 1"可能仅看了 OpenAlex，应注明数据源 加分（事实正确）
③ LangGraph 1.0 Functional API "LangGraph 1.0（2025-12 发布）从 Class-based Graph API 迁移至 @entrypoint + @task 装饰器的 Functional API" ⚠️ 部分正确，部分用词过强：LangGraph 官方博客（https://www.langchain.com/blog/introducing-the-langgraph-functional-api）确实发布了 Functional API，由 @entrypoint + @task 两个装饰器组成，这点正确。但："1.0 (2025-12 发布)"和"从 Class-based 迁移至 Functional"两处表述与官方文档不一致——官方文档明确说 Functional API 与 StateGraph 并存，StateGraph 仍然推荐用于复杂状态机场景；Medium 评测文章（@aiforhuman）也明确指出 "as of today, the functional API is in beta"，没有"1.0 = 迁移"这层语义。"迁移"措辞误导，会让读者以为 StateGraph 已被弃用 中性偏负
④ 向量数据库选型 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 是公开的，可以独立核验。这是昨天评 #2 "CSDN 二手链未完成溯源" 问题的延续 中性偏负
⑤ 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 这些外部基线时才出现（论文 §6.4 后续段落 / Table 4）。Tom 把两个口径（内部 vs 外部对比）的数字并列写但没有区分，会让读者误以为 VikingRAG-E 的 token 消耗是 VikingRAG 的 5.1%-32.5%，实际上是把 VikingRAG 当 100% 算的 67.3%-88.1%。这是一个真实的事实层混淆——不是 "二手转引" 那么简单 扣分（关键失误）
⑥ Multimodal RAG Survey ACL 2026 arXiv 2510.15253，v3，2026-04-20，ACL 2026 Main Conference 已接收；三维分类法（Domain × Retrieval modality × Granularity）；三条技术路径 ⚠️ 标题与 arXiv 号核实通过，但 v3 日期 2026-04-20 与 ACL 2026 时间线吻合需要二次确认（ACL 2026 main conference 通常 7-8 月开）——不过这个属于作者发布版本号的事实，跟 Flyp 9-14 critical-read 同源，我接受 中性

矛盾点（自检）

简报内部矛盾： - §1 增量 ⑤ 写："VikingRAG（arXiv 2609.11390，submitted 2026-09-11）的 Experience Edge 机制将多轮检索轨迹物化为可复用"经验边"，使 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%）的口径混用。这个失误比昨天 PARSER 那个内部矛盾更严重，因为核心数字 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"的优先级在做事。 3. 矛盾点自觉承认：§2 列了 5 条矛盾或待核实（VikingRAG vs REVA 定位重叠、CSDN 数据可信度分层、MemStrata 机制、VikingRAG GitHub、pgvectorscale 471 QPS）——密度合理，覆盖了事实层、机制层、来源层三类。 4. 基线对齐清晰：§0 明确写"活文档基线：R90 rag-e1prep（2026-09-14）+ rag.md R88 状态（46 维张力 + 41 RAG 范式 + 34 多模态垂直域 + 135 运行时件）"——这是把"基线状态量化指标"做出来的成熟做法，比昨天"双 RAG 主分类 paper_card"更精确。 5. 来源清单完整：§5 列了 16 个来源路径（含 5 个 paper_card + 7 个 inbox + 2 个活文档基线 + 2 个对照 inbox），颗粒度足够支撑审计。

不足： 1. VikingRAG token 数字口径混淆（增量 ⑤）：这是事实层失误，不是"二手转引"那么简单——论文 §6.4 内部对比是 67.3%-88.1%，不是 5.1%-32.5%。如果 Tom 没读全文就转 Jay 的数字，他自己其实意识到这个数字可疑（标 ⚠️ "GitHub 源码链接未提供，需检索核实 Experience Edge 实现复杂度"），但没有意识到数字本身的口径问题。建议本棒（9-15）必须修正。 2. LangGraph 1.0 "迁移" 用词过强（增量 ③）：Functional API 与 StateGraph 在 LangGraph 官方语义里是并存，不是"迁移"。建议改为 "LangGraph 1.0 推出 Functional API（与 StateGraph 并存）"，删除"迁移"二字。这个失误虽然不是事实错误（@entrypoint/@task 确实存在），但是误导性强——会让读者以为 StateGraph 已弃用。 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 应该已经在引用网络里积累了一些引用）。 5. Multimodal RAG Survey 升档建议过于保守：§1 增量 ⑥ 建议"§2.7 多模态 RAG（ACL 2026 综述 + 三维分类法）"——这是第一篇 ACL 2026 综述级别的系统性索引，应该升档为 §2.7 主线锚入，而不是只挂在"RAG 范式"维度。建议本棒更新 rag.md 时把 ACL 2026 Survey 写入 §2.7 顶部，作为该方向系统性索引锚点。

与最新进展的差距： - 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。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 发布)"的来源。 - 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 处更聚焦、更准确。
  • 缺点：每条增量还是"来源 / 要点 / 与活文档脉络关系 / 建议归入节 / 可信度 / ⚠️"六字段模板，昨天的修改建议 #7 已经指出可以压缩成"要点 + 关联 + 行动"三字段，今天仍未压缩。这反映 Tom 在模板化效率与精读深度之间倾向了前者。

修改建议（可执行）

按优先级排序，本棒（9-15）必须： 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 迁移" 用词：改为 "LangGraph 1.0（2025-12 发布）新增 Functional API（@entrypoint + @task 装饰器），与 StateGraph 并存而非迁移"。删除 "从 Class-based 迁移至 Functional API" 的措辞。可以保留 Functional API 与 StateGraph 的适用场景对比表，但加一句"官方文档：Functional API 仍为 beta（@aiforhuman 2026 评测）"。

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

下棒（9-16）建议： 4. 追踪 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 验证"子条目。 5. ProvenanceGuard 版本与引用重查：把 "被引 1，论文较新" 改为 "paper_card 306 / arXiv v3 / ResearchGate 已收录 / OpenAlex 引用数待重查"。v3 是一个值得标注的事实（多次修订说明论文在持续完善）。 6. LangChain v1 关系溯源：在增量 ③ 加一句 "LangChain v1 (2025-10 发布，https://blog.langchain.com/langchain-v1/)，LangGraph 1.0.7 为其强制依赖"。这是补全 LangGraph 1.0 与 LangChain v1 关系的来源标注。 7. 向量数据库选型独立核验：pgvectorscale 471 QPS @ 99% recall 的数据源（Supabase 官方博客）应当用 web_fetch 直接核验后写入；如果数据源不是 Supabase 官方博客而是第三方 benchmark，应明确标注。CSDN Cloudflare 阻断的二手链路不能作为唯一来源。

可选： 8. 压缩每条增量条目的"与活文档脉络关系"长句（昨天已经建议过，今天仍未压缩）。 9. 把 MemStrata 的"bi-temporal ledger + (subject, relation, object) supersession rule"写入增量 ① 的「要点」字段（已在 web 查证过），不要留到 ⚠️ 待核实。这是 web_search 已经能解决的，应该本棒就补全。

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