Encoder-Decoder-Modelle einfach erklärt: Funktion & Anwendung
Welche Bauart hinter welcher Aufgabe steckt
Wer ein Sprachmodell für eine Aufgabe im Betrieb auswählt, stößt früher oder später auf eine Unterscheidung, die in Produktbeschreibungen selten vorkommt. Solche Modelle gibt es in drei Bauarten, und welche davon vorliegt, entscheidet über die Art von Ergebnis, die ein Modell überhaupt ausgeben kann. Diese Seite erklärt die Encoder-Decoder-Architektur und ordnet ein, wofür sie gebraucht wird und wofür nicht.
Was die beiden Hälften tun
Der Encoder nimmt die Eingabe entgegen und verdichtet sie zu einer Zahlendarstellung. Was darin steckt, sind nicht mehr die einzelnen Wörter, sondern deren Bedeutung im Zusammenhang: Ob „Bank“ ein Geldinstitut oder ein Sitzmöbel meint, ist an dieser Stelle bereits entschieden. Sprache im Sinne von lesbarem Text ist das Ergebnis nicht.
Der Decoder arbeitet in die Gegenrichtung. Er erzeugt die Ausgabe Stück für Stück und schaut dabei auf zwei Dinge: auf die verdichtete Eingabe und auf das, was er selbst bereits geschrieben hat. Weil er erst zu schreiben beginnt, wenn die Eingabe vollständig gelesen ist, kann er die Reihenfolge umbauen. Genau das braucht eine Übersetzung zwischen zwei Sprachen mit unterschiedlicher Satzstellung, und genau daran sind regelbasierte Übersetzungssysteme jahrzehntelang gescheitert.
Drei Bauarten und ihre Aufgaben
Aus denselben Bausteinen lassen sich drei verschiedene Modelle bauen. Welche Sie vor sich haben, erkennen Sie am ehesten daran, was das Modell ausgibt.
Nur Encoder. Eingabe hinein, Urteil heraus: eine Kategorie oder ein Vektor, mit dem sich zwei Texte vergleichen lassen. Die BERT-Familie gehört hierher, ebenso die gängigen Embedding-Modelle. Das ist die Bauart hinter Klassifikation und Zuordnung, wie sie das Natural Language Understanding im Betrieb einsetzt.
Nur Decoder. Das Modell setzt einen Text fort, Token für Token, ohne getrennte Lesephase. Die Frage des Benutzers und die eigene Antwort stehen für ein solches Modell in derselben Zeile. Hier sind die Chat-Modelle zu Hause, und damit die Technik hinter den LLM-Chatbots.
Encoder und Decoder. Eingabe in der einen Form, Ausgabe in einer anderen, beide unterschiedlich lang. Übersetzung, Zusammenfassung und Spracherkennung fallen darunter. T5 und BART sind die bekannten Textvertreter, Whisper wandelt nach demselben Muster Tonaufnahmen in Text.
Die Zuordnung wird häufig durcheinandergebracht, und fast immer in dieselbe Richtung: Chatbots gelten in Erklärtexten gern als Encoder-Decoder-Modelle. Die Oberfläche legt das nahe, denn sie zeigt Frage und Antwort und nicht, ob dazwischen eine getrennte Lesephase liegt. Gebaut sind die heutigen Chat-Modelle aber als reine Decoder. Wer sich daran hält, ordnet auch die Bildseite richtig ein: Die automatische Bildbeschreibung verbindet einen Bild-Encoder mit einem Text-Decoder und gehört damit hierher. Die Erzeugung neuer Bilder gehört nicht dazu, sie ist eine andere Aufgabe, und diese Seite behandelt sie nicht.
Wo die Bauart im Projekt auftaucht
Im Alltag wählt niemand zuerst eine Architektur und sucht dann eine Aufgabe dazu. Zum Thema wird die Bauart erst, wenn ein Ergebnis ausbleibt, und der Fall wiederholt sich.
Ein Betrieb will Ausschreibungstexte mit früheren Angeboten abgleichen und fragt dafür das Chat-Modell, das ohnehin schon im Haus läuft. Zurück kommt ein Urteil in Worten, „passt eher gut“, beim zweiten Durchlauf etwas anders formuliert. Damit lässt sich nichts sortieren und nichts über hundert Dokumente hinweg vergleichen. Ein Encoder-Modell liefert für jeden Text einen Vektor; der Abgleich ist danach eine Rechenoperation, die zweimal dasselbe Ergebnis liefert. Umgekehrt gilt dasselbe: Ein Embedding-Modell kann keine Zusammenfassung schreiben, weil es keinen Decoder hat, der Text erzeugt.
Praktisch heißt das: Bevor jemand ein Modell auswählt, gehört festgehalten, was hineingeht und was herauskommen soll, und woran das Ergebnis gemessen wird. Bei der Dokumentenverarbeitung ist das ein befülltes Feld im ERP, bei der Textzuordnung eine Rangfolge mit Begründung. Aus dieser einen Festlegung ergibt sich die Bauart von selbst.
Was die Architektur nicht löst
Zwei Punkte stehen in älteren Erklärtexten und führen in die Irre.
Der erste ist die Sorge, ein Encoder müsse einen ganzen Text in eine einzige Darstellung pressen und verliere dabei den Zusammenhang über lange Strecken. Das traf die ersten Modelle dieser Bauart tatsächlich. Mit dem Attention-Mechanismus ist der Engpass entfallen: Der Decoder greift bei jedem Schritt auf die gesamte gelesene Eingabe zurück statt auf eine einzige Verdichtung. Eine Grenze bleibt trotzdem, sie liegt nur woanders, nämlich in der Kontextlänge, die ein Modell verarbeiten kann, und im Rechenaufwand, der mit ihr wächst.
Der zweite ist die Aussage, solche Modelle bräuchten riesige Datenmengen. Für das Vortraining stimmt sie, nur macht dieses Vortraining kein Anwenderbetrieb selbst. Vortrainierte Modelle stehen bereit, viele davon unter einer freien Lizenz. Was im Haus gebraucht wird, sind Beispiele für die eigene Aufgabe, und davon deutlich weniger.
Was die Architektur ebenfalls nicht mitbringt, ist Verlässlichkeit im Inhalt. Auch ein Modell, das nur zusammenfassen soll, kann eine Angabe in die Zusammenfassung schreiben, die im Ausgangstext nirgends steht. Wer Ergebnisse ungeprüft weiterreicht, hat dieses Risiko unabhängig davon, wie viele Hälften sein Modell hat.
Fazit
Encoder-Decoder-Modelle sind die Bauart für Aufgaben, bei denen aus einer vollständig gelesenen Eingabe etwas anderes entstehen soll: aus einem deutschen Satz ein englischer, aus einer Tonaufnahme ein Protokoll, aus zehn Seiten eine halbe. Für die beiden häufigsten betrieblichen Aufgaben ist sie nicht zuständig. Sortieren und Zuordnen erledigt ein Encoder-Modell, Dialog und Textentwurf ein Decoder-Modell. Diese Einteilung ist schnell gemacht und erspart im Projekt die Fehlersuche an der falschen Stelle.