Coligo: A Retrieval-Augmented Generation Assistant for WhatsApp-Based TNEA Engineering Admission Counselling

Résumé Technique : Coligo – Un assistant de génération augmentée par récupération pour le conseil d'admission en ingénierie via WhatsApp (TNEA)

Problématique
Le processus de conseil pour les admissions en ingénierie au Tamil Nadu (TNEA) crée un goulot d'étranglement pour les bureaux des collèges, qui sont inondés de questions répétitives concernant les procédures d'admission, les frais par branche et les rangs de coupure (cutoff) spécifiques aux communautés (OC, BC, BCM, MBC, SC, SCA, ST). Les solutions actuelles reposent sur une intervention manuelle du personnel ou sur des chatbots génériques qui manquent de compréhension sémantique et d'accès à des données institutionnelles vérifiées. Il existe une lacune critique pour fournir des réponses qui soient :

1. Ancrées : Basées strictement sur les documents officiels du collège plutôt que sur les hallucinations du modèle.
2. Sensibles aux communautés : Distinguant les différentes catégories de réservation et les types de coupure (notes vs rangs).
3. Accessibles : Disponibles sur la plateforme que les étudiants utilisent déjà (WhatsApp) sans nécessiter l'installation de nouvelles applications.
4. Contextuelles : Capables de gérer les questions de suivi (ex. : « Qu'en est-il de l'ECE ? ») sans exiger que l'utilisateur reformule l'intégralité du contexte.

Méthodologie et Architecture du Système
Coligo est un système de Génération Augmentée par Récupération (RAG) conçu comme une pile Docker Compose à deux composants (un service FastAPI et une base de données PostgreSQL). L'architecture du système est la suivante :

• Pipeline d'ingestion : Les PDF officiels du collège (fusionnant les procédures d'admission, les cursus académiques et les seuils de coupure) sont traités via pypdf. Le texte est extrait et divisé en segments (chunks) chevauchants (512 mots avec un chevauchement de 50 mots) afin de préserver le contexte entre les limites. Les segments sont hachés (SHA-256) pour éviter les plongements (embeddings) en double lors de la ré-ingestion.
• Stockage vectoriel : Les segments sont plongés à l'aide du modèle text-embedding-004 de Google (768 dimensions) et stockés dans une base de données PostgreSQL étendue avec pgvector. Cela permet une recherche de similitude sémantique par distance cosinus.
• Récupération et Génération :
  • Réécriture de requête : Pour gérer les questions de suivi, le système utilise une mémoire basée sur la session (indexée par le numéro de téléphone WhatsApp ou l'ID de session). Si une requête dépend du contexte (ex. : « Qu'en est-il de l'ECE ? »), un appel LLM distinct réécrit la requête sous une forme autonome aux fins de récupération, tandis que la requête originale est conservée pour la génération de la réponse finale.
  • Pipeline RAG : Le système récupère les 5 segments (RAG_TOP_K=5) les plus pertinents. Ceux-ci sont combinés avec un prompt système strict qui impose les règles du domaine : distinguer les notes de coupure des rangs, répondre uniquement aux catégories de réservation spécifiques et refuser de répondre si le contexte est insuffiisant.
  • Génération : Google Gemini (LLM) génère la réponse finale, ancrée uniquement dans le contexte récupéré.
• Intégration WhatsApp : Le système se connecte via l'API WhatsApp Cloud. Il implémente la vérification de la signature du webhook (X-Hub-Signature-256) et route les messages selon l'identité de l'expéditeur : les requêtes des étudiants vont vers le pipeline RAG, tandis que les requêtes des administrateurs sont routées pour le traitement de commandes (bien que l'exécution des commandes soit actuellement limitée).
• Déploiement : La pile est conteneurisée via Docker Compose, avec des configurations spécifiques pour gérer les problèmes de résolution DNS dans les environnements conteneurisés (fixation des résolveurs externes).

Contributions Clés
L'article distingue explicitement le prototype fonctionnel de l'architecture initialement prévue, mettant en évidence les contributions suivantes qui ont été implémentées :

1. Pipeline TNEA conteneurisé : Un système RAG fonctionnel déployé sur WhatsApp qui repose sur l'ingestion de PDF officiels plutôt que sur la mémoire du modèle.
2. Prompt Système spécifique au domaine : Un prompt conçu pour gérer la logique spécifique au TNEA, incluant la formule de calcul de la coupure (Math/2 + Physique/4 + Chimie/4) et la nécessité de réponses par communauté.
3. Mémoire de conversation résiliente : Une conception de mémoire par session qui se dégrade gracieusement vers des réponses sans état si l'accès à l'historique de la base de données échoue, plutôt que de provoquer un plantage.
4. Déploiement reproductible : Une configuration Docker Compose documentée pour PostgreSQL avec pgvector et FastAPI, incluant des correctifs pour la résolution DNS des conteneurs.
5. Rapport transparent : Un compte explicite et vérifié par le code des composants architecturaux (ex. : mise en cache Redis, travailleurs Celery, routage LLM multi-fournisseurs, exécution de commandes administrateur) qui ne sont pas encore implémentés, évitant ainsi de présenter le prototype comme un système de production complet.

Résultats et Vérification
Les auteurs ont vérifié le système en reconstruisant la pile à partir d'un état propre et en exécutant le code d'ingestion contre un PDF de 9 pages et 5 048 mots provenant du Sri Krishna College of Engineering and Technology (SKCET).

• Ingestion : Le pipeline a traité avec succès le PDF en 11 segments chevauchants, le premier segment faisant 512 mots et le dernier 428 mots, confirmant que la logique de segmentation fonctionne comme prévu.
• Déploiement : La pile Docker Compose a démarré avec succès, les contrôles de santé (/health et /health/detailed) renvoyant un HTTP 200 et confirmant la connectivité à la base de données.
• Limites de la vérification : En raison de l'absence d'une clé GEMINI_API_KEY configurée dans l'environnement de vérification, la latence en direct, la précision de la récupération et les métriques d'ancrage des réponses n'ont pas été mesurées numériquement. La phase « récupération et génération » a été validée via une revue de code plutôt que par une exécution en direct.
• Routage Administrateur : Bien que le système détecte et journalise correctement les commandes administratives (ex. : /ingest, /stats), l'exécution réelle de ces commandes n'est pas encore implémentée.

Signification et Revendications
L'article positionne Coligo non pas comme un produit commercial achevé, mais comme un prototype vérifié qui comble le fossé entre les chatbots LLM génériques et les systèmes rigides basés sur des mots-clés. Sa principale importance réside dans :

1. Honnêteté de l'ingénierie : Les auteurs documentent explicitement l'écart entre l'architecture conçue (qui incluait Redis, Celery et le routage multi-LLM) et l'implémentation actuelle. Ils soutiennent que distinguer le prototype fonctionnel de l'architecture cible est en soi une contribution, garantissant que les parties prenantes ne confondent pas l'état actuel avec le design final.
2. Accessibilité Pratique : En utilisant WhatsApp, le système élimine la barrière de l'installation d'applications pour les étudiants et les parents, les rejoignant sur une plateforme familière.
3. Fiabilité Ancrée : Le système privilégie l'exactitude factuelle sur la fluidité, étant explicitement programmé pour refuser de répondre si le document source ne contient pas les données spécifiques à la communauté, réduisant ainsi le risque d'hallucinations sur les seuils de coupure d'admission.

L'article conclut que bien que le cœur du pipeline d'ingestion et de récupération soit fonctionnel et vérifié, des travaux futurs sont nécessaires pour implémenter l'exécution des commandes administratives, le score de confiance, l'escalade avec intervention humaine et le routage multi-LLM afin de réaliser toute l'étendue de l'architecture proposée.