Mettre en production un RAG traçable (AI Act) avec ≥85 % de groundedness

Ce guide opérationnel s’adresse aux développeurs, data engineers et architectes qui doivent transformer un prototype RAG en une plateforme robuste, auditable et conforme. Objectifs cibles :

• Groundedness ≥ 85 % (réponses appuyées par des sources explicites)
• Taux d’erreur / hallucination < 5 %
• Latence moyenne < 2 secondes
• Traçabilité complète : logs horodatés, citations, identifiants immuables conservés ≥ 7 ans
• Protection PII conforme RGPD / AI Act (anonymisation, chiffrement, contrôle d’accès)

1. Principes d’architecture

Déployer un service RAG interne exposé via une API HTTP. Composants essentiels :

• Ingestion contrôlée (ETL, détection/anonymisation PII, versioning de lot)
• Base documentaire versionnée + index vectoriel (pgvector, Qdrant, OpenSearch, Milvus…)
• Moteur RAG : retrieval → (re-)ranking → prompt → génération → post-traitement
• Système de logging et d’archivage chiffré avec politique WORM pour 7+ ans
• IAM strict (SSO, RBAC, scopes sur les documents) et contrôle d’accès au niveau chunk

Décision de sécurité cruciale : séparer physiquement et logiquement les contenus contenant des PII des index généralistes. Si recherche sur PII requise, créez un index dédié avec accès restreint et surveillance renforcée.

2. Prérequis infra et conformité

• Cluster Kubernetes ou stack Docker + orchestrateur ; stockage objet chiffré (bucket WORM).
• Base relationnelle (Postgres) pour métadonnées + index vectoriel dédié selon besoin de scale.
• KMS/HSM pour gestion des clés (enveloppe + rotation) ; journalisation d’usage des clés.
• Observabilité : Prometheus/Grafana, OpenTelemetry, ELK / OpenSearch pour logs et traces.
• Cadre conformité : classification des données, politique de conservation (≥7 ans) validée par le RSSI/juridique, DPIA si nécessaire.

3. Pipeline d’ingestion et versioning

Objectif : garantir traçabilité et reproductibilité depuis la source jusqu’au chunk indexé.

• Enregistrement d’un ingestion_batch_id, checksum des documents, version du chunker et du détecteur PII.
• Découpage (chunking) par unité logique, chevauchements contrôlés, taille en tokens adaptée au LLM.
• Enrichissement métadonnées : pii_level, acl_tag, source_system, valid_from, owner, doc_version.
• Anonymisation/pseudonymisation en amont : règles heuristiques + modèle NER validé ; stocker mapping en vault si ré-identification contrôlée requise.

// Exemple de table minimale (schéma conceptuel)
CREATE TABLE documents (
  doc_id UUID PRIMARY KEY,
  source_system TEXT,
  uri TEXT,
  version TEXT,
  created_at TIMESTAMPTZ,
  pii_level TEXT,
  acl_tag TEXT,
  checksum TEXT,
  ingestion_batch_id UUID
);

CREATE TABLE chunks (
  chunk_id UUID PRIMARY KEY,
  doc_id UUID REFERENCES documents(doc_id),
  chunk_index INT,
  content TEXT,
  embedding VECTOR,
  metadata JSONB,
  created_at TIMESTAMPTZ
);
  

4. Conception du service RAG

Flux principal :

1. Authentification et détermination des ACLs utilisateur.
2. Retrieval vectoriel filtré par ACL et métadonnées.
3. Re-ranking cross-encoder sur top-K (optionnel pour précision).
4. Construction du prompt avec extraits cités et contraintes explicites.
5. Appel LLM (avec traçabilité modèle_id, checksum, prompt_version).
6. Extraction des références utilisées et post-traitement (filtrage, anonymisation).
7. Journalisation complète (voir § logs).

def handle_query(query, user):
    request_id = generate_uuid()
    ts = now()
    acl = get_acl(user)

    candidates = vector_search(query, top_k=50, filters={"acl_tag": acl})
    ranked = rerank(query, candidates)[:10]

    prompt = build_prompt_with_citations(query, ranked, prompt_version="v2")
    model_resp = call_model(prompt, model_id="llm-legal-1.3")
    used_refs = extract_citations(model_resp.text)

    log_interaction(request_id, ts, user, ranked, model_resp, used_refs)
    return format_response(model_resp.text, used_refs)

Le prompt doit contraindre le modèle à ne s’appuyer que sur les extraits fournis et à émettre des citations structurées (ex. [n|doc_id|chunk_id]). Si l’information manque, le modèle doit répondre explicitement “information non disponible”.

5. Journalisation, archivage et intégrité

Le journal doit permettre de rejouer n’importe quelle interaction : quels documents ont été récupérés, quelle version du modèle a été utilisée, qui a accédé aux résultats.

{
  "request_id": "uuid",
  "timestamp": "ISO8601",
  "user": {"id_hash":"sha256:...", "roles":["support"]},
  "query": "...",
  "retrieval": { "top_k":50, "selected_k":10, "items":[{"rank":1,"doc_id":"...","chunk_id":"...","score":0.87}]},
  "generation": {"model_id":"llm-legal-1.3","model_checksum":"sha256:...","prompt_version":"v2","latency_ms":650,"used_refs":["[1|doc|chunk]"]},
  "ingestion_meta": {"ingestion_batch_id":"..."},
  "quality": {"auto_groundedness_score":0.92}
}

• Ne jamais loguer de PII brute : pseudonymisez ou hachez (id_hash) et tronquez les inputs sensibles.
• Stockage chaud pour 30–90 jours, archives chiffrées en stockage objet WORM pour ≥7 ans.
• Signer périodiquement les lots de logs et ancrer les hash de lots dans un registre immuable pour détecter altérations.

6. Auto-évaluation du groundedness (détails)

Automatiser un score de groundedness fiable : combiner extraction de citations, comparaison aux documents récupérés, et métriques pondérées.

Méthode recommandée :

1. Extraction des références formelles dans la réponse (regex sur le format [n|doc_id|chunk_id]).
2. Vérifier que chaque référence extraite correspond à un chunk effectivement récupéré pour la requête.
3. Calculer : grounded_rate = (nombre de réponses avec au moins une référence valide) / (total réponses).
4. Compléter par un score de précision des citations : citation_precision = (références valides) / (références totales).
5. Utiliser échantillonnage humain périodique (p. ex. 1% ou 1000 réponses/mois) pour calibrer le score automatique et corriger biais.

Formules :

grounded_rate = responses_with_valid_ref / total_responses
citation_precision = valid_refs / total_refs
auto_groundedness_score = weighted(grounded_rate, citation_precision, human_feedback)

Définir seuils d’alerte : auto_groundedness_score < 0.85 déclenche revue ; taux d’hallucination estimé > 5% → investigations (dataset drift, modèle, prompt).

7. Validation humaine et plan d’échantillonnage

• Eval offline sur jeu annoté (300–1000 questions) : métriques de référence.
• Validation online : échantillonnage aléatoire + ciblé (requêtes sensibles, nouveaux documents) avec interface d’annotation métier.
• Boucle H/M pour corriger prompts, retraining du reranker ou mise à jour du contenu.

8. Privacy & key management

• Utiliser KMS/HSM pour la gestion des clés ; appliquer enveloppe encryption (clé de données chiffrée par clé maître).
• Rotation régulière des clés, journalisation des accès aux clés, et séparation des rôles pour accès aux clés.
• Chiffrement en transit (TLS1.2+) et au repos (AES‑256).
• Limiter les sorties vers LLMs externes : minimiser le contexte (pas d’envoi de PII) ; si usage d’un fournisseur, contractualiser non-réutilisation et activer options de non-persistent-storage.
• Gérer les tokens et secrets via vault (HashiCorp Vault, cloud KMS) ; ne pas embedder de secrets dans les prompts.

9. Reproductibilité et gestion des versions

• Versionnez : modèles (model_id + checksum), prompts (prompt_version), pipeline d’ingestion (ingestion_batch_id + chunker_version), index (index_version), et schéma de la base.
• Capturer un instantané des documents référencés (doc_id + doc_version) pour pouvoir rejouer une requête exactement.
• Stocker artefacts d’infrastructure (images container, helm charts, commit hashes) avec CI/CD pour permettre rollbacks reproductibles.

10. Performance et tuning d’index

Objectif latence < 2s : découper le budget et optimiser chaque étape.

• Budget typique : retrieval 150–500 ms, rerank 50–250 ms, LLM generation 300–1200 ms (dépend du modèle), post-traitement 20–100 ms.
• ANN tuning :
• HNSW : M ≈ 12–48, ef_construction ≈ 100–500, ef_search ≈ 100–200 (augmenter ef_search pour rappel)
• IVF/PQ : nlist 1024–8192, nprobe 8–32 ; PQ pour réduire mémoire mais impact recall
• Embedding dims : 768–1536 selon modèle ; quantization si nécessaire pour scale
• Utiliser hybrid search (BM25 + vector) pour améliorer précision initiale.
• Reranker cross-encoder sur top-10 pour corriger erreurs d’ANN ; coût calculé en SLO.
• Mise en cache : résultats de requêtes fréquentes, embeddings warm-up, et shards répliqués pour tolérance.
• Mesurez latence P99, P95, throughput ; scale horizontalement (sharding, réplicas) et verticalement (GPU pour embeddings/LLM).

11. Monitoring, alerting et SLO

• Métriques à surveiller : groundedness (auto score), taux d’hallucination (estimation+humain), latence moyenne/P95/P99, taux d’erreur, disponibilité API, saturation des index.
• Alertes : groundedness < 85%, hallucinations >5%, P99 latency > 2s, erreurs 5xx > seuil.
• Dashboards et playbooks d’investigation (drift de données, dégradation du modèle, surcharge d’infra).

12. Plan de déploiement et gouvernance

• Phase pilote : subset d’utilisateurs, logs exhaustifs, évaluation humaine rapprochée.
• Phase échelle : validation des SLO, optimisation index, autoscaling, rotation des clés.
• Gouvernance continue : comité IA, revue trimestrielle des datasets, contrôles de conformité et audits techniques.

Checklist rapide

• Index séparé pour contenus PII et contrôle d’accès par chunk
• Ingestion versionnée (batch_id, checksum)
• Prompt contraignant aux citations structurées
• Logs détaillés + archivage chiffré ≥ 7 ans + signature d’intégrité
• KMS/HSM, rotation clés, vault pour secrets
• Auto-scoring groundedness + échantillonnage humain pour calibration
• Tuning ANN + reranker pour atteindre latence & recall cibles
• Versioning complet (model, prompt, index, infra) pour reproductibilité

Conclusion

Atteindre ≥85 % de groundedness en production demande d’articuler rigueur architecturale, traçabilité approfondie, gestion stricte des clés et des données personnelles, et une boucle humaine pour valider et corriger le scoring automatique. En combinant : indexation et métadonnées solides, prompt engineering contraignant, journalisation immuable et monitoring ciblé, on obtient une plateforme RAG auditable et conforme au AI Act / RGPD tout en respectant les SLOs de latence et de qualité.

Pour aller plus loin : implémenter des pipelines CI/CD reproduisant exactements les versions d’index et de modèles, et définir un plan d’audit périodique (p. ex. trimestriel) pour vérifier groundedness et conformité.