Kurzantwort: Ein Large Language Model berechnet aus Tokens und Kontext schrittweise wahrscheinliche Fortsetzungen. ChatGPT oder Gemini sind darüberliegende Produkte, die zusätzlich Systemanweisungen, Suche, Dateien, Speicher und Tools einsetzen können. Eine flüssige Antwort ist deshalb weder ein direkter Datenbankabruf noch automatisch wahr. Eingabe → Tokens → Kontext → Modell → Tokenwahl → Antwort ist die Grundkette.
Large Language Models wirken im Chat einfach: Frage eingeben, Antwort erhalten. Technisch liegen dazwischen jedoch mehrere Schichten. Das Basismodell hat gelernte Parameter. Die Anwendung baut einen aktuellen Kontext. Optional sucht sie im Web oder in internen Dokumenten, ruft ein Tool auf oder speichert Gesprächsinformationen. Erst danach wird die Antwort tokenweise erzeugt.
Diese Unterscheidung ist für Unternehmen und für LLMO entscheidend. Wer „ChatGPT kennt unsere Website“ sagt, vermischt möglicherweise Trainingsdaten, Websuche, Retrieval und die aktuelle Antwort. Der LLM-System-Evaluationsplan als CSV hilft, Aufgabe, Quelle, Modellzugang und Testergebnis getrennt zu dokumentieren. Alle Ergebnisfelder sind bewusst leer; es handelt sich um eine Vorlage, nicht um einen Benchmark.
Die wichtigste Unterscheidung: Modell, Produkt und System
Ein Modell ist ein trainiertes mathematisches System mit Parametern. Es nimmt eine Folge von Tokens entgegen und erzeugt Wahrscheinlichkeiten für weitere Tokens oder andere Ausgaben.
Ein Produkt wie ChatGPT oder Gemini Apps kombiniert ein oder mehrere Modelle mit einer Benutzeroberfläche, Systemregeln, Datei-Uploads, Suche, Personalisierung, Sicherheitsfiltern und weiteren Funktionen. OpenAI weist ausdrücklich darauf hin, dass ChatGPT regelmäßig neue Modelle erhält und ältere Modelle eingestellt werden können. Deshalb ist „getestet in ChatGPT“ ohne Datum, Modus und Modellangabe nur begrenzt reproduzierbar. Die OpenAI-Hilfe zu Modellwechseln beschreibt genau diese Produktdynamik.
Ein Produktionssystem umfasst zusätzlich die eigene Anwendung: Datenquellen, Berechtigungen, Prompts, Retrieval, Tools, Protokollierung, Reviews und Fallbacks. Die Qualität des Basismodells ist nur ein Teil seiner Qualität.
| Ebene | enthält | kann sich ändern | sinnvoll protokollieren |
|---|---|---|---|
| Basismodell | Architektur, Gewichte, Tokenisierung | durch neue Modellversion | exakte Modell-ID und Anbieter |
| Chat- oder API-Produkt | Systemanweisung, Routing, Suche, Filter, Speicher | häufig und teilweise ohne Einfluss des Nutzers | Produkt, Modus, Tarif, Datum, Region |
| eigener Workflow | Prompt, Daten, Tools, Rechte, Nachprüfung | durch eigenes Deployment | Versionsstand jedes Bestandteils |
| einzelne Antwort | konkreter Kontext und Tokenauswahl | bei jedem Lauf | Eingabe, Quellen, Output und Urteil |
1. Tokenisierung: Text wird in verarbeitbare Einheiten zerlegt
Das Modell verarbeitet nicht direkt Wörter, Sätze oder Bedeutungen. Ein Tokenizer zerlegt Eingaben in Token-IDs. Ein Token kann ein Wort, ein Wortteil, ein Satzzeichen oder bei multimodalen Systemen eine anders kodierte Einheit sein.
Die Folge
Welche Leistungen bietet die LLMO Agentur Berlin?
wird daher nicht zwingend in sieben ganze Wörter zerlegt. Schreibweise, Sprache und Tokenizer beeinflussen Anzahl und Grenzen der Tokens. Tokens sind relevant für Kontextlimits, Abrechnung, Latenz und die Position von Informationen.
Googles Einführung in Large Language Models definiert Sprachmodelle als Systeme, die Wahrscheinlichkeiten von Tokens oder Tokenfolgen im Kontext schätzen. Diese Definition ist präziser als „das Modell schlägt im Wissen nach“.
2. Embeddings und Position: Tokens erhalten mathematische Repräsentationen
Token-IDs werden in Vektoren, sogenannte Embeddings, überführt. Diese Zahlenrepräsentationen sind trainiert und tragen Beziehungen, die das Modell für seine Berechnung nutzt. Zusätzliche Positionsinformationen helfen, Reihenfolge zu unterscheiden.
Embeddings sind keine lesbaren Lexikoneinträge. Einzelne Bedeutungen liegen nicht sauber in einer Koordinate. Informationen entstehen verteilt über viele Dimensionen, Schichten und Parameter.
Ein Embedding-Modell für eine Suchanwendung ist außerdem nicht automatisch identisch mit den internen Repräsentationen des generierenden Modells. Bei RAG kann ein separates Embedding-Modell Dokumente und Suchfrage in einen Raum abbilden, um ähnliche Textabschnitte zu finden.
3. Transformer und Self-Attention: Kontextbeziehungen berechnen
Die 2017 veröffentlichte Arbeit Attention Is All You Need führte den Transformer als Architektur für Sequenzverarbeitung ein. Ein zentraler Mechanismus ist Self-Attention: Für die Verarbeitung eines Tokens werden Beziehungen zu anderen Tokens im verfügbaren Kontext gewichtet.
Vereinfacht beantwortet eine Attention-Schicht für jedes Token die Frage: Welche anderen Token sind für seine aktuelle Repräsentation relevant? Mehrere Attention-Köpfe und aufeinanderfolgende Schichten können unterschiedliche Muster abbilden. Feedforward-Netze, Residual-Verbindungen und Normalisierung verarbeiten die Repräsentationen weiter.
Wichtig: Nicht jedes moderne LLM besteht aus einem Encoder und einem Decoder. Der ursprüngliche Transformer nutzte beide. Viele generative Modelle sind decoder-only und verwenden kausale Attention, sodass bei der Generierung nur vorherige Tokens berücksichtigt werden. Encoder-only und Encoder-Decoder-Modelle existieren weiterhin für andere Aufgaben. Googles Transformer-Grundlagen unterscheiden diese Varianten.
Self-Attention ist auch kein Beweis für menschliches Verstehen. Sie ist eine mathematische Operation innerhalb eines gelernten Systems.
4. Pretraining: Muster in Daten lernen
Beim Pretraining wird ein Modell mit großen Datenmengen darauf optimiert, fehlende oder nächste Tokens vorherzusagen. Über sehr viele Beispiele passt das Training die Parameter so an, dass die Vorhersageverluste sinken.
Dadurch lernt das Modell nicht nur Wortfolgen. Um viele Fortsetzungen gut vorherzusagen, bildet es auch Grammatik, Stil, Code-Strukturen, Faktenmuster und Beziehungen ab. Trotzdem enthält es keine verlässliche Liste aller Trainingsquellen und keinen eingebauten Herkunftsnachweis für jede erzeugte Aussage.
Allgemeine Aussagen wie „jedes LLM wurde mit Webseiten, Büchern und Petabytes trainiert“ sind zu grob. Datensätze, Größen, Filterung und Offenlegung unterscheiden sich. Ohne Model Card oder technische Dokumentation des Anbieters sollte eine konkrete Trainingsquelle nicht behauptet werden.
5. Post-Training: Anweisungen und Verhalten formen
Ein vortrainiertes Modell sagt zunächst plausible Fortsetzungen voraus. Post-Training richtet es stärker auf Aufgaben, Dialoge, Präferenzen und Sicherheitsziele aus. Verfahren können überwachte Beispiele, menschliche Präferenzdaten, KI-generiertes Feedback, Reward-Modelle oder andere Optimierungsmethoden kombinieren.
Die OpenAI-Arbeit Training language models to follow instructions with human feedback dokumentiert einen konkreten RLHF-Ansatz für InstructGPT. Daraus folgt nicht, dass jedes heutige Modell exakt denselben Prozess oder PPO verwendet. Anbieter und Modellgenerationen können andere Post-Training-Verfahren nutzen.
Post-Training kann Verhalten verbessern, garantiert aber keine Wahrheit, Harmlosigkeit oder Regelbefolgung in jeder Eingabe.
6. Inferenz: Das nächste Token wird wiederholt ausgewählt
Bei einem Aufruf erhält das Modell den zusammengestellten Kontext. Daraus berechnet es für viele mögliche nächste Tokens Werte, die in eine Wahrscheinlichkeitsverteilung überführt werden. Ein Auswahlverfahren bestimmt das nächste Token. Danach wird das gewählte Token an den Kontext angehängt und der Vorgang wiederholt.
Generierungseinstellungen können beeinflussen, wie stark die Auswahl auf sehr wahrscheinliche Tokens konzentriert oder breiter verteilt wird. Selbst bei niedriger Variation können Infrastruktur, Routing, Modellupdate oder Toolergebnis Unterschiede erzeugen. Für reproduzierbare Tests müssen deshalb mehr als Prompt und Markenname gespeichert werden.
Wahrscheinlich heißt nicht wahr. Ein sprachlich passender Satz kann faktisch falsch sein. Das Modell optimiert in der Grundfunktion die Fortsetzung, nicht einen automatischen Abgleich mit einer autoritativen Datenbank.
7. Kontextfenster: aktueller Arbeitsbereich, nicht Langzeitgedächtnis
Der Kontext enthält je nach System:
- System- und Entwickleranweisungen,
- aktuelle Nutzereingabe,
- relevante Teile des Gesprächs,
- hochgeladene Dateien oder Dokumentauszüge,
- Suchergebnisse und Toolantworten,
- gegebenenfalls gespeicherte Präferenzen,
- bereits generierte Tokens.
Das Kontextfenster begrenzt, wie viele Tokens gemeinsam verarbeitet werden. Spezifische Limits ändern sich mit Modellen. Die Gemini-API stellt beispielsweise inputTokenLimit und outputTokenLimit über die Models-Schnittstelle bereit. Das ist belastbarer als eine dauerhaft in einen Ratgeber geschriebene Modellvergleichstabelle.
Ein großes Fenster garantiert nicht, dass jedes Detail gleich gut genutzt wird. Relevanz, Position, widersprüchliche Inhalte und Instruktionshierarchie beeinflussen die Antwort. Ein Produktgedächtnis über mehrere Chats ist eine zusätzliche Anwendungsschicht und nicht dasselbe wie Parameter oder der Kontext eines einzelnen Aufrufs.
8. Suche, RAG und Tools: externe Informationen gelangen in den Kontext
Ein Basismodell durchsucht bei der Inferenz nicht automatisch das Internet. Anwendungen können aber externe Systeme anbinden.
Websuche
Ein Suchprodukt wählt Suchanfragen, ruft Ergebnisse ab und stellt Auszüge oder Seiten als Kontext bereit. OpenAI beschreibt ChatGPT Search als Verbindung von Gespräch und Webquellen. Ob eine konkrete Antwort sucht und welche Quelle erscheint, hängt von Produkt, Frage und Zeitpunkt ab.
Retrieval-Augmented Generation
Bei RAG durchsucht die Anwendung einen definierten Bestand, etwa Handbücher, Produktdaten oder freigegebene Wissensartikel. Typischer Ablauf:
- Dokumente werden bereinigt, segmentiert und mit Metadaten versehen.
- Suchfrage und Segmente werden für Retrieval repräsentiert.
- Ein Retriever wählt Kandidaten.
- Berechtigungen und gegebenenfalls Reranking filtern die Auswahl.
- Auszüge gelangen mit der Aufgabe in den Modellkontext.
- Das Modell formuliert eine Antwort und idealerweise Quellenverweise.
RAG macht falsche Antworten nicht unmöglich. Schlechte Dokumente, falsche Segmentierung, fehlende Berechtigungen, Retrieval-Lücken oder eine nicht belegte Synthese bleiben Fehlerquellen. Der Leitfaden LLM und RAG: Scope und Anbieterwahl trennt Website-Optimierung von interner Retrieval-Architektur.
Tools und Function Calling
Ein Modell kann strukturierte Argumente für ein bereitgestelltes Tool erzeugen. Die Anwendung führt die Funktion aus und gibt das Ergebnis zurück. Googles Gemini-Tool-Dokumentation unterscheidet eingebaute Tools von kundenseitig ausgeführten Funktionen.
Das Modell besitzt durch eine Funktionsbeschreibung noch keine zuverlässige Fähigkeit, eine Aktion sicher auszuführen. Die Anwendung muss Argumente validieren, Berechtigungen begrenzen, Ergebnisse prüfen, Seiteneffekte bestätigen und Fehler behandeln.
Warum LLMs falsche oder unbelegte Antworten erzeugen
NIST bezeichnet überzeugend präsentierte falsche Inhalte im Generative AI Profile als Confabulations. Sie sind mit der statistischen Erzeugung verbunden und können je nach Kontext viele Formen annehmen.
Typische Ursachen oder Verstärker sind:
- der Kontext enthält keine belastbare Antwort,
- Quellen widersprechen sich oder sind veraltet,
- Retrieval liefert irrelevante Passagen,
- die Aufgabe fordert eine Antwort trotz fehlender Evidenz,
- ein Produkt nutzt keine aktuelle Suche,
- das Modell verbindet plausible Muster falsch,
- eine Toolantwort wird falsch interpretiert,
- Prompt Injection verändert die Instruktionslage.
„RAG reduziert Halluzinationen“ ist deshalb nur als Hypothese für einen konkreten Aufbau sinnvoll. Gemessen werden müssen Quellenrichtigkeit, Antworttreue und Verhalten bei fehlender Evidenz.
Sicherheits- und Governance-Grenzen
Sicherheitsfilter allein machen einen LLM-Workflow nicht sicher. Ein System mit Dateizugriff, Kundendaten oder schreibenden Tools braucht technische und organisatorische Kontrollen.
| Risiko | notwendige Kontrolle | Abnahmebeispiel |
|---|---|---|
| sensible Eingabe | Datenklassifizierung, Minimierung, Anbieter- und Vertragsprüfung | Testdaten enthalten keine unzulässigen personenbezogenen Daten |
| Prompt Injection | Inhalt und Instruktion trennen, Quellen als untrusted behandeln | manipuliertes Dokument erhält keine höheren Rechte |
| falsche Toolargumente | Schema-Validierung und Allowlist | ungültige ID oder Aktion wird abgewiesen |
| unerwünschter Seiteneffekt | Least Privilege und Bestätigung | Buchung, Versand oder Löschung braucht explizite Freigabe |
| unbelegte Antwort | Quellenpflicht und Abbruchregel | System meldet fehlende Evidenz statt zu raten |
| Modellupdate | versioniertes Evaluationsset | neue Version muss definierte Tests bestehen |
Googles aktuelle Safety and factuality guidance empfiehlt anwendungsbezogene Risikoprüfung, Tests, Nachbearbeitung und menschliche Evaluation. „Mit Safety Layers sind LLMs sicher“ wäre dagegen ein unzulässiges Pauschalversprechen.
ChatGPT vs. Gemini: Warum eine statische Bestenliste schnell veraltet
ChatGPT und Gemini Apps können unterschiedliche Modelle, Modi und Tools anbieten. Modellnamen, Limits und Verfügbarkeit ändern sich. Eine Tabelle mit ausgemusterten Modellgenerationen wäre 2026 keine tragfähige Grundlage mehr.
Die richtige Auswahl erfolgt über den konkreten Workflow:
- Aufgabe und Entscheidung definieren.
- erlaubte Daten und notwendige Quellen festlegen.
- Qualitäts- und Sicherheitskriterien beschreiben.
- Latenz, Kosten und Betriebsanforderungen festhalten.
- konkrete Produkt- und Modellversionen testen.
- Fehlerfälle und „keine Antwort“-Verhalten bewerten.
- nach jedem relevanten Update erneut testen.
Für eine aktuelle Produktentscheidung bietet der Vergleich Gemini vs. ChatGPT einen datierten Kriterienrahmen. Er ersetzt ebenfalls keinen Pilot mit eigenen Aufgaben.
LLM-Evaluationsplan für Unternehmen
Eine Demonstration mit fünf frei formulierten Fragen ist kein Produktionsnachweis. Ein sinnvolles Testset enthält reale, freigegebene Fälle und bekannte Sollantworten.
1. Use Case begrenzen
Formulieren Sie Eingang, gewünschte Ausgabe, Nutzergruppe und Entscheidung. „Marketing unterstützen“ ist zu breit; „freigegebene Produktdaten in ein Entwurfsformat überführen“ ist prüfbar.
2. Risikoklasse festlegen
Bewerten Sie den möglichen Schaden einer falschen, verspäteten oder unerlaubten Ausgabe. Hochriskante Entscheidungen brauchen stärkere Kontrollen oder dürfen nicht autonom erfolgen.
3. Referenzfälle bauen
Sammeln Sie typische, schwierige, mehrdeutige und adversariale Eingaben. Dokumentieren Sie zulässige Quellen, Sollverhalten und ausdrücklich verbotenes Verhalten.
4. Systemversion protokollieren
Speichern Sie Produkt, Modell-ID, Promptversion, Retrieval-Index, Toolversion, Datum und relevante Generierungsparameter. Ohne diese Angaben ist ein späterer Vergleich schwach.
5. Mehrere Qualitätsachsen messen
Prüfen Sie nicht nur Stil. Relevante Achsen können Faktentreue, Quellenrichtigkeit, Vollständigkeit, Format, Sicherheit, Latenz, Kosten und korrektes Ablehnen sein.
6. Deployment-Gate und Regression definieren
Legen Sie vor dem Test fest, welche Fehler einen Rollout stoppen. Wiederholen Sie das Set nach Modell-, Prompt-, Daten-, Tool- oder Berechtigungsänderungen.
Der Download enthält Beispieltests für Quellenfragen, unbekannte Fakten, Prompt Injection, Toolargumente, personenbezogene Daten und Modellwechsel. Die Felder für tatsächlichen Output, Quelle, Urteil und Reviewer bleiben bis zum realen Test leer.
Was diese Funktionsweise für SEO und GEO bedeutet
Eine Website verändert nicht direkt die Gewichte eines fremden Basismodells. Sie kann jedoch als veröffentlichte Quelle für Such-, Retrieval- und Antwortprodukte auffindbar sein. Daraus folgen nüchterne Maßnahmen:
- zentrale Aussagen sichtbar und belegbar veröffentlichen,
- technische Erreichbarkeit und Indexierbarkeit sicherstellen,
- Entitäten und Beziehungen widerspruchsfrei erklären,
- Originaldaten mit Methode und Stand bereitstellen,
- wichtige Inhalte nicht nur in Bildern oder Interaktionen verstecken,
- Prompt- und Citation-Beobachtungen getrennt von Traffic und Conversion messen.
Der Leitfaden zu technischen LLMO-Voraussetzungen zeigt, welche Website-Kontrollen tatsächlich prüfbar sind. Eine Citation ist kein Beweis dafür, dass ein Modell mit einer Seite trainiert wurde. Sie zeigt nur, dass eine Oberfläche diese Quelle in der beobachteten Antwort ausgewiesen hat.
Fazit: Die Antwort entsteht im System, nicht nur im Modell
LLMs erzeugen Antworten, indem sie aus Kontext und Parametern schrittweise Tokens auswählen. Transformer, Pretraining und Post-Training bilden die Modellgrundlage. Chat-Produkte ergänzen Systemanweisungen, Suche, Dateien, Speicher und Tools. Der eigene Workflow bringt Daten, Rechte, Evaluation und Verantwortung hinzu.
Wer diese Ebenen trennt, kann bessere Entscheidungen treffen: nicht „Welches Modell ist das beste?“, sondern „Welche Systemkonfiguration besteht unsere realen Tests mit vertretbarem Risiko?“
Wenn Sie einen konkreten Workflow mit Quellen, Risiken und Regressionstests prüfen möchten, können Sie eine LLM-Systemevaluation mit dokumentierter Abnahme buchen. Im Funnel wird appointment_booked erst nach bestätigter Terminwahl erfasst und nicht mit einem CTA-Klick gleichgesetzt.
Quellen und Prüfgrundlage
- Vaswani et al.: Attention Is All You Need
- Google Machine Learning: Introduction to Large Language Models
- Google Machine Learning: Transformers
- OpenAI: Training language models to follow instructions with human feedback
- OpenAI: What to expect when models change
- Google Gemini API: Models
- Google Gemini API: Using Tools
- NIST: Generative Artificial Intelligence Profile
Häufig gestellte Fragen
Wie erzeugt ein Large Language Model eine Antwort?
Das Modell zerlegt den verfügbaren Kontext in Tokens, berechnet daraus Wahrscheinlichkeiten für mögliche nächste Tokens und setzt die Auswahl schrittweise fort. Die konkrete Antwort hängt neben den Modellparametern auch von Systemanweisung, Gespräch, eingebundenen Quellen, Tools und Generierungseinstellungen ab.
Versteht ein LLM Sprache wie ein Mensch?
LLMs bilden komplexe statistische Repräsentationen sprachlicher und anderer Muster. Sie können viele Aufgaben überzeugend lösen, doch flüssige Sprache beweist weder menschliches Verständnis noch Bewusstsein, Absicht oder eine verlässliche interne Faktenquelle.
Sind ChatGPT und Gemini jeweils ein einzelnes LLM?
Nein. ChatGPT und Gemini Apps sind Produkte beziehungsweise Oberflächen, die Modelle, Systemanweisungen, Sicherheitsmechanismen, Suche, Speicher, Dateien und Tools kombinieren können. Anbieter aktualisieren oder ersetzen zugrunde liegende Modelle, weshalb Produktname und exakte Modellversion getrennt protokolliert werden sollten.
Kennt ein LLM automatisch aktuelle Informationen aus dem Internet?
Nein. Modellparameter sind keine Live-Verbindung zum Web. Aktuelle Informationen können über Websuche, Retrieval, Dateien oder andere Tools in den Kontext gelangen. Ob eine Oberfläche sucht, welche Quellen sie auswählt und wie sie diese nutzt, ist produkt- und anfrageabhängig.
Verhindert RAG Halluzinationen vollständig?
Nein. RAG kann relevante Quellen bereitstellen, aber Retrieval kann falsche oder unpassende Dokumente liefern und das Modell kann Belege falsch zusammenfassen. Quellenqualität, Chunking, Berechtigungen, Zitierprüfung, Abbruchregeln und anwendungsspezifische Tests bleiben notwendig.
Ist ein großes Kontextfenster dasselbe wie Gedächtnis?
Nein. Ein Kontextfenster begrenzt die Tokens, die ein Modell für einen Aufruf verarbeiten kann. Es ist weder garantiertes Langzeitgedächtnis noch perfekte Aufmerksamkeit auf jedes Detail. Produktseitiger Gesprächsspeicher oder gespeicherte Präferenzen sind separate Funktionen.
Wie wählt ein Unternehmen zwischen Modellen und Produkten?
Nicht anhand einer pauschalen Bestenliste. Definieren Sie Aufgabe, Daten, Risiko, notwendige Quellen, Latenz und Kosten. Bauen Sie danach ein festes Evaluationsset, testen Sie konkrete Modell- und Produktversionen und wiederholen Sie die Tests nach Modell-, Prompt-, Daten- oder Tooländerungen.
Kostenlose Ersteinschätzung
Passt ein LLM wirklich zu Ihrem Anwendungsfall?
Wir zerlegen Aufgabe, Quellen, Risiko, Modellzugang und Messkriterien – bevor ein Chat-Produkt oder eine API zum Produktionssystem wird.
LLM-Einsatz prüfenErgebnis zuerst. Kontaktdaten erst, wenn Sie fortfahren möchten.
