这论文的生命周期短得离谱：8 月 2 号上线，8 月 4 号被撤。撤的人不是外人，是共同作者之一。理由写得倒是实在——没完成内部审查和发布授权，属于过早公开。
但撤稿管的是流程，管不住内容。48 小时已经够一篇论文传遍圈子了，我现在坐在这儿写它，就是证据。
这论文现在卡在一个尴尬状态：正式场合你不能引用，但那个核心想法已经在你脑子里长根了。这篇拆完，你会得出和我一样的判断：它提出来的那个转向——上下文构建是策略，不是程序——比“论文被撤”这件事重要一个量级。
论文给要解决的问题起了个名字：表示-推理差距。说人话就是——GraphRAG 往图里存的信息是分层的。最底下是叶子节点，上面是逐级聚拢的 community summaries，不同层级代表不同粒度的知识。固定上下文构建根本不知道，这一次查询到底该用哪一层。
你拿同一个图谱挂两种查询上去，这个差距立刻就漏出来了。查“这两个人共同创办了哪家公司”，你要的是从叶子节点里拉一条精确的事实链回来，多跳一跳少跳一跳都可能答错。查“这个领域最近在热什么方向”，你要的是高层摘要的覆盖面，底层细节全是噪音。固定程序不区分这两种查询，同一套参数去打两种完全不同的仗，差距就是这么来的。
很多人会把这个问题归结成“图不行”，这不准确。图就在那儿，结构对，信息全，坏在“取”这一环。取什么、取哪一层、取多少，这是上下文构建真正在做选择的地方。听着像不像在书架前挑书？这个类比到这儿就该收了——GraphRAG 里根本没有书架，也没有图书管理员能听懂你的问题帮你挑。它是关键词、向量和遍历路径的组合，机制上跟图书馆压根不是一回事。
ACE-GraphRAG 做的事抽象成三步：先评估当前上下文离“能回答这个查询”还差什么；再按缺口决定往哪个方向补；最后按当前任务类型把补回来的信息整理成该有的样子。三步对应论文里的三个名词：差距感知精炼、检索分支、任务条件适应。
光看这三个名字，你会以为它有个独立的评估模块在给上下文打分。我一开始也这么以为，拆完发现没那么玄。模型没有单独的“评估器”，每一轮的差距判断是靠模型在当前上下文上重新采样，隐式完成的。这么讲其实不太严谨，“隐式判断”容易让你觉得是个黑盒，实际上它跟 agent 循环里“看一眼进展再决定下一步”是同一个机制，只是被挪到了上下文构建这个环节上。
接下来是核心：并行差分检索。两个分支并行跑，一个深度导向的事实分支，一个广度导向的语义分支。为什么要两个？因为查询对证据结构的偏好在这儿分叉了：多跳问答要精确的事实链，“深”方向收益高；查询聚焦摘要要熟悉的覆盖面，“广”方向收益高。只留一种检索模式，就必然在两类任务里的某一类上瘸腿。
“差分”这个词值得停一下。说人话就是——它检索的不是“跟查询相关的所有东西”，而是“当前上下文跟回答这个查询所需证据之间的差”。差什么补什么，而不是从头再捞一遍。这一步省的是重复检索的开销，但对策略演化来说，更要紧的是合并回初始上下文的时候，每个证据块会保留自己的来源信息和抽象级别。
合并不是把证据块摞在一起就行。从不同层级捞上来的证据粒度不一样，直接拼，高层摘要会把底层事实的精确性稀释掉，底层事实也会把高层摘要衬得冗长。所以这个合并动作本身就构成一次“按当前任务重组上下文”的工作。保留来源和抽象级别，是为了让重组有依据可循。这跟普通 RAG 的拼接有本质区别：拼接不管上下文里混进了什么，重组知道每一块的来路、知道它在这次回答里该放在什么位置。
有个细节我忍不住插一句，虽然跟机制无关——撤稿之后，这篇文章讨论反而更多了。你可以说 agentic 这个前缀是流量密码，我倾向认为是“表示-推理差距”这个说法戳中了大家的痛点。很多人在自己的 GraphRAG 项目里隐隐感到固定上下文构建不够用，但一直没个名字。现在名字有了，哪怕论文本身被撤了。拉回来，继续说机制。
论文做了两个变体，Full-ACE 和 Adaptive-ACE。Full-ACE 对一个任务族统一套完整策略，Adaptive-ACE 对每个查询单独选择“任务+拓扑”特定的策略。实验里 Full-ACE 已经赢了所有 RAG 和 GraphRAG 基线，但真正有意思的不是赢，是 Adaptive 在 Full 的基础上还能再赢一截——四个 UltraDomain 子集上全被偏好。
这个结果读出来的信息是：上下文构建这个策略，不但要取代固定程序，策略本身也得看情况。“拓扑”在这不是玄乎的词：一个查询命中的节点密集坐在图谱同一个社区里，跟它零零散散落在五六个社区里，需要的取证据方式完全不一样。前者适合顺着社区摘要往上取，后者需要跨社区的语义分支来兜底。Adaptive-ACE 干的，就是每个查询进来的时候按拓扑形状挑一个策略，而不是每条路都走一遍。任务类型可区分、拓扑可区分的时候，per-query 的选择值得多付的那点成本。论文的消融和拓扑分析都朝同一个方向收：上下文构建不是一个固定程序，是一个依赖查询和任务的推理策略。
至于为什么 Adaptive 在 UltraDomain 上优势更明显，论文没展开。我猜是领域内的知识库查询模式和拓扑结构比通用语料更可预测，per-query 策略有更稳定的规律可循。这点我没细查子集构成，只能算合理推测。
不过你先别急着复现或者部署它。论文没法正式引用，最终版会改成什么样也没人知道。但不妨碍你把它当设计思想读：如果上下文构建是策略，你调的旋钮是“策略如何选择证据”，不是“参数怎么配”。这是完全不同的两层东西。
回到开头那个问题：被撤的论文值不值得读？这问题其实已经过时了——因为它已经被读了，讨论已经发生了。撤稿是流程系统的动作，思想是传播系统的产物，两个系统该分开算。ACE-GraphRAG 不管最终版长什么样，都已经把“上下文构建是策略”这个概念钉在了桌面上。后面的人要么顺着它做，要么反驳它做，但很难无视它。
我现在最好奇的倒不是正式版什么时候来，是下一个问题：上下文构建变成策略之后，策略本身由谁来优化？这篇把上下文构建从“程序”推成了“策略”，那下一步自然是策略的超参——谁来决定用 Full 还是 Adaptive，谁来调那个“差距阈值”，agent 能不能在跑的时候自选。这条留到下次拆。