RAG51 篇实战文章

先说结论：arXiv 2608.16776 这篇 GRIP，值得看。但值得看的是它量出来的那个病，不是它挂在嘴边的那个疗效。 三天前挂的，15 页，3 张图，cs.AI。单作者，Lirui Teng。我一般对单作者论文先压预期。这次压错了，后面收回。

前一阵有篇论文，Shi Zhou 的，做的是 RAG 里“证据效用”的受控实验。整篇论文最扎眼的数字在前几行就露出来了：九个读者模型，在 33% 的共同影响单元上，对同一批证据的判断方向完全相反——同一条证据，到底是帮忙还是帮倒忙，三分之一的格子撞车。

未必。 有人花八个月、两百个实验，试图在纯 CPU、非神经网络的路径上做出 LLM 的替代品，最后承认没做出来。多数人看到这个结果的反应大概是“果然不行”。我倒觉得这是今年我读过最有信息量的失败记录。 他叫 Oleksander。

arXiv 上一篇合规自动化的论文（2608.02472，Roman 他们三个，四大之一内部做的 POC）最近在我时间线上晃了好几回。转的人都拿它当“AI 替代合规审查”的新闻在转。我看了一圈，没人讲它内部是怎么转的。行，那我干我常干的事：当黑箱，画开。

我一直在想，为什么用 embedding 去找“相关代码”这件事，在仓库里会这么容易扑空。上周我又干了一回。 给一个老项目的某个函数补逻辑，我把函数代码完整贴给 LLM，又从仓库里用 embedding 检索捞了五个“最相关”片段塞进去。生成的结果语法对，风格对，测试跑不过。 我回头看了一眼那五个片段。

前几天翻到一篇八月初挂上 arXiv 的论文，做嵌入式 C 代码的函数复用检测。我本来以为是又一篇“用 embedding 找相似代码”的流水线文章——这个方向我绕过弯路，之前画 RAG 那张图的时候就想画“代码相似度”这个口，一直没动手。

前几天翻到一篇八月初挂上 arXiv 的论文，16 个人写的，讲怎么防 RAG 被投毒。本来想扫一眼就关，结果被里面一个结构勾住了——它正好补在我上次画 RAG 那张图漏掉的地方。先别急着看论文，我得把那张图重新画一遍，不然讲不清楚。 上次画完、修正过的 RAG 长这样： 当时我说，RAG 难就难在中间那格“判断”。

8 月 3 号 arXiv 上挂了篇论文，编号 2608.02560，标题一长串，大意是给边缘端语言模型做结构化记忆。我扫了一眼摘要里那个数字就停住了：预填充延迟从约 27 秒降到不到 6 毫秒，约 4500 倍加速，且答案质量跟传统 RAG 相当。 先别急着激动。

前几天翻 arXiv 刷到一篇移动端 RAG 的论文（2608.03148，八月四号挂上去的），讲的事情一句话就能说清：移动设备上跑 RAG，内存和算力都紧，所以只敢留一个检索块；但检索器排第一的那个块，不一定是对回答最有证据价值的那个。他们于是搓了一个选择器，专门负责从候选块里挑出“证据最对齐”的那一个。

『LLM 连个数都数不清』，这话被讲了好几年，讲到现在都快成模型的生理缺陷了。我的判断是：RAG 系统里数错数，锅大半不在模型，在管道。模型只是站在最外面，所以每次都由它背锅。 七月底 dev.to 上有个案例，Rodrigo Diego 写的。我第一眼也以为是“模型数学差”的日常，读完发现根本不是那回事。

速评：RING 这篇论文喊着“完全去除外部检索器”，我不信的是“完全”这两个字。 这剧本，眼熟。三年前就有人说 context window 一长，RAG 就该进坟墓了；之后每隔半年就冒出一篇论文宣布检索步骤是多余的，标题一个比一个狠，结论一个比一个绝对。