Mécanisme d'Attention (Transformer)

Définition

Le mécanisme d'attention est le composant central des architectures Transformer, introduites en 2017 par l'article Attention Is All You Need. Il calcule, pour chaque unité de texte (token), un poids d'importance relative vis-à-vis de tous les autres tokens de la séquence, à partir de trois projections apprenables : Query (requête), Key (clé) et Value (valeur). Contrairement aux réseaux récurrents qui traitaient les séquences pas à pas, l'attention met en relation directe n'importe quelle paire de tokens, quelle que soit leur distance, et le fait de manière massivement parallélisable. C'est cette propriété qui a rendu possibles les grands modèles de langage utilisés aujourd'hui en détection d'anomalies, en analyse de logs ou en génération de rapports SOC.

Fonctionnement technique

Chaque token est d'abord converti en vecteur d'embedding, auquel s'ajoute un encodage positionnel (sinusoïdal ou rotatif de type RoPE) qui réintroduit la notion d'ordre, absente par construction du mécanisme. Trois matrices de poids W_Q, W_K et W_V projettent ensuite ce vecteur en Query, Key et Value.

Le calcul suit la formule de l'attention par produit scalaire mis à l'échelle :

Attention(Q, K, V) = softmax(Q · Kᵀ / √dₖ) · V

• Q · Kᵀ : produit scalaire entre chaque requête et chaque clé, produisant une matrice de scores de similarité n×n.
• √dₖ : facteur de normalisation par la racine de la dimension des clés, qui évite que les scores explosent et saturent le softmax.
• softmax : transformation des scores en distribution de probabilité — la somme des poids d'attention d'un token vaut 1.
• · V : combinaison pondérée des valeurs, produisant une représentation contextualisée du token.

Trois variantes structurent les modèles réels. La self-attention fait porter Q, K et V sur la même séquence. La cross-attention interroge une séquence externe (typiquement l'encodeur depuis le décodeur, ou des documents récupérés en RAG). L'attention causale applique un masque triangulaire empêchant un token de « voir » ses successeurs : c'est ce qui rend la génération auto-régressive cohérente.

En pratique, le calcul est répliqué en multi-head attention : plusieurs têtes parallèles, chacune avec ses propres matrices, apprennent des relations différentes — syntaxe, coréférence, dépendances longue distance — avant concaténation et projection finale. Le coût mémoire et calcul croît en O(n²) avec la longueur de contexte, d'où les optimisations modernes : FlashAttention, grouped-query attention, cache KV, ou attention à fenêtre glissante.

Exemples concrets

• Analyse de logs : dans une ligne d'événement Windows, l'attention relie EventID 4688 au nom de processus enfant situé plusieurs dizaines de tokens plus loin, permettant de qualifier un living-off-the-land sans règle explicite.
• Détection de phishing : le modèle pondère fortement l'incohérence entre un domaine expéditeur et une marque citée dans le corps du message, même séparés par un long préambule.
• Analyse de code : l'attention rattache une variable utilisée dans un appel system() à son point d'entrée utilisateur déclaré bien plus haut — un raisonnement de taint analysis approximé statistiquement.
• Triage SOC : corrélation d'alertes hétérogènes dans une même fenêtre de contexte pour reconstruire une chaîne d'attaque.

Liens avec la sécurité

Le mécanisme d'attention n'est pas neutre du point de vue sécurité : il est précisément la surface exploitée par plusieurs classes d'attaques sur les modèles.

• Injection de prompt : puisque l'attention ne distingue pas structurellement une instruction système d'une donnée utilisateur — tout est token —, un contenu malveillant inséré dans un document peut capter les poids d'attention et détourner le comportement du modèle. C'est le problème de non-séparation instruction/données, analogue conceptuel de l'injection SQL.
• Jailbreak et détournement de contexte : des séquences adversariales optimisées manipulent la distribution du softmax pour diluer l'influence des consignes de sécurité.
• Fuite de données : le cache KV, qui mémorise clés et valeurs des tokens déjà traités, contient des représentations de données potentiellement sensibles ; sa mutualisation entre utilisateurs sur une même instance d'inférence est un risque de cloisonnement.
• Canaux auxiliaires : les variations de latence liées à la longueur de contexte et au cache ont été exploitées pour inférer des informations sur les requêtes voisines.
• Empoisonnement : un entraînement ou un fine-tuning corrompu peut installer des portes dérobées déclenchées par des motifs de tokens spécifiques.

Bonnes pratiques

• Traiter tout contenu externe (page web, PDF, ticket, e-mail) comme non fiable et le délimiter explicitement dans le prompt.
• Appliquer le moindre privilège aux outils exposés au modèle : une injection réussie n'a de valeur que si elle débouche sur une action.
• Filtrer entrées et sorties par des garde-fous indépendants du modèle principal, et journaliser les invocations d'outils.
• Isoler les caches KV par tenant et purger les contextes après session.
• Vérifier la provenance des poids et des jeux de données de fine-tuning (chaîne d'approvisionnement du modèle).
• Mesurer la robustesse par des campagnes de red teaming LLM, en s'appuyant sur le référentiel OWASP Top 10 for LLM Applications et le cadre MITRE ATLAS.

À retenir : l'attention confère aux Transformer leur capacité de mise en contexte globale, mais cette même absence de frontière entre instruction et donnée constitue leur principale faiblesse de sécurité. La défense se construit autour du modèle — cloisonnement, privilèges, supervision — et non dans le mécanisme lui-même.