Évaluer un système RAG avant de l’acheter ou de le déployer

Dossier d’architecture appliquée — sources vérifiées le 21 juillet 2026

Résumé exécutif

Un système RAG peut produire une démonstration convaincante tout en restant fragile. Quelques réponses réussies ne disent rien sur les documents absents, les citations incorrectes, les fuites entre utilisateurs, la fraîcheur ou la stabilité après mise à jour. L’évaluation doit séparer au moins trois étages : récupération des passages, génération à partir du contexte et comportement opérationnel du pipeline. Knowledge Base fournit un terrain de construction pour cette démarche, mais les métriques publiques doivent être produites à partir d’un corpus et d’un protocole versionnés. Cet article propose une grille d’acceptation utilisable avant un achat, un pilote ou une mise en production.

Le problème à résoudre

Les évaluations informelles privilégient les questions dont l’équipe connaît déjà la réponse et corrigent manuellement les échecs pendant la démonstration. Elles mélangent ensuite retrieval, prompt et modèle dans un score global. Cette méthode empêche de localiser les causes : un mauvais résultat peut venir du document, de l’extraction, du chunking, des embeddings, de la fusion, du reranking ou de la génération.

Cette question doit être traitée comme une décision d’architecture et d’exploitation. Un composant impressionnant en démonstration peut rester inutilisable si les droits, la reprise, les coûts et les preuves sont implicites. À l’inverse, une première version bornée peut produire de la valeur si son périmètre est clair et si ses résultats sont mesurés.

Pour qui et pour quelle décision ?

• organisations achetant une solution RAG
• équipes documentaires
• développeurs de Knowledge Base
• responsables qualité et sécurité

Le lecteur ne doit pas seulement comprendre la technologie. Il doit pouvoir décider s’il faut lancer un audit, établir une baseline, construire une preuve de concept, organiser un pilote ou écarter l’approche lorsque les prérequis ne sont pas réunis.

Architecture de référence

Corpus de référence

Documents versionnés, droits, dates, formats et cas difficiles.

Golden set

Questions, réponses attendues, sources pertinentes et cas sans réponse.

Retrieval eval

Recall, precision, MRR, nDCG et couverture des passages utiles.

Answer eval

Fidélité, exactitude, citations, complétude et refus.

Ops eval

Latence, coût, fraîcheur, erreurs, reprise et isolation.

Décision

Seuils par risque, régressions acceptables et verdict borné.

L’intérêt de cette décomposition est de rendre les responsabilités remplaçables et testables. Le domaine métier ne doit pas dépendre d’un fournisseur, d’un modèle ou d’une interface unique. Les adaptateurs peuvent évoluer, tandis que les règles de données, de preuve et de décision restent stables.

Fonctionnement opérationnel

1. Construire les questions sans regarder les résultats du pipeline.
2. Annoter les passages pertinents et les cas où aucune réponse n’existe.
3. Évaluer le retrieval indépendamment du modèle génératif.
4. Vérifier que chaque affirmation importante est soutenue par une citation réellement fournie.
5. Mesurer les distributions et les pires cas, pas seulement la moyenne.
6. Rejouer la suite après tout changement de chunking, embeddings, reranker ou modèle.

Chaque étape doit produire un état observable. Une décision sans version de politique, un appel sans identifiant de trace ou une mise à jour sans rollback ne peut pas être considérée comme une capacité maîtrisée.

Sécurité et gouvernance

Les contrôles prioritaires sont les suivants :

• questions sentinelles vérifiant l’isolation entre utilisateurs
• documents contenant des instructions adversariales inoffensives
• tests de refus lorsque la source est absente
• contrôle des citations vers des sources autorisées
• journalisation des versions et paramètres
• données de test sans secrets réels

La sécurité ne doit pas être résumée à une liste de fonctionnalités. Elle doit être vérifiée par des scénarios négatifs : permission absente, donnée interdite, outil indisponible, secret expiré, résultat ambigu, interruption et reprise.

État de maturité

Ce qui existe, ce qui reste à prouver

Disponible

• architecture RAG hybride documentée dans Knowledge Base v2
• ingestion de notes, fichiers et URLs prévue ou implémentée selon les briques
• PostgreSQL/PGVector, MongoDB, Tika, SearXNG et Ollama documentés

Expérimental

• suite d’évaluation publique
• golden queries françaises
• dashboard de comparaison des pipelines

Planifié

• tests ACL-aware
• campagne adversariale
• régression continue en CI

Non couvert

• score public consolidé
• preuve de charge en production
• validation sur corpus client réel

Preuves et prudence

Registre de preuves

Élément	Statut	Interprétation
Architecture Knowledge Base	prouvé	Le dépôt privé TheWatcher01/knowledge_base_v2 confirme le monorepo Next.js/FastAPI, PostgreSQL/PGVector, MongoDB, Tika, SearXNG, Ollama et Docker Compose.
Qualité RAG	à mesurer	Aucun score ne doit être publié sans corpus, golden set, paramètres et scripts.
Citations	cible	Le protocole exige un lien entre réponse, chunks et sources, à tester systématiquement.
Isolation	à mesurer	Les filtres par utilisateur doivent être éprouvés avec des documents sentinelles.

Cas d’usage pertinents

• comparer deux fournisseurs sur le même corpus
• accepter ou refuser un pilote interne
• mesurer l’effet d’un reranker
• identifier les formats documentaires les plus fragiles
• surveiller les régressions après mise à jour

Ces cas d’usage ne constituent pas des promesses de résultat. Ils indiquent où un atelier ou un pilote peut produire une preuve utile sans engager immédiatement une transformation globale.

Protocole d’évaluation proposé

1. figer un corpus représentatif et ses droits
2. créer des questions factuelles, synthétiques, relationnelles et sans réponse
3. annoter les documents et passages pertinents
4. exécuter plusieurs répétitions par configuration
5. calculer retrieval, answer et ops metrics séparément
6. examiner manuellement les échecs critiques
7. publier configuration, limites et verdict

Les résultats doivent inclure les échecs et les régressions. Une configuration ne doit pas être promue parce qu’elle améliore une moyenne si elle dégrade un scénario critique ou contourne une contrainte de données.

De la preuve au pilote

Le passage à un pilote ne devrait intervenir qu’après la production d’une baseline et d’un registre des hypothèses encore ouvertes. Le premier périmètre doit rester assez petit pour que chaque entrée, décision et sortie puisse être inspectée. Il est préférable de couvrir un cas d’usage réel avec quelques utilisateurs et des critères d’acceptation explicites plutôt que d’ouvrir immédiatement la solution à toute l’organisation.

Le pilote doit produire des actifs réutilisables : jeu de tests, architecture observée, matrice de permissions, dictionnaire de métriques, runbook d’incident et procédure de retour arrière. Ces livrables permettent de décider si le système doit être étendu, corrigé, suspendu ou abandonné. Ils évitent aussi de dépendre d’une démonstration ponctuelle difficile à reproduire.

La valeur commerciale se construit donc autour d’un engagement progressif : audit, atelier, benchmark, preuve de concept puis pilote borné. Les prestations proposées dans cet article ne supposent pas que toutes les capacités sont déjà industrialisées ; elles organisent précisément le travail nécessaire pour transformer une architecture en résultat vérifiable.

Limites et risques résiduels

• Les métriques automatiques peuvent reproduire les biais du juge LLM.
• Un golden set trop simple favorise artificiellement le système.
• La qualité moyenne ne suffit pas pour un usage à fort impact.
• Les données client peuvent empêcher la publication du corpus ; il faut alors publier au moins la méthode.
• Un benchmark devient obsolète lorsque le corpus ou le pipeline change.

Cette transparence protège le lecteur et le projet. Elle évite de confondre une architecture cible, un composant disponible et une capacité démontrée dans des conditions reproductibles.

Questions fréquentes

Sources et méthode

Les sources ci-dessous sont officielles ou primaires. Elles soutiennent le cadre d’architecture et d’évaluation ; elles ne prouvent pas à elles seules la maturité des projets présentés.

• Microsoft GraphRAG — query overview
• Langfuse — traces et expériences
• NIST — pratiques d’évaluation

Le dépôt privé GitHub TheWatcher01/knowledge_base_v2, branche main, a été vérifié le 21 juillet 2026. Son README et son arborescence confirment l’architecture Next.js/FastAPI, PostgreSQL/PGVector, MongoDB, Tika, SearXNG, Ollama et Docker Compose. Les métriques de qualité, l’isolation et les flux end-to-end restent soumis aux protocoles décrits.