RAG82 篇实战文章

为什么 AI 会一本正经地给你一个不存在的网址？ 简单说，不是模型坏了，是它太会把话说圆。上下文不够的时候，LLM 不会卡壳。它会拿旁边的真材料，顺手拼一个像样的答案给你。 这期只收一条。八月底 dev.to 上有篇修复记录，我觉得值得单独占一期。

速评：这篇论文 8 月 30 号挂上 arXiv，到今天六天，我没见一个人把它真正值得聊的那句话挑出来。不是“9B 打平更大模型”，是题目里那个动词：Learning to Navigate。 它把 RAG 的语料观，从“平的”改成了“带结构、可以走的”。 框架本身不玄。

你有没有过这种体验：RAG 系统搭好了，demo 里样样都好，一上真实流量就翻车。第一反应永远是换更强的模型、换更贵的 embedding，折腾一整圈，该翻车还是翻车。dev.to 上那篇被转了一整轮的文章里有个数字：RAG 失败的时候，73% 的情况栽在检索阶段，不是生成阶段。

Rafael Pierre 六月在 Lighthouse newsletter 上发了篇东西，标题大意是：很多团队把 RAG 系统 overcomplicate 了——先上 embedding、上向量库、上 reranking，再做一堆增量优化，结果用户只是想要精确地找到一篇文档。

“上了 RAG，幻觉就压下去了。”这句话在圈子里被重复到快成物理定律了。我以前画 RAG 的时候也顺嘴这么讲过。两周前有人真去数了，八月十四号挂上 arXiv 的一篇（2608.14210），测了八个法律场景的 RAG 系统，语料一边是英文版 GDPR，一边是一部法语的国家民事法律。 结论先甩这儿：幻觉照样遍地都是。

两周前 arXiv 上挂了一篇隐私保护 RAG 的论文。方法说起来一句话就完：用一个轻量级模型认出查询和文档里的敏感实体，给每个实体生成一个别名，建一张替换表，发出去之前先把真名换掉。 就这样。没有密码学，没有可信执行环境，就是换词。 这个办法土到我的第一反应是不屑。

前几天在 arXiv 刷到一篇威胁检测的论文，八月中的，安全方向。本来手指已经划过去了，结果实验结论里有一行，直接推翻了我以前画的一张 RAG 的图。先撂这句：这篇东西最值钱的不是 F1 涨了多少，是它顺手证明了“RAG 是万灵药”这个说法——在强模型身上不成立。 先讲它在干嘛，很快。

RAG 出错就骂模型，这条弯路我绕过，而且绕得比大多数人久。起因是前阵子看到一篇讲 RAG 故障排查的文章——作者用六十来行 Python 搭了个原型，先在六份入职文档上跑顺，然后开始故意找茬。看完我只有一个感觉：她踩的坑我全踩过，还踩得更久。

前两天在 arXiv 上刷到一篇，标题里赫然写着 Six Degrees of Separation。我心想完了，又来一个蹭热词的。结果读了一半发现，歪的不是它，是我——我第一版理解全错了，这回错得还挺有教育意义。 先看我以为的样子。

这期先讲一篇论文。别划走，这条和你天天喂文档给 AI 的那件事，是同一件事。 一篇 8 月 17 日挂上 arXiv 的论文，说 RAG 检索回来的资料可能把模型带沟里 论文编号 2608.16515，三位作者，8 月中旬提交的。 核心说法一句话讲清楚：RAG 不是给了证据就万事大吉。

先说结论：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 写的。我第一眼也以为是“模型数学差”的日常，读完发现根本不是那回事。