Chatbot CAN 2025

Construire un assistant conversationnel capable de répondre en langage naturel sur la CAN 2025 — aussi bien des faits historiques statiques (résultats, buteurs, classements) que des données de match en direct — sans subir la latence ni le coût d'un appel LLM à outils complets sur chaque question.

Objectifs techniques :

• Réponses en moins d'une seconde pour les 90%+ de questions purement factuelles
• Gestion correcte des questions de suivi (« donne-moi les détails du deuxième match ») sans réexpliquer le contexte à chaque tour
• Données live (scores, événements) disponibles à la demande via l'API ESPN, sans payer cette latence sur les questions qui n'en ont pas besoin

RAG hybride : un routeur sémantique classe chaque requête et l'envoie sur l'un des deux chemins plutôt que de systématiquement payer le plus coûteux.

• RAG traditionnel (< 1s, ~0,001$/requête) — les questions historiques/statistiques interrogent un vector store FAISS (376 documents indexés, embeddings sentence-transformers) puis vont directement au LLM avec le contexte récupéré.
• RAG agentique (3-5s, ~0,005$/requête) — les questions live ou multi-sources passent par un agent LangChain avec accès outils (API ESPN) plutôt qu'une simple passe de récupération.
• Cache Redis + fichier devant les deux chemins (TTL 1h pour les données dynamiques, sans expiration pour les réponses historiques statiques), les questions sur la CAN se répétant beaucoup d'un utilisateur à l'autre.

FastAPI a été choisi pour la couche API pour son support async natif — les accès cache, les appels LLM et l'appel à l'API ESPN se chevauchent tous sur des attentes I/O plutôt que de bloquer un thread worker chacun.

Pipeline de données — un script ETL dédié récupère les données de match depuis l'API ESPN vers des fichiers CSV, qu'un loader transforme en embeddings et indexe dans le store FAISS (376 documents / 316 chunks après découpage).

Routage & mémoire — l'orchestrateur du chatbot exécute d'abord une détection intelligente des questions de suivi (motifs comme « le deuxième match », « cette équipe », « donne-m'en plus ») pour qu'un suivi réutilise le contexte déjà récupéré au tour précédent plutôt qu'une nouvelle recherche, puis le routeur sémantique (classification par embeddings) tranche entre RAG traditionnel et RAG agentique.

Mise à disposition — un serveur FastAPI expose /chat (avec session_id pour l'état de conversation), ainsi que /cache/stats et /cache/clear pour piloter le cache en production.

Défi — répondre aux questions de suivi sans tout réancrer à chaque tour. Un RAG naïf traite chaque message indépendamment : « donne-moi les détails du deuxième match » n'a alors aucun antécédent à résoudre. Solution : un détecteur de suivi dédié s'exécute avant la récupération et, s'il reconnaît un motif de référence, réutilise les entités résolues et le contexte récupéré au tour précédent plutôt qu'une nouvelle recherche vectorielle — le routeur ne déclenche une nouvelle récupération que si la question introduit réellement un nouveau sujet.

Défi — le coût/latence du RAG agentique (3-5s, ~5x le RAG traditionnel) si utilisé pour tout. Solution : le routeur sémantique réserve le RAG agentique aux requêtes qui ont réellement besoin de données live ou d'agrégation multi-sources, si bien que le gros du trafic (questions historiques/statistiques) reste sur le chemin rapide et moins coûteux.

• Temps de réponse : < 500ms sur les requêtes en cache, 1-3s sans cache (contre 3-5s si chaque requête passait par le chemin agentique)
• Couverture complète des données : 38 matchs joués, 93 buts, 24 équipes — 376 documents dans le vector store
• Conçu pour supporter 100+ utilisateurs simultanés ; ~500 Mo de mémoire avec le vector store complet chargé
• Livré sous forme de service FastAPI fonctionnel avec documentation auto-générée (/docs), un frontend chat HTML/JS léger, et une note d'architecture en français (ARCHITECTURE_TECHNIQUE.md) fournie avec le code