What happened
Apple’s Machine Learning Research page, published November 5, 2026, explains work on amortizing maximum inner product search (MIPS). MIPS finds the key vector with the largest inner product against a query vector; in a retrieval-augmented generation system, the associated document can then be supplied alongside a user’s question. Exhaustively comparing a query with millions of keys becomes expensive. Common approximate methods cluster keys and route queries by comparing them with cluster centroids, but this can miss a strong match located away from its cluster’s centroid.
The approach in the paper, “Amortizing Maximum Inner Product Search with Learned Support Functions,” was presented at ICML 2026. Apple says the researchers train small neural networks offline for a fixed database of keys and a known query distribution. They generate training examples by sampling queries and computing the exact MIPS answer through exhaustive search. The resulting models learn to approximate either the best match or the support function that describes the best match score. The upfront training cost is amortized across later queries.
Apple describes two model families. SupportNet learns scores for clusters and routes a query toward clusters based on how good their best keys could be for that query, rather than relying only on centroid distance. It can also provide calibrated scores for reranking or thresholding. In tests on Natural Questions, with roughly 2.6 million passages split into 128 clusters, a small SupportNet reached 95% routing recall in 1.74 ms, versus 3.36 ms for centroid routing. With a fixed scan budget of 5% of the database, learned routers recovered the partition containing the exact best key up to 92.6% of the time, compared with 87.5% for the centroid baseline.
KeyNet instead predicts a best-matching key vector from the query. Apple says it can be placed before a standard inverted file (IVF) approximate-search index, including a FAISS IVF index in its examples. The index remains in place; it receives the transformed query. On the Natural Questions benchmark, the largest KeyNet reached 99% recall in 0.23 ms, compared with 1.8 ms for the raw-query search, which Apple describes as up to about eight times less time. At a scan budget of 0.001% of the database, KeyNet-mapped queries retrieved the true key up to 96.7% of the time, against 86% for raw queries. Reaching 99% recall required scanning 0.009% of the database rather than 0.10%.
Apple recommends KeyNet when inference speed is the priority and an approximate best key is sufficient. It presents SupportNet as useful when scores matter or compute is tight at smaller model sizes. The company says both methods train similarly, integrate with existing approximate-search infrastructure, and are reasonably robust to mild shifts in query patterns. It also suggests that very large systems might combine SupportNet routing with KeyNet models inside clusters.
What the archive adds
New Runtime’s earlier coverage of DR Pixel described a research agent that retrieves rendered document pages and reasons over page images rather than OCR text. That note is a different retrieval problem and method, not evidence for Apple’s results. Apple’s announcement is a new research result, not a follow-up to that project.
Trend signal
This result does not yet fit a pattern New Runtime tracks. It concerns a learned retrieval optimization for fixed databases, rather than an agent protocol, runtime boundary, or completed-task economics pattern.
Why it matters
For a team serving repeated questions over a large, relatively stable corpus, retrieval latency can be a meaningful part of the response budget. Apple’s results point to a specific alternative to simply increasing index complexity: learn how the actual query distribution maps onto a known database, then use that learned mapping to guide an existing approximate-search system. If the reported tradeoff holds on a team’s workload, lower search cost could permit more candidates to be examined at a given latency, or reduce latency at a target recall.
The important qualification is that this is not a drop-in improvement for every RAG setup. The models are trained for a fixed key database and representative queries, and the reported figures come from Apple’s benchmark experiments. Teams with frequently changing documents, shifting user questions, or strict freshness requirements would need to account for refresh and retraining costs. The practical comparison is therefore total system cost and quality over time, not just the milliseconds reported for retrieval.
Limits and uncertainty
The figures are Apple’s results on Natural Questions and a setup of about 2.6 million passages; they do not establish the same speedup on other corpora, embedding models, hardware, or production query distributions. The reported performance depends on model size, scan budget, and recall target. Apple says the methods are reasonably robust to mild query-distribution shifts, but does not quantify the boundary of that robustness here. The page does not establish operational costs for retraining as documents or query behavior change, nor does it report an independently reproduced evaluation.
Skill to build now
For a stable retrieval corpus, create a held-out set of real queries and measure baseline recall and end-to-end latency with the current IVF index. If learned query transformation is available in your stack, compare it against the unchanged query at identical recall targets and include preprocessing time. Track corpus updates and query drift as part of the same evaluation; a faster router is useful only while its learned mapping remains representative.
Reader takeaway
Apple’s result is a research demonstration of workload-specific retrieval: small networks can learn how typical queries match a fixed key database and guide existing approximate-search infrastructure. The gains are substantial on the reported benchmark, but teams should treat them as a reason to test their own query and update patterns, not as a general eightfold RAG speed guarantee.