Les modèles de langage face aux défis de la prévision météorologique

Les modèles de langage et leurs limites en météorologie

Les modèles de langage, souvent désignés par l'acronyme LLM, sont devenus des outils courants pour fournir des prévisions météorologiques. Cependant, ils ne sont pas conçus pour indiquer précisément quand un changement météorologique significatif se produit. Cette lacune, bien que pouvant sembler anodine, a des implications importantes dans la pratique.

Les systèmes modernes de prévision numérique du temps, tels que l'ECMWF IFS, fournissent des prévisions d'une précision remarquable. Avec une résolution d'environ 9 km et des mises à jour fréquentes, ces données sont d'une qualité exceptionnelle. Toutefois, le véritable défi réside dans l'interprétation de ces changements pour déterminer leur importance réelle. Le problème ne réside pas dans la prévision elle-même, mais dans l'attention portée à savoir quand un changement dans ces données est réellement significatif.

L'impact de la théorie du chaos

Mon intérêt pour ce problème ne vient pas de mon expérience en ingénierie logicielle, mais d'une étude antérieure de la théorie du chaos à l'Instituto Balseiro. J'y ai découvert une idée fascinante : un système peut être entièrement déterministe tout en restant pratiquement imprévisible. Cette notion a profondément influencé ma compréhension des systèmes d'IA.

En développant des systèmes d'intelligence artificielle, j'ai constaté que beaucoup d'entre eux ne tenaient pas compte de cette complexité inhérente aux systèmes chaotiques. La théorie du chaos m'a appris qu'un système apparemment ordonné peut devenir imprévisible, ce qui est une leçon essentielle pour quiconque travaille avec des modèles de prévision.

Les erreurs des approches intuitives

En observant la manière dont les développeurs créent des agents météo, j'ai remarqué une tendance à simplifier le processus : récupérer les données de prévision, les intégrer dans un LLM, puis demander si le temps a changé de manière significative. Bien que cela semble logique, c'est problématique pour les systèmes où les seuils de décision sont bien définis.

Dans un système chaotique, la signification d'un changement n'est pas une question de langage, mais de seuils précis sur des variables telles que la température ou les précipitations. Les LLM, conçus pour générer du langage, ne sont pas adaptés à imposer des limites déterministes sur ces systèmes. Un LLM est un processus stochastique, excellent pour générer du langage, mais pas pour imposer des frontières déterministes sur des systèmes physiques.

Les défaillances des LLM

Les LLM présentent plusieurs modes de défaillance subtils :

• Ils peuvent inférer des tendances à partir de la formulation plutôt que des données réelles.
• Ils prennent parfois des décisions incohérentes pour des entrées similaires.
• Leurs résultats sont souvent difficiles à tester ou à reproduire.

Dans des secteurs comme l'agriculture ou l'énergie, où une variation de température de 3°C peut avoir des conséquences majeures, ces défaillances ne sont pas acceptables. Les décisions doivent être stables et explicables. Par exemple, une baisse de température peut représenter une transition de phase pour une culture ou un pic de demande énergétique.

Une règle simple pour l'utilisation des LLM

J'ai établi une règle simple : si une assertion peut être formulée, il est préférable de ne pas utiliser un prompt LLM. Cette règle découle de l'expérience que j'ai acquise en travaillant avec des systèmes où la précision et la traçabilité des décisions sont cruciales.

Mon parcours professionnel

Mon parcours professionnel est varié, allant d'un doctorat Marie Curie en dynamique climatique à la direction de la R&D à l'institut national de météorologie de l'Uruguay. J'ai travaillé sur la prévention des incendies de forêt, les prévisions saisonnières et l'adaptation au climat, avant de me tourner vers l'apprentissage automatique chez Microsoft et Mercado Libre.

Cette expérience m'a permis de comprendre la physique des données et ce que signifie réellement un changement significatif dans un système physique, au-delà des abstractions logicielles. J'ai appris à voir les données non pas comme des abstractions, mais comme des deltas mesurables sur des variables avec des limites d'incertitude connues.

L'architecture de Skygent

Skygent est structuré en cinq couches distinctes, avec une seule couche dédiée à l'appel du LLM.

Le Gardien Déterministe

Au cœur de Skygent se trouve un évaluateur Python qui ne fait pas d'interprétation mais effectue des calculs précis. Il compare des prévisions validées, évalue les deltas par rapport à des seuils configurables, et intègre le contexte et l'horizon de prévision.

Les décisions sont prises sur cette base, et chaque alerte est traçable, indiquant quelle variable a changé et quel seuil a été franchi. Dans un cadre professionnel, cette traçabilité est essentielle. Une alerte n'est déclenchée que si un seuil est franchi, ce qui permet de maintenir une condition binaire, testable, et non un jugement subjectif.

Le rôle limité du LLM

Le LLM intervient uniquement après la prise de décision, pour traduire des données structurées en langage naturel. Par exemple, une augmentation de la probabilité de pluie de 10 % à 50 % est expliquée en termes clairs, mais le LLM ne prend aucune décision. Il se contente de transformer des données JSON structurées en une narration compréhensible.

Pourquoi cette architecture est testable

Il est difficile de tester à 100 % un agent LLM pur, car les sorties sont probabilistes. L'approche hybride de Skygent, avec une logique de décision en Python, permet d'effectuer des tests unitaires exhaustifs sans dépendance au LLM. La logique de décision est purement en Python, avec 204 tests unitaires et aucune dépendance LLM dans la suite de tests.

Invocation LLM basée sur des événements

Contrairement à un agent naïf qui sollicite le LLM à chaque cycle, Skygent évalue les données toutes les six heures et n'appelle le modèle que si un seuil est franchi. Cela réduit considérablement le nombre d'appels, rendant le système plus efficace et économique. À un tarif de GPT-4o-mini, le coût est négligeable et proportionnel à l'information réelle.

Un exemple concret

Prenons un exemple : si la probabilité de pluie passe de 10 % à 50 %, une alerte est déclenchée et le LLM génère une explication narrative. Ce processus est répété toutes les six heures. Par exemple, une alerte pourrait être déclenchée si le delta de probabilité de pluie dépasse 20 points de pourcentage.

Limites de cette approche

Cette méthode n'est pas universelle. Elle échoue lorsque les entrées sont ambiguës ou lorsque les frontières de décision ne peuvent pas être définies par des seuils clairs. Dans ces cas, des architectures basées sur les LLM, comme ReAct, sont plus appropriées.

Conclusion

La décision la plus cruciale lors de la construction de ce système a été de déterminer où ne pas utiliser un LLM. Bien que les LLM soient de plus en plus utilisés pour résoudre divers problèmes, certaines décisions nécessitent une structure claire et définie. Dans ces cas, il est préférable d'encoder explicitement les décisions plutôt que de les approcher par le langage.

L'implémentation complète de ce système est disponible sur : github.com/ferariz/skygent