Un chatbot RAG à 0 € d'API : retour de production.

01Le problème : un catalogue que personne ne peut interroger

DriveOnly vend des pièces auto et moto : 265 000 références, des noms composés cryptiques, trois fournisseurs aux formats incompatibles. Les clients écrivent « plaquettes pour 208 » et le moteur de recherche natif rend n'importe quoi. Le support croule sous les mêmes questions.

Objectif : un assistant qui comprend le véhicule du client et répond sur catalogue réel — sans facture d'API, sans envoyer les données clients dehors.

02Pourquoi pas le fine-tuning

Premier réflexe : fine-tuner un modèle sur le catalogue. Je l'ai écarté avec une matrice à trois critères, pas à l'instinct :

• Coût : le RAG ne paie que le calcul local ; le fine-tuning paie l'entraînement + chaque inférence.
• Latence : un embedding + FAISS répond en millisecondes ; un gros modèle génératif, en secondes.
• Fraîcheur : le catalogue bouge chaque semaine — réindexer FAISS prend minutes, réentraîner prend jours.

Verdict : RAG d'abord, fine-tuning supervisé plus tard, sur les vrais logs — une fois qu'on saura quoi optimiser.

033 tiers : ne payer le LLM que quand il le faut

L'idée centrale : la plupart des questions sont simples, donc la plupart ne doivent jamais toucher le LLM. Un orchestrateur (le « Decider ») route chaque requête :

• Tier 1 (~60 %) : FAQ sémantique, Sentence-BERT multilingue, seuil cosinus 0,70, moins de 100 ms.
• Tier 2 (~30 %) : classification d'intention + extraction d'entités (marque, modèle, motorisation, pièce), moins de 500 ms.
• Tier 3 (~10 %) : RAG sur index FAISS de 265 000 produits + Qwen-3.5:9B en local, streaming temps réel.

Le contexte véhicule persiste en Redis (TTL 1 h) : le client ne répète jamais deux fois sa motorisation.

04La donnée d'abord : 80 % du travail

Avant l'IA, le ménage : scraping de 3 fournisseurs (proxies rotatifs, robots.txt respecté), puis normalisation — dédoublonnage, extraction regex + SQL, tags LLM pour les noms composés.

• 265 000+ entrées nettoyées et réimportées (pipeline CSV réparé au passage).
• 200+ produits fantômes purgés ; index de recherche de 1,35 Go reconstruit.
• Mi-projet, un fournisseur a remplacé toutes ses références : ETL repris sans casser la prod.

05Évaluer honnêtement : ce que « 90 % » veut dire

90 %+, c'est la part des requêtes de test ayant reçu une réponse jugée correcte en tests d'intégration, sur des requêtes clients réelles en français. Ni plus, ni moins — et voici les limites :

• Les faux positifs regex (suivi vs livraison) ne sont sortis qu'en testant sur données réelles — jamais sur exemples construits.
• Pas encore de précision/rappel par handler publiés : 3 notebooks documentent la méthode, les chiffres suivront.
• Français uniquement ; qualité liée à celle du catalogue.

06Le vrai coût : « 0 € » veut dire « 0 € d'API »

Soyons précis : un LLM local n'est pas gratuit — il tourne sur un serveur (Ollama, Qwen-3.5:9B). Ce qui est à zéro, c'est la facture d'API par requête : pas de tokens facturés, pas de données qui partent, pas de surprise en fin de mois. Pour un e-commerce indépendant, c'est la différence entre « on peut le laisser tourner » et « on coupe à la fin du pilote ».

07Et après : fine-tuning et pilotage

La suite logique : fine-tuning supervisé de l'intention sur les logs réels, et dashboard Power BI des KPI (résolution, latence, répartition par handler) branché sur Redis/MySQL — le PRJ-014, actuellement sur l'établi.