Die Werbebotschaft ist verlockend: Ein Sprachmodell mit einem Kontextfenster von einer Million Token soll ganze Projekte in einem Rutsch verarbeiten. Man lädt das Repository hoch, stellt eine Frage und erhält eine Antwort, die den gesamten Zusammenhang berücksichtigt. Eine aktuelle Analyse auf Golem.de weist darauf hin, dass genau das in der Praxis nicht zuverlässig funktioniert: Trotz beworbener Kontextlängen von Millionen Zeichen versagen die Modelle bei großen Dokumenten.

Für Unternehmen, die KI in Entwicklung, Dokumentation oder Redaktion einbauen wollen, ist das eine relevante Einschränkung. Denn sie verschiebt den Aufwand: nicht das größere Modell löst das Problem, sondern die saubere Aufbereitung der Eingaben.

Was das Kontextfenster überhaupt ist

Ein Kontextfenster bezeichnet die Menge an Text, die ein Modell bei einer Anfrage gleichzeitig berücksichtigen kann. Gemessen wird sie in Token, also in Textbausteinen, die je nach Sprache etwa einem Wortteil entsprechen. Alles, was in diesem Fenster steht, ist für das Modell sichtbar: die Systemanweisung, der Verlauf des Gesprächs, angehängte Dateien und die eigentliche Frage.

Die Größe des Fensters sagt allerdings nur, wie viel hineinpasst. Sie sagt nichts darüber, wie gut das Modell die einzelnen Stellen darin tatsächlich nutzt. Genau hier liegt die Lücke zwischen technischer Spezifikation und Ergebnisqualität.

Viel Kontext heißt nicht viel Aufmerksamkeit

Je länger die Eingabe, desto mehr konkurrieren die enthaltenen Informationen um die begrenzte Verarbeitungskapazität des Modells. Bei umfangreichen Dokumenten und Codebasen führt das dazu, dass einzelne Details untergehen oder falsch verknüpft werden. Das Modell antwortet dann nicht mit einem klaren Hinweis auf fehlende Information, sondern formuliert plausibel klingende Aussagen, die im Detail nicht stimmen.

Bei Code ist dieser Effekt besonders unangenehm. Eine Klasse, die an einer Stelle definiert und an fünfzig anderen genutzt wird, verlangt genaue Referenzen. Wenn das Modell eine Methodensignatur leicht verschiebt oder eine Konfigurationsoption erfindet, fällt das im Lesen kaum auf, führt aber in der Umsetzung zu Fehlern. Der Prüfaufwand steigt genau dort, wo die Zeitersparnis versprochen wurde.

Kosten und Latenz wachsen mit

Neben der Qualität spielt die Wirtschaftlichkeit eine Rolle. Abgerechnet wird in der Regel pro Token, und zwar auch für die Eingabe. Wer bei jeder Frage ein komplettes Projekt mitsendet, bezahlt bei jeder Iteration erneut für Material, das für die konkrete Aufgabe größtenteils irrelevant ist. Zusätzlich steigt die Antwortzeit, was bei interaktiven Werkzeugen im Entwicklungsalltag schnell störend wirkt.

Der scheinbar einfachste Weg, alles hineinzuwerfen, ist damit auch der teuerste und der langsamste. Und er liefert nicht das beste Ergebnis.

Was stattdessen funktioniert

Die Alternative besteht darin, dem Modell weniger, aber besser ausgewähltes Material zu geben. Dafür haben sich einige Vorgehensweisen etabliert:

  • Gezielte Auswahl statt Vollabgabe. Nur die Dateien und Abschnitte in den Kontext geben, die für die Aufgabe tatsächlich gebraucht werden: die betroffene Klasse, ihre direkten Abhängigkeiten, die zugehörigen Tests.
  • Sinnvolle Segmentierung. Große Dokumente in inhaltlich abgeschlossene Abschnitte zerlegen, statt sie nach Zeichenzahl zu schneiden. Ein halber Absatz oder eine zerteilte Funktion sind als Kontext wertlos.
  • Abruf nach Bedarf. Bei sogenannten Retrieval-Verfahren werden passende Textstellen zur Frage aus einem Index gesucht und nur diese mitgegeben. Das Modell arbeitet dann mit wenigen relevanten Ausschnitten statt mit dem Gesamtbestand.
  • Verdichtete Zwischenebenen. Architekturübersichten, Modulbeschreibungen oder gepflegte Schnittstellendokumentation sind kompakter als der Quellcode und oft aussagekräftiger für Fragen auf Systemebene.
  • Aufgaben zerlegen. Mehrere klar umrissene Anfragen mit eng gefasstem Kontext liefern verlässlichere Ergebnisse als eine große Anfrage, die alles auf einmal klären soll.

Dokumentationsqualität wird zum technischen Faktor

Daraus folgt eine unbequeme, aber nützliche Erkenntnis: Die Wirksamkeit von KI-Werkzeugen hängt an der Ordnung des eigenen Materials. Ein Projekt mit klaren Modulgrenzen, sprechenden Bezeichnungen und aktueller Dokumentation lässt sich deutlich besser mit einem Modell bearbeiten als ein historisch gewachsenes System ohne Struktur.

Das gilt genauso für Content-Prozesse. Wer Redaktionsinhalte, Produktdaten oder Richtlinien in gepflegter, strukturierter Form vorhält, kann sie gezielt in Anfragen einspeisen. Wer stattdessen auf verstreute Dateien in unterschiedlichen Formaten zurückgreift, verlagert das Problem lediglich in den Kontext des Modells, wo es nicht gelöst, sondern nur unsichtbar wird.

Was man bei der Einführung prüfen sollte

Bei der Auswahl von Werkzeugen lohnt es sich daher, nicht auf die beworbene Kontextlänge zu schauen, sondern auf die Frage, wie ein System entscheidet, welches Material es dem Modell überhaupt vorlegt. Werkzeuge, die transparent machen, welche Dateien und Abschnitte sie einbezogen haben, sind in der Fehlersuche erheblich brauchbarer als solche, die den Vorgang verbergen.

Ebenso sinnvoll ist eine eigene kleine Testreihe mit typischen Fragen aus dem eigenen Projekt. Ob ein Modell bei einem Textbeispiel aus der Werbebroschüre gut abschneidet, sagt wenig darüber, wie es sich im konkreten Altsystem verhält.

Einordnung für Web- und Softwareprojekte

Große Kontextfenster sind ein nützlicher technischer Fortschritt, aber sie ersetzen keine Informationsarchitektur. In Web- und Softwareprojekten zahlt sich deshalb die Arbeit aus, die ohnehin sinnvoll ist: klare Modulgrenzen, aktuelle Dokumentation, strukturierte Inhalte. Genau diese Grundlagen entscheiden darüber, ob KI-Unterstützung im Alltag Zeit spart oder zusätzlichen Prüfaufwand erzeugt.

Quellen