1-Million-Token-Kontextfenster: Können Verträge, Forschungsunterlagen und Repos auf einmal gelesen werden?

Die bessere Frage lautet deshalb nicht nur: Passt es hinein? Sondern: Sind die Daten sauber, ist die Aufgabe eng genug gestellt, und lässt sich jede wichtige Aussage wieder am Original prüfen?

Schnellcheck: Was eignet sich für einen einzigen Durchlauf?

Die Tabelle zeigt den Kernpunkt: Ein großes Kontextfenster macht den Gesamtblick wahrscheinlicher. Es bedeutet aber nicht, dass ein unbearbeiteter Datenhaufen automatisch die beste Eingabe ist. Gerade bei Repositories ist das wichtig: Große Codebases werden zwar als Einsatzfeld langer Kontextfenster genannt, doch eine große Codebase ist nicht dasselbe wie ein ungefiltertes Projektverzeichnis mit allen Abhängigkeiten, Build-Artefakten und Altdaten.

Verträge: Ja, aber als Prüfauftrag formulieren

Ein einzelner langer Vertrag ist oft ein sinnvoller Anwendungsfall. Verträge sind in der Regel gegliedert: Definitionen, Klauseln, Anhänge, Nummerierungen, Verweise. Genau diese Struktur hilft dem Modell, relevante Stellen zu ordnen. Große Dokumente werden auch in der Berichterstattung zu 1-Million-Token-Kontextfenstern als naheliegender Anwendungsfall beschrieben.

Das Risiko liegt weniger darin, dass der Text nicht hineinpasst. Gefährlicher ist eine elegant klingende Zusammenfassung, die sich nicht mehr auf konkrete Stellen zurückführen lässt. Statt allgemein zu fragen: „Welche Probleme hat dieser Vertrag?“, sollte die Aufgabe auf Fundstellen, Zitate und Risikokategorien ausgerichtet werden.

Ein brauchbarer Prompt wäre zum Beispiel:

Erstelle eine Übersicht nach Klauselnummern zu Zahlungsfristen, Kündigungsrechten, Haftungsbegrenzungen, Vertraulichkeit und Folgen eines Vertragsbruchs. Gib zu jedem Punkt einen kurzen Originalauszug an und markiere Stellen, die juristisch geprüft werden sollten.

So wird das Modell zuerst zum Nachweis gezwungen und erst danach zur Bewertung. Für Rechtsabteilungen, Einkauf oder Vertrieb ist das lange Kontextfenster damit vor allem ein Werkzeug für Erstprüfung, Strukturierung und Vorbereitung. Es ersetzt keine verbindliche rechtliche Prüfung.

Forschungsunterlagen: Besonders stark beim Quervergleich

Bei Forschungsdossiers ist der Wert oft nicht die Zusammenfassung eines einzelnen Dokuments. Interessanter ist der Vergleich: Welche Befunde wiederholen sich? Welche Annahmen unterscheiden sich? Wo widersprechen sich Definitionen, Methoden oder Ergebnisse? Welche Einschränkungen nennen die Autorinnen und Autoren selbst?

Hier spielt ein großes Kontextfenster seine Stärke aus: Mehrere Berichte, Paper, Interviewprotokolle oder Marktanalysen können in einem gemeinsamen Arbeitsgang betrachtet werden, statt jede Datei einzeln zusammenzufassen und die Synthese anschließend manuell zusammenzubauen.

Sinnvolle Aufgaben sind etwa:

1. Mehrere Berichte in eine gemeinsame Vergleichstabelle bringen.
2. Aussagen markieren, die von mehreren Quellen gestützt werden.
3. Widersprüche bei Begriffen, Annahmen oder Ergebnissen herausarbeiten.
4. Pro Studie Methode, Stichprobe, Grenzen und offene Fragen extrahieren.
5. Aus den Lücken neue Forschungsfragen oder Interviewleitfäden ableiten.

Für solche Arbeiten lohnt sich eine Evidenzmatrix: Neben jeder Schlussfolgerung stehen Quelldokument, Abschnitt oder Seitenhinweis sowie ein kurzer Originalauszug. Das lange Kontextfenster erleichtert den gleichzeitigen Blick auf viele Materialien. Es ersetzt aber nicht die saubere Nachverfolgung. Genau darauf zielt die Kritik, dass 1 Million Token zwar beeindruckend sind, aber nicht automatisch alle Anforderungen realer Workflows abdecken.

Repositories: Nicht den ZIP-Ordner hochladen, sondern kuratieren

Code-Repositories sind einer der reizvollsten Anwendungsfälle. TestingCatalog nennt große Codebases als Einsatzfeld für 1-Million-Token-Kontextfenster; eine technische Analyse beschreibt zudem, dass GPT-4.1 für lange Kontexte und das Auffinden von Informationen darin trainiert wurde.

Trotzdem sind Repos heikel. Sie enthalten oft sehr viel Rauschen: externe Abhängigkeiten, generierte Dateien, Build-Ausgaben, alte Testdaten, Snapshots, Binärdateien oder historische Artefakte. Das Modell braucht meist nicht alles, sondern die für die Aufgabe relevanten Strukturen: Einstiegspunkte, Konfiguration, Kernmodule, Schnittstellen, Fehlermeldungen und Reproduktionsschritte.

Typischerweise sollten Sie zunächst ausschließen oder erst später nachreichen:

• node_modules/, vendor/ und andere Verzeichnisse mit Drittanbieter-Abhängigkeiten
• große generierte Dateien, sofern nicht genau deren Output untersucht werden soll
• Build-Artefakte und temporäre Ausgaben
• Binärdateien, Bilder, Modellgewichte und große Assets
• massenhafte Fixtures, Snapshots oder Testdaten
• Backups, alte Exporte und temporäre Dateien ohne Bezug zur Aufgabe

Stabiler ist diese Reihenfolge: Zuerst Verzeichnisbaum, README, Architekturhinweise und zentrale Konfigurationsdateien. Danach die relevanten Kernmodule. Anschließend Fehlermeldungen, Stacktraces, Reproduktionsschritte, fehlgeschlagene Tests oder das gewünschte Verhalten. So entsteht ein nachvollziehbarer technischer Kontext, statt das verfügbare Fenster mit Nebengeräuschen zu füllen.

Drei häufige Missverständnisse

1. 1 Million Token heißt nicht: Alles ungeprüft hineinwerfen

Die größere Obergrenze macht Aufgaben mit langen Dokumenten und Codebases realistischer. Sie entfernt aber nicht automatisch Duplikate, Scanfehler, generierte Inhalte, veraltete Anhänge oder irrelevante Dateien. Wer den Kontext mit Ballast füllt, darf sich nicht wundern, wenn die Antwort ungenauer wird.

2. Modellgrenze und Plattformgrenze können auseinanderfallen

Wenn ein Modell mit bis zu 1 Million Token Kontext beschrieben wird, bedeutet das nicht zwingend, dass jede API-Umgebung, jeder Cloud-Dienst und jedes Produktpaket dieselbe praktische Obergrenze unter denselben Bedingungen bereitstellt. In Microsoft Q&A berichtete ein Nutzer, dass er bei Azure OpenAI mit gpt-4.1 schon deutlich unter 1 Million Token auf context window exceeded gestoßen sei. Das ist vor allem ein Warnsignal für mögliche Deployment-Unterschiede, keine allgemeingültige Aussage über jede Umgebung.

3. Langer Kontext ist keine perfekte Suche

Material im Kontext zu haben bedeutet: Das Modell kann darauf zugreifen. Es bedeutet nicht: Das Modell findet jeden relevanten Absatz zuverlässig, gewichtet ihn korrekt und zitiert ihn fehlerfrei. Eine kritische Analyse beschreibt das 1-Million-Token-Fenster von GPT-4.1 als beeindruckend, aber für reale Anwendungsfälle weiterhin nicht ausreichend als alleinige Lösung.

Ein praxistauglicher Workflow

Wer Verträge, Forschungsunterlagen oder Repos mit langem Kontext analysieren will, sollte in dieser Reihenfolge arbeiten:

1. Token grob abschätzen. Nicht nur nach Seitenzahl, Dateianzahl oder Megabyte gehen. Textformat, Sprache, Tabellen, OCR und Code können sehr unterschiedlich tokenisiert werden.
2. Daten bereinigen. Duplikate, irrelevante Anhänge, generierte Dateien, Abhängigkeitsordner, Scanmüll und historische Ausgaben entfernen.
3. Struktur erhalten. Bei Dokumenten: Überschriften, Seiten, Absätze, Klauselnummern. Bei Repos: Pfade, Dateinamen, Verzeichnisbaum.
4. Erst Belege anfordern. Das Modell soll zunächst Klauseln, Absätze, Dateipfade oder Codeausschnitte nennen, bevor es bewertet.
5. Die Aufgabe eng stellen. Nicht: „Was ist hier alles problematisch?“ Besser: „Finde Konflikte in Zahlungsbedingungen“, „Vergleiche die Schlussfolgerungen dieser acht Studien“ oder „Welche Module hängen wahrscheinlich mit diesem Fehler zusammen?“
6. Risikoreiche Ergebnisse getrennt prüfen. Verträge, Finanzen, Medizin, Sicherheit und Änderungen an Produktionscode sollten nicht allein auf Basis einer einzigen langen Ausgabe entschieden werden.

Wann sind Chunking oder Retrieval besser?

Ein langes Kontextfenster ist besonders hilfreich, wenn ein gemeinsamer Gesamtblick nötig ist. Es ist weniger ideal, wenn Daten ständig aktualisiert werden, jede Aussage satzgenau rückverfolgbar sein muss, viele Versionen verglichen werden oder ein Repository große irrelevante Teilbereiche enthält.

Dann kann 1 Million Token als Übersichtsebene dienen, während die Detailarbeit über Retrieval-Augmented Generation, also gezielte Suche über einen Dokumenten- oder Codebestand, über Teilzusammenfassungen, Tests und menschliches Review läuft. Das passt zur grundsätzlichen Einordnung: Die Fähigkeit ist stark, aber noch nicht die vollständige Lösung für jeden realen Workflow.

Die praktische Kurzfassung

• Ein einzelner vollständiger Vertrag: meist gut geeignet. Entscheidend sind Klauselnummern, Originalauszüge und Risikokategorien.
• Ein Paket Forschungsunterlagen: häufig geeignet. Besonders stark für Vergleiche, gemeinsame Befunde, Widersprüche und offene Fragen.
• Ein ganzes Repo: nur bei bereinigten kleinen bis mittleren Projekten oder bei klar eingegrenzter Aufgabe wirklich sinnvoll. Große Monorepos und Ordner mit vielen generierten oder externen Dateien sollten vorher gefiltert werden.
• Auch wenn alles hineinpasst: Eine lange Eingabe ersetzt keine Belegprüfung. 1 Million Token löst vor allem das Kapazitätsproblem. Ob die Antwort zuverlässig findet, zitiert und urteilt, hängt weiter von Datenqualität, Prompt-Design, Beleganforderung und menschlicher Kontrolle ab.