OpenResearcher: eine offene Pipeline für Deep-Research-Trajektorien
OpenResearcher: A Fully Open Pipeline for Long-Horizon Deep Research Trajectory Synthesis
Auf einen Blick
- Was ist das?
- OpenResearcher kombiniert einen 96K-Trajektorien-Datensatz, ein 30B-A3B-Modell und ein eigenes Retrieval über einen 11B-Token-Korpus. Der Reiz liegt weniger im Modell als in der Abkehr von externen Search-APIs.
- Für wen ist es gedacht?
- OpenResearcher passt zu Teams, die Trajektorien selbst erzeugen oder destillieren wollen und bereit sind, einen 11B-Token-Korpus sowie GPU-Kapazität zu betreiben. Wer nur ein fertiges Recherche-Frontend sucht, ist hier falsch: Der Betrieb verlangt vLLM, einen lokalen Retriever und je Benchmark unterschiedliche Zugänge.
- Darf ich es kommerziell nutzen?
- Nicht ohne Erlaubnis. GitHub findet in diesem Repository keine Lizenzdatei, und ohne Lizenz sind standardmäßig alle Rechte vorbehalten: Sie dürfen den Code lesen, aber nicht wiederverwenden. Prüfen Sie die README oder fragen Sie die Autoren, bevor Sie ihn nutzen.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 97 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem OpenResearcher adressiert
Lange Rechercheketten mit Werkzeugaufrufen sind teuer zu erzeugen. Wer einem Modell beibringen will, über 100 Interaktionen hinweg Suchanfragen zu stellen, Seiten zu öffnen und Ergebnisse zu verdichten, braucht Trainingsdaten in genau diesem Format. Die übliche Quelle sind externe Such-APIs. Das kostet pro Abfrage, limitiert die Parallelität und macht die Reproduktion eines Datensatzes vom Vertrag eines Anbieters abhängig. Das Repository beschreibt diesen Punkt explizit als Motivation: Die Trajektorien werden über einen selbstgebauten Retriever und einen eigenen Korpus mit rund 11 Milliarden Token erzeugt, wodurch externe Search-APIs entfallen.
Die Zielgruppe ist enger, als der Name vermuten lässt. OpenResearcher richtet sich an Teams, die einen Deep-Research-Agenten trainieren oder destillieren, nicht an Anwender, die eine Rechercheoberfläche suchen. Die HuggingFace-Demo und das 30B-A3B-Modell sind Beiwerk zu einer Rezeptur: Datensatz, Modell, Destillation und ein Evaluationsframework. Wer nur Ergebnisse auf BrowseComp-Plus reproduzieren will, kann auch nur diesen Teil nutzen, aber der volle Nutzen entsteht erst, wenn eigene Trajektorien generiert werden.
Datenfluss: Generator, Korpus, Destillation
Die Pipeline besteht laut README aus drei ineinandergreifenden Teilen. Erstens ein Generator: GPT-OSS-120B erzeugt Trajektorien mit nativen Browser-Werkzeugen, wie sie in den vLLM-Rezepten für dieses Modell dokumentiert sind. Zweitens ein Korpus und ein darauf aufgebauter Retriever, der die Suchschritte bedient. Drittens eine Destillation in ein 30B-A3B-Modell, das die Trajektorien als Trainingssignal nutzt.
Bemerkenswert ist die Reihenfolge. Die Trajektorien entstehen nicht gegen eine Live-Suche, sondern gegen einen festen Korpus. Das macht Läufe wiederholbar und erklärt, warum das Projekt von Skalierung und niedrigen Kosten spricht: derselbe Index, beliebig viele Durchläufe, keine Abrechnung pro Query. Der Preis dafür ist eine Verschiebung. Ein Agent, der auf einem eingefrorenen Korpus trainiert wurde, hat gelernt, mit dessen Abdeckung und dessen Ranking umzugehen. Ob sich das auf einen anderen Index überträgt, lässt sich aus dem Material nicht ableiten. Das README nennt keine Ablation dazu, und die Eval-Logs sind nur als Verweis auf einen HuggingFace-Ordner vorhanden, nicht als ausgewertete Tabelle.
Die 96K Trajektorien mit über 100 Turns sind die zentrale Ressource. Wer sie direkt verwenden will, muss sie nicht selbst generieren. Wer sie nachbauen will, braucht den Generator, den Korpus und die Rechenzeit. Beides sind legitime Wege, aber nur der zweite rechtfertigt den vollen Aufbau.
Installation und Konfiguration
Das README gliedert das Setup in Installation, Vorbereitung der Benchmarks, Konfiguration und Quick Start. Konkrete Befehle sind im vorliegenden Auszug nicht enthalten, nur die Struktur und die Verweise. Wer das Repository klont, findet die Details in den verlinkten Abschnitten; hier lässt sich nur sagen, welche Bausteine das Setup umfasst.
Zwei Betriebsarten werden unterschieden. Beispiel 1 führt BrowseComp-Plus mit einer lokalen Suchmaschine aus, Beispiel 2 nutzt GAIA über die Serper-API und kommt ohne lokale Suche aus. Diese Trennung ist praktisch relevant: Der lokale Pfad verlangt den eigenen Retriever und damit Speicher und Indexierungszeit für den 11B-Token-Korpus. Der API-Pfad ist schnell startklar, gibt aber genau den Vorteil auf, den das Projekt bewirbt. Ein Team, das nur kurz Ergebnisse sehen will, fährt mit Serper günstiger; wer die Kosten über viele Läufe drücken will, muss den lokalen Weg gehen.
Für das Training ist ein eigener README-Abschnitt vorhanden, der seit Februar 2026 verfügbar ist. Auch hier gilt: Die Befehle stehen im Repository, nicht im Auszug. Ein Modell namens OpenResearcher-30B-A3B und ein Demo-Space sind auf HuggingFace verlinkt, was den Einstieg ohne eigenes Training erlaubt. Die Konfigurationsschlüssel sind im Material nicht benannt, deshalb an dieser Stelle keine Angabe dazu.
Was die Zahlen auf BrowseComp-Plus wirklich sagen
Das README nennt 54,8 Prozent Genauigkeit auf BrowseComp-Plus und ordnet das über GPT-4.1, Claude-Opus-4, Gemini-2.5-Pro, DeepSeek-R1 und Tongyi-DeepResearch ein. Diese Zahl ist der stärkste Einzelbeleg im Material, und sie ist gleichzeitig der am schwierigsten zu prüfende. Die Vergleichstabelle liegt als Bild vor (assets/imgs/main_table.png), nicht als Text. Aus dem Auszug geht nicht hervor, mit welcher Konfiguration die Baselines liefen, ob Werkzeugbudgets identisch waren oder wie viele Versuche pro Aufgabe gezählt wurden. Das ist keine Unterstellung, sondern eine Lücke: Wer die Zahl zitieren will, sollte die Tabelle im Repository selbst lesen.
Auffällig ist die Bandbreite der Benchmarks. Neben BrowseComp-Plus werden BrowseComp, GAIA und xbench-DeepSearch genannt. Das sind unterschiedliche Aufgabenformate mit unterschiedlichen Anforderungen an Werkzeuge und Antwortformate. Ein einzelner Wert sagt wenig darüber, ob ein Modell bei kurzen faktischen Fragen und bei langen Rechercheketten gleichermaßen brauchbar ist. Die Eval-Logs sind als eigener HuggingFace-Ordner verlinkt, was immerhin eine Nachprüfung erlaubt, sofern man sie selbst auswertet. Das Repository tut das im README nicht.
Wo die Pipeline an ihre Grenzen stößt
Der wichtigste Vorbehalt betrifft die Abhängigkeit vom Korpus. Die gesamte Kostenargumentation ruht darauf, dass ein selbstgebauter Retriever über einen festen Korpus externe Such-APIs ersetzt. Das funktioniert für Trainingsläufe, in denen derselbe Index tausendfach abgefragt wird. Es funktioniert schlecht, wenn die Fragen aktuelles Wissen verlangen, das im Korpus nicht enthalten ist. Ein Agent, der auf einem eingefrorenen Index trainiert wurde, kann dort keine Antwort finden, und ob er das erkennt oder plausibel halluziniert, ist eine Eigenschaft des Trainings, nicht des Retrievers.
Zweitens die Hardware. Ein Korpus von rund 11 Milliarden Token plus ein 30B-A3B-Modell bedeuten GPU-Speicher und Indexinfrastruktur. Das README bewirbt niedrige Kosten, aber die Kosten sind verschoben, nicht beseitigt: statt pro Query zu zahlen, betreibt man dauerhaft Speicher und Rechenzeit. Für ein einzelnes Experiment ist das teurer als ein API-Guthaben.
Drittens die Lizenz. Das Repository nennt keine Lizenz, weder im vorliegenden Auszug noch in den Metadaten. Datensatz, Modell und Korpus liegen auf HuggingFace unter eigenen Bedingungen, die hier nicht sichtbar sind. Wer die Artefakte kommerziell nutzen will, muss das vorab klären. Ohne Lizenzangabe im Repository ist die Rechtslage unklar, und das ist ein praktisches Hindernis, kein formaler Hinweis.
Viertens die Wartung. Der letzte Push liegt im Juni 2026, Releases sind keine erfasst. Das Projekt ist aktiv, aber es gibt keine versionierten Artefakte, an denen man sich festhalten könnte. Ein Upgrade bedeutet, den Stand des Hauptzweigs zu übernehmen.
Der Unterschied zu Such-API-Agenten
Die naheliegende Alternative ist ein Agent, der seine Suchschritte über eine kommerzielle Such-API ausführt, etwa Serper, das OpenResearcher selbst im GAIA-Beispiel verwendet. Der Unterschied liegt nicht in der Modellarchitektur, sondern in der Datenquelle. Ein API-Agent sieht einen Index, der vom Anbieter gepflegt und aktualisiert wird. Er kann Fragen beantworten, die nach dem Trainingszeitpunkt entstanden sind, und er braucht keine eigene Infrastruktur. Dafür ist jeder Lauf kostenpflichtig, die Abdeckung ist nicht kontrollierbar, und die Reproduzierbarkeit hängt davon ab, dass der Anbieter dieselben Ergebnisse liefert.
OpenResearcher dreht das um. Der Index gehört dem Betreiber, die Abfragen sind gratis, die Ergebnisse sind wiederholbar. Dafür ist der Wissensstand eingefroren und die Abdeckung eine eigene Verantwortung. Für die Erzeugung von Trainingsdaten ist das der bessere Tausch, weil dort Wiederholbarkeit und Volumen zählen. Für einen produktiven Rechercheassistenten ist es der schlechtere, weil Aktualität zählt.
Interessant ist, dass das Projekt beide Wege kennt. Das GAIA-Beispiel zeigt, dass die eigene Pipeline auch mit Serper läuft. Wer den lokalen Retriever nicht betreiben will, kann die Evaluations- und Trainingswerkzeuge trotzdem nutzen und die Suche auslagern. Damit verliert man das Kostenargument, behält aber das Datenformat und die Destillationsrezeptur.
Betriebsaufwand und Pflege
Der Aufwand verteilt sich auf drei Posten. Erstens der Korpus: Indexierung und Speicher für rund 11 Milliarden Token, einmalig und dann dauerhaft. Zweitens der Generator: GPT-OSS-120B über vLLM, was GPU-Kapazität für die Trajektorienerzeugung bedeutet. Drittens das Training des 30B-A3B-Modells, sofern man nicht das veröffentlichte Modell verwendet. Nur der dritte Posten ist optional; die ersten beiden sind der Preis für den lokalen Pfad.
Pflege ist schwer einzuschätzen. Es gibt keine Releases, also keine Versionsnummern, an denen man Upgrades festmachen könnte. Änderungen am Hauptzweig können Konfigurationsformate oder Skriptaufrufe verschieben, ohne dass das im Voraus sichtbar ist. Wer die Pipeline produktiv einsetzt, sollte den verwendeten Commit festhalten und nicht blind aktualisieren.
Die Lizenzfrage bleibt der größte offene Punkt. Ein Repository ohne Lizenzangabe bedeutet nicht automatisch, dass keine Nutzung erlaubt ist, aber es bedeutet, dass man es nicht annehmen darf. Das gilt besonders, wenn die trainierten Gewichte oder der Korpus weitergegeben werden sollen. Hier ist keine rechtliche Einschätzung möglich, nur der Hinweis, dass die Angabe fehlt und vor einer Adoption eingeholt werden sollte.
Redaktionelles Fazit
OpenResearcher passt zu Teams, die Trajektorien selbst erzeugen oder destillieren wollen und bereit sind, einen 11B-Token-Korpus sowie GPU-Kapazität zu betreiben. Wer nur ein fertiges Recherche-Frontend sucht, ist hier falsch: Der Betrieb verlangt vLLM, einen lokalen Retriever und je Benchmark unterschiedliche Zugänge. Vor dem Adoptieren zuerst klären: Ist die Lizenz des Repositories und der HuggingFace-Artefakte für die geplante Nutzung definiert, und lässt sich der Korpus auf der vorhandenen Hardware indexieren?
Community-Notizen