Mit dem Preview von Mythos beschreibt Anthropic einen möglichen Wendepunkt in der Cybersicherheit.
Das Forschungsmodell erkennt gefährliche Sicherheitslücken in bestehender Software – oft schneller und in komplexeren Zusammenhängen als menschliche Analysten.

Dabei ist Mythos kein klassisches Security-Tool. Es wurde nicht gezielt für Exploit-Entwicklung oder Schwachstellensuche trainiert.
Vielmehr handelt es sich um eine Weiterentwicklung eines Large Language Models – optimiert für Code, Reasoning und Autonomie.

Aus dieser Skalierung heraus entstehen neue Fähigkeiten – durch ein Phänomen, das als Emergence bezeichnet wird:

• Analyse von Binärcode auch ohne Sourcecode
• Erkennung klassischer Schwachstellen
• Generierung und iterative Verfeinerung von Exploit-Strategien

Emergence beschreibt, dass ein Modell durch Größe und Training plötzlich Fähigkeiten zeigt, die nicht explizit antrainiert wurden – etwa die Fähigkeit zur Exploit-Analyse.

Das Resultat:
Ein allgemeines LLM ist plötzlich in der Lage, sicherheitskritische Softwareprobleme nicht nur zu erkennen, sondern auch praktisch auszunutzen.

Entscheidend ist jedoch, dass diese Fähigkeiten erst durch strukturierte Systeme, Tool-Nutzung und iterative Prozesse praktisch nutzbar werden.

Anthropic selbst spricht dabei von einem möglichen Wendepunkt („watershed moment“) für die Cybersicherheit.

Zwischen Automatisierung und Realität

Wichtig ist jedoch die Einordnung: Mythos ist (noch) kein magisches One-Click-Tool.

• Nicht jede gefundene Schwachstelle ist tatsächlich ausnutzbar
• False Positives kommen vor
• Exploits funktionieren nicht immer stabil oder reproduzierbar
• In vielen Fällen zeigt das System erfolgreiche Ergebnisse, aber nicht 100 %

Ein gefundener Bug ist nicht automatisch ein funktionierender Exploit.
Erst durch zusätzliche Schritte wie Informationsextraktion, Kontrolle des Programmflusses und Kombination mehrerer Schwachstellen entsteht ein tatsächlicher Angriff.

Das System arbeitet iterativ:

• Hypothesen werden gebildet
• getestet und angepasst
• Ergebnisse werden weiter verfeinert

Dabei nutzt Mythos sogenannte Scaffolds – strukturierte Umgebungen zur Problemlösung – und kombiniert eigene Analyse mit klassischen Tools wie Debuggern oder Disassemblern.

Im einfachsten Fall kann ein Benutzer eine Anfrage stellen wie:
„Finde Sicherheitsfehler in dieser Software.“

Unter der Oberfläche läuft jedoch ein komplexer, mehrstufiger Analyseprozess ab, der eher einem automatisierten Security-Research-Workflow entspricht als einem simplen Scan.

Die Tests fanden dabei ausschließlich in kontrollierten, isolierten Umgebungen statt:

• kein frei zugängliches System
• keine autonome Interaktion mit realen Zielsystemen

Alte Schwachstellen, neue Geschwindigkeit

In internen Tests identifizierte das Modell Sicherheitslücken in realer, produktiver Software – darunter Betriebssysteme, Browser und Anwendungen.

Dabei zeigt sich ein entscheidender Unterschied:

Nicht nur die Schwachstelle selbst wird gefunden, sondern auch der passende Angriffsvektor – also ein konkreter Exploit, der diese Lücke ausnutzt.

Konkrete Beispiele aus den Tests zeigen die Tragweite:

• Ein 27 Jahre alter Bug in OpenBSD konnte in Tests identifiziert und ausgenutzt werden
• Eine Remote Code Execution (RCE) im FreeBSD NFS-Server konnte in Tests entwickelt und demonstriert werden
• In Tests gelang es, vier Schwachstellen zu einer Browser-Angriffskette zu kombinieren
• In Tests konnten Sandbox Escapes aus Browser- und OS-Isolation demonstriert werden

Diese Beispiele zeigen: Es geht nicht nur um theoretische Schwächen, sondern um real funktionierende Angriffe.

In vielen Fällen reicht dafür bereits die Binärdatei. Der fehlende Sourcecode stellt kein grundsätzliches Hindernis dar, sondern wird durch Analyse und Rekonstruktion kompensiert.

Der kritische Punkt ist dabei nicht nur die Fähigkeit selbst, sondern die Geschwindigkeit:

Schwachstellen, die jahrelang unentdeckt bleiben, können potenziell in deutlich kürzerer Zeit identifiziert und analysiert werden – teilweise innerhalb von Stunden.

Das ist Fluch und Segen zugleich – und genau deshalb entsteht der Bedarf nach Kontrolle.

Project Glasswing: Absicherung vor dem Durchbruch

Aufgrund dieser Brisanz wird Mythos nicht frei zugänglich gemacht.

Anthropic nutzt das System stattdessen im Rahmen von Project Glasswing – einer Initiative mit einem klaren Ziel:
Kritische Software absichern, bevor solche KI-Systeme breit verfügbar werden.

Im Kern geht es nicht nur um klassische Schwachstellensuche, sondern um eine präventive Strategie:

• systematische Identifikation von Zero-Day-Schwachstellen in kritischer Infrastruktur
• gezielte Absicherung von Software, bevor Angreifer ähnliche Fähigkeiten einsetzen können
• Zusammenarbeit mit großen Technologie- und Infrastruktur-Anbietern

Gefundene Schwachstellen werden dabei verantwortungsvoll behandelt:

• kritische Funde werden durch Experten validiert
• betroffene Hersteller werden informiert
• Exploit-Details werden nicht öffentlich gemacht

Anthropic beschreibt Glasswing damit implizit als Vorbereitung auf eine neue Realität:
Eine Welt, in der KI-Modelle in der Lage sind, komplexe Angriffe in großem Maßstab zu entwickeln.

Ziel ist es, Verteidigern einen entscheidenden Zeitvorsprung zu verschaffen – bevor diese Fähigkeiten zum Standard werden.

Ein besonders kritischer Punkt:

Es waren nicht zwingend spezialisierte Security-Experten nötig.
Auch Personen ohne tiefen Security-Hintergrund konnten das System nutzen, um komplexe Schwachstellen zu finden und Exploits zu erzeugen.
In einzelnen Fällen wurde dem Modell eine Aufgabe über Nacht gestellt – am nächsten Morgen lag ein funktionierender Exploit vor.

Anthropic weist auch darauf hin:

• Weniger als 1 % der im Rahmen der Tests gefundenen Schwachstellen sind aktuell gepatcht.
• Ein Großteil der Ergebnisse bleibt daher bewusst unveröffentlicht

Warum Sicherheitslücken so gefährlich sind

Sicherheitslücken sind oft keine offensichtlichen Programmfehler.
Software kann lange fehlerfrei funktionieren – bis unerwartete Eingaben oder gezielte Angriffe kritische Schwächen offenlegen.

Beispielsweise kann ein Eingabefeld, das für kurze Texte gedacht ist, durch ungewöhnlich lange oder manipulierte Eingaben zu unerwartetem Verhalten führen – oder zu konkreten Angriffen.

Die Grundlage vieler Angriffe: Memory Corruption

Seit den Anfängen der Softwareentwicklung existiert ein grundlegendes Problem: Buffer Overflows.

Das Prinzip:

1. Ein Programm reserviert Speicher für Eingaben
2. Die Eingabe überschreitet diesen Speicherbereich
3. Benachbarter Speicher wird überschrieben
4. Programmabläufe werden manipuliert

Beispiel: Stack Overflow mit Adressen

Ein Programm reserviert auf dem Stack Speicher für einen Namen mit 4 Zeichen.

name[4]
Startadresse: 1000

Der Stack ist ein schneller temporärer LIFO (Last In, First Out) Speicher – das zuletzt gespeicherte Element wird zuerst wieder ausgelesen.

Die Speicheraufteilung könnte vereinfacht so aussehen:

1000 name[0]
1001 name[1]
1002 name[2]
1003 name[3]
1004 Rücksprungadresse Byte 1
1005 Rücksprungadresse Byte 2
1006 Rücksprungadresse Byte 3
1007 Rücksprungadresse Byte 4

Nun gibt der Benutzer mehr ein als vorgesehen:

„Otto Müller“

Ergebnis:

1000 O
1001 t
1002 t
1003 o
1004 _ ← Overflow beginnt
1005 M
1006 ü
1007 l

Ab dem fünften Zeichen wird bereits die Rücksprungadresse überschrieben.

Das Programm kehrt danach nicht mehr an die ursprüngliche Stelle zurück, sondern springt an eine manipulierte Adresse.

Das ist die Grundlage vieler Angriffe:
Inputs verändern den Kontrollfluss eines Programms.

Moderne Systeme sind besser geschützt – aber nicht sicher

Heute existieren zahlreiche Schutzmechanismen:

• NX (No Execute) verhindert das Ausführen von Daten als Code
• ASLR randomisiert Speicheradressen und schützt vor gezielten Speichermanipulationen
• Stack Canaries erkennen Buffer Overflows durch Sicherheitskennungen
• Control Flow Integrity (CFI) begrenzt unerlaubte Sprünge

Diese Maßnahmen erschweren Angriffe erheblich – verhindern sie aber nicht vollständig.

Zudem sind nicht alle dieser Maßnahmen für sämtliche Systeme und Programmiersprachen verfügbar. Insbesondere ältere Programme wurden häufig in systemnahen Programmiersprachen entwickelt, die über keine expliziten Schutzmechanismen verfügten.

Warum Exploits heute komplex sind

Moderne Exploits bauen auf genau solchen Fehlern auf, sind aber deutlich komplexer geworden.

Angriffe bestehen heute aus mehreren kombinierten Schritten:

1. Speicherfehler (z. B. Buffer Overflow)
2. Informationsgewinn (Info Leak) oder Brute-Force Adressierung zur Umgehung von ASLR
3. Code-Wiederverwendung (ROP – Return-Oriented Programming)

Anstatt eigenen Code einzuschleusen, nutzen Angreifer vorhandene Codefragmente (sogenannte „Gadgets“), die gezielt kombiniert werden.

So entsteht eine komplexe Angriffskette aus mehreren voneinander abhängigen Schritten.

Mythos macht genau das skalierbar

Hier liegt der eigentliche Durchbruch:

Nicht das Finden einzelner Bugs ist neu – sondern die Fähigkeit, daraus funktionierende Angriffsketten zu bauen.

Das Modell kann:

• Speicherstrukturen analysieren
• Offsets berechnen
• geeignete Gadgets identifizieren
• mehrere Schwachstellen zu vollständigen Exploits kombinieren

Die resultierenden Angriffe umfassen:

• Privilege Escalation (User → Admin/Root)
• Remote Code Execution (RCE)
• Sandbox Escapes

Und besonders kritisch:

Die Kombination mehrerer Schwachstellen zu vollständigen End-to-End-Angriffen.

Auch Logikfehler – nicht nur klassische Memory Corruption – können dabei eine Rolle spielen.

Für menschliche Analysten ist dieser Prozess aufwendig und zeitintensiv.
Ein Modell wie Mythos kann ihn systematisch automatisieren und massiv skalieren.

Besonders gefährdet: Embedded Systeme

Ein oft unterschätztes Risiko sind sogenannte Embedded Devices:

• Router, Firewalls und VPN-Gateways
• IoT-Geräte wie Kameras, Thermostate oder Sprachassistenten
• Industrie- und Steuerungssysteme (SPS)
• Bürogeräte wie Drucker oder NAS-Systeme

Diese Systeme haben häufig mehrere Probleme:

• Einsatz hardwarenaher, speicherunsicherer Sprachen
• fehlende oder schwache Schutzmechanismen
• seltene oder gar keine Updates
• direkte Anbindung ans Internet

Gerade hier können automatisierte Schwachstellenanalysen und Exploit-Generierung ein besonders hohes Risiko darstellen.

Das eigentliche Risiko: Zeit

Der entscheidende Faktor ist das sogenannte Window of Exposure – die Zeit zwischen:

• Entdeckung einer Schwachstelle
• ihrer tatsächlichen Ausnutzung

Mit KI verschiebt sich dieses Gleichgewicht:

• Früher: Wochen oder Monate
• Heute: potenziell Stunden oder Tage

Während Angreifer schneller werden, bleibt die Verteidigung weiterhin angewiesen auf:

• Entwicklung von Patches
• Tests
• Rollout-Prozesse

Der Engpass verschiebt sich damit von der Entdeckung zur Reaktion.

Fazit

Sicherheitslücken sind nicht verschwunden – sie sind komplexer geworden.

Ein moderner Exploit ist kein einzelner „Trick“, sondern ein präzise konstruiertes System aus:

• Speicherfehlern
• Informationsgewinn
• kontrollierter Code-Wiederverwendung

Mit Systemen wie Mythos wird dieser Prozess erstmals skalierbar.

Das macht sie gleichzeitig zu einem der gefährlichsten – und wertvollsten – Werkzeuge in der Cybersicherheit.

https://red.anthropic.com/2026/mythos-preview/
https://www.anthropic.com/glasswing

KI ist damit nicht nur ein Beratungstool, sondern entwickelt sich zunehmend zu einem wirtschaftlichen Hebel für moderne Beauty-Unternehmen.

Visuelle Sicherheit als Schlüssel zur Entscheidung

Kund:innen haben häufig Bedenken: Wie sehen sie nach einer Behandlung tatsächlich aus? Gerade im Beauty-Bereich sind Ergebnisse oft schwer oder gar nicht zu korrigieren.

Die persönliche Beratung bleibt zwar der wichtigste Faktor – doch Geschmäcker sind unterschiedlich, und Vorstellungskraft ist begrenzt. Eine realistische visuelle Vorschau des erwarteten Ergebnisses wird daher zu einem entscheidenden Element im Entscheidungsprozess.

Typische Einsatzfelder sind:

• Friseur: Hairstyle, Colorierung, Haaranalyse
• Kosmetik: Make-up Vorschau, Altersveränderung, Beautifying, Hautanalyse
• Nail Design: visuelle Vorschau

Einsatzbereiche von KI im Detail

Colorierung

Die meisten Friseure arbeiten noch mit klassischen Farbkarten – Bücher mit eingefärbten synthetischen Haarsträhnen. Es erfordert viel Vorstellungskraft, sich das Ergebnis auf dem eigenen Kopf vorzustellen.

Mit KI lässt sich die Haarfarbe direkt auf dem eigenen Bild simulieren. Kund:innen sehen sofort:

• wie die Farbe auf ihren Haaren wirkt
• wie sie mit dem Hautton harmoniert

Moderne Systeme berücksichtigen dabei:

• die aktuelle Haarfarbe
• Haarstruktur
• Ergebnisse aus der Haaranalyse

Das Ergebnis ist eine deutlich höhere Entscheidungssicherheit.

Vorschau Hair Design

Auch bei der Wahl einer neuen Frisur fällt es vielen schwer, sich das Ergebnis vorzustellen.

Frühere digitale Lösungen arbeiteten mit statischen Bildern, die manuell angepasst werden mussten. Die Ergebnisse waren oft ungenau und unnatürlich.

Moderne KI-Systeme gehen deutlich weiter:

• Analyse der Kopfform
• realistische Simulation der Haartextur
• präzise Anpassung an das Gesicht

Dadurch lassen sich heute auch komplexe Veränderungen darstellen, wie:

• sehr kurze Haare oder Glatze
• komplette Stilwechsel

Dieses Prinzip funktioniert auch für Bartstyles bei Männern.

Haaranalyse

KI ermöglicht eine präzise Analyse der Haare.

Dazu werden Haarsträhnen – oft mittels Mikroskop – erfasst und von der KI ausgewertet. So lassen sich:

• Haarstruktur
• Zustand
• Schäden

analysieren und bewerten.

Die Beratung wird dadurch objektiver und datenbasiert.

Alter verändern

Eine interessante Anwendung ist die Simulation von Altersveränderungen.

Kund:innen können sehen:

• wie sie in 10 Jahren aussehen könnten
• wie sie früher ausgesehen hätten

Das kann insbesondere bei der Style- und Typberatung hilfreich sein und eröffnet neue Perspektiven in der Beratung.

Style Transfer

Viele Kund:innen orientieren sich an Vorbildern – etwa Prominenten.

Mit KI lassen sich:

• Frisuren
• Haarfarben
• Make-up Styles

von einer Person auf eine andere übertragen.

Dadurch wird aus einer vagen Vorstellung eine konkrete Visualisierung.

Beautifier

KI kann Portraits gezielt „verschönern“.

Dabei werden:

• Unebenheiten reduziert
• Haut optimiert
• kleinere Korrekturen vorgenommen

Auf Wunsch sind auch stärkere Veränderungen möglich.

Neben der Anwendung für Profilbilder kann dies auch als Grundlage für individuelle Styling-Empfehlungen dienen.

Visuelles Make-up

Mit KI können Kund:innen verschiedene Make-up-Stile direkt an sich selbst ausprobieren.

Das ermöglicht:

• schnelle Vergleiche unterschiedlicher Looks
• bessere Entscheidungsgrundlagen

Eine ideale Ergänzung zur klassischen Typberatung.

Hautanalyse

Auch die Hautanalyse lässt sich durch KI deutlich verbessern.

Auf Basis hochauflösender Bilder erkennt die KI:

• Hautprobleme
• Hauttyp
• Auffälligkeiten

Zusätzlich können passende kosmetische Produkte vorgeschlagen werden.

Die Beratung wird präziser und stärker personalisiert.

Virtual Try-On

Die zugrunde liegenden Technologien lassen sich auch über den klassischen Beauty-Bereich hinaus einsetzen.

Typische Anwendungen sind:

• Brillen
• Mode
• Nail Design

Virtual Try-On entwickelt sich zu einem universellen Werkzeug im Retail.

Smart Mirrors

Ein wichtiger Schritt ist die Integration der Technologie in den Salon-Alltag.

Smart Mirrors sind Spiegel mit integrierter Kamera und Display. Sie ermöglichen es, KI-Anwendungen direkt am Platz zu nutzen.

Kund:innen können die Ergebnisse unmittelbar im Spiegel sehen – ohne zwischen Geräten wechseln zu müssen.

Das sorgt für ein besonders immersives und hochwertiges Beratungserlebnis.

KI in der Kundenbetreuung

Auch die Kommunikation mit Kund:innen lässt sich durch KI optimieren.

Typische Anwendungen sind:

• telefonische Kundenannahme
• automatisierte Beratung
• intelligente Terminverwaltung

Das ermöglicht eine bessere Erreichbarkeit und entlastet das Personal.

KI im Salonmanagement

Neben der Kundeninteraktion bietet KI großes Potenzial im operativen Betrieb.

Viele zeitaufwändige Aufgaben lassen sich automatisieren:

• Terminverwaltung
• Lagerverwaltung
• Warenbestellung
• Kundenakquise
• Marketing
• Rechnungserstellung

Prozesse werden effizienter, Fehler reduziert und Ressourcen besser genutzt.

Monetarisierung: Wie KI Umsatz steigert

Der Einsatz von KI hat direkte wirtschaftliche Effekte.

1. Höhere Abschlussquoten
Kund:innen treffen schneller Entscheidungen, wenn sie das Ergebnis sehen können.

2. Upselling und Cross-Selling
Zusätzliche Leistungen und Produkte lassen sich leichter verkaufen, wenn sie visuell dargestellt werden.

3. Höherer Warenkorbwert
Durch personalisierte Empfehlungen steigt der durchschnittliche Umsatz pro Kund:in.

4. Premium-Positionierung
Salons können KI als innovatives Feature vermarkten und höhere Preise durchsetzen.

Integration: Erfolgsfaktor für den praktischen Einsatz

Damit KI ihr volles Potenzial entfalten kann, muss sie in bestehende Systeme integriert werden:

• Buchungssysteme (Terminplanung, Auslastung)
• CRM-Systeme (Kundendaten, Präferenzen)
• Kassensysteme (Produktverkauf)
• Marketing-Tools (personalisierte Kampagnen)

Erst durch diese Vernetzung entsteht ein durchgängiges, effizientes System.

Wettbewerbsvorteil: Der KI-gestützte Salon

Der Einsatz von KI bietet klare strategische Vorteile:

• Differenzierung gegenüber Mitbewerbern
• modernes, innovatives Markenimage
• bessere Kundenerlebnisse
• standardisierte, skalierbare Beratung

Besonders für wachsende Unternehmen und Ketten ist dies ein entscheidender Faktor.

Trends: Die Zukunft von KI im Beauty-Bereich

Die Entwicklung zeigt klar in Richtung:

Hyper-Personalisierung
Individuelle Empfehlungen auf Basis von Daten und Verhalten

Generative KI
Komplette Style-Konzepte statt einzelner Elemente

Omnichannel-Erlebnisse
Verknüpfung von Online-Try-On und Salonbesuch

Neue Hardware
Smart Mirrors, mobile Anwendungen und perspektivisch AR-Brillen

Fazit

Wer seinen Kund:innen visuelle Sicherheit, intelligente Beratung und ein optimiertes Salonmanagement bieten möchte, findet in KI ein leistungsstarkes Werkzeug.

Die Kombination aus:

• besserer Entscheidungsfindung
• effizienteren Prozessen
• neuen Umsatzpotenzialen

macht KI zu einem zentralen Baustein für die Zukunft der Beauty-Branche.

Die zentrale Frage hinter dem Projekt war simpel – und gleichzeitig überraschend unbeantwortet:
Warum existiert noch kein wirklich persönlicher AI-Assistent, der komplett lokal läuft?

Die technologischen Bausteine sind längst vorhanden. Also entstand aus dieser Frage ein Experiment – und daraus wiederum ein funktionierendes System: AIBoxly („Boxly“).

Architektur: Klar, modular und lokal

Der Aufbau folgt einem bewusst einfachen, aber leistungsfähigen Prinzip:

Wakeword → Spracheingabe → Sprachmodell → Reasoning → Tools → Sprachausgabe

Das Besondere dabei:

• Keine Cloud-Abhängigkeit
• Keine externen APIs
• Volle Kontrolle über Daten und Prozesse

Das System verarbeitet Spracheingaben, interpretiert sie kontextuell, entscheidet eigenständig über notwendige Aktionen (Tool Calling) und liefert direkt eine sprachbasierte Antwort zurück.

Funktionalität: Mehr als nur ein Voice Assistant

Boxly ist kein klassischer Sprachassistent, sondern eher eine lokale AI-Orchestrierungsplattform.

• Über 100 Skills lassen sich flexibel definieren und erweitern
• Kombination aus LLM + Reasoning + Tool Execution
• Unterstützung für natürliche Konversation statt starrer Befehle

Bemerkenswert ist die Robustheit der Spracherkennung:

• Funktioniert auch auf Distanz
• Kommt mit undeutlicher Aussprache klar
• Verarbeitet sogar Dialekte zuverlässig

Performance auf Consumer-Hardware

Ein entscheidender Punkt aus Business-Sicht: Effizienz auf begrenzter Hardware

Das gesamte System läuft auf:

• RTX 3060
• 8 GB VRAM

Dabei erreicht Boxly:

• < 1 Sekunde Reaktionszeit (einfachere Anfragen)
• bis ca. 3 Sekunden End-to-End (komplexere Tasks)

Und das trotz vollständiger lokaler Verarbeitung inklusive:

• Speech-to-Text
• LLM-Inferenz
• Reasoning
• Tool-Ausführung
• Text-to-Speech
• optionaler 3D-Visualisierung

Herausforderungen: Wo es wirklich komplex wird

1. Tool Calling

Die größte technische Hürde ist nicht das Modell selbst, sondern die Orchestrierung:

• Wann wird welches Tool genutzt?
• Wie bleibt die Entscheidung konsistent bei vielen Skills?

Mit wachsender Anzahl an Funktionen steigt die Komplexität exponentiell.

2. Hardware-Limits

Lokale AI bedeutet immer Trade-offs:

• Speichergrenzen
• Latenz vs. Modellgröße
• Parallelisierung von Komponenten

Das Ziel: maximale Performance bei minimaler Infrastruktur.

Fazit: Lokale AI ist kein Zukunftsthema mehr

Das Ergebnis ist klar:
Ein vollständig lokaler, persönlicher KI-Assistent funktioniert – und zwar überraschend gut.

Noch nicht perfekt, noch nicht vollständig stabil – aber ein entscheidender Schritt in eine neue Richtung:

Weg von Cloud-Abhängigkeiten
Hin zu echter, persönlicher AI direkt auf eigener Hardware

Für AI-Business-Kontexte eröffnet das spannende Perspektiven:

• Datenschutzfreundliche AI-Lösungen
• Edge-AI für Unternehmen
• Individuelle Assistenzsysteme ohne Vendor Lock-in

Die Frage ist nicht mehr, ob das funktioniert – sondern, wie schnell sich solche Systeme durchsetzen werden.

Dies ist Teil 7 der Kursserie „ChatGPT & Co verstehen: Wie große Sprachmodelle wirklich arbeiten – anschaulich & interaktiv“.

Dem Self-Attention-Mechanismus unter die Haube geschaut!

Das Ziel von Self-Attention ist es, die wechselseitigen Abhängigkeiten zwischen Tokens im Satzkontext zu erkennen und zu gewichten.

Für jedes einzelne Token wird dabei ein neues kontextangepasstes Embedding berechnet – also ein neuer Merkmalsvektor, der die gewichteten Informationen aller Tokens bis zum aktuellen Token im Satz berücksichtigt.
So entsteht für jedes Token eine neue Repräsentation, die seine Bedeutung im Kontext der anderen Tokens widerspiegelt.

Jedes Token startet mit einem eigenen Embedding aus der Roh-Embedding-Lookup-Tabelle – sie wird während des Trainings gelernt und bleibt bei der Inferenz unverändert. So kann etwa „zwei“ als Zahl, „schwarze“ als Farbe und „Katzen“ als Tier dargestellt werden.
Durch den Transformer-Mechanismus werden diese Informationen gemeinsam verarbeitet. Dadurch erhält das Token „Katzen“ ein neues, kontextangepasstes Embedding, das die Bedeutung des gesamten Satzes widerspiegelt – das Bild zweier schwarzer Katzen. (Reale Embeddings sind natürlich latent, wie wir bereits gesehen haben.)

Ein Transformer führt eine große Menge an Berechnungen durch – und das gleichzeitig für viele Tokens.
Um all diese Berechnungen – von den Q/K/V-Transformationen bis zur Gewichtung der Kontextinformationen – effizient durchzuführen, braucht es ein Werkzeug, das viele Operationen parallel und blitzschnell ausführen kann.

➔ Hier kommen Matrizen ins Spiel …

Mathe? Keine Sorge!

Um Self-Attention richtig zu verstehen, brauchen wir etwas Mathe – aber keine Angst, das ist handlich und intuitiv.

[0.3, -1.2, 4.7, ...]

[ 1  2  3 ]
[ 4  5  6 ]
[ 7  8  9 ]

Warum Matrizen?

Die bahnbrechende Publikation von Vaswani et al. („Attention is All You Need“) hat nicht nur eine revolutionäre Architektur vorgestellt, sondern sie auch vollständig auf Matrizenoperationen aufgebaut.
Dieser Ansatz bildet bis heute das Herzstück moderner Transformer-Modelle – darunter GPT, Claude, Gemini, Granite und viele andere.
Die Rechenstruktur wurde seitdem nur leicht optimiert, die Grundidee ist aber nahezu unverändert übernommen worden.

Warum Matrizen so mächtig sind

Matrizen haben zwei entscheidende Vorteile:

1. Sie ermöglichen es, Millionen mathematische Operationen in einem Schritt durchzuführen – dank hochoptimierter Matrixmultiplikation.
2. Sie lassen sich hervorragend auf GPUs parallelisieren – was sie ultra schnell macht.

Matrizen werden schon seit Jahrzehnten in der Computergrafik eingesetzt – besonders in einem Bereich, den fast jeder kennt: 3D-Spiele.
In den letzten Jahren ist die Qualität und der Realismus in Games regelrecht explodiert.
Hauptgrund dafür: Grafikkarten (GPUs) wurden immer leistungsfähiger und können Millionen von Vektor- und Matrizenberechnungen pro Sekunde durchführen.

Man könnte sagen: Power-Gamer haben den Weg bereitet, damit heutige Computer zu echten Matrizenspezialisten geworden sind – eine Entwicklung, von der KI-Modelle heute massiv profitieren.

Erlebe Matrizen in Aktion!

In dieser 3D-Szene siehst du ein Raumschiff als anschauliches Beispiel.

Eine Matrix genügt
Anstatt jeden Rechenschritt – wie Verschiebung, Rotation (um X-, Y- und Z-Achse), Skalierung usw. – einzeln auszuführen, wird das gesamte Modell inklusive Umgebung mit einer einzigen sogenannten Model-View-Projection-Matrix (MVP) transformiert.

Verschiedene Blickwinkel
Du kannst das Raumschiff dabei aus unterschiedlichen Perspektiven betrachten – ähnlich wie wir das später bei Transformationen der Embeddings machen, um Informationen gezielt aus verschiedenen Blickwinkeln zu erfassen.

Probiere es aus: Du kannst dich mit der Maus oder Touch in der Szene frei bewegen!

• linke Maustaste: drehen,
• rechte Maustaste: verschieben,
• Scrollrad: zoomen.

Drei verschiedene Ansichten von jedem Token

Jedes Token liegt ursprünglich als Embedding-Vektor vor – ein Vektor mit z. B. 12.288 Zahlen, die seine Bedeutung in einem hochdimensionalen Raum abbilden.

Aus diesem Embedding-Vektor werden durch Projektion drei neue Vektoren gebildet, die im Attention-Mechanismus unterschiedliche Funktionen erfüllen:

• Query (Q) Vektor – der mit den Keys der anderen Tokens auf Ähnlichkeit geprüft wird
• Key (K) Vektor – der als Grundlage für diesen Vergleich dient
• Value (V) Vektor – dessen Inhalte – je nach Relevanz – in die neue Darstellung des Tokens einfließen

„Im Bild sehen wir einen einzelnen Token Vektor mit 4 Merkmalen, der auf 3 Dimensionen projiziert wurde – in realen Modellen wie GPT‑3.5 bestehen solche Vektoren tatsächlich aus über 12.288 Dimensionen.“

Die Transformation erfolgt durch drei verschiedene – beim Training mit Milliarden Wörtern erlernte – Gewichtsmatrizen:
Eine für Query, eine für Key, eine für Value.

\vec{v} \cdot W =
\begin{bmatrix}
\color{blue}{2} & \color{red}{3} & \color{green}{1} & \color{orange}{1}
\end{bmatrix}
\cdot
\begin{bmatrix}
\color{blue}{1} & \color{blue}{0} & \color{blue}{2} \\
\color{red}{2} & \color{red}{1} & \color{red}{1} \\
\color{green}{0} & \color{green}{1} & \color{green}{0} \\
\color{orange}{1} & \color{orange}{0} & \color{orange}{1}
\end{bmatrix}
=
\begin{bmatrix}
\color{blue}{9} & \color{red}{4} & \color{green}{8}
\end{bmatrix}

\begin{aligned}
\color{blue}{2} \cdot \color{blue}{1} + \color{red}{3} \cdot \color{red}{2} + \color{green}{1} \cdot \color{green}{0} + \color{orange}{1} \cdot \color{orange}{1} &= 2 + 6 + 0 + 1 = \color{blue}{9} \\
\color{blue}{2} \cdot \color{blue}{0} + \color{red}{3} \cdot \color{red}{1} + \color{green}{1} \cdot \color{green}{1} + \color{orange}{1} \cdot \color{orange}{0} &= 0 + 3 + 1 + 0 = \color{red}{4} \\
\color{blue}{2} \cdot \color{blue}{2} + \color{red}{3} \cdot \color{red}{1} + \color{green}{1} \cdot \color{green}{0} + \color{orange}{1} \cdot \color{orange}{1} &= 4 + 3 + 0 + 1 = \color{green}{8}
\end{aligned}

Für jedes Token wird das ursprüngliche Embedding x_i mit den drei Gewichtsmatrizen
W_Q, W_K und W_V multipliziert, um die drei Vektoren Query (Q), Key (K) und Value (V) zu erzeugen.
Diese bilden die Grundlage für den Self-Attention-Mechanismus – vollständig auf Matrizenoperationen basierend und dadurch sehr effizient.

In der Praxis kommt ein weiterer Vorteil hinzu: Alle Tokens der Eingabesequenz X werden parallel verarbeitet – über eine einzige Matrixmultiplikation, bei der jede Zeile einem Token entspricht.

\begin{aligned}
\mathbf{Q} &= \mathbf{X} \cdot \mathbf{W}^Q \\
\mathbf{K} &= \mathbf{X} \cdot \mathbf{W}^K \\
\mathbf{V} &= \mathbf{X} \cdot \mathbf{W}^V
\end{aligned}

Die Gewichtsmatrizen haben so viele Zeilen wie das Embedding Dimensionen besitzt (z. B. 12.288) und so viele Spalten wie die gewünschte Zieldimension vorgibt (z. B. 128).

Das Embedding wird mit jeder Spalte der Gewichtsmatrix elementweise multipliziert und die Produkte addiert:

• Die erste Spalte liefert das erste neue Merkmal,
• die zweite Spalte das zweite neue Merkmal,
• und so weiter …

Jedes dieser neuen Merkmale entsteht durch eine lineare Projektion der ursprünglichen Merkmale – einige werden dabei verstärkt, andere abgeschwächt, manche vollständig ausgeblendet oder sogar umgekehrt (negiert).

Auf diese Weise entsteht aus dem ursprünglichen Merkmalsvektor eine neue Repräsentation in einem kompakteren, reduzierten Merkmalsraum – zum Beispiel von 12.288 auf 128 Merkmale.

Wichtig nochmals zu erwähnen!

• Alle Tokens verwenden dieselben Q-, K- und V-Matrizen pro Attention-Head.
  Es gibt also keine token-spezifischen Gewichtungen, sondern eine einheitliche Transformation für alle Eingaben – das sorgt für maximale Effizienz und Generalisierung.
• Die Q-, K- und V-Matrizen sind unabhängig voneinander.
  Sie lassen sich nicht voneinander ableiten oder direkt in Beziehung setzen – jede von ihnen hat eigene Parameter, die ausschließlich durch das Training gelernt wurden.
• Mit einer solchen Q/K/V-Projektion kann das Modell jeweils nur eine bestimmte Art semantischer Beziehung zwischen Tokens erfassen.
  Ein einzelner Attention-Head bildet dabei typischerweise genau eine Perspektive ab – z. B. „welches Subjekt gehört zu welchem Verb?“.
• In einem vollständigen Transformer-Modell arbeiten jedoch mehrere Heads gleichzeitig und in mehreren gestapelten Layern.
  So entstehen tausende Projektionen, die gemeinsam eine Vielzahl semantischer Muster und Abhängigkeiten erfassen – vom Satzbau bis zur Bedeutung über ganze Absätze hinweg – mehr dazu in einem späteren Abschnitt.

Warum wird die Dimension reduziert?

• Die Reduktion spart Rechenzeit und Speicher – besonders bei großer Kontextgröße,
  da die Berechnungen im Attention-Mechanismus quadratisch mit der Anzahl der Tokens zunehmen.
• Sie erlaubt es dem Modell, die Informationen in einer kompakteren Form darzustellen –
  jeder sogenannte Attention-Kopf arbeitet dadurch mit einer eigenen Projektion, die bestimmte Aspekte der ursprünglichen Merkmale hervorheben kann.
• Der Transformer verwendet mehrere solcher Attention-Köpfe.
  Damit jeder Kopf effizient arbeiten kann, wird die ursprüngliche Embedding-Dimension aufgeteilt – z. B. bei 96 Köpfen: 12.288 / 96 = 128 Dimensionen pro Kopf.

In dieser interaktiven Demo wird das Prinzip anschaulich visualisiert

Wie entstehen diese Q,K,V Matrizen?

Die Q-, K- und V-Matrizen werden durch Training mit riesigen Textmengen gelernt – meist Milliarden von Wörtern.
Das Trainingsziel ist immer die Vorhersage des nächsten Tokens
-> Fehlerhafte Vorhersagen führen zu Rückmeldungen über Backpropagation.

Dadurch lernen die Matrizen:

• Query- und Key-Vektoren so anzupassen, dass relevante Tokens hohe Ähnlichkeit zueinander aufweisen
• Value-Vektoren so zu gestalten, dass nur kontextrelevante Informationen weitergegeben werden

So erkennt der Transformer, welche Tokens relevant füreinander sind

Im Kapitel über Embeddings haben wir bereits gesehen, dass semantisch ähnliche Tokens im Merkmalsraum näher beieinander liegen.

Die Nähe zweier Vektoren wird entweder über ihren Abstand oder den Winkel zwischen ihnen gemessen – bei manchen Verfahren spielt auch ihre Länge eine Rolle.

Bei Transformern spielt vor allem der Winkel zwischen den Vektoren eine zentrale Rolle – nicht ihr euklidischer Abstand.

Zur Erinnerung: Es gibt zwei gängige Verfahren, um Ähnlichkeit über Winkel zu messen:

Skalares Produkt (Dot-Produkt)
Hier werden die entsprechenden Komponenten zweier Vektoren multipliziert und anschließend aufsummiert.
Das Ergebnis ist ein einzelner Wert, der die semantische Ähnlichkeit ausdrückt:

• nahe 0 → kaum Ähnlichkeit
• positiv → semantisch ähnlich
• negativ → eher gegensätzlich

\mathbf{x} \cdot \mathbf{y} = \sum_{i=1}^{n} x_i , y_i

Kosinus-Ähnlichkeit
Die Kosinus-Ähnlichkeit ist ein normalisiertes Skalarprodukt.
Sie berücksichtigt nur den Winkel zwischen den Vektoren – unabhängig von ihrer Länge.
Das Ergebnis liegt immer zwischen –1 und 1.

 cos(\theta) = \frac{ \vec{A} \cdot \vec{B} }{ | \vec{A} | \cdot | \vec{B} | }

Attention Attention!

Bei Transformern ist entscheidend, welche Tokens Einfluss aufeinander ausüben.
Genauer: Für jedes einzelne Token zählt, wie relevant die anderen Tokens für es sind – also welche Informationen sie beisteuern können, die zu seiner Repräsentation im Kontext beitragen.

Um diese Relevanz zu berechnen, haben wir die Tokens bereits mithilfe der Gewichtsmatrizen unterschiedlich projiziert:
Einmal als Query-Vektor und einmal als Key-/Value-Vektoren.
Je besser die Query eines Tokens zu den Keys der anderen passt, desto mehr Value wird von diesen Tokens übernommen.

Attention Score

Die Berechnung der Aufmerksamkeit zwischen Tokens bezeichnet man als Attention Score.
Dabei geht es nicht um einen klassischen geometrischen Abstand, sondern um ein Maß für ihre Nähe im Merkmalsraum – zum Beispiel über die Kosinus-Ähnlichkeit.

Vaswani et al. entschieden sich für die pragmatische Lösung, die besonders effizient ist:
Statt die aufwändige Kosinus-Ähnlichkeit mit zusätzlicher Normierung zu berechnen,
verwenden sie direkt das Skalarprodukt (Dot-Produkt):

\text{score} = \mathbf{q} \cdot \mathbf{k}^\top

Das Dot-Produkt hat noch einen weiteren Vorteil:
Beim Dot-Produkt tragen sowohl der Winkel zwischen den Vektoren als auch ihre Länge zum Ergebnis bei.
Damit hat das Modell die Freiheit, sowohl die Richtung (semantische Nähe) als auch die Stärke einzelner Merkmale (Vektorlängen) zu berücksichtigen.

Allerdings ergibt sich nun ein kleines Problem:
Skalarprodukte in hochdimensionalen Räumen können sehr große Werte annehmen.
Das erschwert die spätere Gewichtung, weil einzelne Tokens dadurch übermäßig stark hervorgehoben werden, während andere kaum noch berücksichtigt würden.

Die Lösung ist einfach und effizient:
Man teilt das Ergebnis durch die Wurzel der Dimensionalität des Key-Vektors (√dk).
So bleiben die Scores stabil und vergleichbar:

\text{score} = \frac{\mathbf{q} \cdot \mathbf{k}^\top}{\sqrt{d_k}}

Token-Relevanz: Probiere aus, wie sich Winkel und Dimensionen auf Cosine Similarity und Dot-Produkt auswirken

Was bedeutet das T bei den Keys?
Das ‚T‘ steht für Transponieren: Es macht aus dem Key-Zeilenvektor einen Spaltenvektor, sodass das Skalarprodukt mit dem Query-Zeilenvektor berechnet werden kann.

Die Attention Score Matrix

Jetzt berechnen wir diese Scores für alle möglichen Kombinationen von Tokens im Satzkontext.
Dazu erstellen wir eine Tabelle: Alle Tokens stehen sowohl in den Zeilen (als Query) als auch in den Spalten (als Key).
An jedem Schnittpunkt wird das Skalarprodukt zwischen Query- und Key-Vektor berechnet – das ergibt den Attention Score.

So entsteht eine vollständige Attention-Matrix, die zeigt, wie stark jedes Token auf alle anderen achtet.
(In dieser Attention-Matrix treten nur positive Scores auf, obwohl negative ebenfalls möglich wären.)

Maskierung aktivieren

Die Attention-Score-Matrix ist konzeptionell von Größe n × n. Der Rechenaufwand wächst damit quadratisch mit der Länge des Kontextfensters, und bei „naiver“ Implementierung gilt dies auch für den Speicherbedarf.

Bei mehreren tausend Tokens steigen die benötigten Ressourcen entsprechend stark an und stellen heutige Hardware schnell vor praktische Grenzen. Ohne spezielle Optimierungen lassen sich in der Praxis meist nur einige Tausend Tokens effizient verarbeiten.
Sehr große Kontextfenster im Bereich von 100.000 Tokens und mehr sind technisch möglich, erfordern jedoch optimierte Verfahren wie FlashAttention sowie teilweise zusätzliche strukturelle Ansätze wie Sparse Attention oder Segmentierung.
Ein weiterer limitierender Faktor ist die Attention selbst – bei sehr langen Kontexten kann sich der Fokus so stark verteilen, dass wichtige Stellen an Gewicht verlieren.

\text{score} = \frac{\mathbf{Q} \cdot \mathbf{K}^\top}{\sqrt{d_k}}

Jetzt zählen die wahren Werte!

Im nächsten Schritt kommen endlich die Value-Vektoren ins Spiel.
Jetzt entscheidet sich, welche Informationen aus dem Kontext auf welches Token übertragen werden.

Doch bevor wir loslegen, müssen wir noch ein Problem lösen …

Bitte nicht schummeln …

Wenn wir für jedes Token alle Attention Scores im Satz berücksichtigen, könnte das Modell auch auf Tokens zugreifen, die erst später folgen – und damit Informationen nutzen, die es zu diesem Zeitpunkt eigentlich noch gar nicht kennen dürfte.

Das widerspricht der Idee eines autoregressiven Decoders, der bei der Vorhersage ausschließlich auf frühere Tokens zugreifen darf.

Die Attention-Maske

Wie verhindern wir diese Schummelei?

Mit einem einfachen Trick: Wir verwenden eine Maske.
Dabei werden alle Scores, die sich auf zukünftige Tokens beziehen, ausgeblendet – oder etwas technischer:
Sie werden durch −∞ (oder eine sehr große negative Zahl) ersetzt, damit diese Positionen bei der Berechnung komplett ausgeschlossen werden.

Wird anschließend die Gewichtung (Softmax) angewendet, werden diese Positionen automatisch auf null gesetzt – und damit vollständig ignoriert.

Probiere es selbst in der Attention-Demo: Aktiviere die Maskierung – und beobachte, wie das Modell nicht mehr auf spätere Tokens zugreifen kann.

Welches Token trägt wie viel bei?

Mit der Attention-Matrix wissen wir nun, welche Tokens einander Aufmerksamkeit schenken. Doch wie genau beeinflussen diese Scores, welche Merkmale ein Token von anderen übernimmt?

Die zentrale Idee: Tokens erhalten im Kontext nicht nur Aufmerksamkeit, sondern übernehmen auch Merkmale – und zwar aus den Value-Vektoren der Tokens, auf die sie sich fokussieren.

Das Team um Vaswani hat dafür einen eleganten Mechanismus entwickelt:
Man geht zeilenweise durch die Attention-Matrix – also Token für Token – und berechnet für jedes Ziel-Token, welche anderen Tokens in der Zeile wie stark beitragen.

Allerdings: Die rohen Attention-Scores sind noch nicht direkt geeignet zum Rechnen – sie sind nicht skaliert, nicht normiert, und schwer vergleichbar.
Deshalb brauchen wir eine Funktion, die Ordnung in diese Werte bringt mit denen wir zuverlässig gewichten können.

Die Rolle der Softmax-Funktion

Hier kommt die Softmax-Funktion ins Spiel.
Sie ist eine mathematische Methode, mit der sich eine Liste von Zahlen in relative Gewichtungen umrechnen lässt.

Dabei wird jeder Wert zunächst durch die Exponentialfunktion verstärkt und anschließend so normalisiert, dass alle Ergebnisse zwischen 0 und 1 liegen und ihre Summe genau 1 ergibt.

So entstehen proportionale Gewichtungen: Größere Eingabewerte erhalten mehr Gewicht, kleinere weniger – so wird die Auswahl gezielt auf die relevantesten Tokens gelenkt.

Die Softmax-Funktion liefert uns damit für jedes Token in einer Attention-Zeile genau den Multiplikator, mit dem sein Value-Vektor gewichtet in das Ziel-Token einfließt.

Die Softmax-Werte einer Zeile ergeben immer genau 1 – das garantiert, dass die resultierende Kombination der Value-Vektoren stabil und ausgewogen ist.

\text{Softmax}(z_i) = \frac{e^{zi}}{\sum{j=1}^{n} e^{z_j}}

Probiere aus, wie sich die Softmax-Gewichtungen verändern, wenn du die Score-Werte anpasst:

Das neue Embedding entsteht

Jetzt haben wir alles beisammen:

• Die Attention-Matrix zeigt, wie stark ein Token auf andere achtet.
• Die Softmax-Funktion wandelt diese Werte in Gewichtungen um.
• Die Value-Vektoren enthalten die Merkmale, die weitergegeben werden.

Nun berechnen wir für jedes Token die gewichtete Summe der Value-Vektoren – mit den Softmax-Werten als Multiplikatoren.
Das Ergebnis ist ein neuer, kontextsensitiver Merkmalsvektor – also das neue Embedding.

Dieser Vektor fasst zusammen, welche Informationen aus dem gesamten Satzkontext für das aktuelle Token wichtig sind.

Die Formel, die gerade die Welt verändert!

\cancel{\boldsymbol{E = mc^2}}

\mathbf{Attention}(\mathbf{Q}, \mathbf{K}, \mathbf{V}) = \mathbf{softmax}\left( \frac{\mathbf{Q}\mathbf{K}^\top}{\sqrt{d_k}} + \mathbf{M} \right)\mathbf{V}

Der gesamte Vorgang der Self-Attention, den wir hier beschrieben haben, wurde von Vaswani und seinem Team in einer einzigen eleganten Formel zusammengefasst.
Alle Hochachtung für diesen genialen Mechanismus – an Vaswani, das gesamte Forschungsteam und natürlich auch an all jene, die zuvor den Weg dafür bereitet haben.

An heutigen Tools wie ChatGPT, Gemini und vielen anderen sehen wir Entwicklungen, die wir noch vor wenigen Jahren für undenkbar gehalten hätten.
Und es ist sehr wahrscheinlich, dass wir schon bald weitere emergente Phänomene erleben werden – Entwicklungen, die unsere heutige Vorstellungskraft nicht nur fordern, sondern weit übersteigen.

Wie geht es nun weiter?

Mit der Self-Attention haben wir nun ein Embedding erzeugt, das für jedes Token – insbesondere das letzte („schläft“) – den gesamten Kontext berücksichtigt.

Was jetzt noch fehlt: Dieses Embedding muss einem konkreten nächsten Token zugeordnet werden.
Dafür kommt ein weiteres neuronales Netz ins Spiel: ein Feedforward-Layer, der das Embedding weiterverarbeitet – und dabei hilft, logische und semantische Muster zu erkennen.

Am Ende erzeugt ein Decoder eine Wahrscheinlichkeitsverteilung über das Vokabular – und wählt das wahrscheinlichste nächste Token aus.

Wie das funktioniert, sehen wir im nächsten Kapitel.

Dies ist Teil 6 der Kursserie „ChatGPT & Co verstehen: Wie große Sprachmodelle wirklich arbeiten – anschaulich & interaktiv“.

Bedeutung durch Kontext

Transformer haben den großen Durchbruch erzielt, weil sie die Bedeutung von Wörtern nicht isoliert, sondern im gesamten Kontext erfassen.

Im Unterschied zu früheren Modellen analysieren Transformer alle Tokens parallel und setzen sie dabei in Beziehung zueinander.
So erkennen sie semantische Zusammenhänge und können Sprache auf einer tieferen Ebene verarbeiten.

Was wir bisher schon wissen:

• Die Bedeutung einzelner Tokens wird durch Embeddings dargestellt – also durch ihre Lage im Merkmalsraum.
• Die Position im Satz wird zusätzlich durch ein Position Encoding berücksichtigt.

Aber – reicht das aus, um den Sinn eines ganzen Satzes zu verstehen?

Sehen wir uns ein Beispiel an:

Das Wort „Schloss“ kann vieles bedeuten:
ein Vorhängeschloss, ein Türschloss – oder ein adeliges Schloss auf einem Hügel.
Ohne weiteren Kontext bleibt die Bedeutung mehrdeutig. In der Fachsprache nennt man das: Ambiguität

Betrachten wir nun einen ganzen Satz:

Klingt poetisch – aber auch hier bleibt offen, was gemeint ist.
Das Adjektiv „alt“ hilft uns zwar weiter, grenzt die Bedeutung aber noch nicht eindeutig ein.

Erweitern wir den Satz um ein weiteres Adjektiv:

Nun wird klar: Ein adeliges Schloss rostet nicht – wahrscheinlich ist ein Sicherheitsschloss gemeint.

Präzisieren wir den Satz noch einmal:

Jetzt besteht kein Zweifel mehr: Es handelt sich eindeutig um ein Fahrradschloss.

Dieses Beispiel zeigt: Wörter werden erst durch den Kontext eindeutig verständlich.

Encoder und Decoder im ursprünglichen Transformer

Das Paper von Vaswani et al. „Attention Is All You Need“ stellte ursprünglich ein Modell für maschinelle Übersetzung vor.
Dafür gab es zwei zentrale Bausteine:

• Encoder: Erfasst den gesamten Eingabetext (z. B. einen deutschen Satz) und erzeugt eine kontextabhängige Darstellung jedes Tokens – also eine Folge von Vektoren, die die Bedeutung im Satzzusammenhang darstellen.
• Decoder: Nutzt diese Abbildung plus die bisher generierten Tokens, um Schritt für Schritt die Übersetzung in der Zielsprache zu erzeugen.

Moderne Sprachmodelle wie GPT vereinfachen diese Architektur: Sie bestehen nur aus Decoder-Stacks.

Das wirkt wie eine Reduktion – ist aber für die Sprachgenerierung eine geniale Spezialisierung. Denn ein Decoder kann beides:

• Den bisherigen Kontext „verstehen“ (durch Self-Attention)
• Und ihn gleichzeitig „weitererzählen“ (durch die Ausgabe des nächsten Tokens).

Darum verwendet GPT nur den Decoder-Teil und verzichtet auf den Encoder:
Es übersetzt nicht von einer Sprache in eine andere, sondern setzt einfach die eigene Geschichte fort.

Roh Embedding

Zu Beginn erhält jedes Token ein Roh-Embedding – also eine Vektorrepräsentation im Merkmalsraum, die während des Trainings gelernt wurde. Dieses Embedding ist zunächst kontextunabhängig: Es berücksichtigt noch nicht die anderen Tokens im Kontextfenster.
Das gleiche Token – etwa ‚Bank‘ – wird immer gleich eingebettet, unabhängig vom Kontext.

Bei mehrdeutigen Tokens – wie Schloss – hat das Modell gelernt, dass sie in verschiedenen Bedeutungsbereichen im Merkmalsraum auftreten können. So wird Schloss anfänglich irgendwo zwischen den semantischen Clustern von adeligem Gebäude und Sicherheitsschlösser (z. B. Vorhängeschlössern) positioniert.

Erst durch den Kontext der umliegenden Tokens entsteht aus dem ursprünglichen Embedding von Schloss eine kontextabhängige Bedeutung – seine Position im Merkmalsraum verschiebt sich entsprechend.

Im nächsten Beispiel kannst du das selbst beobachten:
Je nachdem, welchen Satz du auswählst, bewegt sich das Embedding von Schloss näher an den Cluster repräsentativer Gebäude oder an den Cluster Sicherheitsschlösser.

Viele Touristen besuchen das Schloss jedes Jahr Mit dem Schlüssel lässt sich das Schloss öffnen.

Wie der Transformer Zusammenhänge zwischen Tokens erkennt

Der Self-Attention-Mechanismus

Komplexe neuronale Verfahren wie der Self-Attention-Mechanismus lassen sich für Menschen oft nur schwer intuitiv erfassen. Häufig hilft eine passende Analogie, um ein Gefühl für das zugrunde liegende Prinzip zu bekommen.

Es gibt viele solcher Analogien, die versuchen, das Konzept von Attention verständlich zu machen. Aus meiner Sicht greifen viele davon jedoch zu kurz: Sie vereinfachen den Mechanismus so stark, dass man glaubt, ihn verstanden zu haben – in Wirklichkeit hat man aber nur das Bild verstanden, nicht die dahinterliegende Technik.

Deshalb habe ich mir eine eigene Analogie überlegt – eine, die anschaulich ist, aber dennoch relativ nah an der tatsächlichen Funktionsweise bleibt.

Eine Analogie: Tokens als beratende Experten

Du kannst dir den Self-Attention-Mechanismus als eine Art Expertenplattform vorstellen.

Jedes Token in der Sequenz ist ein Experte, der zwei Dinge bereitstellt:
ein Beratungsprofil (Key) – also worin es sich auskennt –
und konkretes Wissen (Value), das es teilen kann.

Ein anderes Token stellt eine Anfrage (Query) – es sucht gezielt nach Expertise,
die ihm im aktuellen Kontext weiterhilft.

Der Self-Attention-Mechanismus übernimmt die Vermittlung:
Er vergleicht die Frage mit allen Profilen und berechnet, wer wie gut passt.
Je besser ein Experte zur Frage passt, desto mehr Wissen bringt er ein.

So entsteht eine neue Repräsentation – eine neue kontextabhängige Bedeutung – des fragenden Tokens:
angereichert mit genau den Informationen, die im Moment relevant sind – gezielt, gewichtet und kontextabhängig.

Jedes Token im Kontextfenster stellt seine Anfrage an alle anderen Tokens, um sich besser in den Gesamtkontext einzuordnen.

Gleichzeitig tritt jedes Token auch als Berater auf, indem es Informationen bereitstellt, auf die andere Tokens zugreifen können.

Dieser Austausch erfolgt nicht aktiv, sondern wird parallel und automatisch durch den Self-Attention-Mechanismus berechnet.

Query, Key und Value

Jedes Token wird im Self-Attention-Mechanismus aus drei verschiedenen Perspektiven betrachtet:

• als Query: eine gezielte Anfrage, um relevante Informationen aus dem Kontext zu erhalten,
• als Key: ein Profil, das beschreibt, welche Informationen dieses Token anbietet,
• als Value: der eigentliche Informationsinhalt, den es weitergeben kann.

Der Self-Attention-Mechanismus vergleicht die Query eines Tokens mit den Keys aller anderen Tokens.
Je besser ein Key zur Query passt, desto stärker wird das zugehörige Value in die Berechnung einbezogen.

So entsteht für jedes Token eine neue Repräsentation – angereichert mit den Informationen derjenigen Tokens, die im aktuellen Kontext am relevantesten sind.

Wir haben jetzt das Grundprinzip des Self-Attention-Mechanismus verstanden – Zeit, einen Blick unter die Haube zu werfen.
Dafür brauchen wir etwas Mathematik, aber keine Sorge: Es bleibt gut nachvollziehbar.

Solche multidimensionalen Zusammenhänge sind oft schwer vorstellbar.
Doch schon mit ein wenig Mathematik lassen sie sich erstaunlich gut nachvollziehen.
Mein Tipp: dranbleiben – es lohnt sich!

Dies ist Teil 5 der Kursserie „ChatGPT & Co verstehen: Wie große Sprachmodelle wirklich arbeiten – anschaulich & interaktiv“.

Die großen Vorteile moderner Transformer-Modelle

Die drei wichtigsten Vorteile aktueller LLMs mit Transformer-Architektur:

• Parallele Verarbeitung: Alle Tokens werden gleichzeitig verarbeitet – nicht Schritt für Schritt.
• Besseres Textverständnis: Das Modell erkennt komplexe semantische Zusammenhänge.
• Langer Kontext: Transformer können tausende Tokens gleichzeitig betrachten

Diese Fortschritte ermöglichen Einsatzbereiche, die noch vor wenigen vollkommen Jahren undenkbar waren.

Wie viel Text versteht ein Sprachmodell wirklich?

Die Länge des sogenannten Kontextfensters ist ein zentraler Aspekt moderner Sprachmodelle.
Ein LLM analysiert alle Tokens im Kontextfenster gleichzeitig und setzt sie miteinander in Beziehung. So kann es den ganzen Text „verstehen“.

Je größer dieses Fenster, desto mehr Text kann das Modell auf einmal erfassen – also nicht nur einzelne Wörter und Sätze, sondern sogar ganze Abschnitte oder Kapitel.

Die Größe des Kontextfensters bestimmt maßgeblich das Einsatzgebiet eines Sprachmodells – und ist deshalb ein entscheidender Wettbewerbsfaktor bei der Entwicklung leistungsfähiger LLMs.

In den letzten Jahren hat sich die maximale Kontextlänge massiv erhöht:

In der Tabelle erkennt man deutlich: Einige Modelle haben das Kontextfenster beinahe explosionsartig erweitert.
Diese Vergrößerung wird jedoch häufig durch technische Workarounds oder Speichertricks erreicht – denn tatsächlich liegt die effektiv nutzbare Kontexttiefe bei den meisten Modellen weiterhin im Bereich von einigen Tausend Tokens.

Aber – wo befindet sich nun welches Token?

Die parallele Verarbeitung bringt ein Problem mit sich, das serielle Modelle wie RNNs nicht kennen:
Die Reihenfolge der Tokens im Kontext.

Beispiel:

• Der Hund biss den Briefträger.
• Der Briefträger biss den Hund.

Beide Sätze enthalten genau die gleichen Wörter – aber die Reihenfolge der Wörter verändert die Bedeutung vollkommen.

Transformer müssen also wissen: An welcher Position steht jedes Token?

Dieses Problem war auch Vaswani und seinem Team bewusst:
Ein Transformer verarbeitet alle Tokens gleichzeitig – kennt dabei aber nicht die Reihenfolge, in der sie im Satz standen.

Daher musste eine Methode gefunden werden, dem Modell Positionsinformationen mitzugeben:
Es muss wissen, an welcher Stelle im Satz sich ein Token ursprünglich befand.

Positional Encoding

Dazu wird jedem Token eine Positionsangabe hinzugefügt.
Das kann entweder statisch erfolgen – über eine feste Zahl für jede Position –
oder das Modell lernt selbst, wie es sich die Position merken kann – mithilfe einer internen Tabelle.

Doch das Problem ist jedoch etwas komplexer, als es erstmals klingt:
Es genügt nicht, dem Token einfach eine Zahl mitzugeben – wie z.B. Position 1, 2, 3 …
denn die Position muss sich auch in den Embeddings widerspiegeln, also in den einzelnen Merkmalsdimensionen, die das Modell intern verarbeitet.
Nur so kann das Modell lernen, wie sich semantische Beziehungen ändern, wenn die Tokens an unterschiedlichen Positionen im Satz stehen.

Vaswani wählte dafür eine sehr elegante Lösung:
Das sogenannte Sinusoidal Position Encoding – auch als „Vaswani-Methode“ bekannt.

„Vaswani-Methode“

Die Idee:
Jede Position im Satz wird mithilfe von Sinus- und Kosinus-Funktionen in unterschiedliche Werte umgewandelt – separat für jede Dimension im Embedding.
So entsteht ein einzigartiges Wellenmuster, das die Position codiert – mathematisch unterscheidbar für jedes Token und jede Dimension im Embedding.

PE_{(pos, i)} =
\begin{cases}
\sin\left(\frac{pos}{10000^{\frac{2i}{d}}}\right), & \text{für gerade } i \\
\cos\left(\frac{pos}{10000^{\frac{2i}{d}}}\right), & \text{für ungerade } i
\end{cases}

Die exakte Formel ist weniger entscheidend – wichtig ist:
Man kann erkennen, dass die Positionskodierung je nach Position im Satz und Embedding-Dimension variiert.
Dabei wechseln sich Sinus- und Kosinus Funktionen ab und beginnen mit versetzten Phasen – so entsteht für jede Position ein eindeutiges, unterscheidbares Wellenmuster.

Die folgende interaktive Grafik zeigt die Positionskodierung im Detail – du kannst sie selbst steuern und erkunden.

Das Positions-Encoding wird einfach zum Vektor des Tokens addiert – also zu jedem einzelnen Embedding.
Dadurch verschiebt sich die Lage des Tokens im Merkmalsraum leicht, sodass das LLM erkennen kann, an welcher Stelle im Satz das Token ursprünglich stand.

Moderne Methoden wie RoPE

Neuere Modelle verwenden eine verfeinerte Form der Positionskodierung – etwa RoPE (Rotary Positional Encoding).
Dabei wird nicht das Token selbst im Merkmalsraum verschoben, sondern die Art der Betrachtung des Tokens leicht gedreht.
RoPE ist eine relative, aber fest definierte Positionskodierung – sie integriert die Abstände zwischen Tokens direkt in die Berechnung, statt absolute Positionen zu kodieren.

Das zugrunde liegende Prinzip bleibt jedoch gleich:
Die Positions-Information muss dem Modell mitgegeben werden – sonst kann es die Reihenfolge der Tokens nicht erfassen.

Dies ist Teil 4 der Kursserie „ChatGPT & Co verstehen: Wie große Sprachmodelle wirklich arbeiten – anschaulich & interaktiv“.

Wie versteht ein Sprachmodell einzelne Wörter?

Dank des Tokenizers lässt sich ein ursprünglich für den Computer völlig unverständlicher Text in eine Liste von Token-IDs umwandeln – also in Zahlen, die das Sprachmodell intern digital weiterverarbeiten kann.

Doch wie gelingt es einem Sprachmodell (LLM), aus diesen nackten Zahlen die Bedeutung einzelner Wörter zu erkennen – und letztlich den Sinn ganzer Texte zu erfassen?

Wie machen wir Menschen das?

Stellen wir uns das Wort „Katze“ vor.
Für uns ist es weit mehr als eine Reihe von Buchstaben: Wir verbinden damit sofort Vorstellungen wie weiches Fell, flauschige Ohren, große Augen und schnurrende Laute. Zudem wissen wir aus eigener Erfahrung oder Geschichten, dass Katzen gerne Mäuse jagen, viel schlafen – und mit Hunden nicht immer gut auskommen.

Ein LLM wie ChatGPT versucht genau diese Zusammenhänge ebenfalls abzubilden – aber auf statistische Weise.

Lernen aus Texten: Merkmale ohne Etikett

Sprachmodelle können die Welt noch nicht selbst beobachten. Sie haben keine Sinne und können daher keine eigenen Erfahrungen sammeln. Stattdessen lernen sie ausschließlich aus Texten – aus zig Milliarden Wörtern, gesammelt aus Wikipedia-Artikeln, Büchern, Foren, Webseiten und vielen anderen Quellen.

Wir haben bereits gesehen, dass neuronale Netze wahre Meister darin sind, komplexe Muster zu erkennen.
Beim Training erkennt das Modell typische Muster und Zusammenhänge: dass „Katze“ häufig gemeinsam mit Begriffen wie „schnurrt“, „flauschig“, „Maus“ oder „Tier“ vorkommt.

Aus dieser statistischen Häufigkeit leitet es typische Eigenschaften ab – etwa dass eine Katze oft als weich, klein, Haustier oder verspielt beschrieben wird.

Diese Eigenschaften nennt man latente Merkmale (engl. latent Features) – weil sie nicht direkt benannt oder beschriftet sind.
Das Modell vergibt keine festen Etiketten wie „hat Fell“ oder „jagt Mäuse“, sondern entdeckt solche Muster eigenständig auf Basis der Häufigkeit und des Kontexts im Text.

Ähnlich wie bei neuronalen Netzen zur Bilderkennung, bei denen man nicht exakt sagen kann, welche Kante oder welcher Bogen eine „6“ erkennen lässt, lassen sich auch diese Merkmale im Sprachmodell nicht direkt ablesen.
Wir wissen nicht, welche intern erkannten Eigenschaften genau für eine „Katze“ stehen – aber das Modell lernt sie aus dem statistischen Zusammenhang der Sprache.

LLMs erkennen eine Vielzahl an Merkmalen – bei GPT-3.5 sind es 12.288 latente Merkmale, auch Dimensionen genannt.
Jedes Wort wird durch diese 12.288 Merkmale beschrieben – das bildet die Grundlage für seine semantische Bedeutung im Modell.

Noch einmal zur Erinnerung: Die Merkmale (Dimensionen) sind abstrakt und für uns nicht direkt interpretierbar.
Vielleicht steht eines davon für etwas wie „flauschig“ – doch diese Bedeutungen sind nicht benannt, sondern entstehen automatisch beim Training des Modells.
Wir Menschen können nur mit bestimmten Analyseverfahren vermuten, welche Eigenschaften sie repräsentieren.

Jedes einzelne Wort wird als eine Liste von Zahlen dargestellt, zum Beispiel:
[0.12, -0.98, 1.57, 0.03, ..., -0.44]

Jede dieser Zahlen steht für den Wert eines Merkmals (einer Dimension).
Diese Liste von Zahlen nennt man in der Mathematik einen Vektor – in der KI meist ein Embedding, also ein Vektor, der die Bedeutung eines Wortes beschreibt.

Der Merkmalsraum – Bedeutung in Zahlen

Jedes einzelne Wort im Text wird geometrisch in einen Merkmalsraum (engl. Embedding Space) eingetragen, der seine semantische Bedeutung repräsentiert.
Dieser Vektor, der die Position im Merkmalsraum festlegt und damit die Bedeutung des Worts beschreibt, wird Embedding genannt.

Wir Menschen kennen Räume typischerweise in drei Dimensionen – mit den Achsen Breite, Länge und Höhe.
Der Merkmalsraum in einem Sprachmodell wie GPT-3.5 hat jedoch 12.288 Dimensionen.
Jede dieser Achsen repräsentiert ein latentes Merkmal, das die Bedeutung des Wortes mitbestimmt.

Die Illustration zeigt eine vereinfachte Darstellung von acht Dimensionen eines Embeddings.

Das ist nicht nur eine Metapher zur besseren visuellen Vorstellung – der Merkmalsraum wird mathematisch tatsächlich als geometrischer Raum abgebildet.

Worte mit ähnlichen Merkmalen – etwa Katze, Hund oder Haustier – gruppieren sich in einer Region des Merkmalsraums, während Begriffe wie Auto, Fahrrad oder Lkw sich in einer anderen Region konzentrieren.

Im geometrischen Vektorraum bilden sich solche semantisch verwandten Begriffe typischerweise zu Clustern (Gruppen).

Je näher zwei Wörter im Raum beieinander liegen, desto ähnlicher sind sie sich inhaltlich bzw. semantisch.

Die Abbildung zeigt eine dreidimensionale Darstellung semantischer Wortbeziehungen.
Ähnliche Begriffe gruppieren sich zu erkennbaren Clustern:

Links sammeln sich typische Haustiere wie Hund, Kaninchen und Meerschweinchen in enger Nachbarschaft.
Etwas abseits thront die Katze auf ihrem eigenen Platz: selbstständig, aber thematisch verwandt.
In der Mitte befindet sich die Transportbox – eine neutrale Verbindung zwischen Tier- und Fahrzeugwelt.

Rechts davon formieren sich zwei weitere Cluster:
Leichte Fahrzeuge wie Fahrrad und Motorrad – und weiter außen schwere Fahrzeuge wie Auto und LKW.

Die räumliche Anordnung ist – wie wir bereits wissen – kein Zufall:
Sie ergibt sich aus den statistischen Mustern, die Sprachmodelle aus Milliarden Wörtern erkennen
Je näher sich Begriffe im Raum befinden, desto stärker ähneln sie sich in Bedeutung und Verwendung.

Ein bekanntes Beispiel veranschaulicht dies: Der Vektorunterschied zwischen „Frau“ und „Mann“ ist ähnlich dem zwischen „Königin“ und „König“, was auf das Merkmal Geschlecht hinweist. Ebenso ist der Unterschied zwischen „car“ und „cars“ vergleichbar mit dem zwischen „dog“ und „dogs“ – das zeigt, dass auch der Unterschied zwischen Einzahl und Mehrzahl im Vektorraum abgebildet wird.

So entsteht aus Sprache ein intuitives, visuell greifbares Landschaftsbild – mit Clustern und Untergruppen.

Wie ähnlich sind zwei Wörter?

Klassische Embedding-Modelle wie Word2Vec, GloVe oder FastText, aber auch moderne Transformer-Modelle, messen semantische Ähnlichkeit anhand der räumlichen Nähe von Wortvektoren im Embedding Space.
Wörter mit ähnlichem Kontext liegen näher beieinander – unabhängig von Grammatik oder Satzstruktur.

Grundlegend gibt es drei Möglichkeiten, die räumliche Nähe zu messen:

1) Euklidische Distanz
Dabei wird der geometrische Abstand zwischen zwei Embeddings über alle Dimensionen berechnet.
Anschaulich entspricht das der „geraden Linie“ zwischen zwei Punkten im Vektorraum.

d(\mathbf{x}, \mathbf{y}) = \sqrt{(x_1 - y_1)^2 + (x_2 - y_2)^2 + (x_3 - y_3)^2}

d(\mathbf{x}, \mathbf{y}) = \sqrt{sum_{i=1}^{n} (x_i - y_i)^2}

2) Skalares Produkt (Dot-Produkt)
Die Ähnlichkeit von Wörtern lässt sich auch über den Winkel und die Länge der Vektoren ihrer Embeddings verstehen.
Man kann sich das so vorstellen: Je kleiner der Winkel zwischen den Vektoren zweier Wörter ist, desto ähnlicher sind ihre Bedeutungen.

\mathbf{x} \cdot \mathbf{y} = sum_{i=1}^{n} x_i , y_i

3) Kosinus-Ähnlichkeit

Die Kosinus-Ähnlichkeit geht noch einen Schritt weiter und ist ein normalisiertes Skalarprodukt.
Das bedeutet: Es wird nur der Winkel zwischen den Vektoren betrachtet, unabhängig von ihrer Länge.
Das Ergebnis liegt immer zwischen –1 und 1.
Wie auch bei den anderen Verfahren fließen alle Dimensionen der Embeddings in die Berechnung ein.

cos(\theta) = \frac{ \vec{A} \cdot \vec{B} }{ | \vec{A} | \cdot | \vec{B} | }

Zusammenfassung

Das Prinzip der Vektorähnlichkeit wird auch in modernen KI-Anwendungen genutzt – etwa bei der semantischen Suche, bei der Begriffe nicht nur wörtlich, sondern über ihre Bedeutung verglichen werden.
Auch Sprachmodelle verwenden es, um aus großen Textmengen passende Inhalte zu finden und weiterzuverarbeiten.

Moderne LLMs wie ChatGPT gehen allerdings deutlich weiter:
Sie vergleichen nicht nur die semantische Nähe von Wörtern, sondern berücksichtigen zusätzlich auch Grammatik, Satzstruktur und Kontext.

Wie das genau funktioniert, schauen wir uns in den nächsten Abschnitten an.

Mehr als Sprache: Multimodale Embeddings

Embeddings sind längst nicht mehr „nur“ auf Sprache beschränkt.
Neben Text und Tokens lassen sich auch andere Medientypen in Vektoren übersetzen – etwa Bilder, Audio oder sogar Video.
So können KI-Modelle Bedeutungen nicht nur sprachlich, sondern auch visuell und akustisch erfassen.

Die bisher besprochenen Embeddings beziehen sich auf Wort-Embeddings (genauer gesagt Token-Embeddings).
Doch die neuen Modelle von OpenAI, Anthropic, IBM, Meta und anderen sind multimodale Foundation-Modelle:
Sie verstehen nicht nur Text, sondern auch Bilder und Audio.

Das Grundprinzip bleibt dabei gleich:

• Texte zerlegen sie in Tokens,
• Bilder in kleine Bildausschnitte (Patches),
• Audio in kurze Zeitfenster (Samples).

Aus diesen Fragmenten erzeugen die Modelle Vektoren (Embeddings) und verankern sie in semantischen Räumen.

Dabei gibt es zwei Ansätze:

• ein gemeinsamer Embedding-Space für alle Modalitäten,
• oder separate Räume, die durch das Training so aufeinander abgestimmt werden, dass sie miteinander kompatibel sind und sich direkt vergleichen lassen.

So können die Modelle crossmodal arbeiten – ein Bild mit einer Textbeschreibung abgleichen oder ein Geräusch mit einem geschriebenen Begriff verknüpfen.
Auf diese Weise entsteht ein multimediales Verständnis von Inhalten.

Ein einfaches Beispiel macht das greifbar:

• Text → Bild: Die Eingabe „eine Katze in einer Transportbox“ liefert in einer Bilddatenbank genau die passenden Bilder.
• Bild → Text: Ein Foto der gleichen Szene führt zu einer automatisch generierten Bildbeschreibung in Worten.

So verknüpfen multimodale Foundation-Modelle Inhalte in beiden Richtungen und schaffen Verbindungen zwischen Text, Bild und Audio.

Dieses Problem existiert bereits seit vielen Jahren:
Unternehmen sitzen auf einem riesigen Berg wertvoller interner Dokumente in unterschiedlichsten Formaten. Wissen, Regeln, Anweisungen, Tipps und Erfahrungen wurden über Jahre hinweg dokumentiert, gesammelt und an den verschiedensten Orten abgelegt.

Es ist ein enormer Schatz an Wissen – doch sobald man darauf zugreifen möchte, scheint er unauffindbar zu sein. Man weiß, dass die Information irgendwo existiert, doch niemand weiß mehr genau, wo sie abgelegt wurde.

Viele Unternehmen kennen dieses Problem nur zu gut. Immer wieder wird versucht, Ordnung in dieses Dokumentenchaos zu bringen und eine sinnvolle Struktur zu etablieren. Doch das ist in der Praxis oft schwieriger als gedacht. Selbst wenn man sich auf eine einheitliche Struktur geeinigt hat, bleiben Herausforderungen bestehen: Inhalte sind doppelt vorhanden, wurden mehrfach aktualisiert oder widersprechen sich an einzelnen Stellen.

Häufig versucht man, dem Ganzen mit strikten Ordnerhierarchien, Namenskonventionen und Volltextsuche Herr zu werden. Trotzdem kostet die Suche nach den passenden Dokumenten viel Zeit – ganz abgesehen davon, dass die gefundenen Dateien erst mühsam gesichtet werden müssen, um die tatsächlich relevante Information zu finden.

Wie praktisch wäre es, stattdessen einfach Fragen stellen zu können – und ein hilfreicher Assistent beantwortet sie direkt auf Basis der unternehmenseigenen Dokumente?
Welche Richtlinie gilt in diesem Fall?
Was muss ich hier beachten?

Große Sprachmodelle als Game Changer

Bis vor Kurzem war dies leider noch Wunschdenken. Doch dank aktueller Fortschritte in der KI – insbesondere durch große Sprachmodelle wie ChatGPT, Gemini oder Mistral – ist genau das inzwischen realistisch umsetzbar.

Diese Sprachmodelle sind in der Lage, Texte semantisch zu verarbeiten und Fragen auf Basis vorgegebener Texte zu beantworten. Dabei geht es nicht um reines Stichwortsuchen, sondern um das Verstehen von Zusammenhängen und Bedeutungen im Text.

Wir nutzen LLMs wie ChatGPT und ähnliche Modelle heute praktisch täglich, und viele können sich ein Leben ohne sie kaum noch vorstellen. Die Handhabung ist dabei erstaunlich einfach:
Wir geben dem LLM etwas Kontext in Form eines Prompts, und das Modell vervollständigt diesen.

Stellen wir eine Frage, erhalten wir – im Idealfall – eine passende Antwort. Dieses Wissen bezieht das LLM aus seinem Weltwissen, also aus den Daten, mit denen es trainiert wurde.

Fortschrittliche Modelle nutzen darüber hinaus Function Calling oder ähnliche Mechanismen, um sich zusätzliche Informationen aus externen Quellen, etwa aus dem Internet, zu beschaffen.

Wie bringen wir nun unsere eigenen Dokumente ins Spiel?

Für allgemeines Wissen funktioniert das bereits sehr gut. Doch wie stellen wir Fragen zu eigenen Dokumenten – etwa zu einer PDF-Datei?

Im Prinzip scheint auch das ganz einfach zu sein:
Wir extrahieren den Text (und gegebenenfalls auch Bilder und Tabellen) aus dem Dokument, kopieren ihn in das Chatfenster und stellen anschließend unsere Frage. Als Antwort erhalten wir – idealerweise – Informationen, die direkt aus dem Dokument stammen.

flowchart TD
subgraph A[ PDF-Verarbeitung]
A0[ PDF] --> A1[ Text extrahieren]
end

subgraph B[ Anfrage]
B0[ Nutzerfrage] --> B1[ Prompt]
A1 --> B1
end

subgraph C[ Generierung]
B1 --> C0[ LLM]
C0 --> C1[ Antwort]
end

So unkompliziert das zunächst klingt, verbergen sich dahinter jedoch einige grundlegende Probleme:

1. Das Herauskopieren relevanter Informationen aus Dokumenten kann bereits beim Copy-and-Paste mühsam und fehleranfällig sein.
2. Wir müssen dem Modell sehr genau vorgeben, wie es sich verhalten soll, damit es kein eigenes Weltwissen beimischt oder halluziniert.
3. Bei großen Dokumenten stoßen wir schnell an die Grenzen des Kontextfensters – also an die maximale Textmenge, die ein LLM gleichzeitig verarbeiten kann.
4. Der Kontext bleibt nur erhalten, weil das Dokument Teil des Chatverlaufs ist. Wird es nicht erneut mitgeschickt oder fällt aus dem Kontextfenster, ist es für das LLM nicht mehr verfügbar.
5. Durch die hohe Anzahl an Tokens kann dieser Ansatz sehr schnell teuer werden.
6. Zudem können wir auf diese Weise immer nur einzelne Dokumente mitgeben – in der Praxis ist relevantes Wissen jedoch häufig auf Hunderte oder Tausende von Dokumenten verteilt.

Retrieval-Augmented Generation (RAG)

Die grundlegende Idee ist einfach:
Zu einer Frage werden relevante Abschnitte aus den vorhandenen Dokumenten herausgesucht und dem Prompt als zusätzlicher Kontext mitgegeben. Das LLM verfügt dadurch über genau die Informationen, die es benötigt, um die Frage dokumentengetreu zu beantworten.

flowchart TD
subgraph D[ Dokumente vorbereiten]
D0[ Dokumente] --> D1[ Inhalte extrahieren]
end

D1 --> K[ Wissensbasis]

Q[ Nutzerfrage] --> R[ Relevante Inhalte finden]
K --> R
R --> P[ Prompt mit Kontext]
P --> L[ LLM]
L --> A[ Antwort]

Wichtig ist dabei: Die Dokumente werden nicht vollständig, sondern nur selektiv eingebunden – also genau die Textstellen, die für die jeweilige Frage relevant sind.

Auf diese Weise lassen sich mehrere der zuvor beschriebenen Kernprobleme direkt lösen:
Durch die gezielte Auswahl relevanter Ausschnitte können Inhalte aus vielen Dokumenten gleichzeitig berücksichtigt werden, ohne das Kontextfenster zu sprengen oder die Tokenkosten explodieren zu lassen.

Gute Vorbereitung ist alles

Damit das LLM schnell und gezielt auf relevante Inhalte zugreifen kann, müssen die Dokumente vorab aufbereitet werden.
Zunächst gilt es, die Dokumente in eine für Maschinen lesbare Form zu überführen. Anschließend werden die Inhalte in kleinere Einheiten aufgeteilt und indexiert, sodass ein schneller Zugriff möglich ist – vergleichbar mit einer Datenbank.

Dokumente in eine lesbare Form bringen

Dieser erste Schritt ist deutlich anspruchsvoller, als es auf den ersten Blick scheint. Dokumente liegen in der Praxis in den unterschiedlichsten Formaten vor: einfache Textdateien, Word-Dokumente, E-Mails, PDFs, Webseiten und vieles mehr.

Bei einfachen Texten, Word-Dateien oder E-Mails ist die Extraktion meist unproblematisch. Anders sieht es bei PDFs oder Webseiten aus. Diese enthalten oft komplexe Formatierungen, Tabellen, Bilder, Layouts oder sogar interaktive Elemente.

Im Idealfall werden alle relevanten Inhalte vollständig extrahiert, die inhaltliche Hierarchie beibehalten und Bilder sowie Tabellen dem jeweils passenden Text zugeordnet. Gerade bei Webseiten, E-Mails oder PDFs stellt das jedoch häufig eine große Herausforderung dar.

Für diese Konvertierung kommen unterschiedliche Ansätze zum Einsatz: von selbstgebauten Extraktionspipelines über Dokumentenkonvertierungslösungen bis hin zu spezialisierten Parsern wie Docling. Je nach Aufbau und Qualität der Quelldokumente kann dieser Schritt relativ einfach – oder nahezu ein unlösbares Problem sein.

Das Ziel ist im optimalen Fall eine strukturierte, hierarchische Repräsentation der Inhalte, die als Grundlage für alle weiteren Verarbeitungsschritte dient.

Dokumente in kleinere Happen aufteilen

Nachdem wir die Daten in eine einheitliche, lesbare Form gebracht haben, werden die Dokumente in kleinere Einheiten zerlegt – sogenannte Chunks.
Diese Aufgabe übernimmt ein Splitter.

Je nach Art und Struktur des Dokuments kommen dabei unterschiedliche Strategien zum Einsatz:
vom einfachen Längenschnitt, über rekursive Splitter, bis hin zu Verfahren, die Inhalte hierarchisch entlang von Überschriften, Absätzen oder Abschnitten aufteilen.

Damit die einzelnen Chunks ihren inhaltlichen Zusammenhang nicht verlieren, wird in der Praxis meist ein Overlap verwendet. Dabei wird ein Teil des vorherigen und nachfolgenden Inhalts in jeden Chunk übernommen, um Kontext zu erhalten.

Dieser Schritt ist ein essenzieller Bestandteil der RAG-Pipeline, denn die Chunk-Größe hat einen maßgeblichen Einfluss auf die Qualität der Ergebnisse:

• Zu kleine Chunks trennen Informationen, die eigentlich zusammengehören.
• Zu große Chunks packen zu viel auf einmal hinein, sodass das Wichtige untergeht.

Auch der Overlap spielt dabei eine entscheidende Rolle. Häufig werden Faustregeln wie 200–800 Tokens Chunk-Größe bei etwa 10–20 % Overlap genannt. Diese Werte sind jedoch keine festen Vorgaben, sondern hängen stark vom Dokumenttyp und dem konkreten Anwendungsfall ab.

Bewährt haben sich Stichproben, um zu prüfen, ob einzelne Chunks für sich verständlich und sinnvoll in den Gesamtkontext einzuordnen sind. Diese Prüfung kann manuell erfolgen, lässt sich in vielen Fällen aber auch automatisiert unterstützen.

Bedeutung statt Wörter speichern

Nun haben wir unsere lesbaren Häppchen – diese möchten wir so abspeichern, dass wir sie später schnell und gezielt wiederfinden können.
Das Ziel ist, zu einem großen Dokumentenpool Fragen zu stellen und dabei genau die relevanten Chunks zu erhalten.

Früher hätte man diese Chunks einfach in einer klassischen Datenbank gespeichert und über eine Volltextsuche abgefragt – mit, wie wir wissen, oft mäßigen Ergebnissen. Die Suche bleibt dabei stark wortbasiert und berücksichtigt dabei kaum Bedeutung oder inhaltliche Nähe.

Embedding – die Bedeutung eines Worts

Dank moderner Transformer-Modelle können wir heute einen deutlich effektiveren Ansatz verfolgen:
Statt nur den Text zu speichern, speichern wir dessen Bedeutung. Dieser Vorgang wird als Embedding bezeichnet.

In den Grundlagen auf dieser Webseite beschreibe ich die Technologie hinter Embeddings ausführlicher. An dieser Stelle fasse ich das Prinzip bewusst vereinfacht noch einmal zusammen.

Wem das Thema Embeddings geläufig ist, kann diesen Absatz überspringen.

Einzelne Wörter – genauer gesagt Tokens – werden anhand einer Vielzahl von Merkmalen (man könnte auch von Eigenschaften sprechen) beschrieben und als Punkte in einem mehrdimensionalen Raum abgelegt.

Nehmen wir als vereinfachtes Beispiel eine Katze. Mit drei Eigenschaften – etwa flauschige Ohren, Fellnase und große Augen – ließe sich eine Katze in einem dreidimensionalen Raum darstellen: eine Dimension pro Eigenschaft.

Erhöhen wir die Anzahl der Dimensionen, können entsprechend mehr Eigenschaften gleichzeitig berücksichtigt werden. Mit acht Dimensionen wären es acht Eigenschaften, mit sechzehn entsprechend sechzehn. Moderne Embedding-Modelle arbeiten jedoch mit sehr viel höheren Dimensionalitäten, zum Beispiel 1.536 Dimensionen, und können damit eine entsprechend feingranulare Beschreibung der Bedeutung eines Tokens abbilden.

Wichtig dabei: Die Eigenschaften einzelner Wörter oder Begriffe werden nicht manuell festgelegt oder beschriftet. Stattdessen lernt das Modell diese Merkmale automatisch während des Trainings auf großen Textmengen. Man spricht hierbei von latenten Merkmalen, da sie zwar wirksam sind, für uns Menschen jedoch nicht direkt interpretierbar.

Das Ziel ist es, Begriffe mit ähnlicher Bedeutung im Raum nahe beieinander abzubilden.
Der Abstand zwischen ihnen drückt dabei die semantische Nähe aus.

Worte mit ähnlichen Merkmalen – etwa Katze, Hund oder Haustier – gruppieren sich in einer Region des Merkmalsraums, während Begriffe wie Auto, Fahrrad oder Lkw sich in einer anderen Region konzentrieren.

Alle Wörter (Tokens) eines Chunks werden nun embedded – das heißt, sie werden in eine Position in einem mehrdimensionalen Vektorraum überführt.
Das Ergebnis ist ein numerischer Vektor, zum Beispiel (0.1, 0.23, …), mit einem Zahlenwert pro Dimension.

Verschiedene Anbieter stellen heute unterschiedliche Embedding-Modelle zur Verfügung, darunter zum Beispiel E5, OpenAI oder Cohere.

Betrachten wir einen Chunk mit beispielsweise 500 Tokens. Würde man jedes Token einzeln als Vektor mit 1.536 Dimensionen darstellen, ergäbe das pro Chunk 768.000 Zahlenwerte. Das ist unhandlich und lässt sich später nur schwer effizient vergleichen.

Deshalb verfolgen wir einen anderen Ansatz:
Jeder Chunk wird als Ganzes durch einen einzigen Vektor beschrieben. Dieser Vektor dient als eine Art kompakter Fingerabdruck für den gesamten Inhalt des Chunks.

Pooling

Das Verfahren, aus vielen Token-Vektoren einen einzigen Fingerabdruck für den gesamten Chunk zu berechnen, nennt man Pooling.
Dabei gibt es verschiedene Pooling-Strategien, zum Beispiel Mean Pooling, Max Pooling, CLS-Token oder Weighted Pooling.

Für RAG-Anwendungen wird in der Praxis häufig Mean Pooling eingesetzt. Dabei wird für jede Dimension der arithmetische Mittelwert über alle Token-Vektoren eines Chunks berechnet. Konkret bedeutet das:
Jede einzelne Dimension aller Token wird aufsummiert und anschließend durch die Anzahl der Tokens geteilt – eine klassische Mittelwertberechnung.

Durch dieses Verfahren werden die semantischen Merkmale aller Tokens eines Chunks zusammengeführt.
Erstaunlicherweise liefert diese einfache Methode in vielen Anwendungsfällen stabile und gut vergleichbare Ergebnisse.

Je nach Embedding-Modell ist dieser Pooling-Schritt intern umgesetzt oder explizit auswählbar.

Speichern in der Datenbank

Nun können wir den Chunk-Vektor gemeinsam mit dem zugehörigen Text in einer Vektordatenbank speichern.
Dadurch lassen sich die Inhalte später schnell, zuverlässig und semantisch wiederfinden.

Zur Auswahl stehen verschiedene Vektordatenbanken, die jeweils ihre eigenen Vor- und Nachteile haben. Dazu zählen zum Beispiel Pinecone, Weaviate, Qdrant, Milvus oder ChromaDB.

Für Tests und Prototypen (MVPs) eignet sich ChromaDB besonders gut, da es leichtgewichtig, einfach aufzusetzen und lokal nutzbar ist.
Für den produktiven Einsatz greifen Unternehmen hingegen häufiger zu Pinecone, Weaviate oder Qdrant, da diese Lösungen besser auf Skalierbarkeit, Stabilität und Betrieb in Produktionsumgebungen ausgelegt sind.

Frage deine KI

RAG-Systeme sind in Unternehmen oft der erste Berührungspunkt mit KI. Sie lassen sich vergleichsweise einfach implementieren und liefern schnell einen konkreten, messbaren Mehrwert.

Für Mitarbeitende ist das besonders praktisch, um Fragen zu internen Richtlinien, Prozessen oder dem unternehmensweiten Wissenspool zu stellen. Gleichzeitig profitieren auch Kundinnen und Kunden, etwa bei Fragen zu Öffnungszeiten, Produkten oder Services.

In der Praxis erfolgt die Interaktion häufig über eine Chatoberfläche, die an bekannte KI-Systeme erinnert. Alternativ wird das System direkt in eine bestehende Infrastruktur integriert, zum Beispiel in Microsoft Teams oder ähnliche Kollaborationstools.

Dabei gilt: Je unauffälliger und natürlicher die Integration, desto besser wird KI von den Menschen angenommen.

Wie findet RAG die relevanten Chunks?

In der Praxis stellt ein Nutzer eine Frage, zum Beispiel: „Wie sind die Öffnungszeiten?“
Nun ist es Aufgabe des RAG-Systems, auf Basis dieser Anfrage die relevanten Chunks zu finden und daraus eine möglichst passende Antwort zu generieren.

Der Ablauf ist dabei sehr ähnlich zu dem Prozess, den wir bereits beim Embedding der Dokumente kennengelernt haben:

1. Die Frage des Nutzers wird zunächst in Tokens zerlegt.
2. Anschließend wird die gesamte Frage embedded und – je nach Modell – gepoolt. Dadurch erhält sie eine Position im Embedding Space, also im mehrdimensionalen latenten Vektorraum.
3. Die Chunks, die im Vektorraum am nächsten zu dieser Frage liegen, sind diejenigen, die uns interessieren.

Ganz wichtig dabei ist, dass für das Embedding der Chunks und für das Embedding der Nutzerfrage dasselbe Embedding-Modell und dieselben Parameter verwendet werden.

Andernfalls liegen Frage und Dokumente in unterschiedlichen Vektorräumen – sie „sprechen“ dann nicht dieselbe Sprache und lassen sich nicht sinnvoll miteinander vergleichen.

Wie finden wir heraus, welche Chunks am nächsten zu unserer Frage sind?

Dazu messen wir die räumliche Distanz zwischen dem Vektor der Nutzerfrage und den Vektoren der gespeicherten Chunks.
Chunks mit dem geringsten Abstand gelten als semantisch am ähnlichsten und werden für die Beantwortung der Frage herangezogen.

Wie man den geometrischen Abstand zwischen Vektoren misst, habe ich in den Grundlagen auf dieser Webseite bereits ausführlich erklärt.
Ich greife den Punkt hier noch einmal kurz auf, um den Zusammenhang klarzumachen.

Geometrische Nähe im Embedding-Raum

Grundlegend gibt es drei Möglichkeiten, die räumliche Nähe zu messen:

1) Euklidische Distanz
Dabei wird der geometrische Abstand zwischen zwei Vektoren über alle Dimensionen berechnet.
Anschaulich entspricht das der „geraden Linie“ zwischen zwei Punkten im Vektorraum.

d(\mathbf{x}, \mathbf{y}) = \sqrt{(x_1 - y_1)^2 + (x_2 - y_2)^2 + (x_3 - y_3)^2}

d(\mathbf{x}, \mathbf{y}) = \sqrt{\sum_{i=1}^{n} (x_i - y_i)^2}

2) Skalares Produkt (Dot-Produkt)
Die Ähnlichkeit von Wörtern lässt sich auch über den Winkel und die Länge der Vektoren ihrer Embeddings verstehen.
Man kann sich das so vorstellen: Je kleiner der Winkel zwischen den Vektoren zweier Wörter ist, desto ähnlicher sind ihre Bedeutungen.

\mathbf{x} \cdot \mathbf{y} = \sum_{i=1}^{n} x_i , y_i

3) Kosinus-Ähnlichkeit

Die Kosinus-Ähnlichkeit geht noch einen Schritt weiter und ist ein normalisiertes Skalarprodukt.
Das bedeutet: Es wird nur der Winkel zwischen den Vektoren betrachtet, unabhängig von ihrer Länge.
Das Ergebnis liegt immer zwischen –1 und 1.
Wie auch bei den anderen Verfahren fließen alle Dimensionen der Embeddings in die Berechnung ein.

cos(\theta) = \frac{ \vec{A} \cdot \vec{B} }{ | \vec{A} | \cdot | \vec{B} | }

In vielen RAG-Systemen lässt sich eines dieser Distanz- bzw. Ähnlichkeitsverfahren konfigurieren.

In der Praxis werden Embedding-Vektoren oft normalisiert, sodass ihre Länge keine Rolle mehr spielt und beim Vergleich nur noch die inhaltliche Richtung zählt.

Nur die besten kommen in die Auswahl

In der Praxis übergeben wir der Vektordatenbank die Nutzerfrage (als Embedding) sowie die gewünschte Anzahl an Treffern (k).

Die Vektordatenbank berechnet daraufhin, welche Chunks der Anfrage semantisch am nächsten liegen, sortiert sie nach Ähnlichkeit und liefert die Top-k relevantesten Chunks zurück.

Anfrage an das LLM

Die Anfrage an das LLM erfolgt in Form eines Prompts. Dabei werden die System-Anweisung, die relevanten Chunks sowie die Nutzeranfrage zu einem gemeinsamen Kontext zusammengeführt und in einer Anfrage an das LLM gesendet.

In der Praxis wird die System-Anweisung häufig auf Englisch formuliert – selbst dann, wenn der eigentliche Kontext und die Nutzerfrage deutsch sind. Der Grund dafür ist, dass die Stabilität und Zuverlässigkeit von Instruktionen bei den meisten LLMs in englischer Sprache höher ist.

{
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful assistant. Answer only based on the provided context. If the answer is not contained in the context, say that you do not know."
    },
    {
      "role": "user",
      "content": "Context:\n---\n[Chunk 1]\n[Chunk 2]\n[Chunk N]\n---\n\nQuestion:\nWie sind die Öffnungszeiten?"
    }
  ]
}

Mit dieser Anweisung vervollständigt das LLM die Nutzeranfrage gemeinsam mit dem bereitgestellten Kontext zu einer sinnvollen, zusammenhängenden Antwort.

{
  "role": "assistant",
  "content": "Unsere Öffnungszeiten sind Montag bis Freitag von 08:00 bis 17:00 Uhr."
}

In vielen Systemen werden zusätzlich die verwendeten Textstellen referenziert oder mitgeliefert, um Antworten nachvollziehbar zu machen.

Am Ende dieses Prozesses steht ein funktionsfähiges RAG-System, das Antworten auf Grundlage der hochgeladenen Dokumente generiert.

Die RAG-Pipeline im Überblick

flowchart TD

%% INDEXING
subgraph A[ Indexing]
A0[ Dokumente] --> A1[ Chunking]
A1 --> A2[ Tokenisierung]
A2 --> A3[ Transformer Encoder]
A3 --> A4[ Token Vektoren]
A4 --> A5[ Pooling z.B.: Mean]
A5 --> A6[ Chunk Vektor]
A6 --> A7[( VectorDB)]
end

%% QUERY
subgraph B[ Query]
B0[ User Query] --> B1[ Tokenisierung]
B1 --> B2[ Transformer Encoder]
B2 --> B3[ Token Vektoren]
B3 --> B4[ Pooling z.B.: Mean]
B4 --> B5[ Query Vektor]
end

%% RETRIEVAL
subgraph C[ Retrieval]
B5 --> C1[ Similarity Search]
A7 --> C1
C1 --> C2[ Top-k Chunks]
end

%% GENERATION
subgraph D[ Generation]
D0[ Prompt + Kontext + Frage] --> D1[ LLM]
D1 --> D2[ Antwort]
end

C2 --> D0

Unsere RAG-Pipeline ist bereits voll funktionsfähig – dennoch lässt sie sich weiter verbessern.

Die Antworten basieren primär auf semantischer Ähnlichkeit. Das ist der große Fortschritt – und in den meisten Fällen genau richtig. Manchmal möchte man jedoch ganz gezielt exakte Details finden, zum Beispiel Nummern, IDs oder konkrete Fehlermeldungen. In solchen Fällen ist ein rein semantischer Ansatz nicht immer die beste Wahl.

Gespür für Details – BM25

Hier kann ein klassisches Retrieval-Verfahren helfen: BM25 (Best Matching 25).
BM25 basiert auf Wortstatistiken und kommt ohne KI aus. Die Grundidee ist einfach: Seltene Wörter sind oft besonders aussagekräftig – vor allem dann, wenn sie in wenigen, aber relevanten Textstellen auftauchen (z. B. eine eindeutige Fehlermeldung oder ein spezieller Fachbegriff).

BM25 nutzt dabei unter anderem folgende Größen:

• Term Frequency (TF): Wie oft kommt ein Wort in einem Chunk vor?
• Document Frequency (DF): In wie vielen Chunks kommt dieses Wort insgesamt vor?
• Dokumentlänge: Wie lang ist der Chunk im Vergleich zu anderen?

In Kombination mit Embeddings entsteht so ein robustes Hybrid-Retrieval:
Embeddings liefern Textverständnis und finden auch ähnliche Formulierungen, während BM25 besonders gut bei exakten Begriffen, Fehlercodes und Fachtermini ist.

Beim Chunking der Dokumente werden die Chunks sowohl in einen BM25-Textindex aufgenommen als auch parallel als Embeddings in der Vektordatenbank gespeichert.

Hybrid RAG

Beim hybriden RAG werden für eine Nutzeranfrage zwei Suchen parallel ausgeführt: eine semantische Vektorsuche auf Basis von Embeddings und eine statistische, wortbasierte Suche mit BM25.
Beide Verfahren liefern jeweils ihre Top-k Chunks, die anschließend zusammengeführt und weiterverarbeitet werden.

flowchart TD

%% INDEXING
subgraph A[ Indexing]
A0[ Dokumente] --> A1[ Chunking]
A1 --> A2[ Embedding Model]
A2 --> A3[ Chunk Embeddings]
A3 --> A4[( Vector Database)]
A1 --> A5[ Tokenization]
A5 --> A6[( BM25 Text Index)]
end

%% QUERY
subgraph B[ Query]
B0[ User Query] --> B1[ Embedding Model]
B1 --> B2[ Query Embedding]
B0 --> B3[ Tokenization]
end

%% RETRIEVAL
subgraph C[ Retrieval]
B2 --> C1[ Vector Search]
A4 --> C1
C1 --> C2[ Top-k Vector]

B3 --> C3[ BM25 Retrieval]
A6 --> C3
C3 --> C4[ Top-k BM25]

C2 --> C5[ Merge / Re-ranking]
C4 --> C5
C5 --> C6[ Final Top-k Chunks]

end

%% GENERATION
subgraph D[ Generation]
C6 --> D0[ Prompt: Context + Question]
D0 --> D1[ LLM]
D1 --> D2[ Answer]
end

Hier kommt im Retriever eine zusätzliche Komponente ins Spiel: Merge / Re-Ranking.
Denn wir erhalten zwei getrennte Ergebnislisten – einmal aus der Vektorsuche und einmal aus BM25. Diese Kandidaten müssen wir zusammenführen, nach Relevanz sortieren und anschließend auf ein finales Top-k begrenzen.

Dafür gibt es unterschiedliche Strategien, zum Beispiel:

• score-basiert (Scores werden normalisiert und kombiniert)
• ranking-basiert (Ränge werden zusammengeführt, z. B. über Rank-Fusion)

Besonders gute Ergebnisse liefern Transformer-Modelle als Re-Ranker. In der Praxis sind zwei Ansätze verbreitet:

1. Cross-Encoder Re-Ranker
   Ein Modell, das Query und Chunk gemeinsam bewertet und daraus einen Relevanzscore ableitet. Solche Modelle sind typischerweise für Relevanzbewertung (Ranking) optimiert.
2. LLM Re-Ranking (z. B. per GPT)
   Ein klassisches LLM, das per Prompt dazu angeleitet wird, die Kandidaten-Chunks nach Passgenauigkeit zur Frage zu sortieren oder die besten k auszuwählen.

Anschließend gehen die Nutzeranfrage und die passendsten Chunks in die Generation-Pipeline, wo das LLM daraus eine möglichst passende und informative Antwort auf die Frage des Nutzers erzeugt.

Millionen von Vektoren? – Hierarchical Navigable Small World (HNSW)

Spätestens bei großen RAG-Systemen stellt sich die Frage, wie sich Millionen multidimensionaler Vektoren in akzeptabler Zeit durchsuchen lassen. Ein exakter Vergleich aller Vektoren wäre hier zu langsam.

In der Praxis kommen daher approximative Ähnlichkeitssuchen zum Einsatz – Verfahren, die sich schrittweise an die relevantesten Vektoren annähern.
Ein häufig verwendeter Ansatz ist HNSW (Hierarchical Navigable Small World), der von vielen Vektordatenbanken eingesetzt wird.

Das Prinzip lässt sich gut mit einem Straßennetz vergleichen:
Vektoren werden in mehreren Hierarchieebenen organisiert. Die obersten Ebenen sind sehr dünn besetzt und entsprechen gewissermaßen Autobahnen, über die man schnell große Distanzen zurücklegt. Die darunterliegenden Ebenen werden zunehmend dichter und bilden feinere lokale Verbindungen ab – vergleichbar mit Landstraßen und Nebenstraßen.

Die Suche beginnt immer in der obersten Ebene. Dort wird der Vektor gesucht, der der Anfrage am ähnlichsten erscheint. Von diesem Punkt aus wechselt der Algorithmus in die nächsttiefere, dichter vernetzte Ebene und setzt die Suche fort. Dieser Vorgang wiederholt sich Ebene für Ebene, bis die unterste und detaillierteste Ebene erreicht ist.

Auf diese Weise nähert sich die Suche gezielt dem Zielvektor, ohne alle Vektoren vergleichen zu müssen.
Das ermöglicht eine sehr schnelle Ähnlichkeitssuche, insbesondere bei großen Vektormengen, bei gleichzeitig hoher Trefferqualität.

Grenzen von RAG

Moderne LLMs machen es erstmals möglich, intelligente Frage-Antwort-Systeme auf Basis bestehender Dokumente zu realisieren. Dennoch sollten bei RAG-Systemen einige grundlegende Einschränkungen berücksichtigt werden.

1. Datenqualität ist entscheidend
   RAG kann nur mit den Informationen arbeiten, die tatsächlich extrahiert wurden. Gerade bei komplexen Formaten wie PDFs, Webseiten oder E-Mails ist die zuverlässige Extraktion von Text, Struktur und Kontext häufig eine große Herausforderung.
2. Verlust von Kontext durch Chunking
   Durch die Aufteilung von Dokumenten in einzelne Chunks können Zusammenhänge verloren gehen. Aufgaben, die ein globales Verständnis erfordern – etwa vollständige Zusammenfassungen oder Querverweise über mehrere Abschnitte hinweg – sind dadurch nur eingeschränkt möglich.
3. Halluzinationen sind nicht vollständig ausgeschlossen
   RAG reduziert Halluzinationen deutlich, verhindert sie jedoch nicht vollständig. Findet das System keine passenden Inhalte zur Anfrage oder sind die bereitgestellten Chunks unklar, kann das LLM weiterhin plausibel klingende, aber falsche Antworten erzeugen.
4. Begrenzte Nachvollziehbarkeit
   Ohne zusätzliche Maßnahmen ist oft nicht transparent, auf welchen Textstellen eine Antwort basiert. In der Praxis ist es daher sinnvoll, Quellen, Textausschnitte oder Positionsangaben mitzuliefern, um Ergebnisse überprüfbar zu machen.

Künstliche Intelligenz (KI) – mehr als nur ein Hype?

Alle reden über Künstliche Intelligenz – ein Hype, der in aller Munde ist. Täglich hört man von den erstaunlichen Fähigkeiten moderner Sprachmodelle wie ChatGPT, Gemini, Granite und vielen anderen.

Obwohl es Künstliche Intelligenz (KI) und Neuronale Netze schon seit Jahrzehnten gibt – etwa für

• Filmempfehlungen
• Produktvorschläge
• Werbeoptimierung
• Bonitätsprüfungen

löste ChatGPT Ende 2022 einen weltweiten Hype aus.

Warum war das so?

KI war zuvor meist unsichtbar im Hintergrund aktiv: Sie unterstützte Geschäftsprozesse, half bei Analysen oder steuerte Personalisierungen, ohne dass Endnutzer sie direkt wahrnahmen.

Erst mit der Veröffentlichung des großen Sprachmodells (LLM) ChatGPT durch OpenAI konnten plötzlich Millionen Menschen selbst erleben, wie leistungsfähig moderne KI-Systeme sind:

• Texte schreiben
• Erklären
• Zusammenfassen
• Ideen liefern
• Programmieren

Und das alles in natürlicher Sprache – scheinbar mühelos. Damit rückt die KI in Bereiche vor, die lange als kreative Domäne des Menschen galten: Sprache verstehen, Wissen verknüpfen, neue Ideen hervorbringen.

Innerhalb von nur 2 Monaten erreichte ChatGPT bereits über 100 Millionen Nutzer – ein Rekord, der es zum am schnellsten wachsenden digitalen Produkt der Geschichte machte.

Damit wurde KI zum ersten Mal unmittelbar erfahrbar für jedermann, nicht nur für Experten oder Unternehmen. Dieser direkte Zugang erklärt den enormen Hype – und markiert einen Wendepunkt in der öffentlichen Wahrnehmung von Künstlicher Intelligenz.

KI – sicher mehr als nur ein Hype

Ist das alles nur heiße Luft? Meiner Meinung nach nicht. Vielmehr stehen wir wahrscheinlich mitten in einer der größten technologischen Revolutionen unserer Zeit – mit Auswirkungen, die weit über einzelne Branchen hinausgehen werden.

Heute gibt es nicht nur ChatGPT, sondern viele weitere Mitbewerber wie Gemini (Google), Granite (IBM), LLaMA (Meta), Mistral, DeepSeek und zahlreiche andere.
Die rasanten Entwicklungen und Erfolge sind inzwischen kaum mehr vollständig zu überblicken.

Doch gerade deshalb stellt sich die spannende Frage:
Warum überhaupt eine KI auf der eigenen Hardware betreiben, wenn es so viele leistungsstarke Modelle in der Cloud gibt?

Warum eine eigene KI betreiben?

Stellen wir uns vor, wir könnten Sprachmodelle lokal installieren – welche Vorteile würde das mit sich bringen?

• Spezialisierung – Lokale Modelle können gezielt auf eigene Daten oder Fachgebiete zugeschnitten werden.
• Kosten – Nach der Einrichtung entstehen keine laufenden API- oder Abo-Kosten, nur Strom- und Hardwareaufwand.
• Performance – Für viele Anwendungen reicht die Geschwindigkeit lokaler Modelle aus, besonders mit optimierten Versionen.
• Latenz – Abfragen laufen direkt auf der eigenen Hardware, ohne Umweg über die Cloud.
• Sicherheit & Datenschutz – Alle Daten bleiben lokal, nichts verlässt den eigenen Rechner oder das Unternehmensnetzwerk.
• Flexibilität – Nutzer entscheiden selbst, welche Modelle und Tools sie einsetzen.
• Finetuning – Modelle lassen sich mit eigenen Daten nachtrainieren und damit optimal anpassen.
• Vielfalt der Modelle – Es gibt viele offene Modelle (z. B. LLaMA, Mistral, Falcon, DeepSeek), die je nach Bedarf eingesetzt werden können.
• Offline-Nutzung – Auch ohne Internetzugang bleibt die KI einsatzfähig.
• Keine externen Beschränkungen – Keine Limits bei Abfragen oder Abhängigkeit von Nutzungsbedingungen Dritter.
• Individuelle Sicherheitseinstellungen – Man kann selbst entscheiden, welche „Guardrails“ oder Sicherheitsfilter aktiv sein sollen – oder eben nicht.

Die nächste spannende Frage lautet: Ist es überhaupt möglich, so große Sprachmodelle lokal zu betreiben?

Die ganz großen Modelle – etwa GPT-5 (OpenAI), Gemini 2.5 Pro (Google) oder Claude Opus 4 (Anthropic) – werden weder Privatnutzer noch die meisten Unternehmen lokal installieren können. Sie laufen in riesigen Rechenzentren mit Millionen spezialisierter Recheneinheiten (GPUs/TPUs/NPUs) und erfordern eine Infrastruktur, die außerhalb von Hyperscalern (Google, Microsoft, Meta, Amazon usw.) nicht realistisch ist.

{{< note >}}

• GPU: Grafikprozessor, heute auch für parallele KI-Berechnungen.
• TPU: Spezialisierte Google-Hardware für effiziente Tensor-Operationen.
• NPU: Energiesparender KI-Beschleuniger für mobile und Edge-Geräte.
  {{< /note >}}

Ja, es gibt sie wirklich: große Sprachmodelle für den lokalen Einsatz

Aber: Es ist durchaus möglich, leistungsstarke offene Sprachmodelle lokal auf der eigenen Hardware zu betreiben. Projekte wie LLaMA (Meta), Mistral, Falcon, DeepSeek oder Mixtral sind so optimiert, dass sie auch auf normaler Consumer-Hardware (starke CPU, moderne GPU, ausreichend RAM) lauffähig sind.

Und das Erstaunliche: Manche dieser lokalen Modelle kommen in einzelnen Disziplinen – etwa beim Textverständnis, Programmieren oder in Benchmarks – den großen Cloud-Modellen beeindruckend nahe. Damit eröffnen sich für Forschung, Unternehmen und Privatpersonen völlig neue Möglichkeiten: von Datenschutz und Kostenkontrolle bis hin zu individuellen Anpassungen.

Wir sprechen hier meist von Sprachmodellen, doch aktuelle Systeme können längst viel mehr.
Sie verstehen nicht nur Text, sondern sind in der Lage, auch Bilder, Audio und sogar Video zu verarbeiten und zu erzeugen.

Deshalb spricht man heute nicht mehr ausschließlich von Sprachmodellen, sondern von multimodalen Foundation Modellen (kurz MFM).
Diese Modelle verknüpfen verschiedene Eingabe- und Ausgabeformen und eröffnen dadurch völlig neue Anwendungsmöglichkeiten – etwa Bildbeschreibung, Spracherkennung, Code-Generierung oder Videoanalyse.

Auch wenn einige Vorteile vielleicht dafürsprechen, es lokal zu versuchen – welche Nachteile gibt es?
Klar ist: Man benötigt auf jeden Fall leistungsstarke Hardware und ein gewisses Maß an technischem Know-how.

Neuronale Netze

Sprachmodelle – oder allgemeiner Multimodale Foundation Models (MFM) – basieren auf künstlichen neuronalen Netzen.
Diese sind von der Funktionsweise des Gehirns inspiriert und bestehen aus Millionen künstlicher Neuronen sowie Milliarden von Parametern.
Parameter sind die Gewichte und Bias-Werte, mit denen das Netzwerk während des Trainings Muster erkennt und z.B. Vorhersagen trifft.

Dass hierfür enorme Rechenleistung nötig ist, liegt auf der Hand.
Ein einzelner Prozessor (CPU) stößt hier ganz schnell an seine Grenzen – moderne Grafikkarten (GPUs) sind dagegen bestens geeignet.

Grafikkarten treiben lokale KI an

Warum? Neuronale Netze benötigen vor allem extrem viele Matrix-Multiplikationen.
Genau diese Art von Berechnungen sind seit jeher das Herzstück der 3D-Grafik:
Schon seit Jahrzehnten nutzen Computerspiele GPUs, um komplexe 3D-Spielwelten in Echtzeit zu berechnen.
Mit dem steigenden Anspruch an Grafikqualität haben sich Grafikkarten zu wahren Rechenmonstern entwickelt.

Heute profitiert die KI davon: Dieselbe Hardware, die für 3D-Spiele gedacht war, eignet sich auch hervorragend für das Training und den Betrieb neuronaler Netze.
(Zudem gibt es heute auch spezialisierte Chips wie TPUs von Google oder die Tensor Cores in NVIDIA-GPUs sowie andere dedizierte AI-Chips, die speziell für KI-Berechnungen entwickelt wurden.)

Wichtiger Faktor: Geschwindigkeit

Um möglichst viele Matrizen berechnen zu können, braucht es vor allem eine hohe Parallelität.
Das bedeutet: Viele Recheneinheiten („Shaderkerne“) und eine solide Taktfrequenz.

Was sind Shaderkerne?
Shaderkerne sind kleine Recheneinheiten innerhalb der GPU, die ursprünglich für die Berechnung von 3D-Grafik gedacht waren,

• Geometrie zu berechnen (Vertex-Shader)
• Farben und Pixel zu berechnen (Fragment-Shader)

Mit dem Aufkommen von KI kam eine weitere Nutzung hinzu: Compute-Shader.
Dabei handelt es sich um Programme, die auf Shaderkernen laufen und speziell für mathematische Operationen (z. B. Matrixmultiplikationen) entwickelt wurden.
(NVIDIA nennt sie daher CUDA-Kerne)

Im KI-Bereich spricht man deshalb oft von Kernels – hochoptimierten Routinen, die die eigentlichen Berechnungen übernehmen.

Warum ist das wichtig?

• Shaderkerne / CUDA-Kerne sind extrem zahlreich – bei aktuellen Karten wie der RTX 4090 über 16.000 Stück.
• Sie können gleichzeitig (parallel) rechnen, wodurch enorme Geschwindigkeiten erreicht werden.
• Für die Leistung sind daher sowohl die Taktfrequenz als auch vor allem die Anzahl der Kerne entscheidend.

Ausschlaggebend: Speicher

Noch wichtiger als die reine Rechengeschwindigkeit ist der Speicher – und zwar nicht der Hauptspeicher (RAM), sondern das VRAM (Video RAM) direkt auf der Grafikkarte.
Die Recheneinheiten der GPU (CUDA-/Shaderkerne) können ausschließlich auf diesen Grafikspeicher zugreifen.

Foundation Models sind riesig: Sie enthalten Milliarden von Parametern und benötigen daher enorme Mengen an Speicherplatz. Zusätzlich fällt während der Berechnung weiterer Speicherbedarf für Zwischenergebnisse (z.B. KV-Cache) an.
Das macht den Grafikspeicher zum eigentlichen Flaschenhals.

• Mit 8 GB VRAM lassen sich nur kleine Modelle (z. B. 7B-Modelle in starker Quantisierung) nutzen.
• 16 GB ermöglichen schon komfortableres Arbeiten und den Einsatz mittelgroßer Modelle.
• Ab 24 GB VRAM lassen sich auch größere Sprachmodelle lokal laden und sinnvoll betreiben.

Zwar ist es technisch möglich, den Hauptspeicher (RAM) einzubinden, wenn der VRAM nicht ausreicht – doch dann müssen Daten ständig zwischen Hauptspeicher und VRAM hin- und her kopiert werden.
Das verlangsamt die Berechnungen drastisch und macht eine sinnvolle Nutzung praktisch unmöglich.

Das Modell

Wir haben nun schon einige Male den Begriff Modell verwendet – aber was genau bedeutet das eigentlich?

Ein Modell ist das Ergebnis des Trainings eines neuronalen Netzes.
Es umfasst:

• die Parameter des Netzes (vor allem Gewichte und Bias-Werte),
• die Architektur des Netzwerks, also die Beschreibung der Schichten und ihrer Verbindungen (oft als Rechengraph dargestellt).

All diese Informationen werden in einer oder mehreren Dateien gespeichert und können später wieder geladen werden.
So wird aus dem trainierten Modell ein Werkzeug, das für die Inferenz – also die praktische Anwendung – genutzt werden kann.

Das sind letztlich die Rohdaten des Modells, die von einer passenden Runtime oder einem Framework geladen und ausgeführt werden können.
Ähnlich wie bei Bildern – die je nach Format (z. B. JPG, PNG, TIFF) unterschiedliche Eigenschaften haben – gibt es auch für Modelle verschiedene Speicherformate.
Nur wenn das richtige Format verwendet wird, kann ein Modell korrekt geladen und für die Inferenz ausgeführt werden.

Sprach- und Foundation-Modelle – wahre Giganten

Wir haben bereits erwähnt, dass Foundation Models extrem groß sein können. Aber wie groß ist „groß“?
Bei aktuellen Modellen geben die Betreiber – vermutlich aus Konkurrenzgründen – kaum noch Details wie Architektur oder genaue Parameterzahlen preis.
Es gibt jedoch Leaks und fundierte Schätzungen.

Demnach arbeiten diese Netzwerke mit bis zu Billionen von Parametern.
Allerdings werden je nach Architektur (z. B. Mixture of Experts, kurz MoE) nicht alle Parameter gleichzeitig genutzt.
Um Rechenzeit und Speicher zu sparen, werden pro Anfrage („Prompt“) nur bestimmte Experten-Teile des Netzes aktiviert.
Bei GPT-4 bedeutet das nach Schätzungen trotzdem immer noch rund 300 Milliarden aktive Parameter pro Inferenz.

Die Parameter liegen in der Regel als Fließkommazahlen im FP16-Format vor, also 2 Byte pro Parameter (seltener auch als BF16).
Allein das Modell würde damit schon 300 Milliarden × 2 Byte ≈ 600 GB VRAM belegen –
und das ohne zusätzliche Zwischenspeicherungen wie den KV-Cache, der bei langen Kontexten nochmals hunderte Gigabyte beanspruchen kann.

Alles in allem also: riesig und viel zu groß für den lokalen Einsatz.
Deshalb werden für den Betrieb auf normaler Hardware kleinere Modelle entwickelt und optimiert – die aber trotzdem eine erstaunliche Leistung erreichen.

Aktuelle Open-Weight-Modelle für lokale Nutzung

Die Größe der Modelle wird meist mit B angegeben – das steht im Englischen für „Billion“ (US-Zählweise) und entspricht Milliarden Parametern auf Deutsch.
Beispiel: LLaMA-3 8B bedeutet, dass das Modell etwa 8 Milliarden Parameter hat.

{{< note >}}
Die Größe von großen Sprachmodellen bzw. Foundation Models wird in der Anzahl der Parameter angegeben.
Die Einheit ist das amerikanische B für „Billion“ (US), was im Deutschen einer Milliarde entspricht.
In der Regel werden die Parameter als 16-Bit-Fließkommazahlen gespeichert – meist im Format FP16 oder BF16.
Das entspricht 2 Bytes pro Parameter.
{{< /note >}}

Rechnen wir kurz: Das kleinste Modell der Reihe, LLaMA-3 8B, hat rund 8 Milliarden Parameter.

Bei FP16/BF16 (16 Bit) entspricht das 2 Byte pro Parameter → 8B × 2 Byte ≈ 16 GB VRAM nur für die Modellgewichte.

Dazu kommt der KV-Cache für die Attention, dessen Größe linear mit der Kontextlänge wächst.
Als „sehr grobe“ Faustregel (bei 16 Bit):

• kleine Modelle bis ~10B Parameter → ca. 0,5 MB pro Token
• mittlere Modelle (~10–30B Parameter) → ca. 1 MB pro Token
• große Modelle (70B+) → ca. 3–4 MB pro Token

Praxisbeispiel (8k Kontext):

• 16 GB (Gewichte) + ~4 GB (KV-Cache) + Overhead ⇒ > 20 GB Gesamtbedarf

Selbst eine hochwertige Grafikkarte mit 16 GB VRAM reicht für LLaMA-3 8B in FP16 nicht mehr aus.

Trotzdem zu groß – Speicher weiter reduzieren

Drücken wir den Speicherbedarf einmal gedanklich herunter:

Modelle werden meist im Format FP16 ausgeliefert.

In FP16 besteht eine Zahl aus:

V EEEEE MMMMMMMMMM

• v = 1 Bit Vorzeichen
• e = 5 Bit Exponent (legt den Wertebereich fest)
• m = 10 Bit Mantisse (legt die Genauigkeit fest)

Damit lässt sich ein Bereich von rund −65.504 bis +65.504 abdecken.

Für viele KI-Modelle sind die Gewichte jedoch bereits auf den Bereich −1 bis +1 normalisiert.
Der große Exponentenbereich wird also kaum genutzt – die 5 Exponenten-Bits sind in diesem Fall überflüssig.

Theoretisch würden also 11 Bit (1+10) genügen, um Modellgewichte in diesem Bereich ohne Präzisionsverlust darzustellen.
Das entspräche einer Ersparnis von rund 31 % Speicher – allerdings nur als Gedankenmodell, da es kein echtes 11-Bit-Format gibt.

Wie kann man diese Modelle doch noch in den Griff bekommen?

Quantisierung – das Wunder der (fast) verlustfreien Komprimierung

Genau hier setzt Quantisierung an:
Sie reduziert die Bitbreite noch weiter – typischerweise auf 8 Bit oder sogar 4 Bit –
und erzielt dadurch enorme Einsparungen bei Speicher und Rechenaufwand, bei meist nur geringem Qualitätsverlust.

In unseren einfachen Rechnungen konnten wir bereits 5 Bit einsparen, ohne Genauigkeitsverluste.
In der Praxis lässt sich der Wertebereich jedoch nicht immer exakt auf –1 bis +1 begrenzen. Manchmal reicht er weiter, manchmal liegt er nur zwischen –0.2 und +0.2.
Daher arbeitet man nicht mit fixen Grenzen, sondern bestimmt den tatsächlichen Minimal- und Maximalwert der Parameter.
Die so entstehende Range zwischen Min und Max wird anschließend quantisiert, indem man sie in gleichmäßige (lineare) Abstände aufteilt.

Die Quantisierung wird in Bit angegeben, z. B. 8 Bit, 4 Bit oder sogar nur 2 Bit.

• 8 Bit = 256 Stufen
• 4 Bit = 16 Stufen
• Ganzzahlen: 8 Bit = 1 Byte

Beispiel:
Bei einem Range von –1 bis +1 (Breite = 2.0) und 8 Bit teilen wir diesen Bereich in 256 Stufen auf = 1 Byte

Teilen wir den Wertebereich 2.0 durch 256 Stufen, ergibt sich ein Skalierungswert von 0.0078125.
Das ist der Abstand von einer Stufe zur nächsten und bestimmt die Genauigkeit:

• Weniger Bits → größere Abstände → geringere Genauigkeit.

In der Praxis:

• Für jeden Parameter wird eine Stufe gespeichert (als Byte).
• Zusätzlich gibt es den Skalierungsfaktor.
• Diese Quantisierung passiert nach dem Training, aber vor der Nutzung des Modells.

Symmetrische Quantisierung

• Range ist um 0 symmetrisch (z. B. –1 bis +1).
• Nur ein Skalierungsfaktor wird gespeichert.
• Einfach, aber bei asymmetrischen Daten geht Präzision verloren.

Asymmetrische Quantisierung

• Range ist verschoben (z. B. –1 bis +0.2).
• Zusätzlich zum Skalierungsfaktor wird ein Nullpunkt (Zero Point) gespeichert.
• Der Zero Point legt fest, welche Ganzzahl genau den Wert 0 repräsentiert.
• Vorteil: Der verfügbare Wertebereich wird optimal genutzt.

Dequantisierung

Bei der Inferenz (Anwendung des Modells) liegen die Parameter nicht mehr als FP16-Werte vor, sondern z. B. nur noch als Ganzzahlenwerte (z. B. 1 Byte pro Gewicht).

Für die Berechnung müssen diese Ganzzahlen wieder in FP16 konvertiert werden:
Dies geschieht, indem man die Ganzzahl mit dem Skalierungsfaktor multipliziert.
Bei asymmetrischer Quantisierung wird zusätzlich der Nullpunkt (Zero Point) berücksichtigt.

Parameter_fp = (Stufe × Skalierungsfaktor) [+ Nullpunkt bei asymmetrisch]

Durch die Quantisierung können Fehler entstehen, wenn der rekonstruierte Wert vom ursprünglichen Wert abweicht.
Je weniger Bits verwendet werden, desto höher die mögliche Abweichung.

• Mit 8 Bit spart man bereits rund 50 % Speicherplatz, in der Praxis meist mit kaum messbaren Verlusten.
• Mit 4 Bit lassen sich sogar 75 % einsparen, allerdings steigt die Wahrscheinlichkeit von Genauigkeitsverlusten.

Faustregel:

• FP16: Originalpräzision → hohe Qualität, viel Speicherbedarf
• INT8: Standard für Inferenz → kaum Qualitätsverlust, große Ersparnis
• INT4: weitere starke Ersparnis → meist noch gute Qualität (mit spezieller Quantisierung)
• INT2: extreme Kompression → Qualität stark eingeschränkt, oft kaum brauchbar

Bedeutet das nicht großen Rechenaufwand?

Ja, für jeden Parameter ist eine Multiplikation und ggf. eine Addition (bei asymmetrischer Quantisierung) nötig.
Der VRAM-Gewinn gleicht diesen Mehraufwand aber meist aus.
Außerdem unterstützen moderne GPUs, TPUs und NPUs bereits spezielle Quantisierungs-Operatoren, die diese Schritte sehr effizient ausführen.

Bekommt das ganze Netzwerk die gleiche Skalierung?

Nicht unbedingt …
In der Praxis teilt man die Parameter oft in Spalten (Channels) oder Gruppen auf und vergibt dafür getrennte Skalierungsfaktoren.
Das verbessert die Genauigkeit deutlich gegenüber einer einzigen globalen Skalierung.

Werden alle Parameter des Modells quantisiert?

Grundsätzlich ja – aber die größten Einsparungen erzielt man bei den Hauptblöcken:

1. Attention (Q, K, V, O Projektionen):
   Belegen je nach Architektur rund 20–30 % der Parameter.
2. Feed Forward Network (FFN / MLP):
   Macht rund 60–70 % der Parameter aus.

Kleinere Teile wie Embeddings oder LayerNorms sind vergleichsweise unbedeutend. Die meisten Einsparungen durch Quantisierung entstehen also im FFN und im Attention-Block.

GPTQ (Gradient Post-Training Quantization)

GPTQ ist ein Verfahren, das nach dem Training angewendet wird und die Qualität der Quantisierung deutlich verbessert.

Dabei werden die Parameter nicht alle gleich behandelt, sondern nach ihrer Wichtigkeit unterschieden.
Mit Hilfe der Hessian-Matrix (eine Ableitungsmatrix, die Sensitivität und Krümmung beschreibt) wird abgeschätzt, wie stark sich ein Quantisierungsfehler bei einem bestimmten Parameter auf die Modellqualität auswirkt.

So erhalten wichtige Parameter feinere Skalierungen, während weniger wichtige Parameter gröber quantisiert werden können.
Das ermöglicht eine effizientere Kompression, bei gleichzeitig geringerem Qualitätsverlust.

Vorteil: GPTQ erlaubt oft Quantisierungen bis 4 Bit mit nur minimalen Genauigkeitseinbußen, wodurch große Modelle auf deutlich kleineren Geräten lauffähig werden.

Der Player für dein KI-Modell: die Runtime

Jetzt haben wir den etwas trockenen Teil hinter uns und wissen, worauf es ankommt und worauf wir achten müssen.
Einen passenden Computer mit starker Grafikkarte und ausreichend VRAM haben wir uns bereits besorgt.

Nun geht es in die Praxis: Wie lassen sich multimodale Foundation Models auf Consumer-Hardware nutzen?

Bei Modellen ist es ähnlich wie bei Videos: Mit der Datei allein kann der Computer wenig anfangen – er braucht einen Player, damit etwas passiert.
Was bei Videos der Videoplayer ist, ist bei Foundation Models die LLM-Runtime.
Sie lädt das Modell und bietet uns die Schnittstelle, um damit zu interagieren – zum Beispiel in Form eines Chats.

Wie KI-Software auf die Grafikkarte zugreift

Der Zugriff einer Runtime – oder allgemein von KI-Software – auf die GPU erfolgt in mehreren Ebenen.

• Unterste Ebene: die eigentliche Hardware (GPU).
  Dafür stellt der jeweilige Hersteller passende Treiber bereit.
  Diese Treiber sind nötig, damit das Betriebssystem und die Software überhaupt mit der GPU kommunizieren können.
• Darüber: der Zugriff auf die Hardware geschieht über eine Programmierschnittstelle (API).
  Diese kann entweder
  • herstellerspezifisch sein (z. B. CUDA von NVIDIA)
  • oder auf einem offenen Standard basieren (z. B. DirectML)

Diese Schnittstellen bilden die Grundlage, auf der KI-Frameworks wie PyTorch, TensorFlow oder KI Applikationen arbeiten.

Herstellerspezifische Schnittstellen

Diese Schnittstellen sind speziell für eine bestimmte Hardware-Familie optimiert (z. B. nur für NVIDIA).
Sie funktionieren ausschließlich auf den GPUs dieses Herstellers.

• Vorteil:
  Die besonderen Fähigkeiten und Funktionen der Hardware können gezielt und sehr performant genutzt werden.
• Nachteil:
  Für jede andere Hardware-Familie muss separat programmiert werden – ein Wechsel des Herstellers ist damit schwierig.

Beispiele:

• NVIDIA: CUDA
• AMD: ROCm
• Intel: oneAPI
• Apple: Metal (MPS)

Universelle Schnittstellen

Hier stellen Konsortien oder Standardisierungsorganisationen eine gemeinsame Schnittstelle bereit, die auf Hardware vieler Hersteller lauffähig ist.

• Vorteil:
  Eine Schnittstelle funktioniert mit GPUs verschiedener Anbieter – weniger Abhängigkeit vom Hersteller.
• Nachteil:
  Spezielle Funktionen einzelner GPUs können nicht ausgereizt werden, außerdem ist der Zugriff in der Regel etwas langsamer.

Beispiele:

• OpenCL: – Khronos Group
• Vulkan Compute: – Khronos Group
• DirectML: – Microsoft

Runtimes für lokale und skalierte Nutzung

Für die verschiedenen Betriebssysteme – Linux, Windows und macOS – stehen unterschiedliche Runtimes zur Verfügung.
Aktuell sind Linux-Nutzer etwas im Vorteil, da viele Tools zuerst für Linux entwickelt und optimiert werden.
Unter Windows lassen sich viele davon jedoch ebenfalls nutzen, z. B. über das Windows Subsystem for Linux (WSL).
Auch macOS wird inzwischen gut unterstützt, insbesondere seit es Apple Silicon (M1/M2/M3) mit eigener GPU-Beschleunigung gibt.

Wichtig ist die Unterscheidung nach dem Einsatzzweck:

• Lokale Runtimes für Einzelrechner (z. B. llama.cpp)
• Server- oder Cluster-Runtimes für skalierte Nutzung (z. B. vLLM)

Lokale Runtimes

Eine lokale Runtime ist in der Regel schnell installiert und eingerichtet.
Sie ist für den Betrieb auf einem einzelnen Rechner gedacht und eignet sich besonders für kleinere Workflows, die direkt auf dieser Maschine laufen oder sich gezielt mit genau diesem Rechner verbinden.

Typische Vertreter:

• llama.cpp – leichtgewichtig, sehr portabel, läuft auf fast allen Plattformen
• Ollama – CLI-/API-orientiert, einfach in eigene Anwendungen integrierbar
• LM Studio – benutzerfreundliche Desktop-App mit GUI und Modellverwaltung

Server- oder Cluster-Runtimes (Inference Engines)

Diese Runtimes sind deutlich komplexer in der Installation und richten sich an professionelle Anwendungen mit vielen gleichzeitigen Anfragen.
Sie sind für den Einsatz auf leistungsstarker Server-Hardware gedacht, oft mit mehreren GPUs, und lassen sich sehr gut skalieren – von einzelnen Servern bis hin zu großen Clustern.
Typischerweise werden dafür Datacenter-GPUs wie die NVIDIA A100 oder H100 genutzt.

Typische Vertreter:

• vLLM (UC Berkeley) – hochoptimierte Inference Engine, u. a. mit PagedAttention
• Text Generation Inference (TGI, Hugging Face) – Serving-Framework für Produktionsumgebungen
• TensorRT-LLM (NVIDIA) – maximal optimierte Inferenz auf NVIDIA-GPUs mit Tensor Cores

Für kleinere Anwendungen bieten sich lokale Runtimes an

Grundsätzlich brauchen wir einen Motor unter der Haube, der Modelle laden und ausführen kann.
Bei den lokalen Runtimes kommt sehr häufig llama.cpp zum Einsatz.

llama.cpp

llama.cpp ist eine extrem schnelle, hardwarenahe Bibliothek, die in C/C++ mit teils Assembler-Optimierungen entwickelt wurde.
Sie ermöglicht es, große Sprachmodelle effizient auch auf Consumer-Hardware laufen zu lassen.

• Bietet Bindings für viele Programmiersprachen (z. B. Python, Go, Rust), sodass andere KI-Programme unter verschiedenen Betriebssystemen die Funktionen der Bibliothek nutzen können.
• Dieser Zugriff erfolgt über eine API (Application Programming Interface).
• Zusätzlich gibt es ein Command Line Interface (CLI), über das man direkt mit der Bibliothek arbeiten kann.

llama.cpp kann GGUF-Modelle (Generalized GGML Unified Format) laden und ausführen – auch in quantisierter Form, um Speicher und Rechenleistung zu sparen.

llama.cpp auf GitHub

Da die direkte Nutzung von llama.cpp eher technisch und für Entwickler gedacht ist, greifen viele Nutzer auf eine höhere Abstraktionsebene zurück – also auf Runtimes oder Tools, die auf llama.cpp aufbauen und eine benutzerfreundlichere Oberfläche bieten.

LM Studio

LM Studio ist eine komfortable Runtime mit klarer GUI-Ausrichtung und richtet sich vor allem an Endanwender.
Es bietet eine integrierte Modell-Liste („Model Catalog“), über die man Modelle direkt auswählen und herunterladen kann.

Inzwischen legt das Projekt auch mehr Fokus auf Entwickler:

• Es gibt ein eigenes Command Line Tool (lms), mit dem sich Modelle laden, verwalten und der API-Server steuern lassen.
• Zusätzlich stellt LM Studio eine OpenAI-kompatible REST-Schnittstelle bereit, sodass es problemlos von anderen Programmen angesteuert werden kann.

Unterstützte Formate:

• GGUF (Standard für llama.cpp-basierte Runtimes)
• MLX (speziell für Apple über die MLX-Schnittstelle)

Basis: LM Studio baut intern auf llama.cpp auf, erweitert dies aber um GUI, API und Komfortfunktionen.

LM Studio Website
LM Studio Model Catalog

Ollama

Ollama ist stärker auf Developer ausgerichtet und bietet umfangreiche Steuerungsmöglichkeiten:

• Command Line Interface (CLI) für direkte Kontrolle
• OpenAI-kompatible REST-API für die Integration in eigene Anwendungen
• SDKs (z. B. für Python, JavaScript), um Ollama von außen programmatisch zu steuern

Inzwischen richtet sich Ollama aber auch zunehmend an Endanwender – dafür gibt es z. B. einen integrierten UI-Chat-Client.

Basis: Auch Ollama nutzt unter der Haube llama.cpp als Runtime.

Unterstützte Formate:

• Eigenes Ollama-Format (Modelfile), vergleichbar mit einem Dockerfile für Modelle.
• GGUF (Standard für llama.cpp-basierte Runtimes) – kann in ein Ollama-Format „importiert“ werden.
• PyTorch (.pt / .pth) – nach Konvertierung.
• Safetensors (.safetensors) – nach Konvertierung.

Modellbibliothek:
Ollama stellt eine eigene offizielle Modellbibliothek bereit, aus der Modelle direkt per CLI heruntergeladen und gestartet werden können:

Ollama Model Library

Ollama Website
Ollama GitHub

{{< note >}}
Was ist eigentlich …

• API (Application Programming Interface):
  Schnittstelle, über die Programme Funktionen einer Bibliothek aufrufen können.
• Library (Bibliothek):
  Sammlung von wiederverwendbaren Funktionen, die in eigenen Programmen genutzt werden können.
• SDK (Software Development Kit):
  Werkzeugkasten für Entwickler, der eine Bibliothek, Dokumentation, Beispiele und Tools enthält.
• REST API:
  Eine Web-API, die über das HTTP-Protokoll funktioniert und nach REST-Schema aufgebaut ist. Wird genutzt um Dienste über das Netzwerk anzusprechen.
  {{< /note >}}

Gängige Formate für Foundation Models

Welche Runtime passt am besten?

Die drei Runtimes unterscheiden sich zunehmend weniger in ihrem Funktionsumfang.
Am Ende ist es vor allem eine Frage der persönlichen Vorlieben:

• Wie schnell möchte ich starten?
• Wie viel Zeit und Energie will ich in Konfiguration und Feinschliff investieren?

Im nächsten Abschnitt werfen wir einen praktischen Blick auf die Ollama Runtime.

Ollama in der Praxis

In diesem Tutorial zeige ich dir die Installation und Nutzung von Ollama unter Windows.

Ollama herunterladen

Rufe die offizielle Download-Seite auf:

https://ollama.com/download

Dort wählst du dein Betriebssystem aus.

Installation

Nachdem der Download abgeschlossen ist, startest du die Installation.

• Standardinstallation (Ollama wird in den Standardordner installiert): OllamaSetup.exe
• Eigener Installationspfad (Beispiel): OllamaSetup.exe /DIR="D:DeinPfad"

Ollama starten

Die Installation ist abgeschlossen – jetzt können wir Ollama starten.
Da Ollama Command-Line-first ist, öffnen wir eine Eingabeaufforderung oder PowerShell und starten es dort:

Architektur von Ollama

Ollama hat einen hierarchischen Aufbau:

• Es basiert auf llama.cpp
• Beim Start öffnet es einen Port unter
  http://localhost:11434
• Darüber stellt es eine OpenAPI-kompatible REST-API bereit

Auf dieser Grundlage können verschiedene Clients mit Ollama kommunizieren – zum Beispiel:

• die Kommandozeile
• die Chat-Oberfläche
• externe AI-Programme oder Skripte

Ollama Modell laden

Nachdem Ollama läuft, wollen wir natürlich ein Modell starten, mit dem wir chatten können.

Modelle finden

Eine Übersicht verfügbarer Modelle findest du in der Ollama Library:
https://ollama.com/library

Modell herunterladen

Hast du ein Modell gefunden, kannst du es mit ollama pull in dein lokales Modellverzeichnis laden.
Beispiel:

ollama pull llama3.2-vision:11b-instruct-q4_K_M

Modell starten

Um mit dem Modell zu chatten, starten wir es mit ollama run:

ollama run llama3.2-vision:11b-instruct-q4_K_M

In diesem Beispiel verwende ich ein multimodales Vision-/Text-Modell (4-Bit quantisiert).
Das bedeutet: es kann sowohl Texteingaben als auch Bilder verarbeiten. Und obwohl es sich um ein sehr kleines, hochquantisiertes Modell handelt – und als Text-Vision-Modell im reinen Textverständnis nicht ganz so stark ist – liefert es bereits in deutscher Sprache beeindruckend gute Antworten.

Laufzeit-Parameter

Beim Start lassen sich zusätzliche Optionen setzen, um das Verhalten des Modells zu steuern.
Beispiel:

ollama run granite3.2-vision:latest -o temperature=0.2 -o num_ctx=4096

Hiermit werden die Parameter temperature und Kontextlänge (num_ctx) überschrieben.

Nützliche Befehle zur Modellverwaltung

• ollama list → installierte Modelle auflisten
• ollama show <modell> → Infos & Fähigkeiten eines Modells anzeigen
• ollama pull <modell> → Modell herunterladen
• ollama push <modell> → Modell hochladen
• ollama create <modell> → neues Modell anlegen
• ollama cp <quelle> <ziel> → Modell kopieren
• ollama rm <modell> → Modell löschen

Runtime-Befehle von Ollama

Neben den Modell-Management-Befehlen gibt es auch Runtime-Befehle, mit denen laufende Modelle gesteuert werden können:

• ollama stop <modell> → laufendes Modell stoppen
• ollama ps → aktuell laufende Modelle auflisten
• ollama serve → Ollama-Server ohne Modell starten

Modellquellen & Vertrauenswürdigkeit

Alle registrierten Modelle findest du hier:
https://ollama.com/library

Wichtig: Eine „echte“ zentrale Qualitätskontrolle gibt es nicht. Ollama ist eher ein Community-getriebenes Projekt.
Daher solltest du beim Download darauf achten, dass die Modelle von seriösen Uploadern stammen (z. B. direkt von Ollama selbst) und ein Modell validieren, bevor du es produktiv einsetzt.

Herkunft der Modelle

Viele Modelle werden von den Anbietern (Vendors) zunächst auf Hugging Face veröffentlicht:
https://huggingface.co/

Erst danach werden sie von der Community in die Ollama-Bibliothek übernommen.
Daher kann es manchmal etwas dauern, bis neue Modelle auch über Ollama verfügbar sind.

Modelle anpassen (Customizing)

Ollama erlaubt es, ein Modell zu customizen, sodass bestimmte Parameter oder Systemeinstellungen direkt ins Modell „eingebrannt“ werden.
Beispiel:

PARAMETER temperature 0.2
SYSTEM "Du bist ein hilfsbereiter Assistent"

Damit kannst du z. B. die Temperatur dauerhaft setzen oder ein globales System-Prompt definieren.

OpenAI-kompatible REST-API

Ollama bietet eine OpenAI-kompatible REST-API, über die sich Anfragen senden lassen – z. B. mit curl oder in einem Python-Skript.

Diese API hat sich inzwischen faktisch als Standard-Schnittstelle etabliert, um verschiedenste Sprach- und Foundation-Modelle anzusprechen.
Das bedeutet: Viele vorhandene Tools und Bibliotheken, die eigentlich für die OpenAI-API gedacht sind, lassen sich direkt mit Ollama nutzen.

API-Nutzung mit curl

Über die REST-API von Ollama lassen sich Modelle direkt ansprechen – zum Beispiel mit curl:

curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" -H "Authorization: Bearer ollama" -d "{"model":"llama3.2-vision:11b-instruct-q4_K_M","messages":[{"role":"user","content":"Welche Stadt ist die Landeshauptstadt von Vorarlberg?"}]}"

API-Nutzung mit python

#pip install openai

from openai import OpenAI

client = OpenAI(
    api_key="dummy",
    base_url="http://localhost:11434/v1"
)

resp = client.chat.completions.create(
    model="llama3.2-vision:11b-instruct-q4_K_M",
    messages=[{"role": "user", "content": "Welche Stadt ist die Landeshauptstadt von Vorarlberg?"}]
)

print(resp.choices[0].message.content)

... und wir erhalten jeweils das richige Ergebnis als json reponse: Bregenz

Environment-Variablen in Ollama

Ollama unterstützt verschiedene Environment-Variablen, mit denen sich Verhalten und Speicherorte anpassen lassen.
Hier eine kleine Auswahl (die vollständige Liste findest du in der offiziellen Dokumentation):

• OLLAMA_HOST → Server-Adresse & Port festlegen (z. B. 127.0.0.1:0815)
• OLLAMA_MODELS → Speicherort für Modell-Dateien überschreiben
• OLLAMA_DEBUG → auf 1 setzen, um zusätzliche Debug-Ausgaben zu aktivieren

Damit kannst du Ollama an deine lokale Umgebung und Workflows anpassen.

Dokumentation

Ollama ist gut dokumentiert – mit vielen Beispielen und Code-Snippets.
https://ollama.readthedocs.io/en/

Ollama GUI

Obwohl Ollama ursprünglich Command-Line-first entwickelt wurde, gibt es mittlerweile auch eine grafische Benutzeroberfläche (GUI).

Du kannst das GUI mit folgendem Befehl starten:

"ollama app.exe"

Frage im GUI: „Welche Stadt ist die Landeshauptstadt von Vorarlberg?“

Wenn du ein multimodales Modell (z. B. llama3.2-vision) verwendest, kannst du im GUI nicht nur Texteingaben machen, sondern auch Bilder hochladen.

So kannst du direkt Fragen zu einem Bild stellen – das Modell kombiniert dann Text- und Bildinformationen in seiner Antwort.

Nachdem wir ein Bild hochgeladen und eine Frage gestellt haben, liefert uns das multimodale Modell die passende Antwort.

Ollama im System-Tray

Neben der Kommandozeile und dem GUI ist Ollama nach der Installation auch im System-Tray verfügbar (Taskleiste unten rechts in Windows).

Einstellungen in Ollama

Über die Einstellungen in der Ollama-App lassen sich verschiedene Optionen anpassen.
Besonders interessant sind dabei:

• Model Location → legt fest, in welchem Verzeichnis die Modelle gespeichert werden.
• Context Length → bestimmt die Länge des Kontextfensters.
  • Je größer das Kontextfenster, desto mehr Text (oder Bildinformationen) kann das Modell gleichzeitig berücksichtigen.
  • Achtung: Ein größeres Kontextfenster benötigt auch mehr Grafikspeicher (VRAM).

Fazit

Lokale Foundation-Modelle sind längst kein Spielzeug mehr. Mit der richtigen Hardware und Runtime lassen sie sich heute effizient einsetzen – privat wie auch im Unternehmen. Sie bringen Datenschutz, Kontrolle und Kostenersparnis, erfordern aber auch technisches Know-how und klare Verantwortung.

Dies ist Teil 3 der Kursserie „ChatGPT & Co verstehen: Wie große Sprachmodelle wirklich arbeiten – anschaulich & interaktiv“.

Wie verarbeiten Computer eigentlich Texte?

Genau genommen: Gar nicht!
Computer sind pure Rechenmaschinen – sie verarbeiten intern ausschließlich Zahlen.
Mit natürlicher Sprache, wie wir sie sprechen oder schreiben, können sie absolut nichts anfangen.
Deshalb muss jeder Text zunächst in eine für den Computer verständliche Form übersetzt werden.

Ein Zeichen – eine Zahl: ASCII und ANSI

Jedes Zeichen (z. B. ein Buchstabe oder Satzzeichen) wird einer Zahl zugeordnet – typischerweise im Bereich von 0 bis 127 (für ASCII) oder bis 255 (für ANSI).

Diese Zahlen passen genau in ein Byte – die kleinste adressierbare Speichereinheit eines Computers.
Mit diesem Ansatz lassen sich alle englischen Buchstaben, Ziffern und einige Sonderzeichen abbilden.

flowchart TD
classDef bigText font-size:1.0em;

A([" Text-Eingabe"]):::bigText
B([" In Zahlen umwandeln"]):::bigText
C([" Computer verarbeitet Zahlen"]):::bigText
D([" Rückkonvertierung zu Zeichen"]):::bigText
E([" Ausgabe am Bildschirm"]):::bigText

A --> B --> C --> D --> E

Das funktioniert für amerikanisches Englisch perfekt. Doch diese einfache Codierung war auf den US-Markt beschränkt – für viele andere Sprachen reichte sie nicht aus.

Regionale Codepages

Außerhalb der USA gibt es viele Sprachen mit zusätzlichen Zeichen:
z. B. ä, ö, ü, ñ, ç, é – oder völlig andere Schriften wie Kyrillisch, Arabisch, Chinesisch.

Um dieses Problem zu lösen, wurden sogenannte Codepages eingeführt:

• Jedes Land oder Region hatte ihre eigene Zeichentabelle
• Die Zeichen ab Byte 128–255 wurden je nach Codepage unterschiedlich belegt

Das funktionierte lokal – aber beim Datenaustausch über Sprach- oder Landesgrenzen hinweg führte es zu Chaos:

• Texte wurden falsch dargestellt
• Ein Text konnte in einem Land lesbar sein, im anderen absolut unverständlich

Unicode – ein Zeichensatz für die ganze Welt

Um dieses Problem dauerhaft zu lösen, gründeten mehrere Tech-Unternehmen das Unicode Consortium.

Ziel:

Ein gemeinsamer Standard, der alle Zeichen aller Sprachen der Welt eindeutig codieren kann.

Der Unicode-Standard wurde geboren – und mit ihm konnten nun auch:

• Chinesische Schriftzeichen
• Kyrillisch, Arabisch
• Mathematische Symbole
• Emojis
• … und viele weitere Zeichenarten verarbeitet werden

Unicode verwendet 1 bis 4 Bytes pro Zeichen, je nach Codierung (z. B. UTF-8, UTF-16, UTF-32).
UTF-8 ist heute der häufigste verwendete Zeichensatz, da er alle Unicode-Zeichen variabel mit 1 bis 4 Bytes kodiert, platzsparend ist und vollständig mit ASCII kompatibel bleibt.

Damit war endlich möglich:

• Sprachübergreifender Textaustausch
• Einheitliche Darstellung auf allen Geräten
• Kein Chaos mit Codepages

Aber Achtung: Nicht alle Texte werden im Unicode-Format gespeichert – der Ärger ist also noch nicht ganz ausgestanden …

Maschinelles Textverständnis: Weit mehr als nur Worte

Das sinnvolle Erfassen von Texten ist für Computer eine enorme Herausforderung. Was für uns Menschen selbstverständlich ist, stellt Computer vor riesige Probleme.
Mit traditionellen Programmiertechniken ließ sich dieses Problem nicht lösen.

Frühere Ansätze versuchten, Texte mithilfe einfacher Algorithmen zu analysieren – etwa um E-Mails als Spam zu erkennen.

1. Mustererkennung: Programme suchten im Text nach typischen Wortmustern oder Phrasen, die auf Spam hindeuten.
2. Bag-of-Words-Modell (BoW): Der Text wurde in einzelne Wörter zerlegt und diese gezählt.
   Begriffe wie „kostenlos“ oder „gewinnen“ waren statistisch häufiger in Spamnachrichten zu finden.

Diese Algorithmen lieferten teilweise erstaunlich gute Ergebnisse – aber mit wirklichem Textverständnis hatten sie nichts zu tun.

Transformer: Der Durchbruch

Erst durch neuronale Netzwerke – und insbesondere durch die Einführung von Transformer-Modellen – wurde es möglich, Sprache mit Kontext und Bedeutung zu erfassen. Damit begann eine neue Ära im maschinellen Sprachverständnis.

LLMs (Large Language Models) schaffen es mithilfe genialer Techniken, die Bedeutung einzelner Wörter – genauer gesagt: Tokens – zueinander in Beziehung zu setzen.
Dadurch können sie Texte nicht nur lesen, sondern auch semantisch verstehen.

Doch auch bei LLMs beginnt alles mit einem essentiellen Schritt:
Der Text muss zunächst in eine für den Computer verständliche Form umgewandelt werden – sprich: in Zahlen.

Dazu wird die Eingabe in kleine Einheiten zerlegt – sogenannte Tokens.

Textbruchstücke – Tokens

Tokens sind die grundlegenden Bausteine eines Texts.
Sie können ganze Wörter sein, Wortbestandteile oder auch einzelne Zeichen.
Jedem Token wird eine eindeutige numerische ID zugewiesen – über das sogenannte Vokabular, eine Tabelle aller bekannten Tokens.
Diese IDs sind die Grundlage für die Rechenoperationen im Sprachmodell.

Ausschnitt aus dem Vokabular

Wie wurde dieses Vokabular erstellt?

Bevor ein Sprachmodell wie GPT trainiert wird, analysieren spezielle Algorithmen Milliarden von Texten, um die häufigsten Zeichenfolgen zu identifizieren.
Diese Zeichenfolgen – ganze Wörter, Wortbestandteile oder einzelne Zeichen – bilden die Grundlage für das sogenannte Vokabular, also die Token-Tabelle.

Das Verfahren dahinter nennt sich Byte Pair Encoding (BPE).
Ziel ist es, wiederkehrende Textmuster zu finden, die sich effizient als Token darstellen lassen.
Erst auf Basis dieser Tokens kann das Sprachmodell lernen, mit Text zu rechnen und Bedeutung abzuleiten.

LLMs wie ChatGpt sind wahre Sprachgenies – sie verstehen über 90 Sprachen

Dabei werden nicht nur Wörter aus einer Sprache berücksichtigt.
Modelle wie ChatGpt sind multilingual – sie wurden mit Texten in über 90 Sprachen trainiert.

Dementsprechend enthält das Vokabular Tokens aus vielen verschiedenen Sprachräumen, zum Beispiel:

• Englisch
• Deutsch
• Chinesisch
• Arabisch
  … und viele mehr.

So kann das Modell nicht nur Text in verschiedenen Sprachen erkennen – es kann ihn auch verstehen, analysieren und weiterverarbeiten.

Der Tokenizer

Der Tokenizer ist die Komponente, die einen Text in kleinere Einheiten – sogenannte Tokens – zerlegt.

GPT-Tokenizer Live-Demo!

Probier’s einfach aus – gib deinen Text ein und sieh live, wie GPT ihn in Tokens zerlegt!

(GPT-3 verwendet denselben Tokenizer wie GPT-2 – auf Byte Pair Encoding (BPE) basierend.)

Dieser Prozess läuft in 4 Schritten ab:

flowchart TD
classDef step fill:#eef,stroke:#888,stroke-width:1px,rx:10,ry:10,font-size:1em;

A[ UTF-8-Encoding]:::step
B[ Byte-to-Unicode-Mapping]:::step
C[ Byte Pair Encoding]:::step

subgraph LEXP [Token-ID-Zuordnung]
direction LR
D[Vokabular]:::step --> E[„hello“ → 7592]:::step
end
A --> B --> C --> LEXP

1. UTF-8-Encoding
   Der Text wird zunächst in Bytes umgewandelt – also Zahlen zwischen 0 und 255.
2. Byte-to-Unicode-Mapping
   Nicht alle Bytewerte entsprechen direkt sichtbaren Zeichen (z. B. Steuerzeichen). GPT-3 verwendet deshalb den sogenannten „Byte-to-Unicode-Trick“, um jeden Bytewert eindeutig in ein darstellbares Unicode-Zeichen zu konvertieren. So können alle Zeichen sicher verarbeitet werden.
3. Byte Pair Encoding (BPE)
   Anschließend wird die Zeichenfolge mithilfe von Byte Pair Encoding in Tokens zerlegt.
   Häufig vorkommende Zeichen- oder Wortteile werden gemäß einer Merge-Tabelle zu größeren Einheiten zusammengeführt.
   Beispiel: t + h → th
4. Token-ID-Zuordnung
   Die gefundenen Tokens werden nun im Vokabular nachgeschlagen.
   Jeder Token hat dort eine eindeutige numerische ID, mit der das Modell arbeiten kann.

Am Ende dieses Prozesses entsteht eine Liste von Token-IDs – also eine Zahlenfolge, die das Sprachmodell als Eingabe verarbeitet.

Ein interessanter Aspekt ist das sogenannte „greedy Verhalten“:
Der Tokenizer wählt stets das längst mögliche passende Token aus dem Vokabular.

Trotzdem wird ein vorhandenes Token wie „grüße“ nicht immer als solches verwendet.
Warum?

• Es kommt auf exakte Übereinstimmung an (Groß-/Kleinschreibung, Kodierung).
• Wird kein exakter Treffer gefunden, wird das Wort in Subtokens aufgeteilt – z. B. Grüß + e oder gr + ü + ße.

Tiktoken – die etwas modernere Variante

Neuere Modelle wie GPT-4 verwenden nicht mehr den ursprünglichen GPT-2/3-Tokenizer, sondern eine leicht optimierte Variante namens Tiktoken. Tiktoken basiert weiterhin auf Byte Pair Encoding (BPE), wurde aber intern so optimiert, dass er schneller, Unicode-sicherer und robuster bei mehrsprachiger Eingabe ist.