Partie 8 sur 8 — Série d'articles RAG
Précédent : Votre système RAG est erroné. Voici comment savoir pourquoi. (Partie 7)
Le système RAG de TechNova était correct au lancement. Trois mois plus tard, c'était définitivement faux. La politique de retour avait changé. Le journal des modifications du firmware contenait de nouvelles versions. Les conditions de garantie ont été révisées. Les documents dans le CMS étaient à jour. Les morceaux de l'index vectoriel ne l'étaient pas.
Un système RAG de production ne tombe pas en panne d’un seul coup. Il dérive, se dégrade doucement et continue de paraître confiant tandis que sa qualité de récupération se détériore. Le modèle ne sait pas que les données sont périmées. Le récupérateur ne sait pas que les documents ont été modifiés. L’utilisateur voit le même ton fluide et autoritaire fournir des réponses qui étaient justes au dernier trimestre.
La plupart des systèmes RAG qui échouent en production échouent à cause de données obsolètes et non de mauvais modèles. C’est l’opinion opérationnelle autour de laquelle cet article est construit.
Le scénario TechNova dès l’ouverture n’est pas hypothétique. Chaque système RAG avec des données sources changeantes sera confronté à ce problème. La question n’est pas de savoir si l’index deviendra obsolète. Il s’agit de savoir si vous le détecterez avant vos utilisateurs.
Trois stratégies de réindexation, par ordre de complexité. Réindexation planifiée : réexécutez le pipeline d'ingestion complet à une cadence, tous les soirs, toutes les semaines ou après chaque mise à jour de document. Simple, fiable et suffisant pour la plupart des équipes. Réindexation incrémentielle : détectez les documents modifiés et réintégrez uniquement ces morceaux. Plus rapide et moins cher, mais nécessite une logique de détection des changements. Réindexation événementielle : déclenchez automatiquement la réindexation lors de la mise à jour des documents dans le CMS (système de gestion de contenu). Le plus réactif, mais le plus complexe à construire et à exploiter.
La fraîcheur des documents ne représente que la moitié du problème. Les modèles d'intégration changent également. Si vous passez d'un modèle d'intégration à un autre, les vecteurs déjà stockés dans votre index ne sont plus comparables de la même manière, même si les documents eux-mêmes n'ont jamais changé. C’est sa propre forme de dérive. Lorsqu'un fournisseur abandonne un modèle ou que vous effectuez une mise à niveau pour des raisons de qualité ou de coût, la réintégration du corpus n'est pas facultative. Il s’agit d’un événement de réindexation complète. Au fil du temps, la dérive ne concerne pas uniquement les documents obsolètes. La dérive de l'index peut également provenir de modifications des limites des blocs, de nouvelles règles de métadonnées ou de modifications du modèle d'intégration qui modifient discrètement le comportement de récupération.
Quelle que soit la stratégie que vous choisissez, le signal de diagnostic de la partie 7 s'applique ici : lorsque le système se contredit au fil des sessions, donnant des réponses différentes à la même question selon les jours, l'index contient probablement des fragments obsolètes à côté des fragments actuels. Le correctif n'est pas le modèle. Le correctif est le pipeline de données.
Les utilisateurs tenteront de casser votre système. Pas toutes, et pas toujours intentionnellement, mais l'injection rapide, où une entrée est conçue pour remplacer les instructions du système, constitue un véritable vecteur d'attaque, et la fuite de PII (informations personnellement identifiables) constitue un risque réel. Les garde-corps ne sont pas quelque chose que vous ajoutez après le lancement lorsque quelqu'un signale un problème. Ce sont des étapes de pipeline, conçues dès le départ.
Avant que ...
[Courte citation de 8% de l'article original]