Deep Research ist ein Verifizierungs-Workflow

Deep Research wird mächtig, wenn es sich weniger wie ein Chatbot verhält und mehr wie ein Verifizierungssystem.

Dieser Unterschied ist entscheidend. Ein Chatbot beantwortet die Frage, die vor ihm liegt. Ein Verifizierungssystem rekonstruiert die Frage, kartiert die Belege, hinterfragt die Annahmen, prüft den aktuellen Stand und weigert sich, einen gut geschriebenen Absatz als Beweis zu behandeln.

Die meiste KI-Recherche fühlt sich noch wie die erste Variante an. Frag ein Modell nach einem Marktüberblick, einer Wettbewerbsanalyse, einer technischen Zusammenfassung oder einem strategischen Memo, und es wird meist etwas Plausibles produzieren. Es findet die naheliegenden Quellen. Es fasst sauber zusammen. Es schreibt mit Selbstsicherheit. Für Arbeit mit geringem Einsatz reicht das vielleicht.

Bei Arbeit mit hohem Einsatz ist Plausibilität der eigentliche Fehlermodus.

Der Deep-Research-Workflow, den ich nutze, ist genau um dieses Problem herum gebaut. Sein Wert liegt nicht darin, längere Reports zu produzieren. Auch nicht darin, mehr Agents um der Komplexität willen einzusetzen. Der Hebel kommt aus einem wiederholbaren Operating Loop: Kontext entdecken, Behauptungen kartieren, Belege sammeln, den Entwurf herausfordern, das Artefakt korrigieren und das gesamte System validieren, bevor die Arbeit als fertig gilt.

Die wichtige Verschiebung ist diese: Das Ergebnis wird nicht als statisches Memo behandelt. Es wird als lebendiger Evidence Graph behandelt.

Gewöhnliche Recherche hört zu früh auf

Single-Agent-Recherche ist schnell, und diese Geschwindigkeit ist nützlich. Aber sie hat vorhersehbare Schwächen.

Sie übersieht den Systemkontext. Ein neuer Chat kennt nicht automatisch den Source Tree, die Notizen, die Datasets, die Acceptance Criteria oder die Form des fertigen Artefakts. Er startet aus dem sichtbaren Prompt heraus, nicht aus der vollständigen Arbeitsumgebung.

Sie akzeptiert veraltete Behauptungen. Eine Quelle, die früher korrekt war, kann jetzt falsch sein. Eine QA-Notiz kann ein Problem beschreiben, das längst behoben wurde. Ein generiertes Dataset kann alte Formulierungen bewahren, nachdem sich das sichtbare Artefakt bereits geändert hat.

Sie vermischt Beleg und Interpretation. Das Modell fasst eine technische Behauptung, eine Marktschätzung oder ein Quelldokument vielleicht so zusammen, dass es richtig klingt, während es leise den Rahmen der Behauptung verschiebt.

Sie hört beim Prosatext auf. Selbst wenn sie ein Problem erkennt, endet die Arbeit oft mit einem Kommentar: "Diese Quelle scheint veraltet" oder "Dieser Abschnitt sollte überarbeitet werden." Das ist nützlich, aber es ist keine Verifizierung. Verifizierung bedeutet, dass Dokument, Daten, Quellenangaben, Notizen und Validierungsstand nach der Korrektur alle übereinstimmen.

Deshalb kann oberflächliche Recherche fertig aussehen und trotzdem fragil bleiben. Das finale Dokument liest sich gut, aber die Kette der Behauptungen darunter wurde nie gezwungen, ein Review zu überstehen.

Deep Research ist meine Antwort auf diese Fragilität.

Der Workflow

Der Workflow hat sechs Phasen. Sie sind einfach, aber die Reihenfolge zählt.

1. Context Discovery

Der erste Schritt ist nicht Schreiben. Es ist Orientierung.

Bevor extern recherchiert wird, durchsucht der Workflow lokale Dateien, Notizen, Source-Exports, Datasets und alle vorhandenen QA-Artefakte. Das Ziel ist, das Amnesie-Problem zu vermeiden: bei null zu beginnen, obwohl der Workspace bereits relevanten Kontext enthält.

Diese Phase beantwortet Fragen wie:

Welcher Kontext existiert bereits?
Welche Behauptungen sind zentral für das Deliverable?
Welche Quellen sind bereits verknüpft?
Welche Erkenntnisse könnten veraltet sein?
Was bedeutet "fertig" für dieses Artefakt?

Diese letzte Frage überspringt man leicht. Sie ist auch der Punkt, an dem viel KI-Recherche scheitert. Ein Research-Memo, ein technisches Briefing, ein Dashboard und ein Anhang haben nicht dieselben Acceptance Criteria. Der Workflow muss die Form des Artefakts erkennen, bevor er die Qualität des Inhalts beurteilen kann.

2. Source and Claim Mapping

Als Nächstes kartiert der Workflow das Artefakt als System.

In einem normalen Schreibdurchgang liest du den Prosatext. In einem Verifizierungsdurchgang verfolgst du Behauptungen zurück zu den Belegen. Welche Aussagen hängen von welchen Source-IDs ab? Welche Charts hängen von welchen Datasets ab? Welcher Anhang wiederholt eine Behauptung aus der Executive Summary? Welche sichtbaren Quellenangaben werden aus einem Source-Export generiert?

Hier hört das Deliverable auf, ein Dokument zu sein, und wird zu einem Graphen:

Behauptungen
Quellen
Quellenverweise
Datendateien
Notizen
Anhänge
Quelleneinträge
Validierungs-Skripte

Sobald der Graph sichtbar ist, wird Drift leichter zu erkennen. Eine korrigierte Behauptung im Hauptdokument reicht nicht, wenn dieselbe veraltete Behauptung in einem Anhang, in JSON-Daten, in Quellnotizen oder in einem generierten Export überlebt.

3. Parallel Research and Verification

Erst nach Kontext- und Claim-Mapping fächert der Workflow auf.

Verschiedene Research-Spuren können parallel arbeiten: eine prüft die Quellenabdeckung, eine andere die technischen Behauptungen, eine andere Zahlen und Annahmen, eine andere die Metadaten und die Übereinstimmung der Quellenangaben. Der Punkt ist nicht, ein Theater um "Multi-Agent"-Arbeit zu inszenieren. Der Punkt ist Trennung der Zuständigkeiten.

Der Rechercheur, der Quellen sammelt, sollte nicht der einzige Kritiker der Interpretation sein. Der Agent, der Source-IDs prüft, sollte nicht vom narrativen Fluss abgelenkt werden. Die Spur, die technische Behauptungen prüft, sollte sagen dürfen: "Die Prosa ist klar, aber die Behauptung ist zu stark."

Parallelität zählt, weil sie Perspektive bewahrt. Sie macht die Arbeit auch schneller, aber Geschwindigkeit ist nicht der Hauptvorteil. Der Hauptvorteil ist, dass jede Spur einen engeren Standard halten und ihn rigoroser anwenden kann.

4. Adversarial QA

Die vierte Phase ist bewusst skeptisch.

Der Workflow sucht nach veralteten Erkenntnissen, Drift bei Quellenangaben, kaputten Evidence-IDs, doppelten Ankern, toten internen Links, Diskrepanzen bei generierten Daten und überzogenen Schlussfolgerungen. Er prüft, ob alte QA-Notizen noch das aktuelle Artefakt beschreiben. Er prüft, ob cache-busted Assets tatsächlich fehlen oder nur fehlend aussehen, weil der Validator den Dateinamen zu wörtlich liest. Er prüft, ob der Source-Export den erwarteten Key nutzt oder einen anderen stabilen Identifier.

Das zählt, weil Research-Artefakte auf langweilige Arten scheitern.

Die gefährlichen Fehler sind nicht immer große Halluzinationen. Oft sind es kleine Diskrepanzen:

Eine numerische Behauptung verweist auf die falsche Source-ID.
Eine Statusaussage zitiert eine benachbarte, aber schwächere Quelle.
Eine technische Zusammenfassung befördert ein Nebendetail zur Hauptbehauptung.
Ein Quelleneintrag hat das richtige Thema, aber den falschen zugrunde liegenden Verweis.
Eine Validierungsdatei bewahrt eine überholte Erkenntnis.
Ein Dokument und ein Anhang widersprechen sich jetzt, weil nur eines gepatcht wurde.

Diese Defekte übersieht man beim Durchlesen leicht. Genau das ist es, was ein Verifizierungs-Workflow abfangen soll.

5. Direct Correction

Ein Problem zu finden ist nicht die Ziellinie.

Wenn der Workflow einen Fehler bestätigt, korrigiert er das Artefakt direkt. Das kann bedeuten, sichtbaren Prosatext, generierte Daten, Source-Mappings, Source-Exports, Notizen oder Validierungs-Zusammenfassungen zu aktualisieren. Die Korrektur muss dort landen, wo die Behauptung lebt, nicht nur dort, wo das Problem bemerkt wurde.

Das ist der größte Unterschied zwischen Deep Research und gewöhnlicher KI-gestützter Recherche. Der Workflow gibt sich nicht mit einer Kritik zufrieden. Er will, dass das Deliverable wahrer wird.

Der Standard ist evidenzgeführte Korrektur, nicht spekulatives Umschreiben. Ist eine Behauptung unbelegt, engt der Workflow sie ein. Ist eine Quelle veraltet, ersetzt oder relativiert er sie. Lässt sich eine technische Nuance nicht vollständig bestätigen, bewahrt er die Unsicherheit, statt aus einer Schätzung einen Fakt zu machen.

6. Final Validation

Die letzte Phase ist mechanisch und notwendig.

Nach den Korrekturen validiert der Workflow das System erneut: Quellenverweise lösen sich auf, JSON parst, lokale Assets existieren, interne Links funktionieren, doppelte IDs fehlen, Source-Exports stimmen überein und die Formatierungsprüfungen bestehen.

Diese Phase ist nicht glamourös. Sie ist auch der Punkt, an dem Vertrauen verdient wird. Ein Research-Artefakt kann exzellente Prosa haben und trotzdem operativ kaputt sein. Kaputte Quellenangaben, veraltete generierte Dateien und ungültige Datenstrukturen sind keine Präsentationsdetails. Sie sind der Beweis, dass das Artefakt nicht wirklich in einen kohärenten Zustand zurückgeführt wurde.

Deep Research endet erst, wenn das Artefakt und seine Evidenzebene übereinstimmen.

Das System, das ich gebaut habe

Das System ist um eine einfache Annahme herum gebaut: Research-Qualität hängt von der Integrität des gesamten Artefakts ab, nicht nur vom sichtbaren Text.

Das Artefakt kann ein Markdown-Briefing, ein strukturierter Report, eine dataset-gestützte Seite, ein Memo mit Anhängen oder ein generiertes Deliverable sein. Das genaue Format ändert sich. Der Control Loop nicht.

Ein oberflächliches Review liest das oberste Dokument, macht ein paar Formulierungsvorschläge und hört auf.

Das Deep-Research-System behandelt das Deliverable als eine Reihe verbundener Oberflächen:

Narrative Abschnitte
Source-Mappings
Datendateien
Notizen
Anhänge
Generierte Exports
Validierungs-Artefakte

Jede Oberfläche wird gegen die anderen geprüft. Sagt das Narrativ das eine und die Daten das andere, markiert das System die Diskrepanz. Verweist eine Quellenangabe auf die falsche Quelle, behandelt das System das als Fehler in der Behauptung, nicht als kosmetisches Problem. Bewahrt der generierte Output veraltete Formulierungen, verfolgt das System die Behauptung zurück zur Quellebene, statt nur den Absatz zu bearbeiten.

Das ist der Teil, der mir am wichtigsten ist. Der Workflow trennt Schreiben nicht von Verifizierung. Er macht das Schreiben der Evidenzebene gegenüber rechenschaftspflichtig.

Das System hat drei Aufgaben:

Den Source Graph sichtbar halten.
Behauptungen an die richtigen Belege gekoppelt halten.
Das finale Artefakt nach Korrekturen intern konsistent halten.

Das macht den Workflow über eine einzige Domäne hinaus nützlich. Er kann Marktforschung, technische Analyse, Produktstrategie, Wettbewerbsanalyse und interne Entscheidungsunterstützung bewältigen, weil das Kernproblem dasselbe ist: Behauptungen driften von Belegen weg, wenn das System sie nicht immer wieder zurückholt.

Das ist der Unterschied zwischen "Ich habe das Dokument geprüft" und "Das Artefakt ist jetzt zuverlässiger."

Warum sich das aufsummiert

Der Workflow wird mit der Zeit wertvoller, weil jeder Durchlauf besseren Kontext hinterlässt.

Ein normaler Chat produziert eine Antwort. Ein Verifizierungs-Workflow produziert eine Antwort plus Source-Mappings, korrigierte Artefakte, Validierungsnotizen und wiederverwendbares Wissen darüber, wo das Artefakt fragil war. Der nächste Durchlauf startet aus dem Systemkontext heraus statt bei null.

Das ist der Compound-Effekt, der mir wichtig ist. Das Research-System wird besser darin, genau die Fehlerarten abzufangen, die in strukturierter Recherche auftauchen. Es lernt, dass generierte Daten von der sichtbaren Prosa abdriften können. Es lernt, dass alte QA-Dateien veraltet sein können. Es lernt, dass Source-IDs genauso wichtig sind wie Quellentitel. Es lernt, dass technische Zusammenfassungen Disziplin beim Rahmen der Behauptung brauchen.

Das macht den Workflow nicht autonom im leichtsinnigen Sinn. Es macht ihn besser inspizierbar. Der Mensch besitzt weiterhin das Urteil. Der Workflow macht die Beleg-Spur leichter auditierbar.

Das verändert auch die Rolle des Operators. Die Arbeit mit dem höchsten Hebel ist nicht die Frage "Kannst du das recherchieren?" Es ist zu definieren, was als Beleg zählt, welche Oberflächen übereinstimmen müssen, welche Risiken ein adversariales Review verdienen und welche Validierung bestehen muss, bevor dem Ergebnis vertraut wird.

Mit anderen Worten: Der Operator promptet nicht nur. Der Operator designt das Control-System der Recherche.

Was schiefgehen kann

Deep Research ist keine Magie. Es kann scheitern, wenn die operative Disziplin zusammenbricht.

Es kann seinen eigenen Zwischennotizen zu sehr vertrauen. Eine QA-Checkliste ist nützlich, aber sie kann veraltet sein. Das aktuelle Artefakt muss direkt geprüft werden.

Es kann sich zu sehr an generierte Strukturen anpassen. Ein Validator markiert vielleicht ein fehlendes Asset, weil er Query Strings nicht aus lokalen Pfaden entfernt. Eine CSV-Prüfung nimmt vielleicht an, der stabile Key sei id, obwohl der Export tatsächlich evidence_id nutzt.

Es kann unsichere Behauptungen überzeichnen. Marktgröße, technischer Umfang, Wettbewerbspositionierung und Quelleninterpretation haben oft eine Unsicherheit, die in die finale Prosa überleben sollte.

Es kann nur die sichtbare Ebene korrigieren. Das ist der häufigste Fehler. Das Dokument liest sich korrekt, aber die Daten, Notizen oder der Source-Export tragen noch die alte Behauptung.

Die Gegenmaßnahme ist langweilig und streng: das System kartieren, wo möglich gegen primäre oder dauerhafte Quellen verifizieren, jede abhängige Oberfläche patchen und nach den Änderungen validieren.

Das wiederverwendbare mentale Modell

Die einfachste Version des Workflows sind vier Verben:

Kartieren. Verifizieren. Patchen. Validieren.

Kartiere die Behauptungen und die Oberflächen, auf denen sie auftauchen.

Verifiziere die Behauptungen gegen das Quellenmaterial, nicht gegen die Selbstsicherheit der Prosa.

Patche das tatsächliche Artefakt, inklusive generierter Daten und der Ebenen der Quellenangaben.

Validiere, dass das finale Deliverable intern kohärent ist.

Das ist es, was Deep Research von KI-Zusammenfassung unterscheidet. Es optimiert nicht auf einen überzeugenden ersten Entwurf. Es optimiert auf ein Deliverable, das den Kontakt mit den eigenen Belegen aushält.

Für technische Operatoren, Gründer, Produktstrategen und KI-Power-User ist das der Teil, den es sich zu kopieren lohnt. Bau keinen Research-Workflow, der bloß mehr schreibt. Bau einen, der Behauptungen rechenschaftspflichtig macht.

Die Zukunft der KI-Recherche ist nicht die längste Antwort. Es ist die Antwort, deren Evidence Graph nach dem Review noch zusammenhält.