Pourquoi le RAG local et le RAG cloud sont-ils fondamentalement différents ?

Une défaillance silencieuse dont presque personne ne parle

Qu’est-ce que le RAG et pourquoi est-il important ?

Le RAG – Retrieval-Augmented Generation, ou génération augmentée par récupération – est l’une des méthodes les plus utilisées pour permettre à un système d’IA de répondre non pas à partir de connaissances générales, mais à partir de documents spécifiques téléversés. Dans un cabinet d’avocats, cela désigne les contrats propres au cabinet, les textes législatifs et les directives internes. Pour un expert-comptable, les réglementations, les codes fiscaux et les dossiers clients. Pour un médecin, les protocoles, les recommandations thérapeutiques et les antécédents des patients.

Un système RAG se compose de deux éléments interconnectés. Le premier est l’unité de récupération : elle stocke les documents sous forme vectorielle – ce qu’on appelle des embeddings – et, pour toute question entrante, retrouve les passages de texte les plus pertinents. Le second est le modèle génératif : il prend les passages récupérés et compose une réponse cohérente en langage naturel. Les deux composants sont pilotés par des modèles d’IA – et c’est précisément là que naît une différence rarement discutée, mais décisive, entre les déploiements cloud et locaux.

Lorsque quelqu’un entend ‘système basé sur le RAG’, il imagine généralement l’IA : le modèle génératif qui répond aux questions. Le composant de récupération – le modèle d’embedding et la base de données vectorielle – passe presque toujours au second plan. Cette inattention est précisément ce qui crée un risque concret, mesurable mais difficile à détecter dans les systèmes basés sur le cloud.

Le risque caché du RAG cloud : la dérive de version de modèle

Si un système RAG repose sur une API cloud – un point de terminaison d’OpenAI, Anthropic, Google ou tout autre grand fournisseur – les modèles qui fonctionnent en arrière-plan peuvent changer à tout moment, sans que le développeur en soit informé ou y consente. Ce n’est pas un risque théorique : les grands fournisseurs mettent régulièrement à jour leurs modèles en coulisses. Les points de terminaison labellisés ‘-latest’ ou ‘le plus récent’ ne garantissent pas la même version de modèle d’une semaine à l’autre.

Ce phénomène est connu dans la littérature sous le nom de dérive de version de modèle (model version drift). Il peut poser des problèmes au niveau du modèle génératif – mais il est particulièrement dangereux au niveau du modèle d’embedding, car il entraîne un second mode de défaillance, bien plus difficile à détecter : la dérive d’embedding (embedding drift).

Un système RAG stocke les documents sous forme vectorielle. Ces vecteurs – les embeddings – sont produits par un modèle d’embedding : il convertit une phrase ou un paragraphe en un vecteur numérique de plusieurs centaines de dimensions. Les textes proches dans la géométrie de l’espace vectoriel sont considérés comme sémantiquement similaires – c’est sur ce principe que le système trouve les passages les plus pertinents pour une question donnée.

Si le fournisseur cloud met à jour le modèle d’embedding – même avec un léger changement d’emphase – il produira un vecteur légèrement différent pour le même texte qu’auparavant. Cela signifie que les documents téléversés et intégrés en janvier occupent un ‘espace’ géométrique différent de ceux téléversés en septembre, si le modèle d’embedding a changé entre-temps. L’espace vectoriel devient inconsistant en interne : les anciens documents se trouvent à d’anciennes coordonnées, les nouveaux à des coordonnées légèrement décalées.

Le système ne s’arrête pas – il ne génère aucun message d’erreur. La précision de la récupération se dégrade simplement en silence. Les questions qui renvoyaient auparavant précisément le passage pertinent renvoient désormais des textes moins appropriés. Le modèle génératif reçoit cette entrée imprécise et produit une réponse correspondamment imprécise. L’utilisateur peut ne pas s’en apercevoir pendant des mois – jusqu’à ce que la conséquence apparaisse dans un résumé erroné, une citation incorrecte ou une clause contractuelle manquée.

Comment les systèmes cloud tentent-ils de se défendre contre ce problème ?

Les développeurs de systèmes RAG cloud sérieux, destinés à la production, connaissent ce problème et tentent de s’en prémunir. La méthode la plus courante consiste à enregistrer dans les métadonnées de chaque fragment de document la version du modèle d’embedding utilisée pour le traiter. Au moment de la requête, le système vérifie si la version du modèle en cours d’exécution correspond à celle utilisée lors du stockage. Si ce n’est pas le cas, les documents concernés doivent être réintégrés avec le modèle actuel.

Ce mécanisme défensif est techniquement correct – mais il comporte un coût caché rarement communiqué. La réintégration prend du temps, des ressources de calcul et – dans un système basé sur une API – un coût financier direct. Pour un corpus juridique ou médical volumineux de plusieurs milliers de documents, la réintégration se compte en heures, non en minutes. Entre-temps, le système est soit hors ligne, soit continue à fonctionner avec l’ancien espace vectoriel inconsistant – dans les deux cas, avec un compromis.

Dans un système local, ce mécanisme défensif est inutile – non pas parce que la défense est meilleure, mais parce que le problème n’existe pas structurellement : la version du modèle ne change pas d’elle-même.

Le RAG local : ce qui est téléchargé une fois reste statique

Les systèmes ArkeoAI font tourner des modèles entièrement locaux, hors ligne. Les poids des modèles – tant ceux du modèle d’embedding de récupération que ceux du modèle génératif – sont téléchargés une fois et restent sur la machine. Il n’y a pas de connexion API derrière eux, pas de mise à jour en arrière-plan, pas de changement de version à l’insu du propriétaire du système.

En pratique, cela signifie que si le système fait tourner aujourd’hui un modèle d’embedding spécifique et un modèle génératif spécifique, il fera tourner exactement les mêmes modèles demain, la semaine prochaine et l’année prochaine – sauf si le propriétaire décide explicitement de les mettre à jour. Les vecteurs des documents restent cohérents. L’espace vectoriel dans lequel les contrats ont été téléversés en janvier représente exactement le même système de coordonnées en septembre qu’en janvier. La qualité de la récupération ne se dégrade pas en silence.

Cela ne signifie pas nécessairement qu’un modèle local surpasse un modèle cloud sous tous les rapports. Cela signifie qu’il est plus prévisible. Dans un flux de travail juridique ou médical où la stabilité de la qualité des résultats n’est pas un souhait mais une exigence professionnelle, c’est une différence décisive – que les fournisseurs cloud ne mettent presque jamais en avant dans leurs supports marketing.

Une analogie concrète tirée de la réalité du bureau

Imaginez un cabinet qui fonctionne dans le même bâtiment depuis des années, et où chacun sait exactement sur quelle étagère et dans quel classeur se trouvent les dossiers de chaque client. Un jour – sans que personne ne soit prévenu – quelqu’un réorganise les classeurs. Pas de façon spectaculaire, juste légèrement : l’étagère des affaires de droit civil monte d’un étage, celle des affaires de droit commercial descend d’un étage. Le dossier est toujours là – juste à un endroit légèrement différent.

L’avocat ou l’assistant ne s’en aperçoit pas au début – par habitude, il cherche au même endroit et trouve généralement quelque chose. Mais pas toujours exactement ce qu’il cherchait. Dans certains cas, le dossier contenant le précédent le plus important a été déplacé dans un autre classeur et n’apparaît pas dans la recherche. Le cabinet continue de fonctionner – mais la précision de la récupération s’est silencieusement dégradée.

C’est précisément ce qui peut se produire dans un système RAG cloud lorsque le modèle d’embedding, après une mise à jour, ‘range’ les documents légèrement différemment dans l’espace vectoriel. Dans un système local et hors ligne, les ‘classeurs’ ne bougent jamais d’eux-mêmes – et c’est la garantie fournie par l’architecture, et non par une promesse.

La fenêtre de contexte : l’autre facteur dont personne ne parle

Les performances d’un système RAG ne dépendent pas seulement de la stabilité du modèle d’embedding, mais aussi de la taille de la fenêtre de contexte du modèle génératif – et c’est également un facteur que les fournisseurs cloud communiquent rarement à l’avance.

La fenêtre de contexte détermine combien de tokens de texte le modèle génératif peut ‘voir’ et traiter simultanément. Si l’unité de récupération renvoie plusieurs passages pertinents d’un long document, mais que leur longueur combinée dépasse la fenêtre de contexte, le modèle tronque simplement l’excédent – en silence, sans avertissement. L’utilisateur suppose que le modèle a répondu en se basant sur tout le matériel pertinent, alors qu’en réalité il n’a ‘vu’ qu’une partie des documents.

Dans les systèmes ArkeoAI, la taille de la fenêtre de contexte est définie et fixée par nos soins – en fonction du flux de travail du client, et non selon le paramètre par défaut du fournisseur. C’est une autre dimension du contrôle : la question n’est pas ‘qu’est-ce que le fournisseur autorise ?’ mais ‘de quoi le client a-t-il réellement besoin ?’

Pourquoi n’en parle-t-on jamais ?

La dérive d’embedding et la dérive de version de modèle ne sont pas des phénomènes secrets – ils sont bien documentés dans la littérature RAG et connus au sein des communautés de développeurs sérieux. Ils n’apparaissent pourtant jamais dans les communications clients des fournisseurs cloud, les présentations commerciales ou les supports marketing.

La raison est simple : le problème est invisible. Il ne génère aucun message d’erreur, ne provoque aucune interruption de service, n’envoie aucune alerte. Il dégrade simplement la qualité de récupération du système lentement et progressivement – jusqu’à ce que quelqu’un remarque que l’IA ‘se comporte différemment qu’avant’. À ce stade, des semaines ou des mois se sont généralement écoulés, et il est difficile de retracer la cause et le début précis de la dégradation.

L’approche ArkeoAI repose sur l’évitement conscient de ce problème – non pas avec des outils de surveillance sophistiqués, mais par l’architecture. Ce qui n’est pas connecté à un réseau ne peut pas écraser un modèle. Il ne s’agit pas d’un compromis entre commodité et sécurité, mais d’une décision justifiée par les exigences professionnelles du client.