AI4Fire : l'outil SQL fait passer la précision des LLM sur les bases de données d'incendies de 16% à 88%

Six modèles de langage de base, cinq tâches de gestion des feux de forêt, deux modes d'exécution : voilà la structure d'AI4Fire, un nouveau benchmark publié sur arXiv, dont une exécution étendue ajoute 29 modèles. Résultat principal : connecter un outil SQL en lecture seule a fait passer la précision du travail sur base de données de chacun des six modèles de base d'au plus 16% à au moins 88%. Pour la prévision des besoins en personnel, le tableau s'inverse : aucun modèle n'a battu la simple répétition du chiffre du jour.

Comment la comparaison est construite

Les auteurs partent du principe que les évaluations surestimées coûtent cher dans ce domaine : il y va de biens matériels et de vies humaines. Chaque tâche est donc exécutée en deux variantes. En mode « nu » (bare), le modèle ne reçoit que les données d'entrée de la tâche. En mode « ancré » (grounded), on y ajoute un élément propre à la tâche. Pour la détection de fumée, il s'agit d'une image sans fumée prise par la même caméra. Pour le travail sur base de données, c'est un outil SQL. Toutes les exécutions sont en zero-shot, sans fine-tuning ni exemples.

La comparaison par paires donne une mesure propre de l'apport de chaque ajout. D'après les auteurs, ils ont recensé dans la littérature 138 travaux sur des tâches liées aux incendies, et aucun ne combine un tel panel de modèles, une telle couverture de tâches et des exécutions appariées. Les prompts, les réponses, les évaluations, le code et la trace de la revue de littérature sont publiés.

• Modèles de base : 6, plus 29 dans l'exécution étendue
• Tâches liées aux feux de forêt : 5
• Mode : zero-shot, bare et grounded
• Travaux dans la revue de littérature : 138
• Tâche SQL : de ≤16% à ≥88% pour chaque modèle de base

Où l'ajout fonctionne, et où il échoue

Premier constat des auteurs : l'ancrage aide le plus là où l'élément ajouté contient lui-même la réponse. Un modèle qui accède à la base uniquement en lecture, par des requêtes SQL, va chercher l'information dans les tables au lieu de la reconstituer de mémoire ou de la deviner. L'écart entre 16% et 88% indique que, sans l'outil, la tâche est en pratique impossible à résoudre.

Le second constat est plus sobre. Pour la prévision des effectifs, les règles simples se sont révélées difficiles à battre : aucun modèle de base n'a fait mieux que la répétition de la valeur du jour. Deux modèles open-weight ont surtout recopié la médiane de jours passés comparables avec des incendies. C'est une prévision plus faible que celle de la règle naïve. Le modèle donne l'impression de raisonner, mais il reproduit en réalité un schéma moyen, moins bon que le chiffre de la veille.

Les pièges des données publiques

Le troisième constat concerne les jeux de données eux-mêmes. Dans l'une des publications publiques, la colonne d'indice de danger d'incendie sépare parfaitement l'échantillon de test. C'est une fuite de données : un score élevé d'un modèle sur un tel jeu ne dit presque rien de ses capacités. Dans un autre jeu, pour 67 images aériennes d'incendies, les étiquettes « combustion lente » ou « sans feu » sont déduites d'une température maximale tronquée (clipped). Si le capteur a atteint le plafond de son échelle, l'étiquette reflète la limite de l'instrument, et non la réalité.

Chacune de ces erreurs gonfle le résultat, et ce sont précisément ces évaluations que les auteurs jugent dangereuses pour le secteur.

Que faire pour les équipes qui déploient des LLM dans les services d'incendie

Avant tout pilote, posez une règle de référence simple, par exemple la répétition de l'effectif actuel, et exigez que le modèle la batte. S'il n'y parvient pas, il est trop tôt pour le brancher sur la planification. Là où la réponse se trouve dans les données, donnez au modèle un outil d'accès plutôt que de vous fier à sa mémoire : le SQL en lecture seule apporte un gain important pour un risque minimal de corruption des données.

Avant d'utiliser des jeux de données publics, vérifiez-les : fuites de variables et origine des étiquettes. Il suffit de se demander si une seule colonne peut prédire la variable cible, et si l'étiquette n'a pas été obtenue à partir d'un signal saturé.

La prudence reste de mise. Toutes les exécutions sont en zero-shot, et les conclusions valent pour cet ensemble précis de cinq tâches. Les résultats de systèmes fine-tunés ou spécialisés peuvent différer. En revanche, les réponses et le code ouverts permettent de revérifier les chiffres et d'ajouter ses propres modèles.