检索是 RAG 的第一道税。用户的每个问题，都要先在几百万条文档向量里做一遍内积比较，然后才轮到大模型开始写答案。过去十年，整个行业优化这道税的办法基本只有一种思路：靠几何结构省计算——聚类、量化、倒排索引，把"全库扫一遍"变成"只扫最有希望的那几个分区"。11 月 5 日，Apple 机器学习研究团队发布的研究给出了一个相当反直觉的新答案：别优化索引了，把"搜索"本身变成一道回归题，用小模型直接算出答案。

这项工作叫 amortized MIPS（摊销式最大内积搜索），论文《Amortizing Maximum Inner Product Search with Learned Support Functions》发表于 ICML 2026，代码已在 GitHub 开源（apple/ml-amips）。Apple 官方博客给出了关键数字：在 Natural Questions（约 260 万条独立段落）上，查询改写模型 KeyNet 在 99% 召回率下把检索提速最高约 8 倍；聚类路由模型 SupportNet 在 95% 路由召回下提速约 1.9 倍。需要说明的是，这些数字均为 Apple 自测口径，尚未有独立复现。

核心洞察：检索其实是一个凸函数

这篇论文真正有意思的地方不是提速倍数，而是它把一个工程问题翻译成了一个数学对象。把"查询 q 与整个键集合 K 的最大内积"看作一个函数——它恰好是键集合的支撑函数（support function），凸分析里被研究得很透的标准对象。这个函数有两个好性质：它是凸的，所以可以用专门为凸函数设计的一类网络（输入凸神经网络，ICNN）去逼近；它在查询点的梯度，返回的正是最优匹配的键本身。

于是"检索"这个通常依赖专门索引结构的问题，被转化成了经典机器学习里的回归问题：从预期查询分布里采样一批问题，用暴力搜索离线算出每个问题的真实最优匹配，存下来，训练一个小网络去复现这个映射。一次性的离线成本换来了推理时"一次前向传播代替一遍搜索"——这就是"摊销"二字的含义。

这个思路成立的前提很值得琢磨：它假设你的查询分布是稳定的、可采样的。Apple 自己也承认这个限制——固定的键数据库、稳定的查询流。这恰恰描述的是生产环境里的典型 RAG 场景：用户问的问题高度集中在某个领域，文档库相对静态。换句话说，这类方法对"通用问题都能答"没有任何兴趣，它赚的是"我知道我的用户只会问什么"这笔钱。

为什么聚类路由会被打脸

传统 IVF 类索引的做法是：把键分成 k 个簇，查询来了先和 k 个质心比距离，挑最近的簇进去细搜。这个几何论证有个隐藏假设——查询和键长得差不多。但 RAG 场景里这个假设恰恰不成立：查询是用户随手敲的短句，键是长而结构化的文档段落，两者分布差异巨大。质心路由因此会漏：某个真正的最近邻可能离自己簇的质心很远，却离查询很近，被路由步骤直接跳过。

KeyNet 的解法更有工程趣味：它不碰索引基础设施，而是把查询"改写"成一个近似最优键的向量，再喂给现成的检索引擎。不改任何检索链路，搜索自然变快——因为送进来的"查询"已经长得像答案了。SupportNet 则学每个簇的支撑函数，回答的不是"查询离质心多近"，而是"这个簇里最好的键对这个查询有多好"，从根上绕开了质心的几何偏差。

同一天，另一条路：不传文本，传缓存

凑巧的是，同一天 arXiv 上还出现了一篇路线更激进的相关工作。CacheGraft（arXiv 2611.07393，CIKM 2026 KEIR Workshop 论文）干脆质疑了 RAG 的另一个隐含默认——检索结果必须以文本形式塞进提示词。它把语料库的每个段落在离线阶段编码成"缓存到缓存"的 KV cache 表示（实验里用 4B 的共享模型与 0.6B 的接收模型之间的融合缓存），查询时直接把这个缓存注入小模型，完全不需要那个大模型在线参与。

结果是：在五个 QA 基准、两个独立裁判下，CacheGraft 在 30 组对比中 29 组优于纯文本基线，其中 17 组统计显著，而且这些增益是零样本的——融合器从未见过检索数据。它瞄准的场景很明确：算力受限、只能部署小模型做推理的端侧或边缘场景。

两条路线的共同潜台词

把这两项工作放在一起看，会发现一个共同点：它们都在松绑"文本是模型唯一接口"这个默认假设。Apple 的路线是把检索算力摊销进离线训练的小模型；CacheGraft 的路线是把文档知识摊销进 KV 缓存。一个优化"找得多快"，一个优化"注入多少"，但本质都是同一件事——把在线推理时的时间成本，转移到离线阶段去预付。

对做知识库和 RAG 的工程团队来说，有两个直接可用的判断。第一，如果你的业务查询分布稳定、文档库更新不频繁，"为你的查询分布定制检索"比"换更强的嵌入模型"可能收益更大，Apple 的这条路线代码已经开源，值得一试。第二，这两条路线都有明确的天花板：查询分布漂移、文档频繁更新，摊销的前提就塌了——离线预付的成本会变成反复重训的负担。别被 8 倍的数字诱惑，先看自己的查询日志够不够"稳定"。

检索工程的上半场比的是索引结构的精巧，下半场可能比的是谁更了解自己的用户会问什么。

参考来源

• Apple Machine Learning Research：Faster Retrieval for Better, More Efficient RAG（2026-11-05）— https://machinelearning.apple.com/research/faster-retrieval
• ICML 2026 Poster：Amortizing Maximum Inner Product Search with Learned Support Functions — https://icml.cc/virtual/2026/poster/66766
• 开源代码：https://github.com/apple/ml-amips
• CacheGraft: Enhancing Retrieval-Augmented Generation via Latent-Space Document Enrichment（arXiv 2611.07393，2026-11-05）— https://arxiv.org/abs/2611.07393
• ExplainX 对该研究的第三方解读（数字均为 Apple 自报口径）— https://www.explainx.ai/blog/apple-amortized-mips-supportnet-keynet-faster-rag-retrieval-icml-2026-natural-questions-1-9x-faster-2026