Context Stuffing vs. Tool Calling: warum viele KI-Projekte an der Datenarchitektur scheitern

Das Wichtigste in Kürze

• Die verbreitete Annahme "mehr Kontext = bessere Antwort" ist empirisch widerlegt. Forschung zeigt: LLMs werden mit längerem Input messbar schlechter.
• Drei belegte Failure-Modes: Lost in the Middle, Context Rot und Tool-Overload bei langem Kontext.
• Der gefährlichste Befund: Ein Modell kann mit irrelevantem Kontext schlechter abschneiden als ganz ohne Kontext.
• Viele KI-Projekte scheitern nicht am Modell, sondern an der Datenarchitektur: Sie stopfen Kontext hinein, wo sie gezielt abrufen sollten.
• Context-Stuffing hat legitime Einsatzgebiete, aber für exakte, strukturierte Aufgaben ist Tool-Calling die zuverlässigere Architektur.

Die teure Annahme

Wenn ein KI-Projekt in Pharma, Biotech oder Chemie scheitert, lautet die übliche Diagnose: "Das Modell ist noch nicht gut genug" oder "wir brauchen ein größeres Kontextfenster". Beides ist meist falsch. Der häufigere Grund ist eine architektonische Entscheidung, die ganz am Anfang getroffen wurde, oft unbewusst: alles in den Kontext stopfen, statt gezielt das Richtige abzurufen.

Mit Kontextfenstern von einer Million Token klingt Context-Stuffing verlockend einfach: Man wirft Datenblätter, Tabellen, Messreihen und Dokumentation in den Prompt und hofft, dass das Modell sich das Relevante herauszieht. Auf dem Papier ist mehr Information mehr Wissen. In der Praxis ist es das Gegenteil, und das ist inzwischen gut gemessen.

Failure-Mode 1: Lost in the Middle

Die grundlegende Arbeit dazu stammt von Liu et al. (Stanford/UW, TACL 2024). Sie zeigt eine U-förmige Leistungskurve: Modelle nutzen Information am Anfang und am Ende des Kontexts gut, fallen in der Mitte aber deutlich ab. Performance kann erheblich einbrechen, wenn sich die Position der relevanten Information verschiebt, ein klares Zeichen, dass aktuelle Modelle lange Kontexte nicht robust nutzen.

Der eindrücklichste Einzelbefund: Wenn die relevante Information in der Mitte steht, fällt die Genauigkeit von GPT-3.5-Turbo bei einer Multi-Dokument-Frage unter den Wert, den dasselbe Modell ganz ohne Dokumente erreicht. Mehr Kontext machte die Antwort schlechter als gar kein Kontext. Und: Explizite Long-Context-Modelle schneiden hier oft nicht besser ab als ihre Standard-Pendants, das größere Fenster löst das Problem nicht.

Failure-Mode 2: Context Rot

Eine aktuellere Untersuchung von Chroma (2025) hat 18 Frontier-Modelle systematisch getestet und ein Muster gefunden, das die Autoren "Context Rot" nennen: Die Antwortqualität sinkt messbar, je länger der Input wird, und zwar bei jedem einzelnen getesteten Modell, selbst wenn das Kontextfenster bei weitem nicht voll ist.

Besonders relevant für reale Anwendungen ist der Distraktor-Effekt. Irrelevanter Kontext zwingt das Modell zu einem zusätzlichen Such-Schritt und verschlechtert seine Zuverlässigkeit deutlich. Verschärfend: Semantisch ähnliche, aber falsche Inhalte (Distraktoren) sind am schädlichsten, und genau die treten in Fachdomänen ständig auf, wo Dokumente sich stark ähneln und sich nur in Details wie einer Jahreszahl, einem Wert oder einem Substituenten unterscheiden. Ein gut strukturierter, konsistenter Datenbestand erhöht die Distraktor-Dichte sogar, weil jeder falsche Treffer plausibler aussieht.

Das ist die unbequeme Wahrheit hinter "RAG ist tot, wir haben ja jetzt Millionen-Token-Fenster": Das Fenster ist groß, aber die Aufmerksamkeit darin ist es nicht.

Failure-Mode 3: Tool-Overload und lange Tool-Antworten

Der dritte Modus betrifft genau die Agenten-Setups, um die es in der Praxis geht. Das LongFuncEval-Paper (2025) hat gemessen, wie sich Tool-Calling unter langem Kontext verhält, mit ernüchterndem Ergebnis: ein Leistungsabfall von 7 bis 85 Prozent, je mehr Tools verfügbar sind; 7 bis 91 Prozent Einbruch, je länger die Tool-Antworten werden; und deutliche Verschlechterung über lange Mehr-Schritt-Dialoge.

Die Lehre ist nicht "Tools sind schlecht", sondern: Auch Tool-Calling versagt, wenn man es mit Context-Stuffing kombiniert. Hunderte fast identischer Tools und seitenlange Roh-Antworten verlagern das Problem nur. Gutes Agenten-Design heißt wenige, präzise Tools mit kompakten, verwertbaren Antworten.

Wofür Context-Stuffing trotzdem gut ist

Wichtig, damit das Bild fair bleibt: Context-Stuffing und RAG sind nicht generell falsch. Für unstrukturierte, sprachliche Aufgaben sind sie oft die richtige Wahl, eine Frage an ein einzelnes Dokument stellen, einen Bericht zusammenfassen, in einer Wissensbasis nach einer Passage suchen, einen Vertrag durchsuchen. Überall dort, wo die Antwort Text ist und Nuance zählt, ist es sinnvoll, dem Modell den relevanten Text zu geben.

Das Problem entsteht, wenn man Context-Stuffing für Aufgaben einsetzt, die eine exakte, strukturierte, deterministische Antwort haben. Eine Löslichkeit berechnen, Atome zählen, einen ICH-Grenzwert nachschlagen, eine Stabilitätskinetik fitten, das sind keine Leseaufgaben. Sie an den Kontext zu delegieren heißt, ein präzises Problem in ein Wahrscheinlichkeits-Problem zu verwandeln.

Der blinde Fleck: viel LLM-Forschung, wenig Abruf-Forschung

Hier liegt ein strukturelles Ungleichgewicht im Feld. Der ganz überwiegende Teil der Aufmerksamkeit, und des Kapitals, fließt in größere, fähigere Modelle. Vergleichsweise wenig fließt in die Frage, welche Information ein Modell zu welchem Zeitpunkt überhaupt sehen sollte. Dabei zeigen die obigen Befunde, dass genau dort der Hebel liegt: Die Modelle sind oft klug genug, das Problem zu lösen, wenn ihr Kontext sauber bleibt. Er bleibt nur selten sauber.

Für ein Unternehmen heißt das praktisch: Die nächste Modellgeneration wird das Architektur-Problem nicht für euch lösen. Wer auf "das wird mit GPT-X schon besser" wartet, optimiert die falsche Variable. Die zuverlässige Verbesserung kommt aus der Datenarchitektur, daraus, dem Modell gezielt das Richtige zu geben, statt ihm alles vorzulegen.

Die Architektur-Entscheidung, und wie wir sie bei CovaSyn treffen

Die Faustregel, die aus der Forschung folgt, ist klar:

• Text-Antwort, Nuance, Interpretation → Kontext geben (RAG/Stuffing ist richtig).
• Exakte, strukturierte, verifizierbare Antwort → an ein Tool delegieren (Tool-Calling ist richtig).

CovaSyn ist konsequent für den zweiten Fall gebaut. Statt einem Chemie-Agenten Datenblätter und Tabellen in den Kontext zu stopfen und auf das Beste zu hoffen, ruft er ein deterministisches Werkzeug auf, das die exakte Antwort berechnet und kompakt zurückgibt, eine Löslichkeit mit Unsicherheitsintervall, einen Tox-Flag, einen Strukturdeskriptor. Kein Distraktor-Rauschen, keine Mitte-des-Kontexts-Lotterie, keine seitenlange Roh-Antwort.

Dass diese Architektur überlegen ist, haben wir an unabhängigen Daten gemessen: Mit Tool-Anbindung springen Frontier-Modelle auf Chemie-Aufgaben von 14 bis 41 Prozent auf 76 bis 92 Prozent, nicht, weil sie mehr Kontext bekommen, sondern weil sie den richtigen, kleinen, exakten Baustein abrufen. Und weil wir die Tools bewusst kuratieren statt jede Funktion zu exponieren, vermeiden wir den Tool-Overload, den LongFuncEval beschreibt. Mehr zum Unterschied zwischen reinem Deskriptor-Zugriff und einer kuratierten Plattform steht in unserem Beitrag zu RDKit über MCP.

Das Fazit

Die wichtigste Entscheidung in einem KI-Projekt fällt nicht bei der Modellwahl, sondern bei der Datenarchitektur, und sie fällt früh. Wer exakte Aufgaben an den Kontext delegiert, baut die Failure-Modes Lost-in-the-Middle, Context Rot und Tool-Overload von Anfang an ein. Wer sie an Werkzeuge delegiert, umgeht sie. Ein größeres Kontextfenster verschiebt diese Grenze nur; die richtige Architektur entfernt sie.

Im Free-Tier kannst du den Unterschied selbst sehen, Tool-Calling statt Context-Stuffing für deine Chemie-Fragen, direkt im Agenten. 100 Credits pro Woche, keine Kreditkarte. → CovaSyn MCP ansehen

Häufige Fragen

Quellen

• Liu N. F. et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. TACL, arXiv:2307.03172.
• Hong K. et al. (2025). Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma Research.
• LongFuncEval: Measuring the effectiveness of long context models for function calling. arXiv:2505.10570 (2025).
• Shi F. et al. (2023). Large Language Models Can Be Easily Distracted by Irrelevant Context (GSM-IC).