Textfenster
Ein Sprachmodell oder Einbettungsmodell kann immer nur einen begrenzten Abschnitt eines Textes gleichzeitig verarbeiten. Diese Obergrenze heißt Textfenster. Sie bestimmt, wie viel Kontext dem Modell zur Verfügung steht.
Das Textfenster wird in Tokens gemessen. Ein Token entspricht je nach Sprache und Tokenizer einem Wort, einem Wortteil oder einem einzelnen Zeichen. Ein deutsches Wort erzeugt im Durchschnitt 1,3 bis 1,8 Tokens. Bei einem Modell mit 512 Tokens Textfenster ergibt das rund 280 bis 400 Wörter, die gleichzeitig verarbeitet werden können.
Wird ein Text länger als das Textfenster, schneidet das Modell den Rest ab. Diesen Vorgang nennt man Truncation. Der abgeschnittene Teil fließt nicht in die Berechnung ein. Bei Einbettungsmodellen bedeutet das: Informationen jenseits der Grenze fehlen im resultierenden Vektor. Bei generativen Modellen bedeutet es: Der abgeschnittene Kontext existiert für das Modell nicht.
Typische Größen und ihre Konsequenzen
Frühe Transformer-Modelle wie BERT arbeiten mit einem Textfenster von 512 Tokens. Dieses Limit stammt aus der Architektur: Der Self-Attention-Mechanismus berechnet für jedes Token-Paar einen Gewichtungswert, und der Rechenaufwand wächst quadratisch mit der Fensterlänge.
Beispiel: Ein Produktbeschreibungstext mit 800 Wörtern erzeugt rund 1.200 Tokens. Ein Modell mit 512 Tokens Textfenster verarbeitet davon nur die ersten 512. Preisangaben, technische Daten oder Garantiebedingungen am Ende des Textes gehen verloren.
Beispiel: Ein juristischer Vertrag mit 5.000 Wörtern erzeugt etwa 7.500 Tokens. Selbst ein Modell mit 8.192 Tokens Textfenster erfasst diesen Text nicht vollständig. Klauseln im letzten Drittel werden abgeschnitten.
Neuere Einbettungsmodelle bieten größere Fenster. Jina Embeddings v3 verarbeitet bis zu 8.192 Tokens, einige experimentelle Modelle erreichen 32.768 oder mehr. Die Vergrößerung allein löst das Problem aber nicht vollständig: Der Rechenaufwand steigt, und längere Eingaben erzeugen nicht automatisch bessere Repräsentationen.
Was passiert bei Truncation
Truncation schneidet den Text an der Token-Position ab, die dem Textfenster entspricht. Bei den meisten Modellen geschieht das am Ende des Textes. Einige Modelle bieten die Möglichkeit, am Anfang oder in der Mitte zu kürzen, das ist aber selten.
Beispiel: Ein FAQ-Dokument beginnt mit einer allgemeinen Einleitung und enthält die konkreten Antworten erst ab dem dritten Absatz. Bei Truncation am Ende gehen genau diese Antworten verloren. Bei Truncation am Anfang ginge die Einleitung verloren, die den Kontext liefert.
Das Problem betrifft besonders die Suche. Wenn ein Einbettungsmodell einen Text nur teilweise liest, repräsentiert der resultierende Vektor nur den gelesenen Teil. Eine Suchanfrage, die sich auf den abgeschnittenen Abschnitt bezieht, findet das Dokument nicht oder bewertet es niedrig.
Beispiel: In einem technischen Handbuch steht die Fehlerbehebung auf Seite 12. Das Einbettungsmodell hat nur die ersten drei Seiten verarbeitet. Die Suchanfrage "Fehlermeldung E-4012 beheben" ergibt keinen Treffer, obwohl das Dokument die Antwort enthält.
Chunking als Strategie gegen Textfenstergrenzen
Wenn ein Text das Textfenster überschreitet, gibt es eine verbreitete Lösung: den Text in kleinere Abschnitte aufteilen, die jeweils innerhalb des Fensters liegen. Dieses Verfahren heißt Chunking.
Jeder Chunk wird einzeln durch das Einbettungsmodell verarbeitet und erhält einen eigenen Vektor. Bei der Suche wird die Anfrage gegen alle Chunk-Vektoren verglichen. Der Treffer zeigt dann nicht das ganze Dokument, sondern den relevanten Abschnitt.
Beispiel: Ein 20-seitiges Whitepaper wird in 40 Chunks zu je 256 Tokens aufgeteilt. Bei einer Suchanfrage wird der relevanteste Chunk identifiziert. Der Nutzer erhält genau den Absatz, der die Antwort enthält, statt das gesamte Dokument durchsuchen zu müssen.
Chunking führt allerdings zu einem Kompromiss: Jeder Chunk verliert den Kontext der umliegenden Chunks. Ein Satz, der sich auf einen vorherigen Absatz bezieht ("wie oben beschrieben"), ist im isolierten Chunk nicht mehr verständlich. Überlappende Chunks mildern dieses Problem, erhöhen aber die Anzahl der Vektoren und damit den Speicher- und Rechenaufwand.
Überlappung und Grenzeffekte
Um Informationsverlust an Chunk-Grenzen zu verringern, überlappen viele Chunking-Verfahren die Abschnitte. Typische Überlappungen liegen bei 10 bis 20 Prozent der Chunklänge.
Beispiel: Bei Chunks von 512 Tokens und einer Überlappung von 64 Tokens teilen benachbarte Chunks jeweils 64 Tokens. Ein Satz, der genau an der Chunk-Grenze liegt, ist in beiden Chunks enthalten und kann in beiden gefunden werden.
Die Wahl der Überlappungsgröße ist ein Abwägen: Zu wenig Überlappung lässt Grenzeffekte bestehen. Zu viel Überlappung verdoppelt oder verdreifacht die Anzahl der Vektoren und erhöht die Suchzeit. In der Praxis wird die Überlappung oft empirisch bestimmt, indem man die Suchqualität auf einem Testdatensatz misst.
Beispiel: Ein Unternehmen indexiert 100.000 Support-Dokumente. Ohne Überlappung entstehen 250.000 Chunks. Mit 20 Prozent Überlappung steigt die Zahl auf etwa 310.000 Chunks. Die Suchqualität verbessert sich um 4 Prozent, der Speicherbedarf steigt um 24 Prozent. Ob sich das lohnt, hängt von den Anforderungen ab.
Warum das Textfenster begrenzt ist
Die Begrenzung des Textfensters hat einen technischen Grund. Der Attention-Mechanismus in Transformer-Modellen vergleicht jedes Token mit jedem anderen Token. Bei einer Eingabe von n Tokens entstehen n² Vergleiche. Verdoppelt sich die Fensterlänge, vervierfacht sich der Rechenaufwand.
Beispiel: Bei 512 Tokens berechnet der Attention-Mechanismus 262.144 Gewichtungen. Bei 2.048 Tokens sind es 4.194.304. Bei 8.192 Tokens sind es 67.108.864. Der GPU-Speicherbedarf wächst entsprechend.
Verschiedene Ansätze versuchen, diese quadratische Skalierung zu umgehen. Sparse-Attention-Verfahren lassen jedes Token nur mit einer Teilmenge der anderen Tokens interagieren. Lineare Attention-Varianten approximieren die vollständige Attention-Matrix mit geringerem Aufwand. Beide Ansätze ermöglichen längere Textfenster, gehen aber Kompromisse bei der Genauigkeit ein.
Fachliche Einordnung: Die quadratische Komplexität O(n²) des Standard-Attention-Mechanismus ist der zentrale Flaschenhals für längere Textfenster. Verfahren wie Longformer (Beltagy et al., 2020) kombinieren lokale Sliding-Window-Attention mit globaler Attention auf ausgewählten Tokens und erreichen damit O(n)-Komplexität. Die Qualität dieser Approximationen hängt stark von der Aufgabe ab.
Textfenster in RAG-Systemen
In RAG-Systemen (Retrieval-Augmented Generation) spielt das Textfenster eine doppelte Rolle. Zuerst begrenzt es den Retrieval-Schritt: Das Einbettungsmodell, das die Suchanfrage und die Dokumente in Vektoren umwandelt, hat ein eigenes Textfenster. Dann begrenzt es den Generierungsschritt: Das generative Modell, das die Antwort formuliert, hat ebenfalls ein Textfenster.
Beispiel: Ein RAG-System verwendet ein Einbettungsmodell mit 512 Tokens und ein generatives Modell mit 4.096 Tokens. Die Retrieval-Komponente findet drei relevante Chunks zu je 400 Tokens. Das generative Modell erhält die Suchanfrage (50 Tokens), die drei Chunks (1.200 Tokens) und den Systemprompt (200 Tokens). Insgesamt 1.450 Tokens. Es bleiben 2.646 Tokens für die Antwort.
Die Dimensionierung der Chunks hängt also nicht nur vom Einbettungsmodell ab, sondern auch davon, wie viele Chunks das generative Modell gleichzeitig als Kontext erhalten soll. Kleinere Chunks erlauben mehr Kontext-Quellen, größere Chunks liefern zusammenhängendere Information.
Beispiel: Ein Prompt mit Systemnachricht (300 Tokens), zehn Chunks zu je 200 Tokens (2.000 Tokens) und Nutzerfrage (50 Tokens) belegt 2.350 Tokens. Bei einem generativen Modell mit 4.096 Tokens bleiben 1.746 Tokens für die Antwort. Reduziert man die Chunks auf fünf, steigt der verfügbare Platz für die Antwort auf 2.746 Tokens, aber das Modell hat weniger Quellmaterial.
Grenzen und offene Fragen
Die Vergrößerung von Textfenstern löst nicht alle Probleme. Studien zeigen, dass Modelle mit sehr langen Kontexten dazu neigen, Informationen in der Mitte des Textes schlechter zu gewichten als Informationen am Anfang oder Ende. Dieses Phänomen heißt "Lost in the Middle" (Liu et al., 2023).
Beispiel: Ein Modell mit 128.000 Tokens Textfenster erhält 50 Dokumente als Kontext. Die relevante Information steht in Dokument 25. In Tests sinkt die Antwortqualität gegenüber der Platzierung in Dokument 1 oder Dokument 50 messbar ab.
Zudem erhöht ein größeres Textfenster die Latenz und die Kosten. Bei API-basierten Modellen wird der Preis pro Token berechnet. Mehr Kontext-Tokens bedeuten höhere Kosten pro Anfrage, unabhängig davon, ob der zusätzliche Kontext die Antwort tatsächlich verbessert.
Fachliche Einordnung: Die optimale Strategie für den Umgang mit dem Textfenster hängt vom Anwendungsfall ab. Für kurze, strukturierte Dokumente (Produktbeschreibungen, FAQ-Einträge) reichen kleine Textfenster mit 512 Tokens. Für lange, unstrukturierte Texte (Verträge, technische Handbücher) ist Chunking mit Überlappung in Kombination mit einem größeren Einbettungsmodell die robustere Wahl. Die Entscheidung erfordert Tests auf dem konkreten Datensatz.