AI & Analytics Legends La plateforme de connaissance SAP Analytics
Fiche concept

Encoder-Decoder vs Decoder-Only — Pourquoi GPT/Claude/Gemini ont tous choisi Decoder-Only

Encoder-Decoder vs Decoder-Only — Pourquoi GPT/Claude/Gemini ont tous choisi Decoder-Only — illustration de section Analytics Legends pour la base de connaissances SAP Analytics (concepts, études, Academy)

À jour au 2026-10-06

Encoder-Decoder vs Decoder-Only : quelle est la différence ?

Presque tous les LLM de frontière ont convergé vers le decoder-only en cinq ans après le Transformer encoder-decoder original, car une pile unique divise par deux la complexité d'ingénierie et fait émerger naturellement l'apprentissage en contexte en traitant prompt et génération comme une seule séquence.

De quoi il s'agit

Le Transformer original de 2017, décrit dans « Attention Is All You Need », était une architecture encodeur-décodeur : une pile d'encodeur qui lit l'intégralité de l'entrée de façon bidirectionnelle, associée à une pile de décodeur qui génère la sortie de façon autorégressive tout en portant une attention croisée aux représentations de l'encodeur. En l'espace d'environ cinq ans, presque tous les grands modèles de langage de pointe — GPT-3 et GPT-4, Claude, Llama, Gemini, Mistral, DeepSeek — avaient convergé vers une conception différente : le décodeur seul, une pile unique qui traite l'entrée et la sortie générée comme une seule séquence continue sous masquage causal, sans encodeur séparé et sans attention croisée. Comprendre pourquoi cette convergence s'est produite, et où elle ne s'est pas produite, est essentiel pour quiconque évalue des architectures de modèles, calibre un projet de réglage fin, ou explique à un client pourquoi « le chatbot » et « le moteur de traduction » reposent discrètement sur des fondations différentes.

Pourquoi c'est important

  • Les modèles encoder-only (classe BERT) ne peuvent pas générer de texte fluide du tout — conçus uniquement pour la classification, le QA extractif et les embeddings.
  • Le masquage causal des modèles decoder-only permet la réutilisation du cache KV entre étapes de génération d'une manière que la cross-attention encoder-decoder complique.
  • Les architectures encoder-decoder gagnent encore pour la traduction pure et les transformations à schéma fixe structuré-vers-structuré — le decoder-only n'est pas universellement meilleur, juste mieux adapté à la génération généraliste.

Points clés

  • Trois familles — encoder-only (BERT, classification/embeddings), encoder-decoder (T5/BART, transformations structurées), decoder-only (GPT/Claude/Llama/Gemini, génération ouverte).
  • Decoder-only a gagné à l'échelle frontière — une pile plus simple que deux ; l'in-context learning émerge naturellement ; réutilisation KV cache plus propre ; budget complet de params pour compréhension et génération.
  • Encoder-decoder gagne encore — traduction production (Google), transformations à schéma fixe, résumé longue-entrée/courte-sortie.
  • Défaut pratique pour nouveaux projets LLM en 2026 — decoder-only ; l'écosystème (Llama 3, Mistral, DeepSeek, Claude, GPT, Gemini) est decoder-only et le tooling est decoder-only-first.
  • Encoder-only (famille BERT) reste dominant pour embeddings + classification — cas d'usage différent, pas un concurrent à la génération LLM.
  • Tout modèle exposé par SAP via Joule ou le generative AI hub — Claude, GPT, Gemini, Mistral — est decoder-only ; aucune interface SAP n'offre d'alternative encoder-decoder, si bien que le choix ne resurgit que pour un pipeline de transformation dédié, cadré à part, hors du chemin hébergé géré.
  • Le generative AI hub de SAP privilégie par défaut l'orchestration (prompting plus grounding) au fine-tuning, ce qui est en soi un biais de conception decoder-only par défaut, à nommer quand le besoin réel d'un client est une transformation étroite à schéma fixe.

Termes employés sur cette page

Decoder-only transformer
Architecture Transformer à une seule pile de couches, avec self-attention causale de bout en bout, entraînée sur la prédiction du token suivant ; l'architecture canonique de GPT, Claude, Llama, Mistral, Gemini et DeepSeek.
Encoder-decoder transformer
L'architecture Transformer originale de 2017 : un encodeur bidirectionnel lit l'entrée complète, un décodeur causal génère la sortie tout en cross-attendant aux représentations de l'encodeur ; canonique pour T5, BART et les systèmes de traduction en production.
Causal masking
Un masque d'attention qui empêche chaque token d'attendre aux tokens futurs de la séquence ; requis pour la génération autorégressive et le trait distinctif des architectures decoder-only.
Cross-attention
Attention des tokens du décodeur vers les représentations de l'encodeur dans les transformers encoder-decoder ; le mécanisme par lequel le décodeur consulte l'entrée. Absent des modèles decoder-only.
In-context learning (ICL)
La capacité d'un LLM à réaliser une nouvelle tâche à partir d'exemples fournis dans le prompt, sans aucune mise à jour de paramètres ; émerge naturellement dans les modèles decoder-only entraînés à grande échelle sur la prédiction du token suivant.

Sources

  1. Attention Is All You Need (Vaswani et al., 2017)
  2. T5: Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer (Raffel et al., 2020)
  3. GPT-3: Language Models are Few-Shot Learners (Brown et al., 2020)
  4. What Language Model Architecture and Pretraining Objective Work Best for Zero-Shot Generalization? (Wang et al., 2022)
  5. SAP Generative AI — official product page
  6. arXiv — BART: Denoising Sequence-to-Sequence Pre-training for NLG, Translation and Comprehension (Lewis et al., 2019)
  7. arXiv — PaLM: Scaling Language Modeling with Pathways (2022)
  8. SAP Help Portal — What is SAP Document AI (structured extraction capability)
  9. SAP — Document AI service description (plans, error-rate caution)
  10. SAP Help Portal — Orchestration service (prompting plus grounding, the generative AI hub's default path)
  11. SAP Help Portal — Generative AI hub in SAP AI Core (hosted decoder-only endpoints)
  12. Anthropic — Context windows documentation (2026 model context/output limits)
  13. Databricks — Model Serving documentation (deploying a dedicated encoder-decoder model)

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code · les chiffres à citer.

Ouvrir dans l'application →