La fraîcheur des données RAG désigne la capacité d’un système de recherche à refléter la source actuelle approuvée, y compris les mises à jour, suppressions et changements d’accès. Charger régulièrement de nouveaux documents ne constitue qu’une partie du travail. D’anciens fragments, des réponses en cache et des suppressions défaillantes peuvent continuer à influencer ce que dit un assistant.
Définissez la fraîcheur comme un contrat observable entre source et réponse, avec un parcours délibéré pour les mises à jour, retraits et changements de permissions. Conservez l’identité des documents et les preuves de version, rapprochez l’index de la source et vérifiez que les contenus retirés disparaissent. Un horodatage récent d’ingestion ne suffit pas à établir une réponse actuelle ou autorisée.
Imaginez un assistant interne répondant à une question sur une procédure fournisseur. Les opérations ont remplacé le document, mais l’assistant récupère un fragment de la version dépassée. La réponse peut être fluide et citer correctement cet ancien fragment tout en orientant le personnel vers le mauvais processus.
Ce guide porte sur la maintenance des données de recherche après le premier déploiement. Notre explication du RAG présente l’approche générale ; la décision ici consiste à maintenir la fiabilité d’un workflow de connaissances existant.
Définir la fraîcheur des données RAG pour chaque source
Demandez quels changements comptent et à quelle vitesse l’entreprise doit les voir reflétés. Un manuel historique, un stock en temps réel et une politique retirée n’ont pas les mêmes exigences de mise à jour. Définissez des attentes distinctes lorsque les conséquences d’informations périmées diffèrent.
Identifiez la source faisant autorité et la personne qui l’approuve. Un dossier partagé peut contenir des brouillons, des doublons et des archives. Ingérer tout ce qui a changé récemment ne détermine pas quelle version le personnel doit suivre. L’autorité du contenu exige une règle métier avant de devenir une règle d’indexation.
| Changement de source | Comportement système à définir | Preuve à examiner |
|---|---|---|
| Révision approuvée | Remplacer ou rendre obsolète le contenu indexé concerné | Références des versions source et indexée |
| Retrait du document | Retirer son admissibilité à la recherche | Absence dans des tests de recherche contrôlés |
| Changement de permissions | Appliquer la nouvelle limite d’accès | Résultats sous les identités concernées |
| Déplacement ou renommage | Préserver ou changer délibérément l’identité du document | Correspondance stable et rapprochement des liens |
| Échec d’ingestion | Exposer l’état périmé ou indisponible | Alerte attribuée et dernière version confirmée |
Ne promettez pas un intervalle universel de fraîcheur avant de comprendre l’API source, l’indexation et le besoin opérationnel. Une proposition fournisseur doit préciser ce qui est mesurable, ce qui peut le retarder et ce que fait l’assistant pendant la mise à jour en attente.
Préserver l’identité des documents et fragments
Donnez aux enregistrements sources une identité stable qui résiste aux mises à jour ordinaires lorsque la source le permet. Conservez leur version, leur emplacement et leur relation aux fragments. Le nom du fichier seul peut être insuffisant quand des fichiers sont renommés, copiés ou remplacés sur place.
La présentation des indexeurs Azure AI Search de Microsoft décrit les indexeurs comme des composants d’ingestion de sources de données. Lisez le fonctionnement réel du suivi des changements du connecteur choisi. Une exécution planifiée est un mécanisme, pas une preuve que toutes les opérations sources sont détectées.
Gardez vérifiable la correspondance entre source et fragments. Lorsqu’un paragraphe change, le système doit savoir quels fragments antérieurs sont remplacés. Ajouter de nouveaux fragments sans retirer les anciens peut produire des preuves contradictoires, même si chaque embedding est techniquement valide.
Enregistrez la production des champs dérivés. Extraction de texte, normalisation et découpage peuvent changer le sens indexé. Lorsqu’une réponse devient erronée après une modification du pipeline, l’opérateur doit pouvoir distinguer une révision source d’un changement d’extraction ou de recherche.
Traiter la suppression comme un cycle de vie distinct
Ne supposez pas qu’un fichier disparaissant du stockage supprime automatiquement sa représentation indexée. Les recommandations Microsoft sur la détection des modifications et suppressions distinguent explicitement suivi des mises à jour et détection des suppressions pour les indexeurs de stockage, et décrivent les stratégies prises en charge.
L’implémentation dépend de la plateforme, mais la question d’acceptation est générale : après un retrait approuvé, l’assistant peut-il encore récupérer l’ancien contenu ? Testez l’index concerné, les fragments dérivés et les caches de réponses au lieu d’examiner uniquement le dossier source.
Rapprocher l’état après une suppression interrompue
Conservez une trace des retraits jusqu’à confirmation de l’état en aval. Si l’objet source est supprimé définitivement avant que l’indexeur observe son marqueur de suppression, le système peut perdre le signal dont il dépendait. Utilisez le cycle de vie pris en charge par le fournisseur choisi et vérifiez l’état final.
Incluez les transformations d’un objet en plusieurs. Un document peut créer plusieurs fragments ou enregistrements. Le parcours de suppression doit prendre en compte ces objets dérivés. Supprimer une ligne de métadonnées parent tout en laissant des enfants récupérables ne constitue pas un retrait accepté.
Appliquer les changements de permissions lors de la recherche
Un contenu récent peut rester inapproprié pour l’utilisateur demandeur. Identifiez où les droits actuels de l’utilisateur et de l’organisation sont appliqués. Copier une permission source une fois dans les métadonnées ne prouve pas qu’un changement ultérieur d’appartenance atteint la frontière de recherche.
Les recommandations d’OWASP sur l’autorisation conseillent de vérifier l’accès à chaque requête. Appliquez ce principe à la recherche et aux liens de la réponse. Une citation ne doit pas révéler le titre ou un extrait d’un document que l’utilisateur n’est pas autorisé à consulter.
| Couche de recherche | Changement à tester | Question d’acceptation |
|---|---|---|
| Connecteur source | Changement d’appartenance utilisateur ou groupe | L’ingestion préserve-t-elle le périmètre prévu ? |
| Requête de recherche | Un utilisateur perd l’accès au document | Le document est-il exclu des résultats ? |
| Cache de réponses | Une ancienne réponse contient du texte restreint | Une requête ultérieure peut-elle recevoir cette divulgation en cache ? |
| Lien de citation | L’emplacement source change | L’utilisateur atteint-il la bonne version autorisée ? |
Notre guide de l’assistant IA interne couvre le workflow général des employés. La maintenance de la fraîcheur doit s’intégrer à ce modèle de permissions plutôt que créer un parcours de données distinct disposant de droits plus larges.
Rendre les preuves périmées visibles aux opérateurs
Enregistrez la dernière version source confirmée et le point atteint par l’ingestion. Séparez récupération source, extraction, indexation et validation de la recherche. Un pipeline peut récupérer correctement les données sans indexer le contenu révisé ; un seul horodatage de dernière exécution peut donc induire en erreur.
Choisissez les alertes selon les attentes convenues pour la source. Un document d’archive inchangé n’exige pas d’alarme simplement parce qu’il est ancien. Une mise à jour échouée d’une procédure opérationnelle peut nécessiter une enquête même si l’index a été mis à jour correctement peu auparavant.
Présentez aux utilisateurs un état d’incertitude adapté lorsque les preuves actuelles ne peuvent pas être établies. Il peut s’agir d’une invitation à consulter le responsable ou d’un refus de répondre depuis une source retirée. Évitez de présenter avec assurance un texte périmé simplement parce qu’un résultat de recherche existe.
Gardez une journalisation proportionnée. Identifiants sources, versions et résultats du pipeline peuvent soutenir une enquête sans copier chaque document confidentiel dans un système général de télémétrie. Convenez séparément des accès et de la conservation de tout contenu capturé.
Tester tout le cycle de vie avec des documents contrôlés
Créez un petit corpus contrôlé avec des affirmations reconnaissables et des versions volontairement différentes. Posez la même question pertinente avant et après une mise à jour, un retrait ou un changement de permissions. Examinez les preuves récupérées ainsi que la réponse finale.
Incluez les traitements échoués et retardés. Interrompez une mise à jour contrôlée entre les étapes, puis démontrez comment le système reprend et rapproche l’état. Testez renommage, remplacement et sources dupliquées lorsque le connecteur prévu les prend en charge. Documentez la décision d’identité attendue.
Notre guide d’évaluation des agents IA explique comment distinguer une réponse utile d’une preuve du résultat accepté. Ici, l’acceptation comprend le retrait des données de recherche dépassées et l’application des droits actuels du demandeur, et pas simplement une prose paraissant plus récente.
Conservez les jeux de test du cycle de vie comme cas de régression. Revérifiez-les après des changements d’extraction, de découpage, d’indexation ou de cache. Un nouveau modèle de recherche peut améliorer la pertinence tout en révélant un problème d’enregistrements périmés auparavant masqué.
Comparer une réparation à un pipeline de remplacement
Commencez par localiser la rupture dans le cycle de vie. Une gestion des suppressions manquante, une identité instable ou un cache mal délimité peuvent permettre une réparation ciblée. Une nouvelle base vectorielle ne corrigera pas une autorité source incertaine ou une ingestion qui n’enregistre jamais les retraits.
| Lot de travail | Livrable | Facteur de périmètre |
|---|---|---|
| Audit du cycle de vie | Carte des identités et défaillances de la source à l’index | Nombre et comportement des connecteurs |
| Réparation des mises à jour et suppressions | Changements d’état reproductibles en aval | Fragments dérivés et contrats fournisseurs |
| Vérification des permissions | Preuves actuelles de recherche par utilisateur | Appartenances sources et conception du cache |
| Exploitation | Rapprochement et alertes attribuées | Attentes de fraîcheur requises |
| Transfert | Jeux de test du cycle de vie et documentation | Fréquence des changements sources et pipeline |
Demandez des propositions en GBP liées à ces résultats. Séparez réparation initiale, ingestion, stockage, recherche et maintenance continue. Un prix fondé uniquement sur le nombre de documents peut omettre la difficulté principale : maintenir les bons documents à jour et autorisés.
Notre pilote délimité d’intégration IA peut partir d’un exemple de réponse périmée et de sa source faisant autorité. Envoyez-nous la mise à jour ou le retrait manqué par l’assistant pour discuter d’une enquête ciblée et d’une réparation du cycle de vie validée.
Questions fréquentes
Qu’est-ce que la fraîcheur des données RAG ? C’est la relation entre les sources actuelles approuvées et les preuves disponibles pour la recherche et les réponses. Elle comprend mises à jour, retraits, changements d’identité et permissions, et pas seulement la date de la dernière ingestion.
La réindexation supprime-t-elle automatiquement les documents supprimés ? Pas nécessairement. Vérifiez le comportement de suppression pris en charge par le connecteur choisi et contrôlez les fragments dérivés ainsi que les enregistrements parents. Certaines plateformes exigent une stratégie explicite de suppression.
Devons-nous recalculer les embeddings de tous les documents à chaque exécution ? Ce n’est pas une exigence universelle. Utilisez une identité source stable et le suivi des changements lorsque cela convient, puis rapprochez l’état obtenu. Le résultat important est une preuve de recherche actuelle, complète et autorisée.
Quel niveau de fraîcheur faut-il au système ? Définissez-le selon la source et les conséquences. Une instruction opérationnelle retirée peut exiger un traitement différent d’une archive historique. Précisez le comportement attendu de mise à jour et le repli s’il ne peut pas être respecté.
Le cache de réponses peut-il produire des résultats périmés ? Oui. Un index actuel n’invalide pas automatiquement un ancien cache de réponses. Testez la relation du cache aux versions sources, retraits et permissions utilisateur, y compris après une révocation d’accès.
Pourquoi les fichiers renommés comptent-ils ? Ils peuvent changer l’identité ou l’emplacement utilisé par un connecteur. Le système risque sinon de créer un doublon ou de perdre sa correspondance avec les anciens fragments. Définissez si le renommage conserve le même enregistrement source et testez le fonctionnement réel du fournisseur.
Faut-il une nouvelle base vectorielle ? Pas automatiquement. Localisez d’abord le défaut du cycle de vie. Un problème délimité de mise à jour, de suppression ou de cache peut être réparable dans le pipeline existant. Le remplacement doit être justifié par les mêmes exigences de fraîcheur et de responsabilité.
Que doit remettre un fournisseur de maintenance ? Les correspondances sources, règles du cycle de vie, instructions de rapprochement, documents de régression contrôlés et preuves de tests de mise à jour, retrait et permissions. Incluez les limites connues des connecteurs et le responsable des défaillances non résolues.