Quelles fonctionnalités permettent une sélection fiable des versions de documents dans le RAG ?

Une sélection fiable des versions exige de traiter l’identité des documents et leur validité temporelle comme des contraintes de recherche, plutôt que d’espérer que la similarité vectorielle privilégie le texte le plus récent.

Un NAS peut conserver plusieurs manuels d’appareils, polices d’assurance ou plans familiaux modifiés dont le contenu est presque identique. Une recherche dense peut classer une révision obsolète au-dessus de la version actuelle, car la pertinence et la validité sont deux signaux différents. Un pipeline sensible aux versions stocke des révisions immuables, modélise les remplacements et les dates d’entrée en vigueur, interprète la dimension temporelle de la requête et cite la révision exacte utilisée.

Des identifiants stables de source et de révision séparent l’identité de l’emplacement

Un document logique conserve un identifiant de source stable, tandis que chaque révision capturée reçoit un identifiant de révision immuable, une empreinte de contenu, une date d’ingestion, un intervalle de validité, un état de cycle de vie et une correspondance de chemin. Les fragments héritent des deux identifiants au lieu de porter une étiquette vague telle que « dernière version ».

Le cadre de recherche sensible aux versions modélise explicitement les séquences de versions, les limites du contenu et les changements, et fait état de gains importants par rapport au RAG naïf pour les questions sensibles aux versions. Sa conception montre pourquoi un texte similaire nécessite des informations structurelles sur les versions. Cette distinction reste visible lors des tests ultérieurs en environnement domestique.

Les liens de remplacement indiquent si une révision remplace entièrement un document antérieur, ne modifie que certaines sections ou reste valide pour une version différente du produit. La seule date de modification du chemin ne peut pas représenter ces relations et peut refléter une copie plutôt que la validité effective.

La date de la requête et l’applicabilité doivent intervenir dans la recherche

Une requête peut demander la règle actuelle, la règle en vigueur l’année dernière ou les instructions correspondant à une version précise du firmware. Avant le classement des candidats, le processeur de requêtes extrait les contraintes temporelles explicites et implicites, ainsi que le produit, la juridiction, le propriétaire et le contexte du cycle de vie.

Une étude sur un jeu de données de contraintes de recherche temporelles explique comment la mise en correspondance sémantique peut récupérer des éléments obsolètes lorsque les questions comportent des contraintes temporelles. Elle préconise d’évaluer séparément la recherche sensible au temps et la restitution factuelle statique. Le résultat intermédiaire doit rester inspectable avant toute automatisation.

Le filtrage peut sélectionner les révisions admissibles avant la recherche vectorielle, tandis qu’un score temporel peut ensuite réordonner les candidats qui se chevauchent. Le système ne doit pas toujours privilégier le fichier le plus récent : les questions historiques exigent la révision valide au moment demandé.

Les amendements qui se chevauchent nécessitent une logique de conflit et de filiation

Certaines mises à jour remplacent une clause tout en laissant le reste du document en vigueur. Découper chaque instantané en fragments indépendants crée de nombreux doublons presque identiques et peut combiner une ancienne clause amendée avec des éléments actuels inchangés. La filiation des versions nécessite des limites et une validité au niveau des sections.

L’approche de recherche sémantico-temporelle combine la pertinence sémantique et temporelle pour les documents évolutifs qui se chevauchent et fait état de gains en nDCG@10. Cela montre pourquoi le temps n’est pas seulement un critère secondaire pour départager les métadonnées lorsque les amendements restent sémantiquement similaires. Cette limite doit être mesurée séparément dans des conditions d’utilisation réalistes.

La limite d’échec est l’applicabilité inconnue. Des dates d’entrée en vigueur manquantes, des noms de fichiers ambigus ou des révisions actives contradictoires doivent déclencher une demande de clarification ou une abstention, et non une sélection automatique de la « dernière version ». Conservez les candidats concurrents et leurs métadonnées afin qu’un réviseur puisse résoudre le dossier source.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Testez les requêtes portant sur les versions actuelles, historiques et ambiguës

Créez un jeu de test comprenant des remplacements complets, des amendements partiels, des révisions antidatées, des copies en double, des fichiers renommés, des brouillons, des versions archivées et un document dépourvu de date d’entrée en vigueur. Indiquez la révision correcte ou l’abstention attendue pour chaque question. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.

Comparez la sélection avec la chaîne de filiation dans la filiation de la source de réponse. Mesurez le rappel des versions admissibles, le taux de versions incorrectes, les réponses mélangeant plusieurs versions, la résolution des citations et la gestion des dates explicites, des dates relatives, des versions de firmware et des questions sur l’état actuel. Cette dépendance doit rester explicite dans l’interface finale.

Ne validez le système que lorsque chaque réponse cite la révision immuable applicable et que les cas ambigus restent non résolus. Si l’ajout de la récence améliore les requêtes actuelles mais dégrade les requêtes historiques, séparez le filtrage d’applicabilité du classement général au lieu d’augmenter un poids unique de fraîcheur.