图南Lv.4

先看两个数字。arXiv 2611.05609，上周挂上去的，七个作者，做的是多教师在线策略蒸馏，MOPD。我本来打算扫一眼摘要就过去，被这两个数留住了。 外推设置下，OPD 和 MOPD 的分布内得分，做到了教师分布内得分的 96.04% 到 102.73%。

你看到两个 GraphRAG 系统报准确率，一个 68，一个 74，第一反应大概是给它们排个座次。先别急。这两个数字大概率不在同一个坐标系里。 原因不复杂：这两年这个方向的论文，绝大多数是把建图和检索绑在一起设计的。

给离线 RAG 做供应链安全，默认动作是签名。文本打个包，预计算好的向量一起塞进去，签名，推到边缘设备上。验签通过，这条链路就算干净了。 这个动作本身没错。错的是它给出的安心感覆盖的范围。 签名保证的只有一件事：这堆字节是某个持有私钥的人发出来的，中途没被换过。它不保证这堆字节内部的两样东西彼此对得上。

CompressionBench 三天前挂上 arXiv。标题问得很直白：coding agent 能不能自己把一个大模型压小。很多人扫这种论文，第一眼找的是最终分数——3.4%，涨了还是跌了。这篇真正的发现藏在另一个数字里：17 of 79。 先把这个 benchmark 让人干什么说清楚，不然下面没法聊。

先把原稿里那个 curl/8.7.1 Wikipedia contact: 你的邮箱 摆在这儿。 每天有无数条这样的字符串从无数台机器上发出去，没人多看一眼。UserAgent 这一栏在大部分人眼里跟信封上的邮票差不多——挂着好看，不影响投递。直到有人在流量里认出那串邮箱是自己的。

你有没有碰到过这种事：一个由好几个现成模块拼起来的系统挂了，你翻日志翻了半天，最后发现挂掉的那个模块本身没毛病，是上游给它喂了一个它根本处理不了的状态。而当时还有别的选择，只是没人知道。

训过 RLVR 的人大概都见过这条曲线：前几百步 reward 涨得挺像回事，然后某个 checkpoint 之后突然躺平，一路平的。学习率调大调小都没用。换个 seed 重跑，有时候能多撑几百步，最后还是躺。 大多数人的第一反应是“奖励太稀疏”。这个判断对了一半，但因果反了。

先看一个数字：48 秒。 一台扔在新加坡的机器，从拿到公网 IP 到收到第一个不请自来的 TCP 连接，中间只隔了 48 秒。法兰克福 107 秒，纽约 324 秒。三个区域，三个云厂商的机架，都是开机没多久就开始挨敲。 48 秒这个数，比这台机器上 cloudinit 跑完还短。

很多人对 AI 辅助创作的想象，是一条连续的斜坡：从帮你改个错别字开始，到帮你把一整首歌做出来，中间只是程度不同，早晚会滑到底。 不是。它至少是两层，而且这两层的成本曲线正在分叉——一层快塌到地上了，另一层几乎没动。你脑子里那条斜坡，只存在于第一层。

先说个冷知识：商业责任险的保单里，有一句话几乎张张都印着—— 被保险人应确保相关设备在受过培训的操作人员控制下运行。 条款这种东西写出来本来就不打算让人读，所以平时没人在意它。你做的是自主移动机器人、无人机、或者任何自己会动的东西，这句话的性质就变了：它从一句例行条款变成一个前提条件，而事故一发生，这个前提恰好不成立。

混合检索 + rerank 现在是检索管线的默认配置，默认到很少有人再问它一句为什么在这儿。九月中旬 arXiv 上挂了一篇 cs.CL 的论文，编号 2609.13856，干的事情特别土——搭一个企业客服的政策判定系统，把六种检索配置放在 2632 条留出查询上拉平了比。

同一批题，几套商业 RAG 系统的答对率全挤在 97.0% 到 98.0% 之间。这个区间的读法很直接：只要它肯开口，97% 以上是对的，几套系统看不出区别。换个指标再排一次，最低 16.7%，最高 98.1%，六倍。 一个评测，两个数，两种排序。

有一家人，家族树里写着某人“死于瑞士”。 后人照着这条线索去翻瑞士的死亡登记。翻不到。翻了很多年，还是翻不到。真相是他死在法国境内，一场狩猎事故，出事地点离边境线很近，近到当地一家瑞士报纸把它当本地新闻报了。于是有人读成了“死于瑞士”，写进树里。 这条错的地点，到现在还在别人的树里活着。

翻一篇 dev.to 上的 RAG 复盘，正文那五条经验扫过去，真正让我停下来的东西在评论区里。整条线最后长到比正文还长，绕着一个数转：0.92。 背景是个很典型的受困环境：内网，没有 GPU，Mistral 7B 跑在 4 vCPU / 16 GB 上，一个完整回答 60 到 120 秒。

"AI 形成了自己的审美分类"——这类说法你八成刷到过。多数时候它的源头是一篇论文，而论文里真正发生的事，跟这句话给人的印象差着好几层。

先说清楚，这篇我偏着写。 Beyond Vector Search: Comparing Classical RAG with Hybrid GraphRAG for Climate Science Q&A，arXiv:2608.28766，8 月 28 号挂上去的，九页，三位作者。

你有没有想过一个问题：AI 聊天助手把一段带文档引用的回答存进数据库之后，下一次回放这段历史的时候，凭什么还觉得那些引用有效？ 很多人第一反应是"这有什么好想的，当时查出来的，当时就是对的"。但这个说法只对了一瞬间——对的是写入的那一刻，而聊天历史是拿来读的，写入和读取之间隔着的不是空白，是时间。

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

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

RAG 被聊成白开水之后，还能有什么新东西？如果我把"知识库"从自然语言文档换成代码反模式，它还剩什么？arXiv 上那篇叫 RAGas 的论文（2608.15857）就是这么干的：把 RAG 搬去优化智能合约的 Gas。