Qu’est-ce qu’un grand modèle de langage (LLM)?
Un LLM est un système logiciel entraîné sur d’immenses jeux de textes — livres, contenus web, code et articles scientifiques — afin de comprendre et de générer le langage humain. Basé sur une architecture de type transformeur, un LLM traite le langage en pondérant simultanément les relations entre mots et expressions sur l’ensemble de l’entrée, au lieu d’interpréter le texte de gauche à droite, séquentiellement. Cela permet de gérer à grande échelle des requêtes complexes et dépendantes du contexte.
Contrairement aux systèmes de traitement du langage naturel (NLP) basés sur des règles, qui font correspondre les entrées à des modèles prédéfinis et échouent lorsque le langage s’en éloigne, les LLM génèrent des réponses à partir de relations statistiques apprises lors de l’entraînement. Cette distinction est plus importante qu’il n’y paraît : les NLP à base de règles échouent de façon prévisible — on peut auditer l’échec, le retracer à une règle manquante et le corriger — tandis que les LLM échouent de façon probabiliste, c’est-à-dire qu’ils produisent des réponses fluides et plausibles, mais parfois factuellement inexactes.
L’architecture transformeur permet aux LLM de gérer des tâches qui nécessiteraient des systèmes distincts et codés à la main dans un NLP traditionnel : par exemple, résumer un contrat de 200 pages, répondre à des questions sur une base de connaissances ou générer du code à partir d’une description en langage clair. Une telle polyvalence est vraiment utile, mais elle amène des enjeux de gouvernance et des risques opérationnels.
Fonctionnement des LLM : tokens, entraînement et inférence
Tokenisation
Avant qu’un modèle ne lise le moindre texte, ce texte est découpé en tokens – unités qui peuvent correspondre à des mots entiers, des fragments de mots ou des signes de ponctuation, selon le vocabulaire du modèle (ex. : « renouvellement de contrat » pourrait donner trois tokens). Chaque LLM a un nombre maximal de tokens qu’il peut traiter par interaction.
Préentraînement
Un modèle traite d’énormes jeux de textes et apprend à prédire quel token suivra vraisemblablement une séquence donnée, en ajustant ses propres paramètres internes sur des milliards d’itérations, ce qui aboutit à un modèle qui a absorbé de vastes schémas de langage, de raisonnement et d’associations factuelles, sans y avoir été explicitement programmé.
Inférence
Il prédit le token suivant, puis le suivant, construisant la sortie séquentiellement à partir des probabilités apprises et du contexte fourni. La latence d’inférence — le délai entre la soumission d’une invite et la réception d’une réponse complète — est une contrainte de niveau approvisionnement pour les applications en temps réel (ex. : chatbot en direct destiné à la clientèle).
Types de LLM : modèles de fondation, modèles adaptés (fine-tuned) et petits modèles de langage (SLM)
Bien qu’il soit courant de considérer les modèles de fondation comme le choix privilégié — et les modèles adaptés ou SLM comme des options moins coûteuses — cela est inexact et mène au déploiement de systèmes coûteux, ingérables et sous-performants. Comparons :
| Dimension | Modèle de fondation | Modèle adapté | Petit modèle de langage (SLM) |
|---|---|---|---|
| Définition | LLM fondé sur un large corpus, sans adaptation à une tâche spécifique | Modèle de fondation adapté à des données propres à un domaine | LLM compact optimisé pour l’efficacité |
| Périmètre d’entraînement | Général — textes divers à grande échelle | Spécifique au domaine — superposé à une base préentraînée | Restreint — limité à une tâche ou à un domaine |
| Échelle des paramètres | Plus grand | Plus grand, avec des poids adaptés au domaine | Moins de paramètres |
| Adaptation à l’entreprise / Quand l’utiliser | Prototypage, tâches générales de NLP, assistants polyvalents | Secteurs réglementés, tâches critiques pour le domaine, flux de conformité sensible | Applications sensibles à la latence, déploiements à coût restreint, exigences sur site |
| Compromis | Coût élevé; lourdeur de gouvernance; précision de domaine moindre | Nécessite des données de domaine de qualité; investissement additionnel en entraînement | Capacités plus limitées; la portée des tâches doit être clairement définie avant déploiement |
Exemple (points de référence, non recommandations) | GPT-4 | BloombergGPT (modèle adapté, entraîné sur des données financières) | Mistral 7B |
Risques liés aux LLM
Trois risques insolubles définissent la gouvernance des LLM en entreprise; chacun exige une décision de conception, et non une simple mitigation.
Hallucinations Les LLM produisent des résultats à partir de probabilités apprises plutôt que de faits vérifiés, ce qui mène à des réponses confiantes, fluides, mais parfois factuellement incorrectes. La conséquence pour l’entreprise n’est pas seulement une inexactitude occasionnelle — c’est que les erreurs peuvent être indiscernables des bonnes réponses, sans vérification externe. Tous les modèles hallucinent; les questions de conception sont donc :
- Mon flux de travail peut-il détecter les hallucinations?
- Les conséquences d’une erreur non détectée sont-elles acceptables?
Confidentialité des données
Lorsque des données d’entreprise sont transmises à un LLM tiers via API, elles sont utilisées pour l’entraînement du modèle et exposées à d’autres utilisateurs. Même si une solide gouvernance exige un comportement système auditable et stable, les LLM sont mis à jour en continu pour éviter la dégradation et l’obsolescence du modèle. Il n’existe pas de formule pour équilibrer la rigueur de gouvernance et la pertinence du modèle; ce risque doit donc être géré plutôt qu’éliminé.
Biais
Les LLM absorbent et amplifient inévitablement les biais de distribution présents dans les textes d’échelle internet sur lesquels ils sont entraînés, y compris la sous-représentation de certaines langues, industries et groupes démographiques.
Cas d’utilisation des LLM en entreprise
- Résumé de documents en santé
Les fournisseurs peuvent générer des résumés structurés à partir de notes cliniques non structurées, réduisant ainsi le temps de documentation des cliniciens tout en préservant les détails contextuels qui échappent à l’extraction de mots-clés. - Génération de code manufacturier et gestion des connaissances
Les entreprises peuvent automatiser la génération de code d’intégration générique entre systèmes de technologie opérationnelle et logiciels d’entreprise, là où la logique est répétitive mais où la syntaxe varie selon la plateforme. Elles peuvent aussi extraire de la documentation technique pertinente et des procédures de maintenance à partir de dépôts où la terminologie varie d’une génération de produit à l’autre et d’une région à l’autre. - Automatisation du soutien à la clientèle et analyse de contrats en services financiers
Les systèmes de soutien alimentés par LLM peuvent traiter les variations des demandes de compte qui viendraient à bout de la logique des chatbot à base de règles, tout en acheminant les cas particuliers vers des agents humains en fonction de seuils de confiance. Lors de la vérification diligente, les équipes juridiques peuvent repérer des clauses d’indemnisation non standard dans de vastes portefeuilles contractuels.
Comment évaluer et choisir un LLM pour votre entreprise
- Mesures d’exactitude : Il n’existe pas de méthode normalisée pour créer des mesures de référence propres au domaine. Vous devez bâtir des jeux d’évaluation spécifiques à vos tâches à partir de vos propres données; ainsi, l’exactitude est en partie une découverte post-approvisionnement.
- Latence : Définissez votre seuil de latence avant les essais, pas après, et mesurez le délai de réponse sous des charges réalistes et concurrentes, pas seulement dans des tests isolés à requête unique.
- Coût par token : La tarification à l’unité de token augmente rapidement à l’échelle d’une entreprise. Modélisez les coûts en fonction du volume prévu de requêtes avant l’approvisionnement. Un coût inférieur par token sur un modèle moins performant peut convenir à des flux de travail bien définis.
- Conformité : Identifiez quelles règles de résidence de données, de journalisation et de mise à jour du modèle s’appliquent à votre environnement réglementaire avant d’évaluer un fournisseur. Un modèle qui n’y répond pas n’est tout simplement pas admissible.
- Compatibilité avec l’écosystème fournisseur : Évaluez l’intégration avec votre infrastructure existante, y compris les systèmes d’authentification, les pipelines de données et les outils de surveillance. Tout modèle exigeant une intégration personnalisée importante comporte un coût caché.
- Résumé de documents en santé
Au moment de l’évaluation, les DSI se concentrent sur le coût par token et la conformité, tandis que les architectes TI s’attardent à la latence sous charge et à l’intégration à l’écosystème.
