Ne laissez pas les LLM prendre des décisions ni exécuter de la logique métier

Argument central : il faut sortir des LLM le plus vite possible et ne pas y rester longtemps

• Il ne faut pas confier à un LLM la prise de décision ou la logique métier → précision et stabilité insuffisantes
• Dans la plupart des cas, un LLM ne devrait servir que d’interface entre l’utilisateur et l’API de l’application
• La logique centrale doit être exécutée dans un système ou un moteur dédié, et le LLM ne doit faire que convertir la requête utilisateur en appel d’API, puis reconvertir le résultat en langage naturel

Pourquoi ?

• Exemple d’un bot d’échecs : l’utilisateur envoie sur WhatsApp « prends le cavalier avec mon fou » → le LLM pourrait aussi maintenir l’état de l’échiquier et jouer, mais cela pose de nombreux problèmes de fiabilité, de performance et de maintenance

• Performance : les capacités d’un LLM aux échecs sont impressionnantes, mais il reste plus lent et moins précis qu’un moteur spécialisé (par ex. Stockfish)

• Impossible à déboguer et à ajuster : il est difficile de savoir pourquoi il a pris telle décision, donc difficile de le corriger pour qu’il fonctionne comme prévu

• Autres problèmes :

  • Les sorties des LLM sont difficiles à tester
  • Ils sont peu performants en calcul mathématique ou en génération de nombres aléatoires
  • Le versioning et l’audit sont compliqués
  • Le maintien de l’état en langage naturel est fragile
  • Des problèmes de tarification API et de limitation de débit peuvent survenir
  • Les frontières de sécurité deviennent floues

Une bonne séparation des rôles à travers divers exemples

• Dans un jeu, « je veux attaquer le joueur X avec l’épée vorpale » → le LLM ne doit faire que convertir cela en attack(player=X, weapon="vorpal_sword") et le transmettre à la logique du jeu
• Agent de négociation → le LLM ne prend pas les décisions de négociation ; il emballe l’entrée utilisateur, la transmet au moteur de négociation, puis relaie le résultat
• Génération de réponses aléatoires → le choix ne doit pas être fait par le LLM, mais par une fonction aléatoire externe

Ce que les LLM font bien

• Les LLM sont spécialisés dans la transformation, l’interprétation et la communication
• Exemples :
  • « frapper l’orque avec une épée » → conversion en attack(target="orc", weapon="sword")
  • { "error": "insufficient_funds" } → explication naturelle du type « Vous n’avez pas assez d’or »
  • Ils peuvent classer si l’entrée utilisateur est une commande de combat, une consultation d’inventaire ou une demande d’aide
  • Ils comprennent bien les concepts humains (par ex. blade = sword, smash = attack)
• L’essentiel n’est ni le jugement complexe ni la gestion d’état → ils servent simplement de pont entre l’intention de l’utilisateur et le système

Perspectives futures et principe durable

• La technologie évolue rapidement, donc ce qui est impossible aujourd’hui pourrait bientôt le devenir
• Cependant, les problèmes structurels qu’un LLM ne peut pas résoudre ont de fortes chances de subsister :
  • Une logique qui n’utilise pas de LLM est plus facile à comprendre, à maintenir et à versionner
  • Son coût d’exécution est aussi plus faible
• À l’avenir aussi, les LLM devront se concentrer sur leur rôle d’interface, tandis que la logique centrale devra être confiée à des systèmes dédiés

[GN⁺]

Avis Hacker News

• Il existe deux types de logique

  • 1. la logique qui doit être intrinsèquement exacte et rigoureuse
  • 2. la logique qui est devenue ainsi en raison des caractéristiques des ordinateurs

• Le type 1 concerne des domaines comme la sécurité, la finance ou les mathématiques

• Le type 2 a de fortes chances d’être remplacé par l’IA

• Différentes parties d’une même application peuvent convenir au type 1 ou au type 2

• Lors d’un récent hackathon, un jeu éducatif a été créé

  • Le jeu a été généré et exécuté avec un LLM, mais le déroulement du jeu n’était pas satisfaisant
  • Au final, beaucoup de code Python et plusieurs prompts ont été utilisés pour gérer l’état du jeu
  • Il est préférable d’utiliser un LLM comme un petit composant d’un système plus vaste

• Un LLM ne devrait pas implémenter la logique

  • La logique, l’optimisation et la programmation par contraintes sont des techniques distinctes
  • Le fondateur de la logique moderne est George Boole, qui était le grand-père de Geoffrey Everest Hinton

• Il est difficile de comprendre les capacités des LLM

  • Les lecteurs veulent des réponses simples
  • Les LLM peuvent avoir du mal à écrire une simple machine à états
  • Les articles de recherche gagnent en popularité, et d’ici 2025 personne ne comprendra probablement totalement les LLM

• Si les réponses d’un LLM doivent être rapides et peu coûteuses, il faut utiliser des prompts courts et de petits modèles

  • Beaucoup d’informations partent du principe qu’on utilise de grands modèles
  • Une interface utilisateur traditionnelle peut être un meilleur choix

• Il est difficile de tester avec les seuls LLM

  • Le style personnel influence l’interaction
  • Les coûts de maintenance peuvent être élevés
  • Il est plus raisonnable de convertir cela en appels API

• Utiliser des LLM dans la logique métier est risqué

  • Ils sont adaptés au traitement du langage

• Les images générées par l’IA peuvent être utilisées pour résumer des articles