苹果给 RAG 检索换了条快车道

Apple 正在尝试把 RAG 的检索问题，从每次都要现场计算的搜索任务，改造成一个可以提前学习、反复复用的预测任务。

11 月 5 日，Apple 机器学习研究团队发布了对 ICML 2026 论文《Amortizing Maximum Inner Product Search with Learned Support Functions》的进一步解读。研究团队提出一种名为 AMIPS 的摊销式最大内积搜索方案：针对相对固定的文档库，提前用历史或合成查询训练小型神经网络，让网络学会典型问题通常会命中哪些向量区域，再用这个预测结果加速现有的向量索引。

结果相当直接。在约 260 万篇文档组成的 Natural Questions 数据集上，Apple 的 KeyNet 达到 99% 召回率所需的延迟最低约为 0.23 毫秒，而直接使用原始查询搜索需要约 1.8 毫秒，前者快接近 8 倍；SupportNet 达到 95% 路由召回率时需要 1.74 毫秒，传统质心路由则需要 3.36 毫秒，延迟下降约 48%。

这项工作的价值不在于又造了一个向量数据库，而在于它指出了生产级 RAG 长期被忽略的一件事：文档向量和用户查询并不是来自同一种分布，通用索引为了照顾所有可能的查询，往往浪费了大量计算。

RAG 的问题已经不只是回答准不准

RAG 是一种把大语言模型与外部知识库连接起来的生成式 AI 架构，它先检索与问题相关的文档，再把文档片段交给模型生成答案。

这套架构解决了两个典型问题：一是模型训练数据存在截止日期，无法天然掌握企业内部资料和实时信息；二是模型可能生成缺乏依据的内容，而 RAG 可以把答案约束在可检查的外部证据上。

但 RAG 的成本并不会因为接入向量数据库就自动消失。一次完整请求通常需要经历查询改写、Embedding、向量搜索、重排、上下文拼接和大模型生成，其中每一层都可能增加延迟。检索返回的候选越多，后续重排和生成阶段处理的 Token 也越多，最终表现为 GPU 占用、首字延迟和单次请求成本一起上升。

检索延迟看起来只有几毫秒，却会在高并发和复杂流水线中被放大。一个生产系统可能同时查询多个索引，执行关键词与向量混合检索，再调用重排模型筛选几十个候选；如果基础搜索效率不够，工程团队通常只能增加机器、降低召回率，或者缩小知识库规模。

Apple 的方案针对的正是这一层基础开销。它并不会直接减少生成模型输出一个 Token 所需的计算量，但可以减少向量索引需要扫描的文档和分区数量，从而降低检索阶段的推理计算，并为后续减少候选文档、重排规模和上下文长度创造条件。

传统向量检索，输在只看文档、不看问题

MIPS 是最大内积搜索，即从大量候选向量中找到与查询向量内积最高的一个或多个向量。

在语义检索系统中，查询和文档通常会被编码为高维向量，内积越大，一般意味着语义越相关。最准确的办法是让查询向量与库中每一个文档向量都计算一次内积，但当数据库包含数百万条记录、每条向量又有数百甚至数千维时，穷举搜索的计算量很快会失控。

IVF 是倒排文件索引，它先把文档向量划分到多个聚类中，查询时只搜索最可能相关的少数聚类，而不是扫描整个数据库。

传统 IVF 通常使用聚类质心完成路由。系统先计算查询向量与各个质心的距离，再进入距离最近的几个聚类进行精确搜索。这种方法速度很快，但质心只能表示一个聚类的大致中心，无法准确描述聚类内部所有文档的分布。

质心路由的误差尤其容易出现在聚类边缘。某篇文档可能离本聚类质心很远，却恰好与用户问题高度相关；由于查询与质心的距离不够近，系统甚至不会进入这个聚类，自然也无法找到真正的最佳文档。

更关键的问题是，传统索引主要研究文档向量如何分布，却很少利用用户查询如何分布。现实中的 RAG 查询通常是简短、口语化的问题，而文档则是较长、信息密集且经过编辑的文本，两者并不是对称的数据。企业知识助手的用户群、业务范围和常见问题往往还相当稳定，这些可预测的规律在通用索引中基本被浪费了。

Apple 的思路：先把常见问题学一遍

摊销式检索是一种用一次离线训练成本，换取大量后续查询更低推理成本的方法。

AMIPS 的训练流程并不神秘。研究人员先从目标查询分布中采样问题，通过穷举搜索计算每个问题真正对应的最佳文档向量，再把这些查询与正确结果组成监督学习数据，训练一个小型神经网络复现搜索结果。

这相当于让系统提前做一批带标准答案的模拟题。传统向量索引每收到一个问题，都要从聚类质心开始重新判断搜索方向；AMIPS 则把大量查询与最佳文档之间的规律压进网络参数中，新问题到来后先由网络预测大致方向，再让成熟的 IVF 索引完成最后一段搜索。

支持函数是凸分析中的一种数学函数，它可以描述一个向量集合在特定方向上的最大投影值，而其梯度能够指向取得最大值的候选向量。

Apple 研究团队发现，MIPS 的目标函数恰好可以被视为文档向量集合的支持函数。这个对应关系使检索问题不再只是工程上的近邻搜索，还可以被改写成一个结构明确的函数逼近问题。

研究团队由此设计了两种模型：SupportNet 负责学习分区的支持函数，KeyNet 负责直接预测最佳文档向量的位置。两者并非互相替代，而是对应不同的部署瓶颈。

SupportNet：比质心更懂一个聚类里有什么

SupportNet 是一个学习聚类支持函数的神经网络路由器，它判断的不是查询离哪个质心最近，而是哪个聚类中至少存在一个与查询高度匹配的文档。

这一区别看似细微，实际上改变了路由依据。传统质心路由问的是哪个仓库离我最近，SupportNet 问的是哪个仓库里最可能有我要的货。对于分布不规则、存在大量边缘样本的向量聚类，后一个问题显然更接近检索目标。

Apple 在划分为 128 个聚类、包含约 260 万篇独立文档的 Natural Questions 数据上测试了不同规模的 SupportNet。模型深度统一为 16 层，XS、S、M 和 L 四种规模约为数据库大小的 1%、5%、10% 和 20%。

SupportNet 在扫描相同比例数据库时取得了更高的路由召回率。当系统只检查约 5% 的数据库时，学习式路由能够以约 90% 至 93% 的概率找到包含真实最佳文档的分区，中型 SupportNet 达到 92.6%，传统质心路由则为 87.5%，绝对差距为 5.1 个百分点。

SupportNet 在达到相似召回率时也需要更低延迟。小型模型达到 95% 路由召回率需要约 1.74 毫秒，质心路由需要约 3.36 毫秒，相当于前者快约 1.9 倍；大型 SupportNet 在同样约 1.74 毫秒下可以进一步达到 97% 召回率。

KeyNet：不换索引，先把查询送到正确位置

KeyNet 是一个把原始查询向量映射到预测目标向量的神经网络，它可以作为现有 IVF 索引前方的查询转换器。

KeyNet 的部署方式更像导航纠偏。用户问题经过 Embedding 后得到的原始向量，可能离最佳文档还有一段距离；KeyNet 根据训练中学到的查询规律，把这个向量直接推向更接近目标文档的位置，再交给 FAISS 等成熟索引搜索。

这种设计对已有系统更友好。团队不必更换向量数据库，也不必重建一套特殊的搜索引擎，只需要在查询进入现有索引前增加一个较小的网络。Apple 的开源实现也直接使用了 FAISS IVF，说明研究重点是增强现有索引，而不是建立封闭的新技术栈。

KeyNet 的实验数据比 SupportNet 更激进。在 Natural Questions 测试中，最大规模的 KeyNet 达到 99% 召回率只需约 0.23 毫秒，原始查询则需要约 1.8 毫秒，延迟降低约 87%，速度接近 8 倍。

KeyNet 同样显著压缩了实际扫描量。当索引只扫描数据库的 0.001% 时，经过 KeyNet 转换的查询能够以约 89% 至 97% 的概率找到真正的最佳文档，其中大型模型达到 96.7%，原始查询只有约 86%。要达到 99% 召回率，KeyNet 只需扫描约 0.009% 的文档，原始查询需要扫描约 0.10%，候选数量相差约 11 倍。

| 检索方案 | 核心依据 | 代表性结果 | 主要优势 | 主要代价 | |---|---|---:|---|---| | 穷举 MIPS | 查询与全部文档逐一计算 | 理论上可获得精确结果 | 召回率最高 | 计算量随文档数量线性增长 | | IVF 质心路由 | 查询与聚类质心的距离 | 95% 路由召回约 3.36 ms | 成熟、简单、无需训练 | 容易漏掉聚类边缘文档 | | SupportNet | 学习每个聚类的支持函数 | 95% 路由召回约 1.74 ms | 提高分区路由质量，可输出分数 | 需要离线生成标签并训练模型 | | KeyNet | 直接预测最佳文档向量位置 | 99% 召回约 0.23 ms | 可接入现有 IVF，延迟最低 | 对查询分布变化更敏感 |

真正值得关注的是成本曲线，而不只是毫秒跑分

AMIPS 的核心收益是让检索计算跟随真实业务查询，而不是平均分配给所有理论上可能发生的问题。

如果一个企业助手每天处理数百万次查询，即使单次检索只节省 1 毫秒，累计释放的 CPU 或加速器时间也可能相当可观。更重要的是，扫描文档数量减少 11 倍意味着缓存命中、内存带宽和并发能力都有机会改善，而这些指标往往比单次基准测试中的绝对延迟更能决定生产成本。

更准确的检索路由也可能减少后续阶段的浪费。系统不再需要为了避免漏召回而盲目扩大候选集，重排模型可以处理更少文档，最终送入大语言模型的无关上下文也有机会下降。不过，这些端到端收益仍取决于具体 RAG 流水线，Apple 公布的主要数字衡量的是向量检索阶段，不应直接等同于生成模型账单下降 8 倍。

| 指标 | SupportNet | KeyNet | 对 RAG 的潜在影响 | |---|---:|---:|---| | 代表性延迟改善 | 3.36 ms 降至 1.74 ms | 1.8 ms 降至 0.23 ms | 降低检索链路耗时，提高并发吞吐 | | 代表性扫描量改善 | 扫描 5% 数据时召回最高 92.6% | 99% 召回所需扫描量从 0.10% 降至 0.009% | 减少向量比较、内存访问与候选数量 | | 是否替换现有 IVF | 替换质心路由模块 | 不替换，仅转换查询 | 可渐进接入生产系统 | | 是否直接降低生成 Token | 否 | 否 | 需配合候选裁剪和上下文控制间接降本 |

这不是所有 RAG 团队都该立刻上的方案

AMIPS 最适合查询分布稳定、文档库相对固定且调用规模足够大的系统。

企业客服、内部知识助手、商品搜索和垂直领域问答都有较强的查询规律，同类问题会持续重复出现，离线训练成本可以被大量在线请求摊薄。对于这类业务，把过去的搜索结果压缩进一个小网络，确实比每次从零开始找方向更合理。

AMIPS 对快速变化的开放式知识库则未必划算。文档持续新增、删除或重新编码时，最佳匹配关系会改变，训练标签和模型都可能需要更新；如果用户查询突然转向新的主题，历史分布学到的路由规律也可能失效。

冷启动同样是现实门槛。一个刚上线的应用没有足够真实查询，只能依赖合成问题训练，而合成查询与真实用户表达之间通常存在差距。Apple 表示模型对轻微的分布变化具有一定鲁棒性，但这并不代表它能无成本适应业务迁移、语言变化或突发热点。

工程团队还需要计算离线成本。AMIPS 必须先为大量训练查询执行精确搜索，生成最佳文档或各聚类最佳文档作为监督信号；数据库越大、聚类越多，预计算和训练成本越高。只有查询量足够大、索引生命周期足够长，这笔前期投资才容易回本。

开发者应该怎么判断是否值得做

判断 AMIPS 是否值得接入，首先要确认检索是不是系统的真实瓶颈。

如果主要延迟来自大模型生成，向量检索只有 2 毫秒，把它优化到 0.2 毫秒不会让用户明显感知；如果系统存在多路检索、复杂重排和高并发，检索扫描量的下降才可能产生连锁收益。

一个更稳妥的实施顺序是先测量线上查询分布，再决定是否训练专用路由器。开发团队至少应持续记录查询向量、候选分区、最终命中文档、检索延迟和召回结果，并观察头部问题是否稳定、查询主题是否频繁漂移。

SupportNet 更适合需要路由分数的系统。它可以判断不同聚类的最佳匹配程度，便于执行多分区探测、阈值过滤或后续重排，也适合数据库规模巨大、需要先进行全局分区的架构。

KeyNet 更适合索引已经成熟、当前问题主要是查询耗时的系统。它可以放在 FAISS IVF 等现有索引之前，不改变底层数据结构，而且从 Apple 的结果看，即使计入神经网络前处理开销，总延迟仍然明显低于直接检索。

超大规模系统最终可能同时使用两者。SupportNet 先在全局范围选择最可能的聚类，KeyNet 再在聚类内部把查询向量推向最佳文档，这相当于先选对街区，再把导航终点修正到具体门牌号。

Apple 这次做对了什么

Apple 做对的地方，是没有继续把 RAG 优化理解为更大的上下文窗口或更复杂的重排模型。

过去两年，很多 RAG 方案通过增加候选数量、多路召回和多阶段模型提升准确率，但这些手段通常以更高延迟和更多 Token 为代价。AMIPS 提供了相反的方向：先利用业务查询的重复性缩小搜索范围，再把有限计算用在真正可能相关的位置。

这项研究仍然不是一个开箱即用的通用升级。它需要固定文档库、代表性查询数据、离线预计算以及持续监控分布漂移，工程复杂度高于简单调整 IVF 的 nprobe 参数。对于中小知识库，传统索引配合缓存可能已经足够快，额外训练网络反而增加维护负担。

但 AMIPS 很可能代表了检索系统下一阶段的演进方向。Embedding 模型负责把语言映射到向量空间，传统索引负责在空间中搜索，而学习式检索器开始进一步掌握具体业务如何使用这个空间。检索不再只是一个与数据无关的基础设施组件，而会逐渐变成针对用户和场景训练的模型。

对开发者而言，Apple 给出的最重要提醒不是立即部署 SupportNet 或 KeyNet，而是重新审视 RAG 的成本结构：更准确不一定要扫描更多文档，低延迟也不一定只能靠更贵的硬件。只要查询分布具有规律，搜索本身就是可以被学习和摊销的。

参考来源

• Apple AMIPS 开源仓库：包含 SupportNet、KeyNet 的训练流程、配置文件及基于 BEIR 数据集的实验脚本。
• FAISS 向量检索项目：Apple 实验使用的成熟相似度搜索与 IVF 索引基础设施。
• Natural Questions 生成查询数据集：实验所用 BEIR 风格检索数据集，包含查询、文档及文本字段。