Apple: recuperación RAG 1,9 veces más rápida

Por qué la búsqueda vectorial es el cuello de botella de tu RAG

Un sistema de RAG (retrieval-augmented generation) hace tres cosas: parte el corpus en fragmentos, busca los más relevantes y los pasa al modelo. La etapa del medio es la que más se atasca. Y dentro de ella, el corazón es una operación llamada MIPS (maximum inner product search): dada la representación numérica de una pregunta, recorrer millones de vectores candidatos para encontrar el que mejor encaja.

Investigadores de Apple presentaron en ICML 2026 un paper —Amortizing Maximum Inner Product Search with Learned Support Functions— que ataca justo ese punto: entrenar pequeñas redes neuronales, una sola vez y offline, para que aprendan a llevar cada consulta hacia su mejor coincidencia en lugar de compararla contra todo. El resultado que reportan: 95% de recall de enrutamiento 1,9 veces más rápido que el enrutamiento por centroides (1,74 ms frente a 3,36 ms).

Qué es MIPS y por qué el método clásico se queda corto

La técnica estándar parte el conjunto de claves en k clusters y guarda un centroide por cluster. Cuando llega una consulta, se compara con esos k centroides y se manda al cluster más cercano, donde se hace la comparación exhaustiva. Con n claves y k clusters, el trabajo efectivo baja a algo del orden de n/k: un ahorro de factor k.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El problema es que el centroide no representa la dispersión del cluster. Un cluster puede contener una clave lejana de su centroide pero muy cerca de la consulta; si la consulta cae ahí, el enrutamiento por centroide le da puntuación baja y salta el cluster, perdiendo la coincidencia real. Los autores lo señalan como un error estructural, no un detalle de implementación.

Y hay un segundo argumento, más interesante para quien construye producto: los métodos genéricos asumen que las consultas se parecen a las claves. En RAG no es así. Las claves son documentos largos y curados; las consultas son preguntas cortas de usuario. Son distribuciones distintas, y esa diferencia es exactamente el espacio que el paper explota.

SupportNet y KeyNet: dos redes para dos tareas

La base matemática es la función de soporte de un conjunto, un objeto de análisis convexo que había pasado bastante desapercibido en este contexto. Tiene dos propiedades clave: es convexa, así que se puede aproximar con redes neuronales diseñadas para funciones convexas (ICNN); y su gradiente en una consulta devuelve la clave óptima. Los autores entrenan dos modelos separados porque en la práctica funciona mejor que forzar uno solo:

SupportNet: aprende la función de soporte con una ICNN ligeramente relajada. Se puede entrenar una por cluster, y así el router responde una pregunta mucho más útil que la del centroide: no cuánto se parece el centroide a la consulta, sino qué tan buena es la mejor clave dentro de este cluster para esta consulta.
KeyNet: predice directamente el vector de la clave óptima. Usa una pérdida de consistencia derivada del teorema de Euler para funciones homogéneas, que mantiene la predicción anclada geométricamente a la función de soporte sin imponer convexidad explícita.

El entrenamiento es regresión clásica: se muestrean consultas de la distribución real, se calcula la coincidencia óptima por búsqueda exhaustiva una sola vez y se guarda. Eso genera un dataset supervisado que captura el paisaje de soluciones de MIPS para las consultas que de verdad importan.

Los números: 1,9 veces menos latencia y 11 veces menos claves

Entrenaron SupportNets de tamaños XS, S, M y L (1%, 5%, 10% y 20% del tamaño de la base) sobre Natural Questions con 128 clusters y unos 2,6 millones de pasajes únicos.

Con presupuesto fijo de clusters explorados, los routers aprendidos recuperan la partición correcta el 90–93% de las veces escaneando el 5% de la base —hasta 92,6% con el modelo M— frente al 87,5% del baseline de centroides.
El modelo pequeño alcanza 95% de recall de enrutamiento en 1,74 ms; el grande llega al 97% en el mismo tiempo. El cálculo ya incluye el coste de ejecutar las redes.

Con KeyNet el planteamiento cambia: se mantiene el índice IVF existente y se le pasa una consulta reescrita. La red predice dónde está probablemente la mejor coincidencia y el índice busca ahí. Sobre un índice FAISS IVF:

Llegar al 99% de recall cuesta hasta 8 veces menos tiempo con el modelo más grande (0,23 ms frente a 1,8 ms de la consulta cruda).
Escaneando el 0,001% de la base, las consultas mapeadas por KeyNet recuperan la clave correcta el 89–97% de las veces —hasta 96,7% con L— frente al 86% de la consulta cruda.
Para el mismo 99% de recall hacen falta hasta 11 veces menos claves (0,009% frente a 0,10%).

¿Qué significa esto para tu startup?

Si tu producto es un asistente sobre documentos, un buscador interno o un agente que consulta una base de conocimiento, la latencia de recuperación es la parte que el usuario siente. Y el coste de la búsqueda vectorial crece con el tamaño del índice.

El contexto de mercado empuja en la misma dirección. Según Gartner, citado en el anuncio de Actian de abril de 2026, el 33% de las aplicaciones empresariales incluirá IA agéntica en 2028, frente a menos del 1% en 2024. Actian afirma que su VectorAI DB supera en más de 22 veces el throughput de las principales bases de datos vectoriales open source en una prueba de 10 millones de vectores con la metodología VDBBench. Y el índice LEANN de UC Berkeley, premiado en MLSys 2026, comprime un índice de 60 millones de fragmentos de 201 GB a 6 GB. Todo el sector está peleando por lo mismo: menos latencia y menos coste por consulta.

Dos acciones concretas para esta semana:

Mide antes de optimizar. Separa la latencia de recuperación de la de generación. En el caso de LEANN, la recuperación en NQ tarda 2,48 s frente a 0,05 s de HNSW, pero la generación ronda los 20 s: si no separas las etapas, optimizas la equivocada. Si tu recuperación es menos del 10% del tiempo total, el router aprendido no te va a salvar.
Prueba primero la vía barata: mejorar la consulta. KeyNet no requiere cambiar tu índice. Si ya usas FAISS, Elasticsearch o un servicio gestionado, el equivalente práctico es enriquecer la consulta antes de entrar al índice. Y antes de invertir en un router propio, evalúa el híbrido: InfoQ documenta que Perplexity combina scorers léxicos y de embeddings sobre cientos de miles de millones de URLs en Vespa, y que Elasticsearch soporta búsqueda híbrida nativa desde la versión 8.13 con Reciprocal Rank Fusion (k=60 por defecto). Esa combinación suele dar más precisión por hora de ingeniería que un cambio de índice.

KeyNet o SupportNet: cuál elegir según tu cuello de botella

Los propios autores plantean la elección como una decisión práctica, no como una cuestión de superioridad de un modelo sobre otro:

KeyNet cuando la velocidad de inferencia es el cuello de botella y solo necesitas aproximar la mejor clave.
SupportNet cuando además necesitas una puntuación calibrada —para re-ranking, umbrales o uso downstream— o cuando el cómputo es escaso en modelos pequeños, un régimen donde sigue siendo competitivo.

Ambos se entrenan de forma similar, se integran con infraestructura de búsqueda aproximada existente y, según los autores, son razonablemente robustos a cambios leves en la distribución de consultas. Para sistemas MIPS realmente grandes, el paper sugiere combinar las dos piezas: un SupportNet como router sobre todos los clusters y un KeyNet por cluster para que cada índice regular afine más rápido.

El límite que conviene tener claro

El método asume lo que los autores llaman una condición común en producción: que la distribución de consultas se conoce de antemano. Eso es un supuesto de negocio, no un detalle técnico. Si tu producto atiende a usuarios con patrones estables —un buscador interno, un asistente de soporte sobre un catálogo fijo— el amortizado encaja. Si tu tráfico cambia cada semana porque estás lanzando features nuevas o entrando en mercados nuevos, el coste de reentrenamiento se come buena parte del ahorro.

Y hay un matiz que el paper no resuelve: la recuperación es solo una parte del problema. InfoQ señala que los embeddings son aproximadores y fallan en coincidencias exactas —códigos de error, versiones, nombres de flags—, y que en la práctica la mayoría de las consultas de producción son híbridas. Un router más rápido sobre un índice que no distingue un código de error de su variante hermana te lleva más rápido al documento equivocado.

Conclusión

La aportación de Apple no es un producto ni una librería: es un marco matemático que convierte la búsqueda vectorial en un problema de regresión y, con eso, traslada trabajo desde el momento de la consulta hacia el momento del entrenamiento. Para un founder, la lectura práctica es que el índice deja de ser un componente estático y se vuelve algo que se puede entrenar con tu propia distribución de consultas.

Antes de reescribir tu stack, mide dónde se va el tiempo. Si la recuperación pesa poco en el total, el router aprendido no te va a mover la aguja. Si pesa mucho y tu distribución de consultas es estable, ahí sí hay margen: el paper reporta 1,9 veces menos latencia para el mismo recall de enrutamiento y hasta 11 veces menos claves para llegar al 99%.