Chapitre 11 — Mises à jour continues et optimisation du pipeline

Onzième et dernier billet de la tournée chapitre par chapitre de LLM Primer III : Améliorer l'IA d'entreprise avec RAG. Le chapitre où le pipeline n'est jamais terminé — les documents changent, les requêtes dérivent, les modèles sont remplacés — et où l'équipe qui en a la charge apprend à penser sur trois échelles de temps à la fois.

Pourquoi ce chapitre existe

Un système RAG n'est pas terminé au moment où il est livré. Les documents changent, les requêtes dérivent, le modèle lui-même est remplacé tous les quelques mois. Le pipeline dont une équipe est fière en mars est, en septembre, en train de retrouver contre des embeddings devenus rances produits par un modèle de deux générations de retard, servant un modèle de base qui a été silencieusement remplacé, et répondant à une distribution de questions qui a dérivé d'une manière que personne n'a cartographiée. Ce chapitre porte sur l'ingénierie pour rester à jour — détecter ce qui a changé dans le corpus, garder l'index frais sans le reconstruire, empêcher la latence de monter, et fermer la boucle entre la télémétrie de production et les changements que l'équipe fait effectivement.

11.1 Change Data Capture et indexation incrémentale

Le premier instinct de toute équipe qui livre un système RAG est de programmer une reconstruction nocturne de l'index. Cela marche. C'est aussi faux à long terme. Une reconstruction nocturne brûle des appels d'API d'embedding sur des documents qui n'ont pas changé, laisse l'index jusqu'à vingt-quatre heures de retard, et cesse de tenir dans la fenêtre nocturne à mesure que le corpus grandit. Le patron mûr est l'indexation incrémentale pilotée par Change Data Capture — le pipeline réagit aux événements en amont plutôt que de sonder.

Trois types d'événements comptent. Insert : un nouveau document, analysé, découpé, embarqué, indexé. Update : un document existant a changé ; ré-embarquer les morceaux touchés. Delete : un document supprimé ; évincer les vecteurs correspondants avant qu'ils ne puissent revenir dans les résultats — une exigence dure sous RGPD, CCPA, et le reste. Le mécanisme qui rend cela tractable est le hash de contenu. À la première ingestion, stocker un SHA-256 sur le texte normalisé du morceau à côté de l'embedding. À la mise à jour, re-découper, hasher, comparer : les morceaux inchangés restent, les nouveaux sont embarqués, les anciens partent. Une édition de paragraphe devient un appel d'embedding, pas mille. La facture d'embedding passe à l'échelle de l'activité éditoriale au lieu de la taille du corpus.

Le problème plus dur est l'ordre et la cohérence. Les événements arrivent dans le désordre ; un delete peut filer devant le update qu'il aurait dû suivre. Le remède standard est des versions monotones par document, avec des écritures conditionnelles : n'appliquer un événement que si sa version dépasse celle en fichier. Cela rend le pipeline idempotent — un événement dupliqué ne peut pas corrompre l'index — ce qui n'est pas une optimisation mais une exigence de correction à grande échelle. Les contextes de conformité ajoutent des tombstones : une suppression logique qui prend effet au moment de la requête avant que la suppression physique ne se termine de manière asynchrone, pour que la suppression soit honorée immédiatement.

11.2 Maîtriser la latence : cache sémantique et tiering de modèles

Un appel augmenté par la recherche accumule de la latence à chaque saut. La défense est de faire moins de travail quand le travail est manifestement inutile, et deux techniques portent l'essentiel de ce poids. Un cache conventionnel stocke les réponses à clé sur le texte exact de la requête et atteint une fraction infime du trafic réel. Le cache sémantique indexe par sens : embarquer chaque requête entrante, chercher dans un petit cache de requêtes récentes, retourner la réponse cachée si la similarité cosinus à l'entrée la plus proche dépasse un seuil. « Quelle est notre politique de remboursement ? » et « comment marchent les remboursements ? » ne partagent aucun match de chaîne et partagent la réponse entière.

Les trois choix qui comptent sont le seuil de similarité (0,93–0,97 cosinus pour des embeddings généraux, ajusté contre du trafic mis de côté), la durée de vie (idéalement liée aux morceaux contributeurs — invalider quand l'un d'eux est ré-embarqué), et la portée (partitionnée par tenant, par rôle d'accès, par tout ce qui pourrait faire fuiter la réponse d'un utilisateur à un autre). Les déploiements de production rapportent des taux de hit de 30–60 % avec des dizaines de millisecondes sur les hits contre des réponses non cachées en plusieurs secondes, avec des économies de coût proportionnelles puisque les hits de cache court-circuitent à la fois l'embedding et la génération.

Le tiering de modèles gère les requêtes qui doivent utiliser le modèle et ne devraient pas utiliser le plus grand disponible. Deux ou trois tiers : un petit modèle rapide et bon marché pour le gros, un plus grand pour les requêtes sur lesquelles le petit n'est pas confiant, optionnellement un troisième pour la longue traîne. Le routeur est l'endroit où les déploiements de production se trompent à la première passe. La version la plus simple utilise des signaux côté requête (factuel court contre analytique). Une meilleure version utilise des signaux côté recherche (similarité haute et cohérente signifie que le petit modèle suffit). La plus sophistiquée fait tourner le petit modèle d'abord et escalade sur une confiance calibrée — précis à la marge, en payant une inférence supplémentaire sur les escalades. Les nombres à surveiller sont le taux d'escalade et le taux de regret ensemble ; l'un ou l'autre seul induit en erreur.

11.3 La boucle de feedback continue

Un pipeline RAG émet de la télémétrie constante. La plupart des équipes la collectent ; très peu ferment la boucle dessus. La boucle a quatre étapes. Collecter : chaque requête, recherche, génération, citation et interaction utilisateur loguée avec un schéma stable et un identifiant de requête stable qui se faufile à travers chaque étape — sans cet identifiant, diagnostiquer une régression dégénère en conjecture. Évaluer : la triade des Chapitres 9 et 10 tournant dans deux modes, échantillonnée hors ligne contre un ensemble de référence pour la précision, et des proxies comportementaux en ligne (régénération, copie, suivi, abandon) pour la couverture. Aucun n'est suffisant seul. Ensemble, ils triangulent.

Décider est l'étape la plus dure, parce que le même signal implique plusieurs remèdes différents. Une chute de Pertinence du Contexte peut signifier que le corpus manque de sujets, que le reranker s'est dégradé, ou que le modèle d'embedding n'est plus adapté au nouveau vocabulaire. Distinguer exige de découper les métriques — par sujet, par ancienneté de document, par version d'embedding, par tenant — et l'équipe qui ne regarde que l'agrégat découvrira, un trimestre en retard, qu'un sous-ensemble tirait la moyenne vers le bas depuis tout ce temps.

Appliquer vient en trois poids. Les changements de configuration — top-k, poids du reranker, alpha hybride, seuil de cache, règle d'escalade — testés en A/B en quelques heures, retirés en quelques minutes, plusieurs en cours à tout moment. Les actions de réindexation — ré-embarquer un sujet rance, ingérer une nouvelle source, évincer des documents obsolètes — à la semaine ou à la demande, sur une réplique hors production avant promotion. Les changements de modèles — remplacer le modèle d'embedding, remplacer le modèle de base, ré-entraîner un reranker sur mesure — trimestriellement, avec déploiement en shadow, évaluation parallèle, basculement progressif de trafic, et option de retour arrière. La discipline est dans la cadence, pas dans un changement unique. Un petit canal d'étiquetage humain — peut-être une centaine d'exemples par semaine venant de la file de proxies ambigus — garde les LLM-juges calibrés et empêche la boucle de s'optimiser contre ses propres proxies.

Ce que prépare le Volume III

Nous avons commencé en traitant la génération augmentée par la recherche comme la réponse d'ingénierie à deux problèmes que les modèles de langage purs ne peuvent pas résoudre : connaissance fraîche et provenance vérifiable. Nous avons tracé l'architecture du premier patron embed-retrieve-stuff jusqu'aux systèmes modulaires et agentiques désormais en production, et nous avons fait le travail soigneux sur chaque composant le long du chemin — les parseurs qui récupèrent la structure des PDF, les découpeurs qui décident ce qu'est une unité de sens, les bases vectorielles qui stockent le résultat, les retrieveurs et rerankers hybrides qui trouvent ce qui compte, les contrôles d'accès et les couches d'anonymisation qui gardent le système honnête, les frameworks d'évaluation qui nous disent si tout cela marche, et maintenant les mécanismes de mise à jour continue qui le maintiennent en vie.

RAG n'est pas une catégorie de produits. C'est une discipline d'ingénierie composée d'environ une douzaine de sous-disciplines, chacune pouvant faire la différence entre un système qui marche et un système qui hallucine en silence. Une équipe qui traite chaque sous-discipline sérieusement produira quelque chose qui tient sous le trafic réel. Une équipe qui traite l'une d'elles comme une boîte noire produira quelque chose qui ne tient pas.

La série se poursuit dans LLM Primer IV — Concevoir la cognition de l'IA avec MCP. Là où le Volume III portait sur amener la bonne connaissance au modèle, le Volume IV porte sur amener les bonnes mains — le Model Context Protocol, les agents qui le manient, les outils qu'ils appellent, et la mémoire qu'ils accumulent. Même sensibilité architecturale, surface différente du même problème. Le travail continue.