Apple accélère la recherche vectorielle pour le RAG jusqu'à 8 fois avec un rappel de 99 %

Un utilisateur demande comment se faire rembourser, et la recherche dans la base de support lui renvoie des articles sur le paiement. Le modèle de langage reçoit un contexte inadapté, et une belle réponse n'y change plus grand-chose. Des chercheurs d'Apple proposent d'entraîner des réseaux dédiés à déterminer où chercher les correspondances dans une base donnée. Pour une équipe disposant d'un gros volume d'archives, c'est l'occasion de vérifier combien de ressources la recherche elle-même consomme et s'il est possible de réduire le nombre de documents parcourus.

Le réseau apprend où chercher

Dans un RAG, les documents sont d'abord convertis en vecteurs numériques, qui représentent leur contenu. La question de l'utilisateur subit un traitement similaire. Le système cherche ensuite les documents dont les vecteurs correspondent le mieux à celui de la question, puis transmet les fragments trouvés au modèle de langage.

Comparer la requête à chaque document coûte cher. On peut donc découper la base en groupes : choisir d'abord quelques groupes pertinents, puis chercher à l'intérieur. Ce raccourci a un prix : une erreur dans le choix du groupe peut laisser le meilleur résultat hors du périmètre de recherche.

Le travail d'Apple décrit deux manières d'entraîner cette étape. SupportNet estime la qualité de la meilleure correspondance qu'on peut trouver dans chaque groupe. KeyNet prédit le vecteur de la meilleure correspondance et le transmet à un index de recherche classique à la place du vecteur initial de la question. Ces modèles peuvent être utilisés séparément.

Imaginons la base d'une boutique en ligne. Un client écrit : « J'ai annulé ma commande, quand serai-je remboursé ? » L'instruction utile peut s'intituler « Délais de remboursement après annulation ». Dans notre exemple fictif, KeyNet doit orienter la recherche vers le vecteur de cette instruction. Elle travaille sur des nombres : il n'est pas nécessaire de générer le texte de la réponse supposée.

Les exemples d'entraînement sont préparés à l'avance. Pour chaque question, on calcule la meilleure correspondance par recherche exhaustive, puis on apprend au réseau à reproduire cette association. Le coût est déplacé vers la préparation du système ; l'intérêt apparaît lorsque le réseau entraîné sert de nombreuses requêtes ultérieures.

Ce que signifie une accélération jusqu'à huit fois

Dans l'analyse de l'expérience, Apple a utilisé environ 2,6 millions de fragments de Natural Questions. Avec le plus grand KeyNet testé, atteindre un rappel de 99 % prenait 0,23 ms contre 1,8 ms pour la requête d'origine. La mesure inclut la transformation de la requête et la recherche dans l'index. Pour le même rappel, il fallait examiner environ 11 fois moins de vecteurs.

Il est facile de mal interpréter ce résultat. Un rappel de 99 % signifie que la meilleure correspondance selon la métrique vectorielle choisie est retrouvée. Ce n'est pas la promesse d'une bonne réponse pour l'utilisateur dans 99 % des cas : les représentations initiales des documents peuvent aussi mal refléter le sens de la question.

SupportNet donne un autre résultat : avec un rappel de routage de 95 %, la latence est de 1,74 ms au lieu de 3,36 ms. On ne peut pas additionner ces accélérations : ce sont des mesures distinctes pour des variantes de recherche différentes.

Pour un produit, le gain absolu compte aussi. Passer de 1,8 à 0,23 ms fait gagner environ une milliseconde et demie à cette étape. Si l'essentiel de l'attente vient de la génération de la réponse, l'utilisateur peut à peine remarquer la différence. Avec un fort volume de requêtes, l'équipe doit tout de même évaluer l'effet sur les coûts de calcul.

Comment vérifier l'intérêt sur votre base

Vous pouvez commencer par le dépôt officiel AMIPS. L'affirmation du billet d'origine selon laquelle Apple n'aurait pas publié le code est inexacte : on y trouve les scripts de préparation des vecteurs, de calcul des cibles d'entraînement et d'entraînement des modèles, ainsi qu'un exemple d'exécution sur un petit jeu FIQA.

Une expérience pratique doit s'appuyer sur votre propre charge. Prenez un échantillon distinct de vraies questions, fixez le rappel et la latence actuels, puis comparez-les avec la variante entraînée. Calculez séparément le temps de préparation, la mémoire et le coût de mise à jour. Sinon, le gain sur les requêtes peut facilement se perdre lors de l'exploitation du système.

La méthode est conçue pour une base fixe et des types de requêtes familiers. Pour un pilote, il est donc logique de choisir un référentiel relativement stable. Si les documents sont mis à jour ou si les questions changent, il faudra revérifier la qualité et décider s'il faut réentraîner. Le critère d'adoption est simple : la recherche sur cette base se répète-t-elle assez souvent pour amortir l'entraînement et la maintenance supplémentaires ?