LLMON, un langage de balisage conçu pour les LLM, disponible dans Granite 4.1 3B et 8B
IBM vient de publier deux modèles expérimentaux, granite-4.1-3b-LLMON-preview et granite-4.1-8b-LLMON-preview, dérivés de ses modèles de base Granite 4.1 et entraînés à lire et à produire du texte balisé en LLMON (LLM Object Notation, prononcé « lemon »). Ce langage de balisage de type XML délimite les composants du contexte par des balises porteuses de sens, encadrées par des jetons spéciaux réservés : prompt système, tours de conversation passés, instructions, documents récupérés, réponses d'outils, contraintes de sortie ou chaînes de raisonnement. Chaque instruction reçoit un identifiant unique qui la lie aux données sur lesquelles elle doit agir, à la manière d'une fonction appelée avec ses arguments. Un dépôt GitHub accompagne la publication, avec une boîte à outils, des exemples de flux de travail et des modèles. Le langage est aussi pris en charge nativement dans Mellea, qui convertit automatiquement ses appels en LLMON.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de HuggingFace Blog. Lire l'article original →
L'enjeu est d'abord celui de la robustesse et de la sécurité. Grâce à la séparation explicite entre instructions et données, les injections de prompt indirectes, cachées dans les données de l'utilisateur, sont le plus souvent ignorées : sur certains bancs d'essai, le taux de réussite des attaques tombe presque à zéro, alors que les modèles Instruct classiques sont détournés avec une forte probabilité. Les capacités générales restent comparables à celles des modèles Granite 4.1 Instruct. Chaque instruction étant liée aux données exactes qu'elle concerne, les passages sans rapport, les anciens tours de conversation et les sorties d'outils ne contaminent plus la réponse. Pour les équipes, cela signifie aussi moins de fragilité sur les petits modèles, souvent plus sensibles aux défauts de structure du contexte, et la possibilité de définir ses propres balises puis d'entraîner un LoRA par-dessus les modèles LLMON pour les comprendre.
Le contexte tient à une limite de JSON, conçu pour des analyseurs syntaxiques et non pour des modèles de langage causaux. Son tokeniseur ne respecte pas la grammaire, et les symboles de structure comme les accolades, guillemets ou deux-points peuvent aussi apparaître dans le texte ordinaire : pour un modèle, un guillemet dans un document et un guillemet qui ferme un champ sont le même jeton. Les règles d'échappement ne sont que des régularités statistiques, et l'imbrication, fondée sur le décompte des crochets, reste un point faible des transformeurs sur de longues séquences. LLMON utilise au contraire des jetons spéciaux distincts du contenu, annonce les balises en début de segment et énonce localement les structures imbriquées. Comme beaucoup d'équipes disposent déjà de chaînes de traitement en JSON, IBM fournit des convertisseurs sans perte dans les deux sens et des notebooks d'exemple. LLMON ne remplace pas les modèles de conversation : il les enrichit en précisant la signification de chaque composant et leurs relations, au sein d'un même rôle comme entre rôles. Les modèles livrent leur propre gabarit, utilisable via applychattemplate, où chaque partie d'un tour peut être marquée exec: True ou False. Une partie marquée True est liée au bloc d'exécution final, qui indique l'instruction à exécuter et ses données, tandis qu'une partie marquée False reste dans le contexte sans être référencée.