LLM

Le principe de prédiction

Un LLM est un réseau de neurones de grande taille, entraîné sur d'énormes quantités de textes à une tâche unique : deviner ce qui suit. À chaque étape, il calcule une probabilité sur les unités de texte possibles, les tokens, puis en choisit une. Répété, ce mécanisme produit des phrases, des paragraphes, du code. L'impression de compréhension vient de la qualité des enchaînements appris, pas d'une intention de l'auteur, ni d'une représentation du monde vérifiée.

L'entraînement se déroule en plusieurs temps. Un passage massif sur des textes variés donne au modèle une connaissance statistique du langage et des sujets. Un ajustement sur des exemples de dialogues l'oriente vers la forme attendue d'un assistant. Un retour humain sur des réponses préférées affine le comportement. Ces étapes expliquent pourquoi deux modèles de taille comparable peuvent se comporter très différemment : les données et les consignes d'ajustement comptent autant que l'architecture.

Ce que cela produit

La prédiction explique les forces et les faiblesses. Le modèle excelle sur les tâches dont la forme est fréquente dans ses données : reformuler, résumer, traduire, écrire un courriel type, expliquer un concept courant. Il produit volontiers une réponse plausible là où l'information manque, sans signaler son incertitude. C'est le mécanisme de l'hallucination : la phrase la plus probable n'est pas la phrase vraie, et rien dans le calcul ne distingue l'une de l'autre.

Il n'a pas accès, par lui-même, à des données récentes ou internes. Tout ce qu'il sait de l'entreprise doit lui être fourni dans la consigne ou par une recherche documentaire. Il ne calcule pas de façon fiable, ne vérifie pas une source et ne conserve pas la mémoire d'un échange au-delà de ce qu'on lui transmet. Ces limites se traitent par l'architecture de l'application et par des contrôles, pas par une consigne plus ferme.

Contexte, latence, coût

Le modèle ne voit qu'une fenêtre de texte limitée, appelée contexte. Tout ce qui doit être pris en compte, consigne, historique, extraits de documents, doit tenir dans cette fenêtre. Au-delà, l'information est tronquée ou ignorée. Une fenêtre large permet de traiter des dossiers entiers, mais augmente le coût et le temps de réponse, car le calcul porte sur l'ensemble du texte fourni à chaque appel, même si la réponse est courte.

La facturation suit généralement les tokens consommés, en entrée et en sortie. Un usage intensif avec de longs documents coûte donc plus cher qu'un échange bref. La latence dépend de la taille du modèle, de la longueur de la réponse et de la charge du service. Ces paramètres se mesurent sur des cas réels avant de dimensionner un déploiement, et ils évoluent avec les versions successives des modèles comme avec les conditions commerciales du fournisseur.

Ce qu'un dirigeant doit vérifier

Quatre questions suffisent souvent à qualifier un projet. Quelle tâche précise, avec quel volume et quelle tolérance à l'erreur. Quelles données sont envoyées, et où elles sont traitées. Qui relit la sortie avant qu'elle ne parte vers un client. Comment l'on saura, dans quelques mois, que l'outil apporte quelque chose. Les réponses écrites à ces questions évitent les projets qui avancent sans critère d'arrêt et sans mesure de leur intérêt réel.

Le choix du modèle vient après. Un petit modèle suffit pour classer des courriels ou reformuler des fiches ; une rédaction longue ou un raisonnement sur des documents demande davantage. Comparer deux modèles sur une centaine de cas réels, avec une grille de notation simple, vaut mieux que de lire des classements généraux. Cette démarche coûte peu et donne une base de décision défendable devant une direction ou un client.