Tokens, embeddings et formulation des prompts

Trois notions, trois rôles

Les tokens sont les unités que le modèle reçoit et produit. Les embeddings sont des représentations numériques utilisées pour manipuler ou comparer du contenu. Le prompt est l’ensemble des informations données au modèle pour orienter sa réponse.

Ces notions sont liées, mais elles ne désignent pas la même étape.

Les tokens : le découpage interne du texte

Un grand modèle de langage (LLM) ne lit pas directement des mots. Un tokeniseur découpe le texte en unités qui peuvent être un mot courant, une partie de mot, un signe de ponctuation ou une suite de caractères.

Le découpage dépend du modèle. « Informatique » peut former un seul token dans un vocabulaire et plusieurs dans un autre. Les identifiants, les adresses, le code et les langues moins bien représentées dans les données d’apprentissage peuvent également être découpés de manière moins intuitive.

Ce fonctionnement a trois conséquences concrètes :

• la fenêtre de contexte est mesurée en tokens, pas en pages ;
• le coût d’une API est souvent lié au nombre de tokens reçus et générés ;
• deux textes de même longueur apparente peuvent consommer un nombre différent de tokens.

Le tokeniseur ne fixe pas à lui seul le sens d’un texte. Un découpage très fragmenté allonge cependant la séquence et peut compliquer le traitement de certains motifs.

Les embeddings : représenter des proximités

Le mot embedding, ou plongement vectoriel, recouvre plusieurs usages.

À l’entrée d’un grand modèle de langage, chaque token est d’abord associé à un vecteur numérique. Après le passage dans les couches du Transformer, sa représentation devient contextualisée : elle dépend des autres tokens présents dans la séquence. « Python » n’active donc pas les mêmes relations dans un article sur la programmation et dans un article sur les reptiles.

Il existe aussi des modèles d’embeddings conçus pour représenter une phrase, un paragraphe, une image ou un document par un vecteur. On peut alors comparer deux vecteurs pour estimer une proximité sémantique. C’est utile pour :

• rechercher des documents proches d’une question ;
• regrouper des tickets similaires ;
• détecter des doublons ;
• fournir à un LLM les passages les plus pertinents d’une documentation.

L’exemple célèbre roi − homme + femme ≈ reine illustre certaines propriétés d’anciens embeddings statiques. Il ne faut pas en déduire que tous les embeddings modernes obéissent à une arithmétique sémantique exacte. Une proximité vectorielle reste un signal statistique, pas une preuve de synonymie ou de vérité.

Le RAG : retrouver avant de générer

La génération augmentée par recherche, ou RAG (Retrieval-Augmented Generation), associe généralement un moteur de recherche à un modèle génératif. Le système cherche d’abord des passages pertinents dans une base documentaire, puis les insère dans le contexte du LLM afin qu’il prépare sa réponse.

Les embeddings peuvent participer à cette recherche, mais ils ne constituent pas le RAG à eux seuls. Il faut aussi choisir les documents, les découper, filtrer les résultats et demander au modèle de citer ses sources. Le RAG réduit certains manques d’information ; il ne garantit ni que le bon passage sera retrouvé, ni que la réponse l’interprétera correctement.

Un bon prompt est un contrat de travail

La formulation des prompts, parfois appelée prompt engineering, consiste surtout à réduire les interprétations possibles de la demande.

Un prompt robuste précise :

• la tâche : analyser, résumer, comparer ou transformer ;
• le contexte : système concerné, public ou objectif ;
• les données de référence : texte, code, logs ou documentation ;
• les contraintes : éléments à ignorer, limites et critères ;
• le format attendu : tableau, JSON, liste ou procédure ;
• la conduite à tenir en cas d’incertitude.

Par exemple :

À partir du log délimité ci-dessous, regroupe uniquement les lignes de niveau ERROR par message normalisé. Retourne un tableau avec le nombre d’occurrences et une ligne source pour chaque groupe. Si une information manque, indique « non déterminé ». N’utilise aucune connaissance extérieure au log.

Les délimiteurs et le format demandé facilitent ensuite la vérification du résultat.

Les techniques qui aident réellement

Fournir un exemple

Un exemple de sortie montre plus clairement le format attendu qu’une longue description. Il faut néanmoins vérifier que le modèle ne copie pas aveuglément les valeurs de l’exemple.

Découper une tâche

Séparer l’extraction, l’analyse et la présentation rend souvent le résultat plus contrôlable. Pour un traitement automatisé, plusieurs étapes spécialisées peuvent être plus fiables qu’un seul prompt chargé de tout faire.

Demander des éléments vérifiables

Exigez des citations de lignes, des extraits de code ou des champs structurés lorsque la source le permet. Ces éléments n’éliminent pas les erreurs, mais facilitent leur détection.

Attribuer un rôle avec mesure

« Vous conseillez une équipe réseau » peut orienter le vocabulaire et le point de vue. Ce rôle n’est toutefois ni une certification, ni une garantie d’exactitude. Le contexte, les données et les critères de réussite comptent généralement davantage.

Température et sorties structurées

La température est un réglage utilisé par de nombreux systèmes de génération pour modifier la diversité des choix de tokens. Une valeur basse tend à concentrer la génération sur les candidats les plus probables ; une valeur plus élevée tend à la diversifier. Son effet exact dépend du fournisseur et des autres réglages. Une température basse ne rend pas une réponse vraie et ne garantit pas toujours une sortie identique.

Une sortie structurée contraint la réponse à respecter un schéma, par exemple un objet JSON avec des champs définis. Elle facilite l’intégration dans un programme, mais ne garantit pas que les valeurs contenues dans ces champs sont exactes.

Ce qu’un prompt ne peut pas réparer

Une consigne parfaite ne compense pas des données absentes, une tâche hors de portée, un contexte mal sélectionné ou l’absence de contrôle sur une décision critique. Le prompt est une interface, pas un mécanisme de preuve.

À retenir

Les tokens déterminent le découpage et le volume traité. Les embeddings représentent des relations statistiques, souvent dépendantes du contexte. Le RAG apporte des documents au modèle. Le prompt définit sa mission, mais ne transforme jamais une génération probabiliste en vérité garantie.

L’étape suivante consiste à intégrer cette génération dans un outil sans perdre le contrôle des données, des erreurs et des coûts.

Pour aller plus loin

• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.