Apple acelera hasta 8 veces la búsqueda vectorial para RAG con una exhaustividad del 99%

Un usuario pregunta cómo obtener un reembolso, pero la búsqueda en la base de soporte devuelve artículos sobre pagos. El modelo de lenguaje recibe un contexto inadecuado, y una respuesta bien redactada sirve de poco. Investigadores de Apple proponen entrenar redes independientes para que aprendan dónde buscar coincidencias en una base de datos concreta. Para un equipo con un archivo extenso, es una oportunidad para comprobar cuántos recursos consume la propia búsqueda y si es posible reducir el número de documentos que se examinan.

La red aprende dónde buscar

En RAG, los documentos se convierten primero en vectores numéricos que representan su contenido. La pregunta del usuario pasa por un proceso similar. A continuación, el sistema busca los documentos cuyos vectores mejor coinciden con el vector de la pregunta y envía los fragmentos recuperados al modelo de lenguaje.

Comparar la consulta con cada documento resulta costoso. Por eso, la base de datos puede dividirse en grupos: primero se seleccionan algunos grupos prometedores y después se busca dentro de ellos. Este atajo tiene un coste: un error al elegir el grupo puede dejar el mejor resultado fuera de la búsqueda.

El trabajo de Apple describe dos formas de entrenar esta etapa. SupportNet estima la calidad de la coincidencia que puede encontrarse dentro de cada grupo. KeyNet predice el vector de la mejor coincidencia y lo entrega a un índice de búsqueda convencional en lugar del vector original de la pregunta. Estos modelos pueden utilizarse por separado.

Imaginemos la base de conocimiento de una tienda en línea. Un comprador escribe: «He cancelado el pedido, ¿cuándo recibiré el dinero?». La guía adecuada podría titularse «Plazos de abono tras la cancelación». En este ejemplo hipotético, KeyNet debería orientar la búsqueda hacia el vector de esa guía. Trabaja con números: no necesita generar el texto de una posible respuesta.

Los ejemplos de entrenamiento se preparan de antemano. Para cada pregunta se calcula la mejor coincidencia mediante una búsqueda exhaustiva y después se entrena la red para reproducir esa correspondencia. Los costes se trasladan a la preparación del sistema; el enfoque cobra sentido cuando la red entrenada atiende muchas consultas posteriores.

Qué significa una aceleración de hasta ocho veces

En su análisis del experimento, Apple utilizó unos 2,6 millones de fragmentos de Natural Questions. Con la mayor de las KeyNet probadas, alcanzar una exhaustividad de búsqueda del 99% llevó 0,23 ms, frente a los 1,8 ms de la consulta original. La medición incluye la transformación de la consulta y la búsqueda en el índice. Para lograr la misma exhaustividad fue necesario examinar aproximadamente 11 veces menos vectores.

Es fácil interpretar mal este resultado. Una exhaustividad del 99% significa recuperar la mejor coincidencia según la métrica vectorial elegida. No garantiza una respuesta correcta al usuario en el 99% de los casos: las representaciones originales de los documentos también pueden reflejar mal el sentido de la pregunta.

SupportNet obtuvo otro resultado: con una exhaustividad de enrutamiento del 95%, la latencia fue de 1,74 ms en lugar de 3,36 ms. Estas aceleraciones no se pueden sumar: son mediciones independientes de distintas variantes de búsqueda.

Para un producto también importa el ahorro absoluto. Pasar de 1,8 a 0,23 ms ahorra alrededor de un milisegundo y medio en esta etapa. Si la mayor parte de la espera corresponde a la generación de la respuesta, el usuario puede apenas notar la diferencia. Con un gran volumen de consultas, aun así conviene que el equipo evalúe el impacto en los costes de cómputo.

Cómo comprobar la utilidad en tu propia base de datos

Puedes empezar por el repositorio oficial de AMIPS. La afirmación de la publicación original de que Apple no había publicado el código es incorrecta: hay scripts para preparar vectores, calcular los objetivos de entrenamiento y entrenar modelos, además de un ejemplo de ejecución con un pequeño conjunto de datos FIQA.

El experimento práctico debe centrarse en tu propia carga de trabajo. Toma una muestra independiente de preguntas reales, registra la exhaustividad y la latencia actuales de la búsqueda y compáralas después con la versión entrenada. Calcula por separado el tiempo de preparación, la memoria necesaria y el coste de las actualizaciones. De lo contrario, el ahorro en las consultas puede perderse fácilmente en el mantenimiento del sistema.

El método está pensado para una base de datos fija y tipos de consulta conocidos. Por eso, para una prueba piloto resulta lógico elegir una base de consulta relativamente estable. Cuando se actualicen los documentos o cambien las preguntas, habrá que volver a evaluar la calidad y decidir si es necesario reentrenar. El principal criterio de adopción es sencillo: ¿se busca en esta base con suficiente frecuencia como para compensar el entrenamiento y el mantenimiento adicionales?