Embeddings et tokenisation : questions d'entretien

Article 5 de la série The AI Engineer Loop — À quoi ressemble un entretien d'AI Engineer en 2026, question par question. Précédemment : où vivent les poids Q, K, V.

Les fondamentaux d'un entretien d'AI Engineer ne s'arrêtent pas à l'attention. Il reste trois sujets qu'on glisse presque toujours, parce qu'ils décident de ce que vous construirez ensuite : les familles d'architectures, les embeddings et la tokenisation.

Chacun a une version « vocabulaire » et une version « décision ». C'est la seconde qui est testée. Dans l'article précédent, nous avons posé que la table d'embeddings d'un LLM n'a rien à voir avec votre modèle d'embeddings de recherche. Voici pourquoi, et ce que cela change pour votre RAG.

Ce que ces questions testent vraiment

Si la taxonomie est, pour vous, une liste de noms à réciter ou quelque chose que vous appliquez. Un bon candidat termine chaque réponse par une conséquence : un choix de modèle, un budget, un bug évité.

« Encodeur, décodeur, encodeur-décodeur : lequel utilisez-vous ? »

Trois familles, à distinguer par la façon dont l'attention est masquée :

Encodeur seul (la lignée BERT). L'attention est bidirectionnelle : chaque token voit toute l'entrée. Ce n'est pas un modèle génératif, il produit des représentations. Votre modèle d'embeddings et votre reranker sont des encodeurs.
Décodeur seul (la lignée GPT et Llama). L'attention est causale, le modèle est entraîné à prédire le token suivant. C'est ce que vous appelez dès que vous voulez du texte généré.
Encodeur-décodeur (T5, et l'architecture d'origine de 2017). Un encodeur lit la source, un décodeur lui prête attention pendant qu'il génère. C'est le schéma de la traduction et des tâches séquence-à-séquence, largement supplanté pour les usages généralistes.

Schéma de l'architecture complète d'un transformer : à gauche la pile encodeur (attention multi-têtes et réseau feed-forward), à droite la pile décodeur (attention masquée, attention croisée et feed-forward), avec embeddings et encodage positionnel en entrée — **Figure — Les deux piles du transformer d'origine.** À gauche, l'encodeur : son attention est bidirectionnelle. À droite, le décodeur : son attention est masquée, et il regarde aussi la sortie de l'encodeur (attention croisée). Un modèle « encodeur seul » est la pile de gauche ; un modèle « décodeur seul » est la pile de droite sans l'attention croisée.
Source : « Transformer, full architecture », dvgodoy (dl-visuals), Wikimedia Commons, licence CC BY 4.0. Rendu PNG de 960 px fourni par Wikimedia, recompressé sans perte (WebP) et hébergé sur viite.ai ; contenu inchangé.

Là où la taxonomie devient une décision : bi-encodeur et cross-encodeur

La réponse qui fait mouche applique la distinction à votre pipeline de recherche :

	Bi-encodeur	Cross-encodeur
Ce qu'il lit	la requête et le document, séparément	la requête et le document, ensemble
Précalculable	oui : les vecteurs des documents sont calculés une fois	non : le score dépend de la paire
Coût à la requête	un calcul, puis une recherche de plus proches voisins	un appel de modèle par candidat
Précision	bonne, avec une petite perte	meilleure
Rôle dans un RAG	récupérer large (premier étage)	réordonner étroit (second étage)

Un bi-encodeur calcule un vecteur par document, une fois pour toutes, ce qui permet de les indexer et de les chercher vite. Un cross-encodeur concatène la requête et le document et fait circuler l'attention entre les deux : il juge la paire d'un seul regard, bien plus précisément, mais rien ne peut être précalculé puisque la représentation dépend de la paire.

Cette seule différence d'architecture justifie tout le schéma « on récupère large, puis on réordonne étroit ».

Signal d'alarme : présenter l'encodeur-décodeur comme la norme, ou réciter BERT, GPT et T5 sans dire ce que ça change pour votre système. La plupart des modèles génératifs que vous appellerez sont des décodeurs seuls.

« Qu'est-ce qu'un embedding, vraiment ? »

C'est un vecteur appris dont la géométrie encode une similarité, mais uniquement celle que définit l'objectif d'entraînement.
Il est entraîné de façon contrastive : on rapproche les paires réellement liées, on éloigne les autres. « Sémantiquement proche » veut donc dire « proche selon la notion de quelqu'un d'autre ». C'est pourquoi un modèle d'embeddings générique peut sous-performer sur le jargon de votre domaine.
On les compare par similarité cosinus : l'angle, pas la norme. Si vous normalisez les vecteurs une fois à l'indexation, le cosinus devient un simple produit scalaire.
La dimension est un compromis entre coût et précision : des vecteurs plus grands capturent plus de choses et coûtent plus cher à stocker et à parcourir. Les embeddings de type Matryoshka sont entraînés pour pouvoir être tronqués en se dégradant doucement.
Dites où ça échoue. Les vecteurs denses sont avares sur les tokens rares qui portent beaucoup d'information : codes d'erreur, références produit, numéros de version. ERR_5521 et ERR_5512 peuvent y être presque indiscernables. C'est le mécanisme derrière la recherche hybride, qui ajoute une recherche par mots-clés exacts.

cos(a, b) = (a · b) / (‖a‖ × ‖b‖)

# vecteurs normalisés à l'indexation (‖a‖ = ‖b‖ = 1) :
cos(a, b) = a · b

Signal d'alarme : dire que deux textes sont « similaires » sans dire selon quel entraînement. Un embedding ne mesure pas le sens en général, il mesure ce pour quoi on l'a entraîné.

« Pourquoi un ingénieur applicatif devrait-il se soucier de la tokenisation ? »

Les modèles lisent des sous-mots. La tokenisation (BPE et ses variantes) se place entre les caractères et les mots : un mot courant tient en un token, un mot rare se fragmente.
Elle explique les ratés classiques : compter les lettres d'un mot, inverser une chaîne, faire une opération chiffre à chiffre. Le modèle ne voit jamais les caractères.
C'est une question de budget. Un texte non anglophone, ou du code, coûte souvent sensiblement plus de tokens pour un même contenu. Pour du français, mesurez avec le tokenizer du modèle que vous utilisez plutôt que de supposer : vos estimations de contexte et de coût en dépendent.
C'est aussi une question de correction, dans votre propre code : la taille d'un chunk se compte en tokens, pas en caractères. Découper sur les caractères produit des chunks qui débordent de façon imprévisible.

# pseudo-code
len("l'été prochain")                       # des caractères : pas le bon compte
len(tokenizer.encode("l'été prochain"))    # des tokens : celui qui compte

Signal d'alarme : dimensionner ses chunks ou son budget de contexte en caractères, ou en « nombre de mots × 1,3 » repris d'un article sur l'anglais.

La phrase à prononcer en entretien

Un encodeur lit tout d'un bloc et produit des représentations : c'est mon modèle d'embeddings et mon reranker. Un décodeur génère, un token après l'autre. Je récupère large avec des bi-encodeurs, dont les vecteurs sont précalculés, puis je réordonne étroit avec un cross-encodeur, qui juge la paire ensemble. Je compte mes chunks en tokens et pas en caractères, et je teste mon modèle d'embeddings sur mon propre jargon plutôt que de me fier à un benchmark.

Pour aller plus loin

Si vous voulez voir comment on construit un tokenizer :

Construire un tokenizer de zéro, en vidéo.
Vidéo : « Let's build the GPT Tokenizer », par Andrej Karpathy — Voir sur YouTube.

Article suivant de la série The AI Engineer Loop : comment les modèles connaissent l'ordre des mots, pourquoi le contexte long se dégrade, et ce que font le pré-entraînement, le fine-tuning et le RLHF.

Chez Viite, nous simplifions les processus d'entreprise avec l'IA, mais pour l'humain. Nous éditons aussi l'application Business Studio pour gérer vos vies privées ou pros.