Une application IA ne corrige pas une donnée mal comprise. Elle peut au contraire rendre l'erreur plus convaincante en la transformant en réponse fluide. Construire une architecture data pour l'IA consiste donc moins à choisir une base vectorielle qu'à organiser la provenance, les droits, la qualité, l'évaluation et l'exploitation.

Partir de la réponse attendue

Avant le pipeline, définissez la décision ou l'action soutenue par le système. Une recherche documentaire interne n'a pas les mêmes exigences qu'un assistant client ou qu'une prédiction utilisée pour allouer des ressources.

Pour chaque réponse, demandez :

  • quelles sources font autorité ;
  • quelle fraîcheur est nécessaire ;
  • quelles citations doivent être visibles ;
  • qui a le droit d'accéder au document ;
  • comment reconnaître une réponse insuffisante ;
  • comment corriger la source.

Cette analyse évite de verser des documents dans un index sans savoir ce que signifie « correct ».

Construire une chaîne traçable

Une chaîne RAG typique comprend collecte, extraction, nettoyage, découpage, enrichissement, indexation, recherche et génération. Chaque étape doit conserver un identifiant reliant le fragment au document, à sa version et à ses droits.

Le découpage influence fortement la qualité. Des fragments trop courts perdent le contexte ; des fragments trop longs diluent le signal et augmentent le coût. Testez plusieurs stratégies sur des questions réelles plutôt que de choisir une taille universelle.

Les métadonnées sont aussi importantes que les embeddings : type de document, produit, langue, date, propriétaire, niveau de confidentialité et période de validité permettent de filtrer avant la recherche.

Base vectorielle ou base existante

Une base vectorielle spécialisée devient utile lorsque le volume, les types d'index, la distribution ou la latence le justifient. Pour un premier système, une base relationnelle déjà maîtrisée avec une extension vectorielle peut simplifier sauvegarde, droits et exploitation.

La décision doit comparer :

  • volume de vecteurs et fréquence de mise à jour ;
  • filtres structurés nécessaires ;
  • exigences de cohérence ;
  • sauvegarde et restauration ;
  • compétences disponibles ;
  • coût d'une migration.

Le guide sur la qualité d'un RAG et le choix vectoriel détaille les compromis. Évitez de créer un second système de vérité : l'index sert la recherche, tandis que les sources originales restent responsables du contenu.

Mesurer la qualité à plusieurs niveaux

Un pipeline vert ne garantit pas une réponse utile. Mesurez séparément :

  1. ingestion : documents attendus, erreurs et retards ;
  2. recherche : présence des bons passages parmi les résultats ;
  3. génération : fidélité aux sources et respect du format ;
  4. produit : résolution de la tâche et satisfaction ;
  5. risque : fuite de données, contenu obsolète et réponse non fondée.

Constituez un jeu de questions avec sources attendues. Ajoutez des questions sans réponse, des droits différents et des documents contradictoires. Le système doit pouvoir dire qu'il ne sait pas.

Notre article sur l'observabilité des pipelines data propose les signaux techniques ; celui sur la qualité des données pour l'IA générative complète la partie métier.

Gérer fraîcheur, suppression et droits

Une mise à jour de document doit déclencher la réindexation ou rendre l'ancienne version indisponible. Une suppression doit se propager aux fragments, caches, index et jeux de test lorsque la politique l'exige.

Les droits doivent être appliqués avant que les passages n'entrent dans le contexte du modèle. Masquer une réponse dans l'interface après génération arrive trop tard. Testez explicitement qu'un utilisateur ne peut pas retrouver un document auquel il n'a pas accès.

Attribuez un propriétaire aux jeux de données critiques et une durée de validité. Une donnée sans responsable finit par devenir une dépendance que personne n'ose corriger.

Exploiter comme un service

Définissez des objectifs de fraîcheur, disponibilité et temps de réponse. Surveillez coût par requête, volume de contexte, erreurs d'ingestion, dérive des résultats et proportion de réponses sans source.

Préparez des modes dégradés : recherche classique sans génération, réponse limitée aux documents vérifiés ou transfert à un humain. Une indisponibilité du modèle ne devrait pas nécessairement rendre toute la connaissance inaccessible.

Les changements de modèle, d'embedding ou de découpage nécessitent une comparaison sur le même jeu d'évaluation. Le suivi MLOps en production fournit un cadre pour cette continuité.

Une architecture progressive

Commencez avec une source bien comprise, un pipeline observable, un index et cinquante questions évaluées. Ajoutez ensuite les sources, formats et automatisations. Cette progression révèle les vrais problèmes avant qu'ils soient masqués par une plateforme complexe.

La qualité d'une architecture data pour l'IA se mesure à sa capacité à expliquer d'où vient une réponse, qui pouvait la voir, quand la source a changé et comment le système a été testé.