Warum ein grösseres Kontextfenster Ihr RAG-Problem nicht löst

Von Julian Ott, Managing Partner Technology bei Alpinity AI · Aktualisiert am 29. August 2026

Kurz gesagt: Ein grösseres Kontextfenster macht Antworten nicht automatisch besser. Sprachmodelle nutzen die Mitte langer Eingaben messbar schlechter als Anfang und Ende, und die Genauigkeit sinkt bereits deutlich vor dem technischen Limit. Wer Firmenwissen zuverlässig nutzbar machen will, entscheidet pro Anwendungsfall zwischen Retrieval, Vorladen und einer Kombination aus beidem.

Ein Industriebetrieb legt sein 400 Seiten starkes Servicehandbuch vollständig in den Prompt. Das Modell verarbeitet eine Million Tokens, das Handbuch braucht davon einen Bruchteil. Technisch passt alles.

Trotzdem nennt der Assistent auf die Frage nach dem Anzugsmoment für Bauteil Z einen Wert aus einem anderen Kapitel. Nicht immer, aber oft genug, dass die Werkstatt ihm nicht mehr traut.

Der Reflex lautet dann: noch mehr Kontext mitgeben. Das ist genau die falsche Richtung.

Ein grosses Fenster ist eine Kapazitätsangabe, keine Qualitätsangabe

Die Fenstergrösse sagt, wie viel Text ein Modell entgegennimmt. Sie sagt nichts darüber, wie zuverlässig es die einzelne relevante Zeile darin wiederfindet und verwendet. Das sind zwei verschiedene Eigenschaften, und nur die erste steht im Datenblatt.

Genau diese Lücke ist inzwischen gut untersucht. Und die Ergebnisse sind für den Praxisbetrieb unbequemer, als die Marketingfolien der Modellanbieter vermuten lassen.

Modelle nutzen die Mitte schlechter als Anfang und Ende

Der bekannteste Befund stammt aus einer begutachteten Arbeit, die eine einfache Frage sauber isoliert hat. Sie legte dieselbe relevante Information einmal an den Anfang, einmal in die Mitte und einmal an das Ende einer langen Eingabe und mass, wie gut das Modell sie noch verwendet.

Das Ergebnis in den Worten der Arbeit: Die Leistung ist am höchsten, wenn die relevante Information am Anfang oder am Ende steht, und sie fällt deutlich ab, wenn das Modell auf Informationen in der Mitte langer Kontexte zugreifen muss, selbst bei ausdrücklich für lange Kontexte gebauten Modellen (Liu et al., Transactions of the ACL 2023, begutachtet).

Für Ihr Handbuchbeispiel heisst das: Kapitel 7 von 14 ist die schlechteste Position im ganzen Dokument. Nicht weil der Inhalt schwierig wäre, sondern weil er in der Mitte steht.

Die Genauigkeit sinkt, lange bevor das Fenster voll ist

Der zweite Befund ist der praktisch wichtigere. Das Forschungsteam von Chroma hat 18 Modelle geprüft, darunter GPT-4.1, Claude 4, Gemini 2.5 und Qwen3, und dabei die Eingabelänge systematisch erhöht, ohne die Aufgabe schwieriger zu machen (Hong, Troynikov und Huber, Chroma Technical Report, 14. Juli 2025, Industriebericht).

Zwei Beobachtungen daraus sind für Firmenanwendungen entscheidend.

Erstens taugt der verbreitete Test „Nadel im Heuhaufen" wenig als Beleg. Die Autoren halten fest, dass er im Kern eine einfache Suchaufgabe ist und vor allem wörtliche Übereinstimmung misst. Sobald Frage und gesuchte Stelle nicht mehr dieselben Wörter verwenden, was in echten Handbüchern und Verträgen der Normalfall ist, fällt die Trefferquote.

Zweitens genügt bereits ein einzelner plausibel klingender, aber falscher Absatz im Kontext, um die Antwortqualität zu senken. Und dieser Effekt verstärkt sich mit zunehmender Eingabelänge. Je mehr Sie hineinlegen, desto mehr Ablenker legen Sie mit hinein.

Warum Ihr Assistent auch mit RAG noch halluziniert

Genau hier liegt der häufigste Irrtum bei Wissensassistenten. Ein Abruf über die eigenen Dokumente senkt die Zahl frei erfundener Antworten deutlich, er beseitigt sie aber nicht. Denn das Modell erfindet in diesem Aufbau selten aus dem Nichts, es fasst zuverlässig zusammen, was ihm vorgelegt wurde.

Wenn die Abrufschicht einen Absatz liefert, der zur Frage passend klingt, inhaltlich aber die falsche Maschinengeneration oder die alte Fassung einer Richtlinie beschreibt, dann gibt das Modell diesen Inhalt sauber formuliert und selbstbewusst wieder. Das Ergebnis wirkt auf den Leser wie eine Halluzination, entstanden ist es jedoch eine Stufe früher.

Deshalb sind die wirksamen Gegenmassnahmen nicht im Prompt zu suchen, sondern im Abruf: eine zweite Bewertungsstufe, die Kandidaten aussortiert, eine Mindestähnlichkeit, unterhalb derer gar nichts weitergegeben wird, und die Erlaubnis für den Assistenten, keine Antwort zu geben. Warum diese Ehrlichkeit im Kundenkontakt der bessere Weg ist, haben wir in KI-Halluzinationen: Warum die ehrlichste KI gewinnt beschrieben.

Warum Ihr Chatbot im zehnten Turn schlechter antwortet als im ersten

Der dritte Befund betrifft jeden Assistenten, der ein Gespräch führt statt eine Einzelfrage zu beantworten. Ein Forschungsteam hat verglichen, wie gut Modelle abschneiden, wenn dieselbe Aufgabe auf mehrere Gesprächsrunden verteilt wird, statt vollständig in einer einzigen Anweisung zu stehen.

Über sechs Aufgabentypen hinweg fiel die Leistung im Mehrrundengespräch im Schnitt um 39 Prozent, ausgewertet über mehr als 200’000 simulierte Gespräche. Der Verlust bestand kaum aus fehlendem Können, sondern fast vollständig aus gestiegener Unzuverlässigkeit. Die Autoren fassen es so zusammen: Wenn Modelle in einem Gespräch einmal falsch abbiegen, finden sie nicht mehr zurück (Laban, Hayashi, Zhou und Neville, 2025, Preprint).

Das erklärt ein Verhalten, das viele KMU aus dem Alltag kennen: Der Assistent trifft früh eine Annahme, niemand widerspricht ihr, und ab da baut jede weitere Antwort auf dieser Annahme auf.

Was der direkte Vergleich zwischen Retrieval und langem Kontext zeigt

Damit ist langer Kontext nicht erledigt. Eine weitere Arbeit hat beide Ansätze systematisch über mehrere öffentliche Datensätze und drei Modelle verglichen. Ihr Befund: Mit genügend Ressourcen liefert langer Kontext im Durchschnitt die besseren Antworten, aber die deutlich geringeren Kosten von Retrieval bleiben ein klarer Vorteil (Li, Li, Zhang, Mei und Bendersky, EMNLP 2024 Industry Track, begutachtet).

Interessant ist ihre Schlussfolgerung. Statt sich zu entscheiden, lassen sie das Modell pro Anfrage selbst bestimmen, welcher Weg genügt. Dieses Verfahren senkt die Kosten deutlich und hält die Qualität auf dem Niveau des langen Kontexts. Die richtige Antwort auf „RAG oder langer Kontext" lautet also meistens: pro Anfrage entscheiden.

Für die Praxis in einem KMU sind die Unterschiede weniger akademisch, als die Studienlage klingt.

Die Zeile zu den Zugriffsrechten ist in der Schweiz oft die entscheidende. Sobald Personendaten im Spiel sind, muss nachvollziehbar bleiben, wer welche Information sehen darf. Ein Abruf, der pro Nutzer filtert, lässt sich sauber begründen. Ein Prompt, in dem vorsorglich alles liegt, nicht.

Manchmal ist Retrieval die falsche Antwort

Es gibt einen Fall, in dem der lange Kontext klar gewinnt, und der wird in der Praxis übersehen: einen kleinen, stabilen Wissensbestand, der sich selten ändert. Dafür ist ein Ansatz beschrieben worden, der die Abrufschicht ganz weglässt. Statt pro Anfrage zu suchen, wird der gesamte Bestand einmal vorgeladen und der Rechenzustand des Modells zwischengespeichert (Chan, Chen, Cheng und Huang, WWW 2025, begutachteter Kurzbeitrag).

Wirtschaftlich wird das durch das Zwischenspeichern des Prompts interessant. Bei Anthropic kostet das Lesen aus dem Cache 0,1 mal den normalen Eingabepreis, das Schreiben in den Cache 1,25 mal bei fünf Minuten Haltedauer und 2 mal bei einer Stunde. Die Mindestlänge liegt bei Claude Sonnet 5 bei 1’024 Tokens (Anthropic, Entwicklerdokumentation, abgerufen am 29. August 2026).

In Zahlen: Ein Handbuch von 60’000 Tokens, das bei jeder Anfrage neu bezahlt wird, kostet über tausend Anfragen das Tausendfache. Einmal geschrieben und tausendmal aus dem Cache gelesen kostet dasselbe Handbuch etwa ein Zehntel davon, plus einmalig den Aufschlag für das Schreiben. Genau deshalb lohnt sich die Frage, ob Ihr Bestand überhaupt gross genug für eine Abrufschicht ist.

Vier Entscheidungen, die in der Praxis den Unterschied machen

Aus den Befunden folgt eine Reihenfolge. Nicht „welches Modell", sondern welche Architektur, und zwar in dieser Abfolge.

1. Bestand einordnen, bevor Sie bauen. Wie viele Dokumente, wie oft ändern sie sich, wer darf was sehen? Ein stabiles Handbuch verlangt eine andere Architektur als ein CRM, das sich stündlich ändert.

2. Kürzen statt füllen. Nicht der ganze verfügbare Platz gehört genutzt. In den Prompt gehört die kleinste Menge Text, die die Frage beantwortet, und die relevanteste Stelle gehört an den Anfang oder das Ende, nicht in die Mitte.

3. Zweistufig abrufen. Erst breit suchen, dann mit einem Reranker auf wenige Abschnitte verdichten. Das ist der wirksamste einzelne Hebel gegen Ablenker, weil plausible, aber falsche Treffer in der zweiten Stufe herausfallen.

4. Gespräche zurücksetzen. Weil Modelle nach einer falschen Annahme nicht von selbst zurückfinden, braucht ein Assistent einen Punkt, an dem der Stand zusammengefasst und der alte Verlauf verworfen wird. Bei uns geschieht das nach jedem abgeschlossenen Anliegen.

So bauen wir das bei Alpinity AI

Wir starten jedes Wissensprojekt mit einer Messung statt mit einer Werkzeugwahl. Dazu gehören 30 bis 50 echte Fragen aus dem Betrieb, mit den Antworten, die fachlich korrekt wären. Erst gegen diese Liste lässt sich beurteilen, ob eine Änderung an der Architektur wirklich etwas verbessert hat oder nur anders klingt.

Die Grundkonfiguration, mit der wir starten, sieht in vereinfachter Form so aus:

abruf:
  kandidaten: 40          # breite erste Suche
  rerank: true            # zweite Stufe verdichtet
  final: 6                # so viel geht an das Modell
  mindest_score: 0.35     # darunter: lieber nichts

kontext:
  reihenfolge: relevanteste_zuerst_und_zuletzt
  max_tokens: 8000        # bewusst weit unter dem Limit

gespraech:
  reset_nach_anliegen: true
  zusammenfassung_ab_turn: 6

antwort:
  quellenangabe: pflicht
  abbruch_wenn_kein_treffer: true

abruf:
  kandidaten: 40          # breite erste Suche
  rerank: true            # zweite Stufe verdichtet
  final: 6                # so viel geht an das Modell
  mindest_score: 0.35     # darunter: lieber nichts

kontext:
  reihenfolge: relevanteste_zuerst_und_zuletzt
  max_tokens: 8000        # bewusst weit unter dem Limit

gespraech:
  reset_nach_anliegen: true
  zusammenfassung_ab_turn: 6

antwort:
  quellenangabe: pflicht
  abbruch_wenn_kein_treffer: true

abruf:
  kandidaten: 40          # breite erste Suche
  rerank: true            # zweite Stufe verdichtet
  final: 6                # so viel geht an das Modell
  mindest_score: 0.35     # darunter: lieber nichts

kontext:
  reihenfolge: relevanteste_zuerst_und_zuletzt
  max_tokens: 8000        # bewusst weit unter dem Limit

gespraech:
  reset_nach_anliegen: true
  zusammenfassung_ab_turn: 6

antwort:
  quellenangabe: pflicht
  abbruch_wenn_kein_treffer: true

Zwei Zeilen davon sind wichtiger als der Rest. max_tokens liegt bewusst weit unter dem, was das Modell könnte. Und abbruch_wenn_kein_treffer sorgt dafür, dass der Assistent lieber sagt, dass er es nicht weiss, statt etwas Plausibles zu formulieren. Für eine Werkstatt oder eine Praxis ist eine ehrliche Fehlanzeige brauchbar, eine erfundene Zahl nicht.

Betrieben wird das Ganze mit Hosting in der Schweiz oder der EU, auf Wunsch ausschliesslich in der Schweiz, und mit einer Protokollierung, die zu den Anforderungen des revidierten Datenschutzgesetzes passt.

Was gilt weiter, wenn die Modelle besser werden

Die Fenster werden weiter wachsen, und einzelne der oben genannten Messwerte werden sich verschieben. Drei Punkte bleiben davon unberührt.

Erstens kostet jeder Token Geld und Zeit, auch wenn er nichts zur Antwort beiträgt. Zweitens sind Zugriffsrechte und Nachvollziehbarkeit organisatorische Anforderungen, keine Modellfähigkeiten. Und drittens bleibt eine Bewertungsliste aus echten Fragen die einzige Möglichkeit, eine Verbesserung von einem Gefühl zu unterscheiden.

Wer diese drei Dinge geklärt hat, profitiert von jedem besseren Modell automatisch. Wer sie nicht geklärt hat, bekommt mit jedem grösseren Fenster nur ein teureres Problem.

Quellen

• Patrick Lewis, Ethan Perez, Aleksandra Piktus et al.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020, begutachtet.

• Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang: Lost in the Middle: How Language Models Use Long Contexts. Transactions of the ACL, 2023, begutachtet.

• Kelly Hong, Anton Troynikov, Jeff Huber: Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma Technical Report, 14. Juli 2025, Industriebericht.

• Philippe Laban, Hiroaki Hayashi, Yingbo Zhou, Jennifer Neville: LLMs Get Lost In Multi-Turn Conversation. 2025, Preprint.

• Zhuowan Li, Cheng Li, Mingyang Zhang, Qiaozhu Mei, Michael Bendersky: Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach. EMNLP 2024 Industry Track, begutachtet.

• Brian J. Chan, Chao-Ting Chen, Jui-Hung Cheng, Hen-Hsen Huang: Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks. WWW 2025, begutachteter Kurzbeitrag.

• Anthropic: Prompt caching. Entwicklerdokumentation, abgerufen am 29. August 2026.

Wie ein solches Wissenssystem im Kundenkontakt aussieht, zeigt unser Beitrag RAG erklärt: KI sicher mit Firmenwissen füttern.

Passende Leistung von Alpinity AI: KI-Chatbots für WhatsApp, Instagram und Web