Was ein Modell weiß, und woher

In Kapitel 07 ging es darum, woran Sie eine erfundene Angabe erkennen. Hier steht einer der Gründe, warum es überhaupt so weit kommt: Das Wissen eines Modells hat ein Ende, und das Modell merkt es von allein nicht.

Alles, was es weiß, hat es einmal gelesen

Das Training ist ein abgeschlossener Vorgang. Über Monate läuft Material durch ein sehr großes Rechenwerk, und am Ende steht eine Datei mit Zahlen. Diese Zahlen heißen Gewichte, und sie sind der gelernte Teil des Modells. Was sonst noch dazugehört, damit daraus Antworten werden, steht in Kapitel 01.

An dieser Datei ändert Ihr Gespräch nichts. Auch nicht, wenn Sie stundenlang mit ihm arbeiten, es korrigieren, ihm etwas beibringen. Was im Gespräch wie Lernen aussieht, ist Lesen: Alles, was Sie schreiben, steht im Kontext dieser einen Anfrage. Schließen Sie das Fenster, ist es weg.

Der Hersteller kann die Zahlen sehr wohl ändern, und er tut es. Ein Modell bekommt Nachfolger, und es gibt Verfahren, die eine vorhandene Datei auf eigene Beispiele abstimmen (Beurteilen und Einordnen, Kapitel 02). Beides geschieht außerhalb Ihres Gesprächs und dauert länger als eines.

Das Modell selbst hat also nie etwas gespeichert, das es vergessen könnte. Die Anwendung darum herum kann es durchaus, und die Werkzeuge fürs Arbeiten tun es an mehreren Stellen: in einer Projektanweisung, in eigenen Notizen, in einer Wissensbasis daneben. Welche Orte das sind und wer sie füllt, steht in Vibe-Coding / Agentic Engineering, Kapitel 05. Wo es diese Orte nicht gibt, erklären Sie dieselbe Sache in jedem neuen Chat erneut.

Der Stichtag

Irgendwann endet der Text, der ins Training ging. Dieser Zeitpunkt heißt Knowledge Cutoff, und die Anbieter geben ihn an. Drei Beispiele, abgerufen am 10.10.2026:

Diese Zahlen veralten schnell, das Verfahren dahinter nicht. Für alles, was danach geschah, taugt keines der drei Modelle als Auskunft: kein Wahlergebnis, kein neues Gesetz, keine Version einer Software, die seither erschienen ist. Und was noch wichtiger ist: keine Korrektur an etwas, das es vorher gelesen hat.

Eine Mauer ist der Stichtag dabei nicht. Einzelnes von danach kann durchaus dastehen, aus Gründen, die in der dritten Tiefe stehen. Als Zusicherung taugt er in beide Richtungen wenig.

Warum das Modell es selbst nicht weiß

Naheliegend wäre, einfach zu fragen. „Bis wann reichen deine Daten?“ Sie bekommen darauf eine Antwort, oft mit Monat und Jahr, und sie klingt, als käme sie aus dem Modell.

In Claude.ai und den Apps kommt sie bei den Claude-Modellen nachweislich von außen. Anthropic veröffentlicht die Systemanweisungen dieser Anwendungen im Wortlaut, und dort steht der Stichtag als Vorgabe, wie jede andere Anweisung auch. In der Systemanweisung zu Claude Opus 5.5 (externe Seite, platform.claude.com) heißt es, das verlässliche Wissen reiche bis Ende Juni 2026, und darüber hinaus könne Claude nicht verlässlich antworten.

Der Text geht weiter und regelt gleich mit, was das Modell tun soll, wenn eine Frage jenseits davon liegt: Oft kann es das so oder so nicht wissen und soll das sagen. Bei aktuellen Fragen soll es seinen letzten Stand nennen, dazusagen, dass der veraltet sein kann, und auf die Websuche verweisen.

In Claude.ai beantwortet die Frage nach dem Stichtag also der Zettel, den dem Modell jemand hingelegt hat. Wer wissen will, wo solche Zettel sonst noch hängen, findet das in Kapitel 05.

Über die Schnittstelle bekommt das Modell diese Anweisung nicht. Anthropic schreibt dazu, die Systemanweisungen der Anwendungen gelten dort nicht (externe Seite, platform.claude.com). Wer ein Modell so anspricht, findet den Stichtag in der Modellübersicht des Anbieters, und in die Anfrage kommt er nur, wenn er ihn selbst hineinschreibt.

seitlich verschiebbar

eigene Darstellung, Stand 10.10.2026

Drei Wege, wie Neues hineinkommt

Wenn das Modell nichts dazulernt, wie kommt es dann an Aktuelles? Von Ihrer Seite aus auf drei Arten, und alle drei laufen über dieselbe Stelle.

Sie schreiben es hin. Der direkteste Weg. Was in Ihrer Frage steht, ist da.

Sie geben eine Datei mit. Ein Dokument, eine Tabelle, ein Bild. Meist liest die Anwendung den Text aus und legt ihn dazu. Bei Bild und Ton geht es auch ohne diesen Umweg: Was ein Modell auf einem Bild sieht und was ein PDF dabei kostet, steht in Kapitel 13, der eigene Weg des Tons in Conversational AI, Kapitel 02.

Die Anwendung schlägt nach. Websuche, eine Firmenablage, eine Datenbank. Ein Programm sucht, findet, und schiebt das Gefundene in dieselbe Anfrage.

Der dritte Weg ist der, den man am ehesten für Zauberei hält. Er ist es am wenigsten: Das Modell surft nicht. Ein Programm sucht, und was es findet, steht dann in der Anfrage, als hätten Sie es selbst hineinkopiert. Wie das bei eigenen Dokumenten gebaut wird und woran Sie erkennen, dass die Suche danebengriff, steht in Agenten und Harness, Kapitel 03.

Eine Quelle liegt außerhalb dieser drei, und Sie haben sie eine Überschrift weiter oben schon gesehen: die Anweisung des Anbieters, in der bei Claude.ai der Stichtag steht. Sie füllt dieselbe Stelle, nur schreibt dort jemand anders.

Alle drei enden im Kontext. Keiner erreicht die Gewichte. Deshalb ist alles Nachgeschlagene beim nächsten Gespräch wieder weg, und deshalb belegt es jedes Mal aufs Neue Platz im Fenster. Was die Gewichte erreicht, ist ein Verfahren für sich, und darum geht es in Beurteilen und Einordnen, Kapitel 02. Warum Wissen über den Kontext meist besser ankommt als über ein Training, zeigt Nutzung und Anpassung von LLMs, Kapitel 08.

Woran Sie es merken

Ein Modell sagt selten von sich aus „das war nach meiner Zeit“. Es antwortet lieber, und zwar in derselben ruhigen Tonlage wie sonst. Drei Anlässe, bei denen sich Nachsehen lohnt:

Sie fragen nach etwas Frischem. Ein Produkt von letzter Woche, eine Personalie, eine Version. Hier fehlt dem Modell die Grundlage am ehesten, und hier ist es am schnellsten geprüft.

Die Antwort nennt eine Version oder ein Datum. Beides veraltet, und beides klingt nachgeschlagen, auch wenn es das nicht ist.

Es steht kein Beleg dabei. Kam die Auskunft aus einer Suche, steht meist eine Fundstelle daneben. Fehlt sie, ist die Herkunft offen: aus den Gewichten, aus Ihrer eigenen Frage oder aus einer Suche, die ihre Fundstellen für sich behält. Nur im ersten Fall ist die Angabe so alt wie das Training, und welcher Fall vorliegt, sagt die Antwort selten.

Wo das keine Rolle spielt

Bei allem, was nicht vom Kalender abhängt, ist der Stichtag gleichgültig. Ein Text soll umformuliert, eine Gliederung geordnet, eine Rechtschreibung geprüft, eine Idee weitergedacht werden: Dafür braucht es keine Nachrichten von gestern. Die Frage nach dem Wissensstand stellt sich dort, wo eine Antwort etwas über die Welt behauptet.

Ein Stichtag klingt nach einer Linie im Kalender. In den Angaben der Anbieter ist er das an keiner Stelle.

Zwei Stichtage, nicht einer

Anthropic führt in der Modellübersicht zwei Zeilen und definiert beide in der Legende darunter (externe Seite, platform.claude.com): Der verlässliche Knowledge Cutoff ist der Tag, bis zu dem das Wissen des Modells am umfangreichsten und verlässlichsten ist. Der Trainingsdaten-Stichtag ist die weitere Spanne der verwendeten Daten.

Bei manchen Modellen fallen beide zusammen, bei anderen liegen Monate dazwischen. Der deutlichste Fall ist Claude Sonnet 4.5, das Anthropic zum 30.11.2026 abschaltet. Die Werte stehen auf der Seite je Modell, abgerufen am 10.10.2026:

Bei Sonnet 4.5 ist ein halbes Jahr Text ins Training gegangen, ohne dass der Hersteller dafür geradesteht. Diese Lücke ist die Angabe selbst: Material am Ende des Trainings ist dünner, weil das Netz die Welt noch nicht eingeholt hat. Ein Ereignis vom Mai ist im Juli in ein paar Meldungen beschrieben. Ein Ereignis von vor drei Jahren steht in Büchern, Analysen, Streitschriften und tausend Kommentaren.

Ab Claude Opus 4.7 vom April 2026 steht in beiden Zeilen bei jedem neuen Modell derselbe Monat, bis zur aktuellen Reihe vom Herbst. Einen Grund dafür nennt die Modellübersicht nicht.

Das Wissen endet nicht überall gleichzeitig

Google sagt für Gemini 3.6 Flash zunächst das Erwartbare: Laut Modellkarte (externe Seite, deepmind.google) reicht das Wissen bis März 2026. Im selben Satz folgt die Einschränkung: In manchen Gebieten dürfen Nutzer aktuelle Angaben erwarten, in anderen kann das Wissen des Modells beim Januar 2025 enden.

Vierzehn Monate Unterschied, je nachdem, wonach Sie fragen. Welche Gebiete gemeint sind, steht nicht dabei. Für die Praxis heißt das: Der veröffentlichte Stichtag ist die günstigste Auslegung, nicht der Durchschnitt.

Dass es die Anbieter selbst uneinheitlich halten, zeigt sich sogar innerhalb eines Hauses. Anthropics Hilfeartikel für Endnutzer nennt für Haiku 4.5 den Juli 2025 und meint damit die Trainingsdaten. Die Ent­wick­ler­do­ku­men­ta­tion führt für dasselbe Modell den Februar 2025 als verlässlich. Beide Seiten sind richtig, sie reden über verschiedene Dinge, und der Hilfeartikel (externe Seite, support.claude.com) sagt nicht, über welches.

Was in den Daten steckt

Woraus die Gewichte entstanden sind, beschreiben die drei großen Anbieter unterschiedlich ausführlich. Der Vergleich ist die eigentliche Auskunft.

Googles Modellkarte zu Gemini 3 Pro zählt im Abschnitt Training Dataset sieben Herkünfte einzeln auf: frei herunterladbare Datensätze, Material von Webcrawlern, lizenzierte Daten aus Verträgen, Daten aus der Nutzung von Google-Produkten, weitere im Geschäftsbetrieb erworbene oder erzeugte Bestände, Daten von der eigenen Belegschaft und maschinell erzeugte Daten. Die Karte sagt dazu, dass sie mehr offenlege als frühere.

OpenAI (externe Seite, arxiv.org) braucht dafür einen Satz und nennt drei: öffentlich zugängliche Informationen aus dem Internet, Material von Partnern, und was Nutzer, Trainer und Forschende beisteuern oder erzeugen.

Bei Anthropic lässt sich der Wandel an derselben Seite ablesen, der Transparenzseite (externe Seite, anthropic.com). Für Sonnet 4.5 steht dort noch die lange Aufzählung, mit einem Punkt, der bei den anderen beiden so nicht vorkommt: Daten von Claude-Nutzern, die eingewilligt haben, dass ihre Daten fürs Training verwendet werden.

Für Sonnet 5 ist daraus eine kürzere Fassung geworden. Trainiert wurde es danach auf einer eigenen Mischung aus öffentlich zugänglichen Informationen aus dem Internet, öffentlichen und nichtöffentlichen Datensätzen und Daten, die andere Modelle erzeugt haben.

Aus fünf benannten Herkünften sind drei zusammengefasste geworden. Die eingewilligten Nutzerdaten fehlten in der Aufzählung, maschinell erzeugte Daten waren dazugekommen. Bei Claude Opus 5, Fable 5.1 und Opus 5.5 stehen Nutzerdaten wieder darin, ohne den Zusatz über die Einwilligung. Für Fable 5.1 etwa nennt die Transparenzseite (externe Seite, anthropic.com) öffentlich zugängliche Informationen aus Online-Quellen, öffentliche und nichtöffentliche Datensätze, Nutzerdaten und Daten, die andere Modelle erzeugt haben.

Beim jüngsten Modell auf der Seite, Claude Haiku 5.5 vom Oktober 2026, ist eine Einschränkung zurück, in neuer Form: Die Aufzählung nennt Nutzerdaten aus Rückmeldungen oder Fehlerberichten und Daten, die Nutzer ausdrücklich fürs Training freigegeben haben.

Was das über die Praxis dahinter aussagt, bleibt offen. Was es über die Auskunft aussagt, steht da: Die Formulierung wechselt von Modell zu Modell, auch zwischen Opus 5.5 vom September und Haiku 5.5 vom Oktober 2026.

Bei OpenAI ist die Auskunft kürzer geworden. Zur Herkunft des Materials sagt die Karte zu GPT-6 Astra (externe Seite, deploymentsafety.openai.com) vom September 2026 im zuständigen Abschnitt nur noch, das Modell sei auf vielfältigen Datensätzen trainiert, die eine Ver­ar­bei­tungs­kette des Herstellers gefiltert habe, unter anderem, um persönliche Angaben zu verringern. Eine Herkunft nennt der Satz nicht. Die Ergänzung zu GPT-6.1 Sol (externe Seite, deploymentsafety.openai.com) vom Monatsende sagt an derselben Stelle nur noch, das Modell nutze dieselben Arten von Daten und dasselbe Training wie Astra.

Bei Google steht die Aufzählung weiterhin da, gebündelt an einer Stelle: Die Karte zu Gemini 3.1 Pro (externe Seite, deepmind.google) führt die Überschrift zum Trai­nings­da­ten­satz und schickt den Leser darunter weiter: Gemini 3.1 Pro baue auf Gemini 3 Pro auf, und wer mehr über den Trai­nings­da­ten­satz wissen wolle, finde es in der Karte zu Gemini 3 Pro.

Beim Flash-Zweig ist der Weg länger. Die Karte zu Gemini 3.8 Flash (externe Seite, deepmind.google) verweist auf die zu 3.7 Flash, und die verweist ihrerseits weiter (externe Seite, deepmind.google), auf 3.6 Flash. Bis zu einer Karte mit Aufzählung, der zu Gemini 3 Pro, sind es fünf Verweise. Wer eine Angabe über die Trainingsdaten sucht, folgt bei Google also einer Kette von Karten, bevor er sie findet. Welches Haus heute was veröffentlicht und ob es seine Karten überhaupt an einer Stelle auflistet, steht im Modellkarten-Verzeichnis. Wie man eine solche Karte liest, steht in Beurteilen und Einordnen, Kapitel 07.

Der Nachschub kostet Platz und Geld

Dass nachgeschlagene Inhalte im Kontext landen, ist keine Erklärhilfe. Anthropic schreibt es in der Doku zur Websuche (externe Seite, platform.claude.com) aus, für die einfache Websuche (im Original „basic web search“): Dort wird jedes Suchergebnis in das Kontextfenster geladen, und vieles davon kann für die Anfrage belanglos sein. Zur Abrechnung heißt es auf derselben Seite, Suchergebnisse zählen im ganzen Gespräch als Eingabe-Token, in den Suchrunden eines einzelnen Zugs und in allen folgenden Gesprächszügen.

Zwei Dinge stecken darin. Erstens lädt die einfache Suche jedes Ergebnis ganz, auch den unpassenden Teil. Zweitens wird es in jedem weiteren Gesprächszug erneut mitgeschickt und als Eingabe gezählt. Ein Modell, das dreimal sucht, schleppt drei Ergebnismengen durch den Rest des Gesprächs.

Wie viel Platz das braucht, steht in der Dokumentation zum Abrufwerkzeug (externe Seite, platform.claude.com): eine durchschnittliche Webseite von 10 Kilobyte entspricht rund 2.500 Token, eine Forschungsarbeit als PDF von 500 Kilobyte rund 125.000. Was das Kontextfenster ist und warum es knapp wird, steht in Kapitel 03.

Dieselbe Rechnung erklärt, warum Anbieter Wissen nicht einfach ins Modell nehmen: Ein Trainingslauf dauert Monate und kostet ein Vermögen. Eine Suche kostet bei Anthropic einen US-Cent (externe Seite, platform.claude.com), dazu die Token für das Ergebnis.

Das Wort „basic“ ist die halbe Auskunft

Im ersten Satz der Doku steht eine Einschränkung, die leicht überliest, wer ihn für die Beschreibung des Suchwerkzeugs hält. Der Rest davon steht im selben Absatz der Dokumentation (externe Seite, platform.claude.com): Ab der Fassung web_search_20260209 schreibt Claude stattdessen Code, der die Treffer zuerst filtert, und führt ihn aus, sodass nur das Passende ins Kontextfenster kommt.

Die Vollständigkeit ist damit eine Eigenschaft der ältesten Tool-Fassung. Die neueren lassen Code über die Treffer laufen, bevor sie ankommen, und schicken weiter, was zur Frage passt. Das geht ab Claude 4.6, und Anthropic begründet es mit der Ersparnis bei suchlastigen Anfragen (externe Seite, platform.claude.com). Das Abrufwerkzeug hat dieselbe Vorauswahl seit seiner Fassung web_fetch_20260209 (externe Seite, platform.claude.com), für ganze Seiten und PDFs.

An der Richtung ändert das nichts, der Nachschub landet weiterhin im Kontext. Es ist weniger davon, und ausgewählt hat vorher ein Programm, das das Modell selbst geschrieben hat. Wie ein Modell dazu kommt, Tools aufzurufen, steht in Kapitel 09.

Der praktische Schluss ist einer über Angaben: Eine Auskunft darüber, wie ein Suchwerkzeug arbeitet, gilt für eine Tool-Fassung. Über die Schnittstelle steht die Versionsnummer in jeder Anfrage, weil das Tool ohne sie nicht anzugeben ist. Wer eine fertige Anwendung benutzt, sieht sie nicht und hat sie sich nicht ausgesucht.

Was der Cache davon abzieht

„Jedes Mal neu“ ist dabei zu grob. Zwi­schen­ge­spei­cherte Eingabe wird billiger abgerechnet, und beim Abrufwerkzeug hält der Anbieter die geholten Inhalte zusätzlich eine Weile vor. Das Abrufwerkzeug (externe Seite, platform.claude.com) speichert seine Ergebnisse zwischen, damit es schneller antwortet und dieselbe Seite nicht mehrfach holen muss.

Am Platz im Fenster ändert das nichts, dort steht der Text weiterhin. Was es am Preis ändert, steht in Kapitel 10, und was es beim Durchsatz ausmacht, in Kapitel 11. Die Kehrseite nennt dieselbe Seite: Der Cache liefert unter Umständen eine ältere Fassung der Seite, und wer die frische braucht, schaltet ihn für diesen Abruf ab.

Dieselbe Sache, drei Namen

Weil jeder Anbieter seine eigenen Begriffe pflegt, hier die Zuordnung. Die Stelle, an der das Gefundene ankommt, ist bei allen dieselbe. Wie es dorthin gelangt und wie viel davon, unterscheidet sich, siehe den Abschnitt über die Tool-Fassungen weiter oben.

OpenAI hat für den Unterschied, um den es in diesem Kapitel geht, einen eigenen Ausdruck. Die Dateisuche, heißt es dort, erlaube es, das dem Modell innewohnende Wissen zu ergänzen (externe Seite, developers.openai.com). Inherent knowledge steht im Original, und die Unterscheidung zwischen mitgebrachtem und mitgegebenem Wissen kommt damit vom Anbieter selbst. Google benennt in der Dokumentation zur Verankerung (externe Seite, ai.google.dev) den Knowledge Cutoff ausdrücklich als das, was mit der Suche überschritten wird.

Was das Nachschlagen nicht repariert

Ein Modell mit Suchzugriff wirkt gegen die Erfindungen aus Kapitel 07, und es wirkt begrenzt. Die Suche kann daneben greifen, und dann formuliert ein einwandfrei arbeitendes Modell eine falsche Auskunft aus einem falschen Beleg. Der Fehler ist dann eine Reihe früher passiert, vor dem Modell, und dort schwerer zu sehen.

Google stellt den Knowledge Cutoff deshalb in dieselbe Liste wie die Halluzinationen. In der Modellkarte zu Gemini 3 Pro (externe Seite, storage.googleapis.com) stehen beide unter Known Limitations, im selben Absatz. Der Stichtag zählt dort als bekannte Grenze des Modells.

Der Stichtag ist eine Angabe des Herstellers über sein eigenes Produkt. Wie alle solchen Angaben lohnt es, ihn daraufhin anzusehen, was er behauptet und was er offenlässt.

Er gilt in beide Richtungen nicht streng

Naheliegend wäre, den Stichtag als obere Schranke zu lesen: davor alles, danach nichts. Paleka, Goel, Geiping und Tramèr halten dagegen. In ihrer Arbeit über die Bewertung von Sprachmodellen als Prognosewerkzeug (externe Seite, arxiv.org) ist der Stichtag ausdrücklich keine Zusicherung, dass das Modell nichts von der Zeit danach kennt.

Die Begründung im selben Abschnitt nennt den Weg, auf dem spätere Information hineinkommt. Was der Stichtag bedeutet, kann je nach Hersteller verschieden sein, und er kann sich allein auf die Daten des Pre-Trainings beziehen. Präferenzdaten von Nutzern, die erst später erhoben wurden, bringen dann ein wenig Information über die Zukunft mit.

Für die Autoren ist das ein methodisches Problem: Wer ein Modell Vergangenes vorhersagen lässt, um seine Prognosefähigkeit zu messen, kann sich auf den Stichtag als Trennlinie nicht verlassen.

Für den Alltag folgt daraus wenig, für die Bewertung von Messungen viel. Eine Prüfung, die auf „das kann das Modell nicht gewusst haben“ beruht, steht auf einer Zusicherung, die niemand gegeben hat.

Was die Angabe verschweigt

Keiner der drei Anbieter beschreibt in seinen Modellangaben, wie er den Stichtag bestimmt. Anthropic unterscheidet verlässliches Wissen von der Reichweite der Trainingsdaten und definiert beides (externe Seite, platform.claude.com), ohne ein Verfahren zu nennen. Was „am umfangreichsten und verlässlichsten“ heißt, ist damit eine Einschätzung und bleibt ohne Messwert.

Um daraus eine Zahl zu machen, bräuchte es vier Dinge. Erstens eine Menge von Fragen mit bekannter Antwort, gleichmäßig über die Zeit verteilt. Zweitens eine Festlegung, ab welcher Trefferquote Wissen als verlässlich gilt. Drittens eine Aufteilung nach Gebieten, denn Google räumt selbst ein, dass die Grenze je Gebiet verschieden liegt. Viertens die Trennung zwischen wirklichem Wissen und geratener Antwort, und die ist beim selben Verfahren schwierig, das Kapitel 07 beschreibt.

Nichts davon steht in den Angaben. Damit sind sie eine Selbstauskunft: nützlich als Größenordnung, ungeeignet als Grenzwert in einer Prüfvorschrift.

Der Nachschub verdrängt

Nachgeschlagenes landet im selben Fenster wie alles andere, und die Größenordnungen sind unangenehm. Anthropic nennt für eine Forschungsarbeit als PDF rund 125.000 Token (externe Seite, platform.claude.com). Bei einem Fenster von 200.000, wie es Claude Haiku 4.5 hat, bleiben danach 75.000 für Systemanweisung, Tool-Beschreibungen, Gesprächsverlauf und die eigentliche Frage. Die aktuellen Claude-Modelle fassen eine Million Token (externe Seite, platform.claude.com), dort belegt dieselbe Arbeit ein Achtel des Fensters.

Drei Folgen, die in Kapitel 05 ausführlicher stehen und hier zusammenlaufen:

Die Mitte wird schlechter berücksichtigt. Ein Dokument, das drei Viertel des Fensters füllt, hat sehr viel Mitte. Was in einem kurzen Prompt eine Randerscheinung ist, wird hier zur Regel.

Beim Überlaufen entscheidet die Anwendung. Ob der Anfang herausfällt, ob zusammengefasst wird, ob das Fenster geleert wird: Das ist eine Pro­dukt­ent­schei­dung, und sie wird selten angezeigt.

Jede weitere Runde zahlt erneut. Ein Suchergebnis wird in jedem folgenden Gesprächszug mitgeschickt. Drei Suchen in einem langen Gespräch sind kein einmaliger Aufwand.

Daraus folgt eine Bauregel, die dem naheliegenden Weg widerspricht: Mehr Nachschlagen macht die Antwort nicht sicherer. Ab einem gewissen Punkt macht es sie schlechter, weil das Nachgeschlagene die Anweisung verdrängt, die es einordnen sollte. Was hilft, ist genaueres Suchen und weniger Text davon.

Bei einem Anbieter ist diese Regel inzwischen ins Tool selbst gewandert. Die neueren Fassungen der Websuche lassen Code über die Treffer laufen, bevor sie ins Fenster kommen, und geben nur weiter, was zur Frage passt (externe Seite, platform.claude.com). Beim Abrufwerkzeug (externe Seite, platform.claude.com) geht dasselbe mit ganzen Seiten und PDFs. Die Vorauswahl bleibt damit dieselbe Idee, nur trifft sie ein Programm, das dasselbe Modell im selben Durchgang geschrieben hat.

Wenn das Modell selbst weitersucht

Bis hierher ging es um das einzelne Nachschlagen: eine Frage, eine Suche, das Ergebnis im Fenster. Ein Suchagent macht daraus eine Schleife. AllSpark beschreibt die Aufgabe bei der Veröffentlichung seiner beiden offenen Suchagenten Iris-mini und Iris-pro auf der Projektseite (externe Seite, github.com) so: Ein fähiger Suchagent muss entscheiden, wonach er sucht, wie er liest, was zurückkommt, wann er weitermacht und wann die gesammelten Belege genügen.

Die Suche selbst führt weiterhin ein Programm aus. Das Modell schreibt die Anfragen, liest die Treffer und entscheidet, ob es eine weitere Runde braucht. Bei Iris stehen ihm dafür zwei Werkzeuge zur Verfügung, eine Websuche und der Abruf einzelner Seiten. In Gemini und ChatGPT ist dieselbe Bauform als Funktion Deep Research (externe Seite, blog.google) bekannt geworden.

Damit wird die dritte Folge aus dem vorigen Abschnitt zur Hauptsache. Jede Runde legt ihr Ergebnis ins Fenster, und bei einer schweren Frage ist das Fenster voll, bevor die Antwort feststeht. Die Arbeit zu Iris misst deshalb jeden Test zweimal, mit und ohne Verwaltung des Kontexts. Die Begründung im Abstract (externe Seite, arxiv.org): Wie der Kontext während der Ausführung verwaltet wird, macht in diesen Tests mehr aus als die meisten veröffentlichten Unterschiede zwischen Systemen.

Die Zahlen dazu stehen in der Tabelle der Projektseite (externe Seite, github.com). Im Test BrowseComp beantwortet Iris-mini ohne Verwaltung 64,7 Prozent der Fragen richtig. Mit der Einstellung, die den gesammelten Werkzeugverlauf verwirft und bei der Frage neu beginnt, sobald das Fenster eine Schwelle überschreitet, sind es 82,2 Prozent. Der Abstand zum nächstbesten offenen Modell derselben Größe beträgt in derselben Tabelle 3,4 Punkte, und dessen Wert stammt aus einem eigenen Bericht mit eigener Verwaltung.

Für das Lesen solcher Zahlen gilt dasselbe wie für den Stichtag: Eine veröffentlichte Zahl beschreibt ein Modell zusammen mit dem Programm, das es betreibt. Was zu diesem Programm gehört, steht in Agenten und Harness, Kapitel 04, wie man eine Messung liest, in Beurteilen und Einordnen, Kapitel 04.

Wo die Anbieter auseinandergehen

Die drei Häuser geben unterschiedlich viel preis, und zwar nicht nur in der Ausführlichkeit.

Googles Uneinheitlichkeit ist belegbar: Die Karten zu Gemini 3.6 Flash und 3.8 Flash (externe Seite, deepmind.google) nennen einen Stichtag samt Einschränkung, die Karte zu Gemini 3 Flash nennt gar keinen und verweist für alles auf die Karte zu Gemini 3 Pro (externe Seite, storage.googleapis.com), und Gemini 3.1 Pro nennt ebenfalls keinen.

Und innerhalb eines Hauses geht es ebenfalls auseinander. Anthropics Ent­wick­ler­do­ku­men­ta­tion führt je Modell zwei Daten. Der Hilfeartikel (externe Seite, support.claude.com) für dieselben Modelle nennt einen einzigen Wert und wählt mal den einen, mal den anderen: Für Claude Haiku 4.5 nennt er den Juli 2025, das Ende der Trainingsdaten, für Claude Sonnet 4.6 den August 2025, das Ende des verlässlichen Wissens. Die Transparenzseite (externe Seite, anthropic.com) gibt für Sonnet 4.6 einen dritten Wert an, Mai 2025, und nennt ihn den Tag, bis zu dem das Wissen am verlässlichsten ist. Die Ent­wick­ler­do­ku­men­ta­tion führt dafür den August 2025 und für die Trainingsdaten den Januar 2026. Wer sich auf eine dieser Seiten beruft, sollte sagen, auf welche.

Was man daraus nicht schließen sollte

Ein späterer Stichtag ist kein Qualitätsmerkmal. Er sagt, wann der Text endete, und nichts darüber, wie gut das Modell damit umgeht. Ein Modell mit frischeren Daten kann in jeder anderen Hinsicht schwächer sein.

Ein Modell mit Suchzugriff ist auf eine Suche angewiesen und deshalb noch lange nicht aktuell. Die Suche hat ihre eigenen Fehler. Der Unterschied ist, wo der Fehler entsteht und wie sichtbar er ist: Ein falscher Beleg im Kontext sieht für das Modell aus wie ein richtiger.

Die Zahl in der Tabelle gibt die Auslegung des Herstellers wieder, keine Grenze im Kopf des Modells. In einem Fall liegt sie vierzehn Monate großzügiger als in bestimmten Gebieten. Wer die Grenze für eine eigene Anwendung braucht, misst sie selbst, mit eigenen Fragen aus dem eigenen Gebiet.