Retour à l’étude de cas

Architecture du système

Vue technique de l’infrastructure qui propulse l’écosystème Casa Islamica, au croisement de la data engineering et des applications utilisateur.

Système en production

Moteur d’IA conversationnelle (v3.1)

Pipeline RAG (Retrieval-Augmented Generation) multi-étapes avec routing sémantique, fallback de précision sur source primaire et reranking Cohere.

1. Ingestion et routing
  • ◆ Réception de la requête via Webhook et initialisation de la gestion de session.
  • ◆ Le Query Rewriter LLM traduit et enrichit sémantiquement les termes de recherche.
  • ◆ Détecteur de correspondance exacte par regex déclenche le routing spécialisé.
2. Recherche vectorielle
  • ◆ Application de filtres de dimension dynamiques (ex. Cadre juridique, Théologie, Philosophie).
  • ◆ Recherche parallèle dans Pinecone et lookup direct sur l’index des manuscrits primaires.
  • ◆ Le Reranker Cohere optimise les Top K résultats pour la précision contextuelle.
3. Synthèse
  • ◆ Formatage du contexte récupéré selon la hiérarchie de sources par tier.
  • ◆ Injection du buffer mémoire LangChain pour le contexte des conversations multi-tours.
  • ◆ GPT-4o génère la réponse en respectant des guardrails stricts par domaine.
4. Télémétrie et output
  • ◆ Retourne le payload à l’interface utilisateur.
  • ◆ Enregistre les métriques de récupération (F1, Précision) dans Google Sheets.
  • ◆ Pousse les données d’interaction vers Supabase et déclenche les notifications Slack.
Pipeline de data engineering

Classification automatisée du corpus (v3)

Système de traitement par lots pour ingérer des PDF bruts, extraire le texte et appliquer un étiquetage de métadonnées par LLM en vue de la vectorisation.

1. Extraction

Itère sur les PDF bruts dans Google Drive. Télécharge les fichiers et exécute l’OCR/extraction de texte pour préparer les payloads de chaînes brutes.

2. Analyse IA

Gemini 2.5 Flash analyse les textes complets pour déterminer la stratégie de chunking, le tier de source, les tags de catégorie et les patterns regex structurels.

3. Formatage structuré

Parse l’output JSON, le formate dans un schéma standardisé, ajoute les métadonnées structurées au répo central et envoie les alertes de finalisation.

QA et pipeline ML

Système d’observabilité et d’évaluation

Architecture à 4 couches conçue pour une IA exigeant une haute précision. Sépare l’infrastructure transactionnelle du chat de la télémétrie analytique, et convertit les évaluations d’experts en dataset d’entraînement RLHF.

1. Télémétrie automatisée

N8N écrit le contexte complet de récupération (18+ champs incluant les scores de reranking et les snippets) dans une table OLAP, permettant le diagnostic de cause racine entre échecs de génération et de récupération.

2. Signal utilisateur

Le frontend React capture un feedback structuré. La distinction stricte entre ‘pas utile’ (échec UX) et ‘erreur’ (désinformation théologique) achemine les cas à haute sévérité vers une file prioritaire.

3. Revue d’experts

Panneau d’administration avec scoring isolé par administrateur. Utilise un rubric à 4 catégories où un score ternaire de ‘Correction’ conditionne automatiquement le verdict final, évitant les labels d’entraînement contradictoires.

4. Export RLHF

Agrège les logs revués dans un dataset de 30 champs. Préserve les métadonnées de récupération, l’identité de l’annotateur et les détails complets du rubric pour entraîner de futurs reward models.

Sous le capot

Logique d’orchestration

Exécution nœud par nœud, mappée directement depuis les couches d’orchestration n8n. Organisée par étape architecturale pour mettre en évidence les gates de décision, la gestion des contraintes et les mutations de données.

Pipeline 1 : RAG Chatbot (v3.1)

33 nœuds · Synchrone + Asynchrone
Étape 1 : Prétraitement
Webhook Trigger

Reçoit la requête en espagnol et l’UUID de session. Découple N8N des edge functions du frontend.

Query Rewriter (GPT-4o-mini)

Traduit de l’espagnol vers l’anglais et enrichit sémantiquement la requête pour améliorer le recall vectoriel.

Décision : GPT-4o-mini plutôt que GPT-4o. La traduction est une tâche à faible enjeu ; économise le coût et la latence avant la récupération intensive.
Étape 2 : Récupération
Filtre de dimension et router

Extrait les tags thématiques (ex. Rulings juridiques, Théologie) pour restreindre l’espace de recherche. Détecte les demandes explicites de texte primaire et les route vers un index autoritatif dédié.

Recherche vectorielle Pinecone

Interroge 64 800 vecteurs. Récupère Top-K=30. Strictement limité aux sources Tier 1 (Pratique) et Tier 2 (Commentaire).

Étape 3 : Reranking
Cohere Rerank API v2

Requête HTTP directe contournant le wrapper SDK pour un contrôle total des paramètres. Utilise un cross-encoder pour réordonner le Top 30 en Top 7. Écarte les scores inférieurs à 0,3.

Post-Rerank processing

Applique un boost Tier 1 pour prioriser les guides pratiques. Plafonne la diversité des sources (max. 2 chunks par livre). Fusionne les chunks adjacents pour restaurer le contexte.

Étape 4 : Génération
Assemblage du contexte

Formate les chunks par tier. Injecte le buffer mémoire persistant sauvegardé dans Supabase pour le contexte des conversations multi-tours.

Synthèse GPT-4o

Lit les sources en anglais pour générer un output localisé. Applique des guardrails stricts par domaine et des citations inline. Instruit pour admettre l’incertitude si les sources manquent de contexte.

Étape 5 : Output et observabilité
Exécution parallèle

Retourne le JSON au Webhook de façon synchrone pour le rendu immédiat de l’UI, tout en enregistrant la télémétrie de façon asynchrone.

Métriques trackées
Reranker F1 & Precision E2E Latency (ms) Source Tier Spread Context Diversity
Séparation des données : Écrit l’historique de session dans Supabase (agrégations analytiques OLAP) et Google Sheets (QA humaine immédiate), maintenant les requêtes analytiques hors de la base de production.

Pipeline 2 : Classification batch du corpus (v3)

10 nœuds · Traitement par lots
Étape 1 : Contrôle du lot
Drive Discovery

Scanne le dossier d’ingestion à la recherche de PDF bruts. Alimente le tableau de fichiers au contrôleur d’itération.

Loop Controller

Traite exactement un livre à la fois pour éviter l’épuisement du rate limit de l’API et le débordement mémoire.

Étape 2 : Ingestion
Extraction binaire

Télécharge le PDF et extrait le payload de texte brut. Une extraction de faible fidélité est acceptable ici : le LLM n’a besoin que d’une compréhension thématique.

Étape 3 : Analyse IA
Gemini 2.5 Flash

Exploite la fenêtre de contexte de 1M tokens pour ingérer le livre entier. Classifie le tier de source, génère 22 champs JSON distincts et détermine la stratégie de chunking vectoriel (ex. thématique vs. épisodique).

Étape 4 : Transfert des données
Ajout dans Sheets

Écrit l’output analysé dans Google Sheets, qui sert de gate obligatoire de revue humaine avant la génération des vecteurs.

Buffer de rate limit

Impose une attente stricte de 10 secondes avant de passer au livre suivant, pour protéger les quotas de l’API Gemini.

Pipeline 3 : Architecture d’observabilité et d’évaluations

4 couches · Écritures parallèles en DB
Couche 1 : Télémétrie (N8N)
chatbot_queries_logs

Capture le contexte complet de récupération — pas seulement la réponse. Permet de diagnostiquer si un échec vient d’une mauvaise récupération de chunks ou de la génération LLM.

OLAP Table
Couche 2 : Signal utilisateur (React)
chatbot_message_feedback

Chemins de feedback structuré. Distinction stricte imposée : ‘erreur’ ≠ ‘pas utile’. Les erreurs signalent une potentielle désinformation théologique nécessitant une revue immédiate.

OLTP Table
Séparation intentionnelle du schéma
Couche 3 : Revue administrative
Moteur de rubric ternaire

Note selon 4 dimensions. La Correction admet des états partiels (0, 0,5, 1) car la précision théologique a des gradations significatives. Clarté/Efficacité sont binaires.

Verdict calculé automatiquement
  • IF correctness = 0 → BAD
  • IF correctness = 0.5 OR completeness = 0 → BAD
  • IF correctness = 1 AND completeness = 1 → GOOD

Calculé, non fixé manuellement — évite les contradictions rubric/verdict dans les données d’entraînement.

Couche 4 : Export Super Admin
Dataset prêt pour le RLHF

Export CSV/XLSX en masse combinant métadonnées de récupération, identité de l’annotateur, notes utilisateur et détails complets du rubric.

Pourquoi 30 champs ?
Les reward models ont besoin de signaux plus riches qu’un simple « bon/mauvais ». Exporter le contexte complet permet d’entraîner des modèles qui améliorent simultanément la récupération et la génération.