前几期塞得满，这周只收一条。
不是没动静。是动静都太吵，挑不出一句能对普通人讲清楚的白话。吵的那些下周再说。
留下来的这条，8 月 25 号挂在 arXiv 上，cs.CL，交叉到 cs.IR，作者两个人。标题里有个 Less can be More。这种标题一般两种下场，要么标题党，要么真把常识说反了。
这条是后者。
RAG 慢，慢在哪
最近总有人问，RAG 优化到底该动哪一段。
简单说，以前默认慢在生成。所以大家都在压上下文、优化服务、换更快的推理。
这篇说，不一定。
RAG 是个端到端系统。瓶颈会随服务负载在两段之间跑来跑去。查询速率一高，或者重排预算给得大，先扛不住的是上游重排序，不是生成。
这个道理在分布式系统里讲了很多年。你优化掉一个环节，瓶颈就搬到下一个环节去。搬到 RAG 上，很多人当没有这回事。
而且重排序这个环节，普通人几乎从不碰。它躲在框架里，不出问题你根本不知道它在跑。
砍预算谁都会，难的是砍哪几个
重排太慢，最省事的做法是少排几篇。
代价它自己也认。丢掉支撑性证据，召回往下掉。
PACE 这个框架给的是另一种砍法。不按单条相关度排，按边际证据覆盖度排。这条跟已经选进去的那些，互补不互补，能不能把多跳链上缺的那一环补上。
一刀砍掉的是最冗余的，不是最不相关的。
这个区别挺大。相关度排名前十的那几条，往往在说同一件事。留下一条就够，剩下的位置应该给别处的证据，而不是继续堆同义重复。
作者证明了这个排序目标是单调子模的，所以贪心选就能拿到 1-1/e 的近似保证。方法本身不算新，新的是把它放在这个位置上用。
免训练，这三个字我多看了一会儿
现在什么东西都得先训个模型。这篇不用训，直接套在现成的重排器上。
它除了砍，还会调。重排器和大模型两边谁的相对压力大，预算就往另一边挪。名字起得挺正经，叫压力自适应预算。说白了是个动态配额的活。
验证到什么程度
三个多跳问答数据集，加一个在线服务模拟。
证据召回率上去了。重排负载重的场景下，p95 延迟下来了。
这是模拟。真跑在生产线上的样子，我不知道。三个多跳问答数据集的规模，也谈不上多扎实。
先放在这里。
普通人能抄的部分
道理是可以抄的。
你在 Claude Code 或者 Cursor 里挂 MCP 接自己的笔记，本质上就是个小号 RAG。有个常见的坑是把整个文件夹一次塞进去，塞得越满它反而越抓不住重点。
同样的文件，把总览或者索引那篇放最前，先给三篇，不够再加，效果经常比一次给三十篇好。
这跟论文没关系，是同一个道理的白话版。证据密度比证据数量重要。
现在大家都在比 context window 谁大。窗口大是一回事，该不该塞满，是另一回事。这两件事容易被混成一件。
没吃透的地方
两个组件耦合的那部分，我只看懂了一半。
为什么按边际覆盖度排出来的结果能直接对上延迟，作者给的解释我读了两遍，还是有点绕。先放在这里，等我搞明白再补一句。
有读透的，愿意回来给我讲讲的，更欢迎。
本周就这些。
下周见。