AutoRAG 2.0: ein Bibliothekar-Agent über bereits vorhandenen CLI-Indizes
AutoRAG: Now your agent can find anything in your computer. It gets smarter if you are using it frequently.
Auf einen Blick
- Was ist das?
- Marker-Inc-Korea hat das Repository von einem Python-AutoML-Werkzeug für RAG-Pipelines in einen TypeScript-Agenten umgebaut, der bestehende lokale Indizes föderiert statt Daten zentral zu ingerieren. Die Idee ist klar, die Betriebskosten liegen in der Legacy-Spaltung und im MinSync-Binary.
- Für wen ist es gedacht?
- Wer bereits katok, discrawl, qmd, msgvault oder rclone betreibt und die Daten nicht in einen zentralen Index kopieren will, findet hier einen Agenten, der die Indizes in place nutzt. Wer eine reproduzierbare RAG-AutoML-Pipeline mit Python-API braucht, bleibt beim Verzeichnis legacy/ und bei pip install AutoRAG.
- Darf ich es kommerziell nutzen?
- Erst prüfen. Die Lizenz dieses Repositorys ordnen wir nicht automatisch ein; lesen Sie vor jeder kommerziellen Nutzung die LICENSE-Datei.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, 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
Das Problem: Suchwerkzeuge liefern Pfade, keine Antworten
Die README benennt den Ausgangspunkt nüchtern. Jedes Suchwerkzeug gebe dasselbe zurück: eine Liste von Dateipfaden und passenden Zeilen. Danach öffnet der Nutzer jede Datei, liest den Kontext, entscheidet über Relevanz, synthetisiert eine Antwort und merkt sich, was funktioniert hat. Das Werkzeug zeigt nur, so die Formulierung der Autoren.
AutoRAG setzt genau an diesem letzten Schritt an. Die Zielgruppe sind nach der Beschreibung Nutzer mit PDFs, Wikis, Notizen, Forschungsarbeiten und Wissensbasen, die bereits lokal erschlossen sind. Der Agent soll Kandidaten abrufen, Quelldateien direkt lesen, die Evidenz beurteilen und ein strukturiertes Ergebnis kuratieren. Die README zeigt als Beispiel eine Antwort mit drei nummerierten Einträgen und Seitenangaben statt Dateipfaden und Zeilennummern.
Bemerkenswert ist die Abgrenzung, die das Projekt selbst zieht: AutoRAG sei kein Koordinator für andere Modellrollen. Ein einziges konfiguriertes Modell besitzt den vollständigen Abruf-, Lese-, Urteils- und Kuratierungszyklus. Wer Multi-Agent-Orchestrierung sucht, ist hier falsch.
Föderation statt Ingestion: warum der Index beim CLI-Werkzeug bleibt
Der erste der drei genannten Grundsätze lautet, das eigene Datenmaterial nie zu migrieren, um es durchsuchbar zu machen. AutoRAG föderiert laut README CLI-eigene Speicher wie katok, discrawl, qmd, msgvault und rclone an Ort und Stelle. Es gibt keine erzwungene Ingestion in einen zentralen Index und keinen Drittanbieter-Server, der eine Kopie des Korpus hält. Ergebnisse tragen quellennative Identitäten, im Beispiel das Format kakao:<chat>/<sender>/<chunk>, mit zugriffsgeprüftem Scope.
Das ist eine Architekturentscheidung mit Folgen. Externe Datenquellen behalten ihren eigenen Archiv- und Index-Lebenszyklus. AutoRAG betreibt für sie kein zweites Indexmanagement. Der Preis dafür ist, dass die Qualität der Föderation von der Qualität der fremden Indizes abhängt. Wer eine Quelle anbindet, die schlecht erschlossen ist, bekommt schlechte Kandidaten. Die README behandelt diesen Fall nicht.
Für lokale Dateien gilt ein anderes Modell. MinSync indiziert geparste Markdown-Spiegel unter .autorag für BM25, Vector und Hybrid. Es entsteht also doch ein Index, nur einer, der aus den Quellen abgeleitet und lokal gehalten wird.
Der Mechanismus: ein Agentenloop mit Registry und ResultMerger
AutoRAG ist laut README ein angepasster Pi-Agent, der Pi-Agentenloop als Bibliothekar konfiguriert. Der Ablauf: Der Bibliothekar ruft Abrufwerkzeuge auf, liest die zugrunde liegenden Dokumente direkt über das eingebaute bash-Werkzeug und kuratiert nach ResultMerger-Score-Normalisierung und Deduplizierung einen vereinheitlichten Ergebnissatz. Abrufwerkzeuge können Kandidatenpfade liefern, aber derselbe Agent öffnet das Quellmaterial, bevor er kuratiert. Antworten kommen als strukturiertes SearchDocumentsResponse zurück, und die Ergebnisse tragen ihre echte Quelle im internen Mapping für Feedback und Kuratierung.
Die Abrufmethoden sind über die RetrievalMethodRegistry austauschbar. Lokales lexikalisches BM25, semantisches Vector und Hybrid laufen über MinSync auf einem gemeinsamen CDC-Chunk-Lebenszyklus. Die README ordnet die Verfahren nach Dokumenttyp zu: grep für Klartext und Konfigurationsdateien, Vektorsuche für dichte Prosa, BM25 für Rechtstexte und Spezifikationen, Hybrid für gemischte Sammlungen.
Diese Tabelle ist eine Heuristik, keine Messung. Das Projekt liefert in der README keine Zahlen dazu, wann welche Methode gewinnt. Wer die Auswahl überprüfen will, muss selbst evaluieren.
Selbstlernendes Gedächtnis: was tatsächlich gelernt wird
Die README beschreibt ein selbstentwickelndes Gedächtnissystem. Jede Suche lehre etwas: welche Abrufmethoden für welche Abfragetypen funktionieren, welche Dokumentbereiche am produktivsten sind und was der Aufrufer über explizites Feedback als nützlich markiert hat. Ein frisches AutoRAG probiere alles, ein erfahrenes wisse, wo es suchen muss.
Das ist die interessanteste Behauptung des Projekts und zugleich die am dünnsten belegte. Die README nennt weder ein Speicherformat noch einen Mechanismus, wie die gelernte Präferenz in die nächste Abfrage einfließt. Sie nennt auch keine Evaluationsmethode, mit der sich der Lerneffekt messen ließe. Wer das prüfen will, muss im Repository nachsehen, nicht in der README.
Klar ist nur die Schnittstelle: Feedback wird über das interne Mapping den echten Quellen zugeordnet, nicht den kuratierten Ausgabetexten. Das ist konsistent mit dem Föderationsprinzip, weil die Rückmeldung an der Quelle ansetzt.
Inbetriebnahme: init, Embedder-Flags und die MinSync-Schalter
Der Einstieg läuft über einen Konstruktoraufruf. Die README zeigt für die Parser-Konfiguration dieses Muster:
new AutoRAGAgent({ searchPaths: ["/path/to/documents"], parserOptions: { thinExtract: { minPages: 3, minChars: 800, minCharsPerPage: 40, timeoutMs: 30_000, hybrid: "docling-fast", hybridMode: "auto" } } });
Für die Indexierung nennt die README Konfigurationsschlüssel. BM25, Vector und Hybrid sind standardmäßig aktiv, sobald MinSync aktiv ist. Lokale Indexierung lässt sich mit "minSync": false abschalten, nur die lexikalische Suche mit "bm25": false. MinSync installiert beim ersten Gebrauch eine geprüfte Release nach <workspace>/.autorag/bin, gesteuert über autoInstall: true. Wer das Binary selbst verwaltet, setzt "autoInstall": false.
Der Embedder wird über die Flags autorag init --embedder-* konfiguriert, für entfernte Embedding-Endpunkte. Wenn ein lokales Embedder-Modell ein kleineres Kontextfenster hat, setzt man minSync.maxChunkSize oder den Schalter --minsync-max-chunk-size. Laut README erzwingt AutoRAG weder TEI noch einen externen Embedding-Dienst. Als lokaler Embedder wird EmbeddingGemma über Ollama genannt, zusammen mit einem MinSync-Auto-Install für die Einrichtung ohne API-Schlüssel.
Dünne PDFs: ein Retry mit harten Schwellenwerten
Der PDF-Pfad enthält eine explizite Qualitätsprüfung. Der Standardparser prüft bei mehrseitigen PDFs, ob das lokale Markdown ungewöhnlich dünn ist: weniger als 800 Zeichen oder weniger als 40 Zeichen pro erkannter Seite, und das über mindestens drei Seiten. Trifft das zu, wird ein zweiter Versuch über den docling-fast-Hybrid-Backend von OpenDataLoader mit hybridMode: "auto" und 30 Sekunden Timeout unternommen.
Die Ausschlüsse sind so wichtig wie die Regel. Dichte PDFs werden nicht erneut verarbeitet. Hybrid wird nie für einseitige PDFs verwendet und nie als erster Pfad für Bilder. Das Gate gehört dem Parser und ist über vertrauenswürdige programmatische parserOptions justierbar, mit den Schlüsseln minPages, minChars, minCharsPerPage, timeoutMs, hybrid und hybridMode.
Das ist eine pragmatische Konstruktion. Sie kostet bei dünnen Dokumenten einen zweiten Parsing-Durchlauf und verlagert die Entscheidung in den Parser statt in eine Nutzerkonfiguration. Ob die Schwellenwerte für ein konkretes Korpus passen, lässt sich nur empirisch klären. Die README liefert dazu keine Auswertung.
Ein Repository, zwei Produkte: die Legacy-Spaltung
Der wichtigste praktische Punkt steht ganz oben in der README. Dieses Repository beherbergt AutoRAG 2.0, eine vollständige Neufassung als selbstentwickelnder Bibliothekar-Agent. Das ursprüngliche Python-AutoRAG, das RAG-AutoML-Werkzeug zur automatischen Suche nach einer optimalen RAG-Pipeline, liegt jetzt im Verzeichnis legacy/.
Der Vorgänger ist laut README nicht aufgegeben. Er wird im Wartungsmodus weiter gepflegt: Bugfixes, Abhängigkeitsaktualisierungen und PyPI-Releases über pip install AutoRAG. Bestehende Nutzer können ihn unverändert weiterverwenden, die Dokumentation steht in legacy/README.md, und Issues laufen weiterhin über dieses Repository. Neue Funktionsentwicklung findet nur in AutoRAG 2.0 statt.
Für Adoption heißt das: Die Entscheidung ist keine Versionsfrage, sondern eine Produktentscheidung. Wer eine optimierbare Pipeline sucht, bleibt beim Legacy-Werkzeug und akzeptiert, dass dort keine neuen Funktionen mehr kommen. Wer einen Agenten sucht, wechselt die Sprache von Python auf TypeScript. Ein Migrationspfad zwischen beiden wird in der README nicht beschrieben.
Grenzen, Lizenz und die Frage vor dem ersten Einsatz
Die Hauptsprache des Repositorys ist TypeScript. Wer den Legacy-Pfad nutzt, arbeitet in Python, wer AutoRAG 2.0 nutzt, in TypeScript. Zwei Laufzeitumgebungen in einem Repository bedeuten zwei Abhängigkeitsbäume und zwei Releasezyklen. Die letzten Releases v2.4.0 und v2.4.1 liegen nur einen Tag auseinander, was auf eine aktive, schnelle Releasefolge hindeutet. Für Produktivsysteme ist das ein Grund, Versionen zu pinnen.
MinSync ist eine zusätzliche Betriebsabhängigkeit. Das Binary wird beim ersten Gebrauch automatisch installiert, sofern autoInstall nicht abgeschaltet ist. In Umgebungen ohne Netzzugang oder mit strikter Artefaktkontrolle muss dieser Schritt vorab erfolgen. Die README verweist für automatische Installation, verwaltete Binary-Pfade und den lokalen EmbeddingGemma-QA-Ablauf auf docs/minsync-setup.md.
Zur Lizenz lässt sich aus dem vorliegenden Material nichts Belastbares sagen. Die Metadaten melden NOASSERTION, die README nennt keine Lizenz. Das ist vor jedem produktiven Einsatz zu klären, weil davon abhängt, ob und wie das Projekt weitergegeben werden darf. Eine rechtliche Einschätzung kann dieser Text nicht liefern.
Als Alternative bietet sich ein klassischer Vektorstore mit eigenem Ingestion-Pfad an, etwa ein Aufbau, bei dem alle Dokumente in einen zentralen Index kopiert und dort versioniert werden. Der Unterschied im Ansatz ist grundsätzlich: Dort kontrolliert man den Index vollständig und kann ihn neu aufbauen, hier bleibt die Quelle maßgeblich und der Index ist abgeleitet. Der zentrale Ansatz kostet Kopien und Synchronisationsaufwand, der föderierte Ansatz kostet Abhängigkeit von fremden Indexqualitäten. Wer Kopien aus Compliance-Gründen ausschließt, hat die Entscheidung bereits getroffen.
Redaktionelles Fazit
Wer bereits katok, discrawl, qmd, msgvault oder rclone betreibt und die Daten nicht in einen zentralen Index kopieren will, findet hier einen Agenten, der die Indizes in place nutzt. Wer eine reproduzierbare RAG-AutoML-Pipeline mit Python-API braucht, bleibt beim Verzeichnis legacy/ und bei pip install AutoRAG. Vor dem Einsatz zu prüfen: ob das Projekt tatsächlich unter der deklarierten Lizenz nutzbar ist, denn die Metadaten melden NOASSERTION und die README nennt keine Lizenz.
Community-Notizen