RAGAL: A Frugal, Fully Local Retrieval-Augmented Assistant for Technical Support at a Government Agency

Imaginez que vous avez un robot bibliothécaire super intelligent capable de lire des millions de livres et de répondre à n'importe quelle question que vous lui posez. Habituellement, pour faire fonctionner ce robot, vous devez envoyer vos questions et les livres à un cerveau géant basé dans le cloud, situé dans un centre de données lointain. Mais que se passerait-il si votre bibliothèque contenait des fichiers gouvernementaux top secrets qu'il est illégal de faire sortir du bâtiment ? Et si vous ne pouviez pas utiliser le cloud du tout ? C'est le casse-tête qui est au cœur de la Génération Augmentée par Récupération (RAG - Retrieval-Augmented Generation). Voyez le RAG comme une danse en deux étapes : d'abord, le robot balaie rapidement une pile spécifique de documents pour trouver les pages les plus pertinentes (récupération/retrieval) ; ensuite, il utilise ces pages pour rédiger une réponse intelligente et précise (génération/generation). La grande question pour de nombreuses organisations est la suivante : pouvons-nous construire ce robot entièrement à l'intérieur de nos propres murs, en utilisant seulement un modeste ordinateur portable, sans jamais envoyer un seul octet de données vers l'extérieur du monde ?

Ce document raconte l'histoire de RAGAL, un projet d'une agence gouvernementale roumaine qui a construit exactement un tel robot. Ils ont été confrontés à trois règles qui semblaient impossibles : aucune donnée ne pouvait jamais quitter leur bâtiment, le robot ne pouvait que rédiger des réponses (les humains devaient appuyer sur le bouton "envoyer"), et ils devaient tout faire sur un simple ordinateur portable avec seulement 8 Go de mémoire. Au lieu d'abandonner, ils ont transformé cette configuration « frugale » en un laboratoire d'ingénierie astucieuse. Ils ont découvert que le secret de la réussite ne résidait pas dans l'achat d'un cerveau plus gros et plus coûteux, mais plutôt dans l'apprentissage de la manière dont le robot cherche l'information. En affinant leur moteur de recherche sur de vrais tickets de support et en utilisant une astuce appelée « distillation d'ancrage » pour empêcher le robot d'inventer de fausses commandes de base de données, ils ont créé un système qui fonctionne de manière sûre et efficace. Ils ont même construit un « juge au ralenti » — un modèle d'IA massif qui s'exécute si lentement sur leur processeur qu'il ne peut pas discuter en temps réel, mais qui est parfait pour corriger les devoirs du robot pendant la nuit. Le résultat est un modèle pour toute organisation ayant des règles de confidentialité strictes souhaitant construire un assistant IA utile sans jamais avoir besoin du cloud.

L'histoire de RAGAL : Un robot qui ne quitte jamais la maison

Rencontrez RAGAL, le nouvel assistant d'une agence gouvernementale roumaine qui gère des fonds d'investissement ruraux. Cette agence traite chaque jour des milliers de documents sensibles et de tickets de support. Comme ces fichiers contiennent des données privées de citoyens, il est strictement interdit de les faire sortir du bâtiment de l'agence. Cela signifie qu'ils ne pouvaient pas utiliser les outils d'IA habituels et puissants qui vivent dans le cloud. Ils ont dû construire leur propre robot « entièrement local », et ils ont dû le faire sur un simple ordinateur portable doté d'une carte graphique qui ne possède que 8 Go de mémoire — une quantité minuscule selon les standards de l'IA.

L'équipe a dû suivre trois règles strictes, qu'ils appellent des contraintes :

1. Zéro Égress : Pas un seul morceau de donnée ne pouvait jamais quitter le bâtiment. Pas d'envoi de questions vers le cloud, pas de téléchargement de données d'entraînement depuis Internet. Tout devait se passer sur leur propre matériel.
2. Lecture seule : Le robot était un écrivain, pas un acteur. Il pouvait rédiger du code SQL (des instructions pour réparer des erreurs de base de données) ou écrire des explications, mais il ne pouvait jamais exécuter ces commandes. Un humain devait les réviser et les exécuter.
3. Frugalité : L'ensemble du système a été développé, entraîné et testé sur un seul ordinateur portable grand public.

La grande découverte : Une meilleure recherche bat un cerveau plus gros

L'équipe est partie d'une hypothèse commune : pour obtenir de meilleures réponses, il faut un modèle d'IA plus gros et plus intelligent. Mais ils ont vite découvert que c'était faux. Leur première victoire majeure n'est pas venue de l'amélioration du « cerveau » (le générateur), mais de l'amélioration du « moteur de recherche » (le récupérateur).

Ils ont réalisé que demander simplement au robot de trouver des documents ne suffisait pas. Ils devaient lui apprendre comment chercher. Ils ont construit un système de recherche hybride qui combine deux méthodes : une recherche « dense » qui comprend le sens des mots, et une recherche « parcelleuse » (sparse) qui recherche des correspondances exactes de mots-clés. Ils ont également ajouté un « agent de circulation » (routage d'intention) qui décide quel type de document consulter en fonction de la question. Si vous posez une question sur une procédure, il regarde les manuels ; si vous posez une question sur une réparation de base de données, il regarde les anciens tickets de support.

Ce changement simple a été une mise à niveau massive. Avant tout entraînement sophistiqué, cette recherche hybride a fait bondir leur taux de réussite de 62 % à 81 %. C'est l'amélioration la plus économique et la plus efficace qu'ils aient réalisée.

Le miracle des 8 Go : Entraînement sur un ordinateur portable

Le défi suivant était d'entraîner le moteur de recherche sur leurs propres données. Ils disposaient d'environ 15 000 tickets de support résolus et de documents internes. Ils voulaient apprendre au moteur de recherche à comprendre le langage spécifique de leur agence.

Habituellement, l'entraînement d'un modèle de ce type nécessite un supercalculateur massif. Mais l'équipe n'avait que 8 Go de mémoire. Ils ont découvert un piège caché : sur leur ordinateur portable Windows, le pilote de la carte graphique « déversait » silencieusement des données dans la mémoire régulière de l'ordinateur lorsqu'il manquait d'espace, rendant l'entraînement incroyablement lent sans jamais planter. C'était comme essayer de courir un marathon avec un sac à dos rempli d'eau sans même savoir qu'on le portait.

Pour corriger cela, ils ont utilisé une recette spéciale :

• Optimiseur 8-bit : Une façon de réduire les calculs mathématiques que l'ordinateur doit effectuer.
• Checkpointing de gradient : Une technique qui économise de la mémoire en recalculant certaines étapes au lieu de les stocker.

Avec ces astuces, ils ont réussi à entraîner entièrement leur moteur de recherche en seulement 72 minutes sur ce seul ordinateur portable. Les résultats étaient stupéfiants : la capacité à trouver le bon document parmi les 10 premiers résultats (Recall@10) est passée de 0,663 à 0,850.

Le piège silencieux : Un domaine, deux mondes

C'est ici que l'histoire devient complexe. Lorsqu'ils ont entraîné le moteur de recherche uniquement sur les tickets de support, il est devenu très bon pour trouver des tickets. Mais, de manière silencieuse et invisible, il est devenu moins performant pour trouver les documents officiels. L'entraînement avait « déformé » la compréhension du moteur de recherche, lui faisant oublier comment gérer les documents formels.

Ils ne l'ont découvert que parce qu'ils avaient construit un ensemble de tests séparé dédié aux documents. S'ils ne l'avaient pas fait, ils auraient pensé que leur système était parfait, alors qu'il échouait en réalité sur la moitié de leurs données. Pour corriger cela sans envoyer de données vers le cloud, ils ont utilisé une astuce ingénieuse appelée GenQ. Ils ont utilisé une IA locale pour générer de fausses questions pour leurs documents, créant ainsi un nouvel ensemble d'entraînement qui équilibrait les deux mond actually. Cela a réparé les dégâts, et le moteur de recherche est redevenu excellent pour trouver à la fois les tickets et les documents.

La sécurité avant tout : Empêcher le robot de mentir

Puisque le robot rédigeait des commandes de base de données, l'équipe devait s'assurer qu'il n'inventait rien (hallucinations). Ils ont utilisé une technique appelée Distillation d'ancrage. Au lieu de laisser l'IA écrire le code SQL de zéro, ils ont pris du code réel et fonctionnel provenant de tickets passés, l'ont copié exactement, et ont seulement laissé l'IA écrire le texte autour (expliquer ce qu'il fait et quand l'utiliser). Cela rendait impossible pour le robot d'inventer de fausses commandes de base de données, car le code lui-même était un « ancrage » réel et vérifié.

Ils ont également constaté un avantage surprenant à la masquage des PII (informations personnellement identifiables). En remplaçant les noms réels par des marqueurs comme <utilisateur> ou <id_projet> avant l'entraînement, le robot écrivait en fait de meilleures réponses. Il a cessé de copier les noms de personnes spécifiques issus des anciens tickets pour commencer à écrire des modèles flexibles qui pourraient être utilisés pour n'importe qui.

Le Juge Lent

Enfin, comment noter un robot si vous ne pouvez pas utiliser une IA basée sur le cloud pour vérifier son travail ? L'équipe a construit un « juge lent ». Ils ont utilisé un modèle d'IA massif (744 milliards de paramètres) qui était trop gros pour s'exécuter rapidement. Il s'exécutait sur le processeur principal (CPU) de leur ordinateur au lieu de la carte graphique, déplaçant les données depuis le disque dur au fur et à mesure. C'était incroyablement lent, prenant environ 10 à 13 minutes pour noter une seule réponse. Mais, comme il était très intelligent, il était parfait pour corriger les devoirs du robot pendant la nuit.

Ils ont découvert que ce juge lent était un excellent « second avis », mais pas parfait. Il n'était pas toujours d'accord avec les experts humains, surtout sur les très bonnes ou les très mauvaises réponses. La leçon est d'utiliser le juge pour identifier des tendances et des modèles, mais de toujours faire vérifier les verdicts spécifiques par un humain.

Ce qu'il faut retenir

Le projet RAGAL prouve que vous n'avez pas besoin d'un supercalculateur ou du cloud pour construire un assistant IA puissant et sûr. En se concentrant sur une ingénierie astucieuse — de meilleures stratégies de recherche, une gestion rigoureuse des données et des règles de sécurité strictes — une petite équipe avec un simple ordinateur portable peut créer un système qui respecte la vie privée et apporte une réelle valeur ajoutée. Ils ont montré que parfois, la meilleure façon d'avancer est d'aller plus lentement, de tout garder en local et de prêter une attention particulière aux détails.