Transformers et mécanisme d’attention : l’explication utile aux équipes assurance

Ce qu’il faut retenir

• Dans un Transformer, l’attention ne « comprend » pas une clause : elle calcule, pour chaque position, un mélange pondéré de représentations à partir de trois projections apprises, les requêtes, les clés et les valeurs.
• Le score entre une requête et une clé indique une compatibilité dans l’espace appris. Après normalisation par softmax, les poids servent à agréger les valeurs ; ils ne sont ni une probabilité de vérité ni une justification métier.
• L’attention multi-têtes répète ce calcul dans plusieurs sous-espaces. Les têtes peuvent présenter des comportements différents, mais leur seule visualisation ne prouve pas pourquoi la sortie finale a changé.
• Pour une équipe assurance, la bonne recette ne consiste pas à regarder une carte colorée : elle consiste à tester des paires minimales, les négations, les montants, les dates, les renvois de clause, les omissions et la stabilité de la sortie.
• Une preuve exploitable doit rester construite hors du mécanisme d’attention : passage source localisable, règle appliquée, version du système, sortie obtenue et décision humaine ou déterministe.

L’attention en une phrase : faire circuler l’information entre positions

Le mécanisme d’attention répond à une question étroite : pour construire la représentation d’un jeton à une couche donnée, quelles représentations disponibles doivent être combinées, et dans quelles proportions ? Il ne recherche pas spontanément une pièce dans un dossier, ne vérifie pas une règle contractuelle et ne mémorise pas un échange précédent. Il transforme une séquence déjà convertie en vecteurs.

Dans l’article fondateur de Vaswani et al. publié en 2017, le Transformer remplace les réseaux récurrents et convolutifs du modèle de traduction étudié par des blocs d’attention et des réseaux entièrement connectés. Cette architecture permet notamment de traiter en parallèle les positions pendant l’entraînement. Cette observation historique ne signifie pas que tous les modèles actuels reprennent exactement le même bloc ni qu’une amélioration mesurée en traduction vaut pour une tâche d’assurance.

Une équipe métier n’a donc pas besoin de retenir toute l’algèbre du modèle. Elle doit savoir ce que les poids représentent, ce qu’ils ne représentent pas et comment transformer cette compréhension en tests. C’est le fil directeur de ce guide.

Le calcul Q, K, V pas à pas

La formule canonique de l’attention par produit scalaire redimensionné est :

Attention(Q, K, V) = softmax(QKᵀ / √dk)V

Cette ligne compacte décrit quatre opérations distinctes. Les séparer évite les métaphores trompeuses.

1. Partir de représentations, pas de mots bruts

Le texte est d’abord découpé en jetons selon le tokenizer du modèle. Chaque jeton est associé à un vecteur, auquel s’ajoute ou s’intègre une information de position. Sans mécanisme de position, l’auto-attention seule ne dispose pas de l’ordre de la séquence sous la forme nécessaire au calcul. Le Transformer original emploie des encodages sinusoïdaux ; d’autres architectures utilisent d’autres dispositifs. « Transformer » désigne donc une famille, pas une configuration unique.

Cette étape compte déjà pour l’assurance. Un numéro de contrat, un montant ponctué, une référence d’avenant ou une abréviation métier peut être fragmenté en plusieurs jetons. Une erreur sur ces éléments ne se diagnostique pas en observant seulement la phrase lisible : il faut conserver la version du tokenizer et tester les formats réellement rencontrés.

2. Projeter chaque position en requête, clé et valeur

À partir de la représentation d’une position, le modèle calcule trois projections linéaires apprises :

• la requête décrit ce que la position courante cherche à combiner dans cet espace de calcul ;
• la clé sert à mesurer la compatibilité de cette position avec une requête ;
• la valeur contient l’information qui sera effectivement agrégée si la clé reçoit du poids.

Ces termes sont des noms de matrices. Une « requête » n’est pas la question écrite par l’utilisateur, une « clé » n’est pas une clé de base de données et une « valeur » n’est pas la valeur juridique d’un document. Une même représentation alimente les trois projections en auto-attention ; leurs paramètres sont néanmoins différents.

3. Calculer les compatibilités et appliquer le masque

Le produit QKᵀ produit un score pour chaque paire de positions autorisée. La division par √dk limite l’amplitude des produits scalaires lorsque la dimension des clés augmente, avant leur passage dans le softmax. Un masque peut interdire certaines relations. Dans un décodeur autorégressif, le masque causal empêche une position d’utiliser les jetons futurs pendant la prédiction.

Le softmax transforme ensuite chaque ligne de scores en poids positifs dont la somme vaut un sur les positions autorisées. Cette normalisation est locale à une requête et à une tête. Un poids de 0,6 ne signifie donc ni « 60 % de confiance », ni « 60 % de responsabilité », ni « information vraie à 60 % ».

4. Agréger les valeurs

Les poids multiplient les vecteurs de valeur, puis les résultats sont additionnés. La sortie d’attention d’une position est ainsi une combinaison contextuelle. Deux positions peuvent obtenir des poids proches et transporter des valeurs très différentes ; inversement, modifier un poids n’entraîne pas nécessairement une variation proportionnelle de la sortie finale, car d’autres têtes, les connexions résiduelles et les couches suivantes interviennent.

Objet technique	Rôle exact	Contresens à éviter
Requête Q	Projection de la position qui reçoit une représentation contextualisée	La confondre avec la consigne utilisateur
Clé K	Projection comparée à la requête pour produire un score	Y voir un identifiant documentaire stable
Valeur V	Projection agrégée selon les poids normalisés	Y lire directement le sens métier du jeton
Poids d’attention	Coefficient de mélange dans une tête, une couche et un exemple donnés	L’interpréter comme une confiance ou une causalité
Sortie de la tête	Somme pondérée des valeurs	La prendre pour la décision finale du modèle

De l’attention au bloc Transformer : ce que l’image simplifiée omet

Plusieurs têtes, plusieurs sous-espaces

L’attention multi-têtes applique plusieurs jeux de projections Q, K et V en parallèle. Les sorties des têtes sont concaténées, puis projetées. L’intérêt n’est pas de voter entre plusieurs « experts » nommables : chaque tête participe à une représentation distribuée. L’analyse expérimentale de Clark et al. a observé dans BERT des têtes sensibles à des positions, à des délimiteurs ou à certaines relations syntaxiques, mais aussi des comportements redondants. Ces constats sur BERT ne permettent pas d’attribuer à chaque tête d’un autre modèle une fonction stable.

Une carte isolée perd en outre quatre coordonnées indispensables : le modèle et sa version, la couche, la tête et la position interrogée. Agréger les têtes peut rendre la visualisation lisible tout en effaçant des différences ; choisir seulement une tête spectaculaire peut produire l’effet inverse. Dans les deux cas, le graphique reste un diagnostic interne, pas une preuve de conformité.

Résiduel, normalisation et réseau positionnel

Un bloc ne s’arrête pas à l’attention. Le Transformer de 2017 entoure chaque sous-couche d’une connexion résiduelle suivie d’une normalisation, puis applique un réseau entièrement connecté séparément à chaque position. De nombreuses architectures ultérieures changent l’ordre de normalisation ou d’autres détails. La connexion résiduelle est essentielle pour l’interprétation : l’état transmis peut conserver de l’information en dehors de la seule sortie d’attention.

Après empilement de nombreux blocs, la sortie finale dépend donc d’une chaîne de transformations. Dire « le modèle a regardé ce mot » à partir d’un poids élevé dans une tête revient à ignorer les valeurs transportées, les autres têtes, les résidus et toutes les couches suivantes.

Pourquoi la longueur du dossier a un coût

Dans l’attention dense, la matrice de scores relie chaque position à toutes les positions autorisées. Sa taille croît comme le carré de la longueur de la séquence. Les implémentations et variantes modernes peuvent réduire certains coûts ou restreindre les relations, mais « accepter davantage de jetons » ne rend pas gratuitement chaque passage également exploitable.

Cette limite technique complète un problème de qualité : un document présent dans la fenêtre de contexte n’est pas nécessairement utilisé de manière fiable. Le guide sur la fenêtre de contexte et la qualité d’un dossier assurance détaille les tests à mener lorsque l’on envisage d’envoyer davantage de pièces au modèle.

Encodeur, décodeur et attention croisée : trois flux différents

Le mot Transformer masque plusieurs modes de circulation de l’information. Les distinguer aide à choisir une recette cohérente avec le cas d’usage.

Flux	Relations autorisées	Exemple de tâche à évaluer	Point de vigilance
Encodeur bidirectionnel	Chaque position peut utiliser le contexte à gauche et à droite	Classer un courrier ou extraire une catégorie après adaptation du modèle	La représentation dépend de tout le passage fourni
Décodeur causal	Chaque position n’utilise que les positions antérieures autorisées	Produire un résumé jeton après jeton	Une erreur générée rejoint le contexte des étapes suivantes
Attention croisée	Les requêtes d’un flux consultent les clés et valeurs d’un autre	Dans l’architecture encodeur-décodeur originale, générer à partir d’une séquence encodée	La provenance n’est pas garantie par le seul lien attentionnel

BERT, décrit par Devlin et al., fournit un exemple documenté d’encodeur préentraîné qui conditionne les représentations sur le contexte gauche et droit. Le Transformer original, lui, associe encodeur et décodeur pour la traduction. Ces exemples établissent des différences d’architecture ; ils ne suffisent pas à choisir un modèle pour un parcours d’assurance. Le choix doit partir de la sortie attendue, du coût d’erreur et des données de recette.

Lire une clause d’assurance sans fausse analogie

Scénario pédagogique, sans résultat de modèle réel. Une équipe teste un assistant chargé de préparer un résumé de garanties à partir d’un contrat. Elle utilise la phrase synthétique suivante : « La garantie vol n’est acquise que si le véhicule est remisé dans un garage fermé entre 22 h et 6 h. »

Pour construire la représentation du jeton associé à « acquise », certaines têtes pourraient, selon le modèle appris, combiner des informations liées à « n’est », « que si », « remisé » ou aux horaires. Le mécanisme le permet ; cette phrase ne prédit pas les poids qu’un modèle donné produira. Le sens exploitable résulte de l’ensemble des couches et de la tâche pour laquelle le système a été entraîné ou adapté.

L’équipe ne cherche donc pas une jolie carte. Elle construit des variantes qui isolent une difficulté :

1. retirer « n’ » pour vérifier que la polarité change ;
2. remplacer « que si » par « même si » pour tester la condition ;
3. modifier uniquement « 22 h » en « 20 h » afin d’observer le traitement du seuil temporel ;
4. placer une clause contradictoire plus loin dans l’extrait et vérifier que le système signale le conflit au lieu de choisir silencieusement ;
5. supprimer la page contenant la définition de « garage fermé » et attendre une abstention ou une demande de source, selon le contrat de service.

Ces paires minimales évaluent l’effet d’une information sur la sortie. Elles sont plus proches de la question métier qu’une inspection de poids internes. Elles doivent être complétées par des dossiers représentatifs, car réussir cinq phrases construites ne démontre ni la robustesse sur les scans, ni la gestion des avenants, ni la fidélité sur des contrats longs.

Si le système récupère des passages avant la génération, l’attention du modèle et la recherche documentaire sont deux opérations différentes. Les embeddings et la recherche vectorielle construisent des candidats ; le reranking et les citations dans un RAG assurance servent ensuite à ordonner les passages et à relier la réponse à une preuve consultable. Aucun de ces étages n’est remplacé par une carte d’attention.

Pourquoi les poids d’attention ne suffisent pas à expliquer une sortie

La littérature scientifique a posé la question de manière contradictoire et utile. Jain et Wallace ont montré, sur les tâches et modèles étudiés, que des distributions d’attention très différentes pouvaient conduire à des prédictions équivalentes et que les poids étaient souvent peu corrélés à des mesures fondées sur les gradients. Leur conclusion met en garde contre l’assimilation automatique des poids à une explication.

Wiegreffe et Pinter ont ensuite contesté la portée générale de cette conclusion. Elles soulignent qu’il faut définir ce que l’on appelle « explication » et évaluer le mécanisme dans le contexte du modèle complet ; elles proposent plusieurs tests, notamment des références uniformes, des comparaisons entre initialisations et des diagnostics contrôlés. La conclusion raisonnable pour une équipe assurance n’est donc pas « les poids ne servent jamais » mais « leur valeur dépend d’une question précise et d’un protocole ».

Trois niveaux à ne pas fusionner

• Diagnostic de mécanisme : une tête ou une couche réagit-elle à une structure, une position ou un type de jeton dans un jeu de tests contrôlé ?
• Explication du comportement : quelles modifications d’entrée changent effectivement la sortie, toutes choses égales par ailleurs ?
• Justification du dossier : quelles pièces, clauses et règles autorisées soutiennent l’information présentée à l’utilisateur ?

Une carte d’attention peut contribuer au premier niveau. Elle ne fournit pas automatiquement les deux suivants. La justification d’un dossier exige une provenance externe au calcul latent : identifiant du document, version, page ou segment, date de récupération, règle éventuellement appliquée et trace de la validation.

Le test contrefactuel est plus informatif que la couleur

Lorsqu’une équipe affirme que le système utilise une négation, un montant ou un renvoi, elle doit modifier cet élément et observer l’effet. Si la sortie ne change pas alors que la décision attendue change, le test a trouvé un défaut. Si elle change, cela ne prouve pas encore la correction générale, mais fournit une observation directement reliée à la promesse du système.

Les perturbations doivent rester sémantiquement maîtrisées. Remplacer un mot par un synonyme peut modifier le sens juridique ou la tokenisation ; supprimer une phrase peut rendre le document incohérent. Chaque variante est donc relue par une personne compétente et étiquetée avec l’effet attendu avant l’exécution.

La recette utile aux équipes assurance : sept tests séparés

Le protocole ci-dessous évalue un usage, pas le Transformer en général. Les seuils dépendent du dommage possible, du canal et de la place de la sortie dans la décision. Le NIST AI RMF 1.0 propose de gérer les risques d’un système au moyen des fonctions Govern, Map, Measure et Manage ; cette logique conduit ici à documenter le contexte avant de mesurer, puis à décider quoi faire des écarts.

1. Tester les unités sensibles au tokenizer

Constituez une liste de formats réellement présents : références de contrats, plaques lorsque leur usage est autorisé, dates, heures, montants, pourcentages, numéros d’articles et abréviations. Observez leur découpage avec la version exacte du tokenizer lorsque l’outil le permet, puis testez le comportement de bout en bout. Le livrable n’est pas une liste de jetons « correcte » en soi, mais un registre des formats fragiles et de leurs conséquences.

2. Construire des paires minimales métier

Pour chaque règle importante, préparez deux entrées qui ne diffèrent que par un élément décisif : présence d’une négation, seuil de franchise, date d’effet, qualité du bénéficiaire ou condition cumulative. Écrivez la sortie attendue avant le test. Mesurez séparément l’absence de changement injustifiée et le changement excessif.

3. Distinguer repérage, extraction et conclusion

Demandez trois sorties structurées : le passage localisé, les éléments extraits et la conclusion proposée. Un passage correctement cité peut être mal interprété ; une conclusion correcte peut provenir d’une source non autorisée. Cette séparation rend l’erreur attribuable et facilite le repli vers une règle ou une revue humaine.

4. Déplacer l’information dans le contexte

Placez la même information utile au début, au milieu et à la fin d’un dossier de longueur contrôlée, sans changer le reste. Ajoutez ensuite du contenu non pertinent réaliste. L’objectif n’est pas d’expliquer la couche interne, mais de vérifier que la promesse reste tenue lorsque la position et le bruit changent.

5. Injecter contradictions et informations manquantes

Présentez un avenant qui modifie une condition du contrat initial, deux dates incompatibles ou une référence absente. Le comportement attendu doit être explicite : priorité documentée, signalement du conflit ou abstention. Une synthèse qui masque le désaccord est un échec, même si sa formulation est fluide.

6. Comparer versions et répétitions

Rejouez un lot gelé après chaque changement de modèle, de prompt, de tokenizer, de stratégie de contexte ou de moteur de recherche. Répétez aussi les cas lorsque le système est stochastique. Conservez sorties, paramètres accessibles et erreurs par famille ; une moyenne globale ne montre pas une régression concentrée sur les exclusions ou les montants.

7. Mesurer l’usage réel de la sortie

Un résumé fidèle peut tout de même faire perdre du temps s’il est systématiquement relu, ou créer un risque s’il est validé par automatisme. Pendant un pilote borné, mesurez les corrections, abstentions, escalades, temps de vérification et catégories d’erreur. Ne déduisez pas la valeur opérationnelle d’un score technique isolé.

Preuve conservée	Question qu’elle permet de trancher	Ce qu’elle ne démontre pas
Paire minimale et sortie attendue	Le système réagit-il à l’élément décisif testé ?	La robustesse sur toutes les formulations
Segment source localisable	La réponse peut-elle être contrôlée dans le dossier ?	La validité juridique de l’interprétation
Trace de version	Quel système a produit cette sortie ?	Pourquoi chaque opération interne a eu lieu
Journal de correction humaine	Où la sortie demande-t-elle une reprise ?	L’absence de biais dans les cas non revus
Carte d’attention	Quel motif interne explorer dans ce modèle précis ?	La causalité ou la justification métier à elle seule

Les questions à poser à un fournisseur ou à une équipe modèle

Il est rarement utile d’exiger une explication exhaustive de toutes les têtes. Il est en revanche raisonnable d’obtenir des réponses vérifiables sur le service livré :

1. Quelle architecture est réellement utilisée ? Encodeur, décodeur, modèle multimodal, mécanisme de recherche et versions doivent être distingués.
2. Quel tokenizer et quelle limite de contexte s’appliquent à notre endpoint ? La réponse doit porter sur la configuration consommée, pas sur une famille commerciale.
3. Quels masques ou restrictions structurent l’attention ? Cette question concerne surtout les équipes qui entraînent ou hébergent le modèle ; une API fermée peut ne pas exposer ces détails.
4. Quelles traces sont disponibles sans journaliser des données inutiles ? Source, version, paramètres autorisés, identifiant de requête et voie de repli doivent respecter les règles de conservation.
5. Quels changements sont annoncés et lesquels peuvent être silencieux ? Un alias de modèle ne suffit pas à garantir une représentation stable.
6. Comment rejouer un lot de non-régression ? Le protocole doit couvrir les cas rares et les erreurs coûteuses, pas seulement quelques exemples de démonstration.
7. Quelle preuve accompagne une information présentée à l’utilisateur ? Une citation doit être localisable et vérifiée indépendamment de l’attention interne.

La réponse à ces questions alimente le contrat de recette. Pour organiser toute la chaîne, de la sélection des documents jusqu’à la sortie, le dossier sur l’architecture RAG réellement vérifiable en assurance fournit un cadre complémentaire.

Sources et références primaires

Sources vérifiées le 12 août 2026. Les articles scientifiques décrivent des architectures et expériences précises ; leurs résultats ne sont pas transposés à un produit ou à un portefeuille d’assurance sans test local.

• Vaswani et al., « Attention Is All You Need », NeurIPS 2017 — architecture encodeur-décodeur, attention par produit scalaire redimensionné, attention multi-têtes et position.
• Devlin et al., « BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding », NAACL 2019 — exemple d’encodeur Transformer bidirectionnel préentraîné.
• Clark et al., « What Does BERT Look at? An Analysis of BERT’s Attention », BlackboxNLP 2019 — analyse expérimentale de motifs observés dans les têtes de BERT.
• Jain et Wallace, « Attention is not Explanation », NAACL 2019 — tests de la relation entre poids d’attention et prédictions.
• Wiegreffe et Pinter, « Attention is not not Explanation », EMNLP-IJCNLP 2019 — clarification des définitions et protocoles nécessaires pour évaluer l’attention comme explication.
• NIST, Artificial Intelligence Risk Management Framework 1.0, 2023 — cadre volontaire de gouvernance, cartographie, mesure et gestion des risques d’un système d’IA.

Passer de l’explication technique au contrat de test

Comprendre Q, K et V est utile si cette compréhension change la façon de recetter le service : moins de confiance dans les visualisations isolées, davantage de paires minimales, de sources localisables, de versions gelées et de décisions d’arrêt. C’est à ce niveau que le mécanisme d’attention devient réellement utile à une équipe assurance.