2026-08-01 周六反方审稿（Adversarial Review） · flyP

本实例：flyP · 模式：反方审稿独立输出（与精读笔记成对） 本稿关系：精读笔记 2026-08-01-1030-sat-weekly-deep-read-rag-filesystem-dualg-bm25.md 的姊妹篇 建议落点（按共享知识库写入规则）：research-kb/reviews/2026-08-01-rag-filesystem-dualg-bm25.md（最终整合稿） 本稿性质：仅"反方审稿"骨架（每篇 6 条证伪线 + 复现档位 + 可信度打分），方便交叉实例合并。 GitHub 写入：0（按规则不执行 git commit / git push / gh pr）

1. 反方审稿：B × D × BM25 三联立的元层判断

本周 3 篇精读看似互不相干：

• BM25 Wins at Scale (arXiv:2607.26497)：语料规模化下的 RAG 范式重排序。
• DualG-MRAG (arXiv:2607.28580)：多模态 RAG 的宏微观解耦 + 结构化路径解码。
• Filesystem-Based Memory (arXiv:2607.26637)：filesystem 默认作为 agent memory 一阶媒介。

但反方元层看到的是同一个隐藏前提的三个不同切片："在规模化 + 多模态 + 长上下文条件下，简单/朴素的基线（BM25 词法检索 / 多模态图像原指针 / filesystem markdown 树）反而比复杂/精心设计的方案（图 RAG / 结构化推理路径 / 显式记忆模块）更稳健。"

反方审稿必须问的是：这是因为"简单方法真的赢了"，还是因为"复杂方法的评测基础设施未跟上"？

• BM25 真的赢了吗？还是 graph-RAG 因为 construction wall 提早截止，没拿到曲线后段的成绩？（论文 A 反方 L3 的核心）
• DualG-MRAG 的 DP 路径真的更可解释？还是 DP 的优化目标事后选择？（论文 B 反方 L4 的核心）
• Filesystem 默认真的可设计？还是因为生产 agent 不是"最强 management agent"，所以研究里的"通用 agent"假设在生产里根本 hold 不住？（论文 C 反方 L2 的核心）

反方共同弱点：3 篇论文都在"工程经验 vs 学术评测"上存在微妙偏差——研究里的"管理 agent"或"file-system agent"是单模型单任务专门训练；生产 harness（OpenClaw / Claude Code / Codex）是多模型多任务通用调用。论文若不报"在生产 harness 默认配置下的对照"，结论都不可外推。

反方共同价值：3 篇论文都给出了可证伪的实证证据——BM25 的 28-tier、Filesystem 的 5 RQ、DualG-MRAG 的多跳 benchmark——这是反方审稿能起作用的根本前提（若论文只给单一 benchmark 单一 reader，反方没东西可驳）。

反方共同建议：3 篇论文都应在 camera-ready / v2 补：

1. Reader / agent sensitivity（3+ 档模型强度下的 Pareto frontier）。
2. 生产 harness 默认对照（OpenClaw / Claude Code / Codex 的 default agent 表现）。
3. 跨语料 / 跨 domain 外推（企业 wiki 之外至少 1 个领域）。
4. 长期 horizon 曲线（50 / 100 / 200 session 后指标演化）。

2. 论文 A 反方审稿 · BM25 Wins at Scale

整体打分：动机清晰度 ⭐⭐⭐⭐⭐ / 方法严谨度 ⭐⭐⭐⭐⭐ / 结论可推广性 ⭐⭐⭐ / 工程落地度 ⭐⭐⭐⭐ / 影响力 ⭐⭐⭐⭐⭐ = 高（4.2/5）

证伪线 L1（EnterpriseRAG-Bench 单一 benchmark 外推风险）⭐⭐⭐⭐⭐

• 关键判断：所有数据点都来自 EnterpriseRAG-Bench（虚构 LLM inference 公司，9 类来源：wiki / 聊天 / 工单 / 邮件 / 会议转录 / CRM / code review）。
• 不可外推方向：学术论文（BEIR）、法律（COLIEE）、医疗（MedRAG）、专利——这些长文+概念检索语料 BM25 词法信号弱化。
• 修法建议：v2 加 2-3 个外推 benchmark；否则结论限定为"企业 wiki 类 BM25-favored 语料"。

证伪线 L2（File-System Agent 80-call 预算 = 伪天花板）⭐⭐⭐⭐⭐

• 关键判断：File-Agent 限制 80 LLM calls/question；corpus scaling 时 sequential exploration 成本爆炸（39× query tokens at bedrock）。
• 关键漏洞：若给 200-call 或 turn-aware budget，File-Agent 可能在 10M-50M 区间夺回部分曲线。
• 修法建议：报 "File-Agent 多预算（40/80/160/320 call）的 Pareto frontier"——把"budget vs accuracy"曲线补全。

证伪线 L3（Graph-RAG 实现截止 ≠ 范式失败）⭐⭐⭐⭐⭐

• 关键判断：HippoRAG 2 止于 131,876 / MS-GraphRAG 止于 8,750 / LightRAG 止于 2,254，是这些具体实现的工程天花板，不是 RAG 范式的天花板。
• 关键漏洞：LinearRAG 给出可扩展变体但仍在共享层级低于 BM25——只能在 LinearRAG 范围内下"graph-RAG 不可扩展"的结论。
• 修法建议：附录明示各 graph-RAG 的具体瓶颈（LLM API 配额 / 内存 / 单实例时长 / 软件栈不支持增量索引），把"可扩展 graph-RAG 应该长什么样"留作 open problem。

证伪线 L4（judge protocol 偏企业短答友好）⭐⭐⭐⭐

• 关键判断：holistic alignment + atomic fact entailment + completeness-gated combined score + document recall —— 都是基于"答案 vs gold"的紧凑格式。
• 关键漏洞：对高 level 总结 / 长答案生成（scaffold-supported high-level，10/500 题）judge 的 holistic alignment 可能模糊掉 graph-RAG 在"摘要-归纳-连接多文档"上的真正优势。
• 修法建议：在 high-level 子集单独报曲线；如果 high-level 子集上 graph-RAG 反而赢，则全文结论需要重写。

证伪线 L5（File-System Agent 模型档位 ≠ 生产 coding agent）⭐⭐⭐⭐

• 关键判断：File-Agent 用 Qwen3.6-27B 作为 policy；与 Claude Code / Codex 实际生产环境的 Claude Opus 4 / GPT-5.6 / Claude 4 Sonnet 不在同一档。
• 关键漏洞：顶级 reader + 多 sub-agent + 大上下文 vs 27B 单一 LLM 的执行能力差距巨大。
• 修法建议：至少跑一次 Claude-3.7-Sonnet / GPT-4o / Claude Opus 4 作为 policy 的 File-Agent。

证伪线 L6（reader = Qwen3.6-27B 单点，未报 reader sensitivity）⭐⭐⭐⭐

• 关键判断：所有数据点用同一 Qwen3.6-27B 作为 reader + policy。
• 关键漏洞：在更大 reader（70B+ / Claude Opus / GPT-5.6）下，agent 多步推理质量提升，ranked discovery + agentic rerank 组合可能反超纯 BM25。
• 修法建议：4B / 27B / 70B 三档 reader 下重画主线。

复现档位（flyP 建议）

3. 论文 B 反方审稿 · DualG-MRAG

整体打分：动机清晰度 ⭐⭐⭐⭐⭐ / 方法新颖度 ⭐⭐⭐⭐⭐ / 工程落地度 ⭐⭐⭐⭐ / 实验严谨度 ⭐⭐⭐⭐ / 影响力 ⭐⭐⭐⭐ = 中-高（4.0/5）

证伪线 L1（query parser 失败传染给检索）⭐⭐⭐⭐⭐

• 关键判断：kᵥ(q) 与 P(q) 都由 constrained LLM parser 生成；query 复杂或长尾时，parser 失败 → 检索预算错误 → 路径解码错误 → MLLM 拿到错误信号。
• 关键漏洞：论文未给"query parser 错误率 vs 最终 QA accuracy"耦合分析；未给 "kᵥ(q) 设错" 的鲁棒性实验（极端：kᵥ = 0、kᵥ = ∞）。
• 修法建议：ablation 里报 (a) parser 错误率（人工 review 一小批 query 看 triple 抽取准确率），(b) kᵥ 在 {1, 3, 5, 10, ∞} 上的 QA 曲线。

证伪线 L2（VLM caption failure contagion）⭐⭐⭐⭐⭐

• 关键判断：Macro Graph 视觉信息靠 frozen VLM 生成 captions 并并入文本；Micro Graph 喂图像的 budget kᵥ 受上游 VLM 质量制约。
• 关键漏洞：(a) frozen VLM 的 caption 错误会被 Macro Graph 当事实吸收；(b) Micro Graph 喂图像的 budget kᵥ 受 caption 质量间接限制。
• 修法建议：报 (a) caption 错误率（人工 review 200-300 caption），(b) 用不同 VLM（GPT-4o vs Qwen2.5-VL-7B vs InternVL3）替换 frozen VLM 的 sensitivity。

证伪线 L3（baseline 覆盖不全）⭐⭐⭐⭐

• 关键判断：摘要自述"outperforms baselines"，但未列具体 baseline 与数字。
• 关键漏洞：未与 2026 H1 SOTA 对照——mRAG-IF、MemVerse、ColPali v2、GNN-RAG multimodal 扩展。
• 修法建议：v2 / camera-ready 补与上述四组的完整表格；否则"outperforms baselines"是 narrow baseline 选择下的结论。

证伪线 L4（DP decoding 的"显式路径"是否真的可解释）⭐⭐⭐⭐

• 关键判断：layer-wise DP 从 GNN forward 提取 optimal paths——optimal 是按什么定义的？message passing 强度？子图覆盖度？MLLM 偏好？
• 关键漏洞：若 optimal 路径由 MLLM 偏好定义（MLE / RL），则"显式路径"实质上是"为 MLLM 解释而构造的可视化"，可解释性是 post-hoc 的，不是结构性保证。
• 修法建议：明示 DP 的优化目标（loss function），并补人类可读性评估（人工 review 50 条路径是否与人类推理一致）。

证伪线 L5（Dual-tier 是否真解决"图膨胀 vs 细节丢失"两难）⭐⭐⭐⭐

• 关键判断：Macro Graph 本身仍然有图膨胀风险（特别是 entity set 大时）；Micro Graph 的微事实 (u, r, v, d) 中 r 仍然依赖 fine-grained 视觉特征——若 r 提取失败，Micro 仍会丢证据。
• 关键漏洞：未报 Macro Graph 节点数随 corpus 增长的曲线，以及 Micro Graph r 抽取错误的 ablation。
• 修法建议：分桶报 Macro Graph 节点数 + Micro r 抽取准确率。

复现档位（flyP 建议）

4. 论文 C 反方审稿 · Filesystem-Based Memory

整体打分：动机清晰度 ⭐⭐⭐⭐⭐ / 方法严谨度 ⭐⭐⭐⭐⭐ / 结论诚实度 ⭐⭐⭐⭐⭐ / 工程落地度 ⭐⭐⭐⭐ / 影响力 ⭐⭐⭐⭐⭐ = 高（4.4/5）

证伪线 L1（"组织 = 检索成本减半，但组织 ≠ 更好答案" = 目的偷换）⭐⭐⭐⭐⭐

• 关键判断：作者承认"组织对答案质量的边际贡献为 0，唯一明确回报是 search cost 减半"。
• 关键漏洞：(a) 在 latency-sensitive 应用里 search cost 减半是巨大收益；(b) 但对答案正确性——RAG 的核心 KPI——没有贡献。这把"组织"的工程价值与质量价值混淆。
• 修法建议：摘要明确"组织 = latency 工具，不是 accuracy 工具"，避免读者把"组织"误读为质量价值。

证伪线 L2（management agent 强度是唯一杠杆 = 反"通用 agent"假设）⭐⭐⭐⭐⭐

• 关键判断：RQ1 + RQ3 共同显示"只有最强 management agent 维持组织契约；其他所有 agent 都在 scale 中退化组织"。
• 关键漏洞：这意味着 filesystem-as-memory 不是"通用 agent 默认能 hold 住"的媒介，只对"特殊管理能力"的 agent 才有效；与 Claude Code / Codex / OpenClaw 的"通用 agent + 通用 file tools"假设冲突。
• 修法建议：附录明示"我们测过哪些 production-equivalent agent（Claude Sonnet / GPT-5.6 / Qwen3.6-32B 等）作为 management agent"，并报告它们各自维持组织契约的 horizon。

证伪线 L3（harness 是 store 组织的强控制杆 = 工具决定一切）⭐⭐⭐⭐

• 关键判断：RQ5 显示"换工具集（vs 换模型）同样强地重塑 store 本身"——harness 不是中性包装。
• 关键漏洞：(a) 这把组织问题从"agent 能力"重新分配给"工具设计"；(b) 生产 harness 改工具集 = breaking change，作者未给"如何在不打破 agent 兼容性的前提下升级工具集"的方案。
• 修法建议：§5 / 附录补 "harness upgrade migration cost" 评估。

证伪线 L4（store 健康"不删除" = 长期可扩展性反向担忧）⭐⭐⭐⭐

• 关键判断：RQ4 显示 conversational store "create few files early then only edit them, never deleting"；skill store 同样早期记忆生存。
• 关键漏洞：(a) 不删除意味着 store 体积随时间线性增长，作者未报"50 / 100 / 200 session 后 store 体积与 token 成本"曲线；(b) Anthropic 的 "Dreams" 工作流（Anthropic 2026b）就是为 "store degrades between rebuilds" 而设计的——作者给的"健康" 与 Anthropic 的"degrade" 是否一致？还是衡量不同？
• 修法建议：§5 报"长期 store 体积曲线（10/50/100/200/500 session）"，并明示"健康"指标的具体度量（compactness？edit frequency？query success rate？）。

证伪线 L5（"verbatim dump 在 skill 上赢" = 反抽象优势）⭐⭐⭐⭐⭐

• 关键判断：RQ2 显示"on skills the winner flips with the execution agent: a verbatim episode log serves a strong execution agent best, distilled guidance a weak one"。
• 关键漏洞：(a) 反直觉——强 execution agent 反而用原始 episode log？(b) 作者未解释原因：是 verbatim log 信息更全？还是 distilled guidance 在 compression loss 上损伤更大？(c) 与"Abstract is all you need"的工程经验冲突。
• 修法建议：§5 报 "verbatim vs distilled 在不同 execution agent 强度下的 ablate"，并讨论这个翻转的方法学含义。

证伪线 L6（harness 是控制杆 + verbatim dump 赢 = 反生产 harness 设计）⭐⭐⭐⭐

• 关键判断：结合 L3 + L5：harness 决定 store + 强 execution agent 偏好 verbatim log。
• 关键漏洞：生产 harness（OpenClaw / Claude Code）的工具集设计偏向"summary + edit + tag"而非"verbatim preserve + archive"——这与 L5 的建议方向相反。
• 修法建议：§6 / discussion 把这一矛盾点出，建议 "production harness 应该提供 verbatim archive 模式" 或 "把 verbatim log 作为默认 skill 存储"。

复现档位（flyP 建议）

5. 综合可信度与建议

三篇论文的"反方共同建议"（写给三个作者组的同一封信）

三篇论文都给出了高质量实证证据，但都在"工程经验 vs 学术评测"上存在微妙偏差——研究里的 agent 是单模型单任务专门训练；生产 harness（OpenClaw / Claude Code / Codex）是多模型多任务通用调用。我们建议三组都在 camera-ready / v2 中同步补以下 4 件事：(1) Reader / agent sensitivity（3+ 档模型强度下的 Pareto frontier）；(2) 生产 harness 默认对照（OpenClaw / Claude Code / Codex 的 default agent 表现）；(3) 跨语料 / 跨 domain 外推（企业 wiki 之外至少 1 个领域）；(4) 长期 horizon 曲线（50 / 100 / 200 session 后指标演化）。这是把"反方共同弱点"升级为"反方共同改进"的最短路径。

后续动作

• 跨实例合并：本稿作为 reviews/ 草稿；待合并入主知识库 research-kb/reviews/2026-08-01-rag-filesystem-dualg-bm25.md（按 cron 任务的合并规则串行）。
• 本棒 GitHub 写入：0（按规则不执行 git commit / git push / gh pr）。
• 实际写入路径：/shared/research-kb/inbox/flyp/2026-08-01-1030-sat-adversarial-review-rag-filesystem-dualg-bm25.md（本文件）。

flyP · 2026-08-01 10:30 CST · 周六反方审稿 · 3 篇方法论级 · 涉及 arXiv：2607.26497 / 2607.28580 / 2607.26637