Aller au contenu

Reliability Pipeline

Mission

Le Reliability Pipeline analyse chaque transcription produite par le moteur ASR pour
détecter, normaliser et corriger les entités nommées erronées (lieux, personnes,
organisations, acronymes, fautes d'orthographe) puis exposer un score de fiabilité
par transcription servant de KPI qualité produit.

Le pipeline est :

  • Asynchrone — déclenché par événement à la fin de la transcription, n'impacte
    jamais la latence de l'utilisateur final.
  • Multi-signal — fusionne au minimum trois sources de preuves indépendantes
    (RAG, validation géographique, raisonnement LLM contraint) avant toute décision.
  • Human-in-the-loop — les corrections automatiques ne sont appliquées qu'à
    partir d'un score de confiance élevé ; sinon une suggestion est soumise à
    validation utilisateur via l'interface Corrections Hub.
  • Idempotent et reprenable — toute opération de persistance utilise une clé de
    déduplication stable ; toute action utilisateur accepte une idempotency_key.

Vue d'ensemble du flux

flowchart LR A[Transcription terminée] --> B[Event Redis Stream] B --> C[Reliability Worker] C --> D[Extraction des candidats] D --> E[Enrichissement RAG] E --> F[Raisonnement LLM contraint] F --> G[Scoring multi-signal] G --> H[Decision Gate] H -->|HUMAN_REVIEW| I[Persistance suggestion] H -->|REJECT| J[Suggestion ignorée] I --> K[Corrections Hub UI] K -->|action utilisateur| L[Application & audit] L --> M[Snapshot score mis à jour]

Carte du hub

Page Contenu
Architecture Composants, dépendances, frontières du domaine
Pipeline de traitement Étapes ordonnées de l'extraction à la décision
Validation géographique Sous-pipeline Photon + Wikidata pour les lieux
Scoring & décision Fusion multi-signal et Decision Gate
Intégration RAG Collections Qdrant utilisées par le pipeline
Workflow & événements Redis Streams, worker, state machine
Modèle de données Tables, contraintes, relations
API REST Endpoints publics et administration
Configuration Variables d'environnement
Observabilité Métriques, logs, troubleshooting

Principes directeurs

  1. Le score est calculé côté backend uniquement. Aucun calcul ni cache local
    côté frontend n'est admis ; le frontend lit les snapshots persistés.
  2. Fail-soft sur les dépendances externes. Une panne Photon, Wikidata, Qdrant
    ou LLM dégrade la qualité du signal correspondant mais ne bloque jamais le
    pipeline.
  3. Adaptation au contexte. Le pipeline opère en deux profils — RAG_ENHANCED
    quand un contexte canonique riche est disponible, CONTEXT_FREE sinon — avec
    seuils et capping de score adaptés.
  4. Toutes les décisions sont auditables. Chaque suggestion conserve un trail
    d'évidence (signaux, poids, seuil, raison), et chaque action utilisateur produit
    une ligne dans la table reliability_actions.