Agent d'analyse multilingue TAE

Développé pour l'équipe finance et analytique de Tractafric Equipment, qui répondait auparavant à ces questions manuellement dans Excel. Le vrai défi n'était pas de connecter un LLM à une base de données : c'étaient trois pièges précis dans les données qui font échouer les approches naïves de texte vers SQL.

Le schéma comporte 50 colonnes ambiguës, dont trois champs "major class" différents, quatre champs GPM, et des pourcentages stockés sous forme de fractions. Des vues SQL sémantiques écrites à la main et des fiches de schéma permettent au modèle de ne jamais toucher directement la table brute.

Deux programmes Caterpillar définissent le support comme une courbe de GPM% plutôt qu'un seuil fixe. Une jointure naïve multiplie ou sélectionne mal les lignes, faussant environ 26 % du support total (environ 570K$). Une jointure par sous-requête corrélée par tranche corrige ce problème, et c'est précisément ce que couvre la catégorie "join" du benchmark.

Le français métier ne correspond pas au vocabulaire du schéma : "pompes hydrauliques" doit être résolu vers des codes PPC comme HGP, HPM et HRP à travers 4 653 descriptions de pièces en français. Un index vectoriel NumPy en force brute (pas besoin de base vectorielle pour environ 5 500 vecteurs) combiné à un graphe de taxonomie déterministe dans NetworkX s'en charge.

Tout fonctionne entièrement hors ligne : SQLite en lecture seule, un modèle Ollama local (qwen3.5:9b), aucun appel au cloud, aucune donnée ne quitte la machine. Un benchmark de 100 questions, avec des ablations retirant les vues, la résolution et le graphe un par un, montre que la couche de vues sémantiques vaut à elle seule environ 47 points de précision, et que le plus petit modèle du test est aussi le plus précis : le mode raisonnement et un modèle 30B obtiennent tous deux un moins bon score que le 9B par défaut sans raisonnement.