Intégration RAG¶

Le pipeline s'appuie sur deux collections Qdrant complémentaires.

Diagramme¶

Collection 1 : entités canoniques par transcription¶

Nom de la collection : {transcript_id} (une collection par transcription,
créée par l'étape d'enrichissement RAG du pipeline de transcription).

Usage par le Reliability Pipeline¶

Le module ReliabilityRagEnricher.fetch_canonical_entities exécute un
scroll sur cette collection (top-K configurable, défaut 20), puis agrège
les payloads pour reconstruire un dictionnaire :

{
  "persons":   ["Alice", "Bob", ...],
  "orgs":      ["MeetNoo", ...],
  "places":    ["Tunis", "Lyon", ...],
  "acronyms":  ["API", "RAG", ...],
  "keywords":  ["pipeline", ...],
}

Chaque liste est plafonnée à RELIABILITY_RAG_CANONICAL_MAX_ITEMS
(défaut 30) et triée par fréquence décroissante.

Effets de ce dictionnaire¶

• Sert d'entrée à la détermination du mode (RAG_ENHANCED vs
  CONTEXT_FREE).
• Active le gate S2 : si la valeur normalisée d'un candidat est strictement
  présente dans la liste de son type, l'appel LLM est sauté.
• Fournit le signal RAG consommé par le Multi-Signal Scorer (via
  token_set_ratio).
• Conditionne le prompt LLM en mode RAG_ENHANCED (la liste est injectée
  comme source de vérité avec un cap RELIABILITY_V5_CANONICAL_LIST_CAP,
  défaut 50).

Collection 2 : mémoire des corrections¶

Nom de la collection : reliability_corrections_memory (une seule
collection partagée, namespacée par user_id dans le payload).

Dimension vectorielle : RELIABILITY_CORRECTIONS_MEMORY_VECTOR_DIM
(défaut 1024, aligné sur bge-m3).

Bootstrap¶

CorrectionsMemoryBootstrap.ensure_collection est exécuté au démarrage de
l'application FastAPI (lifespan). L'opération est idempotente :

1. Vérifie l'existence de la collection.
2. Vérifie la cohérence de la dimension vectorielle (sinon DIM_MISMATCH).
3. Crée trois index de payload :
4. user_id (keyword) — filtrage par utilisateur,
5. entity_type (keyword) — filtrage par type,
6. quarantine_until (integer) — filtrage temporel pour le job de promotion.

Écriture (action utilisateur)¶

Module : CorrectionMemoryWriter.

Lorsqu'un utilisateur accepte ou édite une suggestion (validated ou
auto_applied), l'application enregistre la correction :

1. Déduplication sémantique : recherche cosine top-1 ; si score ≥
   RELIABILITY_CORRECTIONS_MEMORY_DEDUPE_THRESHOLD (défaut 0.95),
   incrémente uniquement frequency au lieu d'écrire un nouveau point.
2. Écriture Qdrant du point avec payload structuré.
3. Mirror PostgreSQL dans la table
   reliability_corrections_quarantine (point pivot pour les jobs et la
   cascade RGPD).
4. Compensation atomique : si l'écriture PostgreSQL échoue après
   l'écriture Qdrant, le point Qdrant est supprimé pour préserver la
   cohérence.

Le payload Qdrant contient :

{
  "user_id": str,
  "entity_type": "person" | "org" | "location" | "acronym" | "date" | "typo",
  "original": str,
  "final": str,                       # tronqué à FINAL_TEXT_MAX_LEN
  "action": "accept" | "edit",
  "frequency": int,
  "context_phrase": str,              # ±CONTEXT_RADIUS chars
  "promoted_to_canonical": bool,
  "quarantine_until": int,            # epoch
  "source_suggestion_id": str | None,
  "transcript_id": str | None,
  "payload_schema_version": int,
  "embedding_model": str,
  "embedding_model_version": str,
}

Lecture (boost de confiance)¶

Module : CorrectionsMemoryReader.

Avant le scoring, le pipeline interroge cette mémoire pour appliquer un boost
de confiance aux candidats déjà corrigés par le même utilisateur dans le passé.

Filtres appliqués à la recherche :

• user_id = utilisateur courant,
• entity_type = type du candidat,
• quarantine_until > now() exclu (les corrections expirées ne sont pas
  considérées),
• promoted_to_canonical = false exclu (les corrections promues sont déjà
  consommées par d'autres mécanismes).

Formule du bonus :

bonus = min(MAX_BONUS,
            (score - THRESHOLD) * SCORE_WEIGHT
          + log(1 + freq) * FREQ_WEIGHT)

Constantes (par défaut) : THRESHOLD=0.85, SCORE_WEIGHT=1.5,
FREQ_WEIGHT=0.05, MAX_BONUS=0.20.

La lecture est fail-soft : toute erreur Qdrant laisse les candidats
inchangés.

Promotion canonique¶

Un job périodique (quotidien) promeut les corrections suffisamment fréquentes
et anciennes pour devenir des entités canoniques globales. Les points promus
sont marqués promoted_to_canonical=true puis exclus des lectures de boost.

Variables associées :
RELIABILITY_CORRECTIONS_MEMORY_PROMO_MIN_FREQ,
…_PROMO_BATCH_SIZE, …_PROMO_RUN_HOUR_UTC,
…_DELETE_AFTER_PROMO, …_PROMO_ALERT_THRESHOLD.

Cascade RGPD¶

Module : CorrectionsMemoryCleanup.

Lors de la suppression d'un utilisateur :

1. Sélectionne qdrant_point_id depuis
   reliability_corrections_quarantine filtré par user_id.
2. Supprime en batch les points Qdrant correspondants.
3. Laisse la suppression PostgreSQL se faire par cascade ON DELETE CASCADE
   définie sur la FK user_id.

Un job de réconciliation détecte et nettoie les éventuels points orphelins
côté Qdrant.

Garde-fous¶