CASE STUDY

Academic DeepSearch

Abundance: eine Deep-Research-Anwendung, die aus einer komplexen Frage einen belegten Bericht macht – mit Gegenbelegen, kalibrierter Konfidenz und Zitaten, die nur auf zugelassene Quellen zeigen dürfen.

Rolle: Konzeption, Architektur und Entwicklung
Status: Open Source (MIT) auf GitHub, Release v1.0.0

Startbildschirm von Abundance mit Verlauf bisheriger Recherchen, Modellauswahl und Eingabefeld für eine neue Frage — Screenshot der Anwendung.

AUSGANGSLAGE

Problem

Deep-Research-Tools klingen überzeugend, aber die Kette von der Behauptung zur Quelle reißt schnell: Das Modell entscheidet selbst, welche Werkzeuge laufen, zitiert Seiten, die nie geprüft wurden, und liefert eine Konfidenz, die niemand nachrechnen kann. Für akademische Fragen ist genau das unbrauchbar – dort muss jeder Satz auf einen Beleg zurückführbar sein, und der Gegenbeleg gehört mit in den Bericht.

SO FUNKTIONIERT ES

Lösung & Architektur

Recherche

Der Graph entscheidet, nicht das Modell

Die Recherche läuft als deterministischer LangGraph-Workflow mit acht Stufen. Das Modell plant falsifizierbare Belegfragen und synthetisiert am Ende, aber welche Fähigkeit wann läuft, legt der Graph fest. Belege werden parallel und nur lesend gesammelt; Quellenzulassung, Deduplizierung und Zitatbindung sind Code, keine Prompts. Drei Modi setzen harte Budgets von 9, 30 oder 60 Belegen pro Lauf.

8 Stufen, vom Scoping bis zur Veröffentlichung
Quick, Balanced, Thorough: maximal 9, 30 oder 60 Belege
Abgerufener Text gilt als nicht vertrauenswürdige Daten

Schematische Darstellung des Recherche-Ablaufs von der Frage über parallele Belegsuche und Zulassung bis zum Bericht, mit den drei Budgetmodi

Verifikation

Jede Behauptung muss auf ihren Beleg zeigen

Zitate im Bericht dürfen nur auf zugelassene Belege verweisen – das erzwingt der Code. Zusätzlich prüft ein festgepinntes DeepSeek-V4-Flash-Profil im Schattenmodus, ob der gebundene Beleg eine Behauptung stützt, ihr widerspricht oder nicht ausreicht. Freigeschaltet wird ein solches Modell nur über ein reproduzierbares Gate: drei Läufe auf einem versionierten Datensatz mit zwölf Fällen, auf dem der alte Zitat-Check 0 von 12 bestand.

Verdicts stützt, widerspricht, unzureichend – jeweils mit wörtlichem Zitat
3 Läufe: 11/12, 10/12 und 11/12 bestanden
Schattenmodus: misst den Bericht, kann ihn aber nicht umschreiben

Schematische Darstellung einer Behauptung mit gebundenem Zitat, den drei Verdicts und dem Promotion-Gate über drei Läufe

ARCHITEKTUR

Der Weg durch das System

Frage

komplexe Fragestellung

Plan

falsifizierbare Belegfragen

Belege

parallele Suche, nur lesend (Tavily)

Zulassung

URL-Policy und Dedup im Code

Synthese

strukturierte Claims mit Beleg-IDs

Verifikation & Bericht

Zitatbindung, deterministisches Rendering

Streaming
SSE-Events mit stabilem Vertrag; ein Abbruch läuft vom Browser bis in den Graph
Persistenz
PostgreSQL für Runs, Berichte, Metriken und LangGraph-Checkpoints

Qualitätssicherung: CI mit Tests, mypy, ruff und pip-audit; Eval-Harness mit 30 Referenzfällen und einem Promotion-Gate über 3 Läufe für die Claim-Verifikation

Von der Frage zum belegten Bericht

Ergebnisse

deterministische Stufen im LangGraph-Workflow: 8deterministische Stufen im LangGraph-Workflow
Belege je Recherche, hart budgetiert nach Modus: bis zu 60Belege je Recherche, hart budgetiert nach Modus
mittlere Pass-Rate der Claim-Verifikation über 3 Läufe (12 Fälle): 89 %mittlere Pass-Rate der Claim-Verifikation über 3 Läufe (12 Fälle)
Pass-Rate des vorherigen Zitat-Checks am selben Datensatz: 0/12Pass-Rate des vorherigen Zitat-Checks am selben Datensatz

NACHWEIS & EINORDNUNG

Was belegt ist – und wo die Aussage endet

Die vier Felder trennen meinen Beitrag, den Projektkontext, die Messgrundlage und die Grenzen der Ergebnisse.

Mein Anteil: Konzeption, Architektur und Entwicklung des achtstufigen LangGraph-Workflows, der Quellenzulassung, Zitatbindung, Persistenz, Streaming-Schnittstelle und des Eval-Gates.
Team & Kontext: Das Projekt ist als MIT-lizenziertes Release v1.0.0 öffentlich auf GitHub. Die Case Study quantifiziert keine weiteren Teambeiträge und leitet aus dem Open-Source-Status keine alleinige Urheberschaft ab.
Messgrundlage: Das Promotion-Gate nutzt zwölf versionierte Claim-Verifikationsfälle und drei Läufe mit 11/12, 10/12 und 11/12 bestandenen Fällen, im Mittel 89 %. Der vorherige Zitat-Check erreichte auf demselben Datensatz 0/12; das gesamte Eval-Harness enthält 30 Referenzfälle.
Grenzen: Die 89 % beziehen sich auf zwölf Fälle und ein festgepinntes Modellprofil, nicht auf beliebige Forschungsfragen oder Modelle. Die Verifikation läuft im Schattenmodus: Sie misst den Bericht, darf ihn aber nicht umschreiben.

GEBAUT MIT