RAG Anything Verwandelte Meine Gescannten PDFs in Durchsuchbares Wissen

RAG Anything Verwandelte Meine Gescannten PDFs in Durchsuchbares Wissen

Ich hatte drei Wochen lang einen 47-seitigen Finanzbericht auf meinem Desktop liegen. Gescanntes PDF. Balkendiagramme auf jeder zweiten Seite. Umsatztabellen als Bilder gerendert, nicht als echte Daten. Die Art von Dokument, bei der jedes RAG-System, das ich je gebaut habe, die Schultern zuckt und sagt: "Hier ist etwas wirres Kauderwelsch, das ich zwischen den Überschriften gefunden habe."

Ich hatte LightRAG seit Monaten im Einsatz -- Textaufnahme, Wissensgraph-Konstruktion, hybrides Abrufen. Es verarbeitete meine Markdown-Dateien und Klartextdokumente wunderbar. Aber jedes Mal, wenn ich versuchte, etwas mit Diagrammen, Grafiken oder gescannten Seiten einzuspeisen, war die Ausgabe irgendwo zwischen nutzlos und komisch falsch. Einmal fragte ich nach den Umsatztrends im Q3 und erhielt einen Absatz über die Formatierung des Inhaltsverzeichnisses zurück. Der Wissensgraph hatte den OCR-Müll aus den Seitenköpfen getreu indiziert und die eigentlichen Daten im Balkendiagramm darunter ignoriert.

Dieser Finanzbericht war der Wendepunkt. Ich brauchte ein RAG-System, das Dokumente so versteht, wie ich sie verstehe -- nicht nur die Wörter auf der Seite, sondern auch die Diagramme, die Bilder, die visuellen Daten, die die Hälfte der Bedeutung in jedem ernsthaften Geschäftsdokument tragen. Und dann fand ich RAG Anything.

Entwickelt vom gleichen HKUDS-Team hinter LightRAG, ist RAG Anything ein Wrapper, der multimodale Dokumentenverarbeitung auf dein bestehendes LightRAG-Setup aufpfropft. Es ersetzt LightRAG nicht. Es erweitert es. Und die Art, wie es die Aufteilung zwischen Text- und Bildinhalten handhabt, ist wirklich clever -- clever genug, dass ich meine gesamte Dokumentenaufnahmepipeline in einem einzigen Wochenende darum herum neu aufgebaut habe.

Hier ist die vollständige Aufschlüsselung, wie es funktioniert, wie ich es eingerichtet habe und was passierte, als ich diesen Finanzbericht endlich durchlaufen ließ.

Warum Standard-RAG an Dokumenten aus der Echten Welt Scheitert

Das schmutzige Geheimnis der meisten RAG-Tutorials ist, dass sie mit makellosen Markdown-Dateien und sauberen PDF-Texten demonstrieren. Die Art von Dokumenten, bei denen jedes Zeichen bereits maschinenlesbar, ordentlich strukturiert und bereit zum Chunking ist. Das sind vielleicht 30% der Dokumente, mit denen ich tatsächlich arbeite.

Die anderen 70%? Gescannte Verträge. Präsentationen als PDF exportiert. Forschungsarbeiten mit LaTeX-Gleichungen. Finanzberichte, bei denen die wichtigsten Daten in Balken- und Kreisdiagrammen stecken. Interne Memos, die jemand ausgedruckt, von Hand unterschrieben und dann wieder eingescannt hat. Behördenformulare. Rechnungen mit Logos und Tabellen, die als Bilder gerendert sind.

Standard-RAG-Pipelines -- einschließlich Vanilla-LightRAG -- gehen mit diesen Dokumenten vor, was ich den "Augen-zusammenkneifen-und-hoffen"-Ansatz nenne. Sie führen eine grundlegende Textextraktion durch, erhalten partiellen Müll aus der OCR-Schicht, chunken welchen Text sie finden, betten ihn ein und nennen es fertig. Die Diagramme? Unsichtbar. Die Bilder? Ignoriert. Die handschriftlichen Notizen? Ein Salat aus falsch erkannten Zeichen.

Ich versuchte Workarounds. Ich ließ Dokumente durch separate OCR-Tools laufen, bevor ich sie LightRAG fütterte. Ich verwendete GPT-4o, um Bilder zu beschreiben, und injizierte diese Beschreibungen dann als Text. Ich baute sogar eine Vorverarbeitungspipeline, die Bilder aus PDFs extrahierte, jedes an ein Vision-Modell schickte, Textbeschreibungen zurückbekam und diese Beschreibungen in den ursprünglichen Textstrom vor dem Chunking einfügte.

Es funktionierte. Kaum. Der Wartungsaufwand war brutal, die Verarbeitungskosten waren hoch, weil jedes einzelne Bild durch eine Cloud-Vision-API ging, und der Wissensgraph endete mit seltsamen Verbindungsunterbrechungen zwischen den "echten" Textentitäten und den "beschriebenen" Bildentitäten. Sie existierten in parallelen Universen innerhalb derselben Datenbank.

RAG Anything löst das auf eine grundlegend andere Art und Weise. Anstatt Bilder als Nachgedanken zu behandeln, die in Text umgewandelt werden müssen, verarbeitet es sie als erstklassigen Datentyp mit eigenem Einbettungsraum und eigenem Zweig des Wissensgraphen -- und führt dann alles in einer einheitlichen Abrufschicht zusammen. Der Unterschied ist wichtiger, als er klingen mag.

Aber bevor ich die Architektur erkläre, musst du den Dokumentenparser verstehen, der das Ganze möglich macht.

MinerU: Der Dokumentenparser, der die Schwere Arbeit Erledigt

Im Herzen von RAG Anything sitzt MinerU, ein Open-Source-Dokumentenparser vom OpenDataLab-Team. Wenn du ihm noch nicht begegnet bist: MinerU ist das, was entsteht, wenn du ein PDF-Extraktionstool baust, das die Komplexität echter Dokumente wirklich respektiert.

Die meisten PDF-Parser behandeln eine Seite als flachen Textstrom. MinerU behandelt sie als Layout -- mit Überschriften, Absätzen, Tabellen, Bildern, Gleichungen, Fußnoten und Seitenleisten, jeweils identifiziert und an ein spezialisiertes Extraktionsmodell weitergeleitet. Stell dir das als Triagesystem vor. Das Dokument trifft auf MinerU, und MinerU sagt: "Dieser Block ist eine Überschrift. Dieser Block ist Fließtext. Das ist eine Tabelle. Das ist ein Diagrammbild. Das ist eine LaTeX-Gleichung." Jede Komponente wird von dem Modell verarbeitet, das am besten dafür geeignet ist.

Für Text verwendet MinerU PaddleOCR -- Baidus Open-Source-OCR-Engine, die ab PP-OCRv5 mehr als 100 Sprachen unterstützt. PaddleOCR ist nicht nur Zeichenerkennung. Es verarbeitet komplexe Layouts, mehrspaltigen Text, rotierten Text und in Bilder eingebetteten Text. Wenn MinerU einen Textblock in einem gescannten PDF identifiziert, extrahiert PaddleOCR die tatsächlichen Zeichen mit überraschend hoher Genauigkeit.

Für Nicht-Text-Elemente -- Diagramme, Grafiken, Fotos, Schaubilder -- geht MinerU einen anderen Weg. Es erfasst sie als Screenshots. Saubere, zugeschnittene Screenshots, die die visuellen Informationen genau so bewahren, wie sie auf der Seite erscheinen.

Diese Trennung ist die Schlüsselerkenntnis, die RAG Anything zum Funktionieren bringt. Anstatt zu versuchen, alles in Text zu zwingen (was Informationen verliert) oder alles als Bilder zu verarbeiten (was teuer und langsam ist), teilt MinerU das Dokument in zwei saubere Buckets auf:

• Text-Bucket: Alles, was tatsächlich Text ist, per OCR mit hoher Treue extrahiert
• Bild-Bucket: Alles, was visuell ist, als Screenshots mit vollem Kontext erfasst

Beide Buckets speisen die nächste Phase der Pipeline. Und hier wird die Architektur von RAG Anything interessant -- denn jeder Bucket bekommt seinen eigenen parallelen Verarbeitungstrack.

MinerU läuft vollständig lokal. Keine API-Aufrufe für die Parsing-Phase. Keine Daten, die dein Gerät verlassen. Der Kompromiss ist, dass es schwerer ist als eine einfache PDF-Bibliothek -- du lädst echte ML-Modelle für die Layout-Erkennung, OCR und Komponenten-Klassifizierung herunter. Auf meinem M2 MacBook Pro war der initiale Modell-Download etwa 2 GB. Danach dauert das Parsen eines 50-seitigen gescannten PDFs auf der CPU etwa 45 Sekunden. Der Wechsel zur GPU (den ich im Setup-Abschnitt behandle) reduziert das auf etwa 12 Sekunden.

Die lokale Verarbeitung ist es wert zu betonen. Jede Seite deines Dokuments bleibt beim Parsen auf deiner Hardware. Der einzige Zeitpunkt, an dem Daten dein Gerät verlassen, ist in der nächsten Phase, wenn extrahierter Text und Bilder zur Entitätsextraktion und Einbettungsgenerierung an ein LLM gesendet werden.

Die Dual-Pipeline-Architektur: Wie RAG Anything Tatsächlich Funktioniert

Hier wird das Engineering wirklich clever. Sobald MinerU dein Dokument in Text- und Bild-Buckets aufgeteilt hat, führt RAG Anything zwei parallele Verarbeitungspipelines aus -- eine für jeden Bucket. Beide Pipelines tun die gleichen zwei Dinge, aber auf unterschiedliche Weise.

Pipeline 1: Textverarbeitung

Der Text-Bucket geht an ein LLM (standardmäßig GPT-4o mini, obwohl du jedes Modell eintauschen kannst). Das LLM führt zwei Operationen durch:

1. Entitäts- und Beziehungsextraktion -- Es liest den Text und identifiziert Entitäten (Personen, Unternehmen, Konzepte, Daten, Finanzzahlen) und die Beziehungen zwischen ihnen. Diese werden zu Knoten und Kanten in einem Wissensgraphen.
2. Einbettungsgenerierung -- Die Textchunks werden in Vektoreinbettungen umgewandelt (standardmäßig mit text-embedding-3-large) und in einer Vektordatenbank gespeichert.

Das ist im Wesentlichen das, was Vanilla-LightRAG bereits tut. Nichts Neues hier.

Pipeline 2: Bildverarbeitung

Der Bild-Bucket geht an dasselbe LLM, aber die Interaktion ist anders. Jeder Screenshot -- jedes Diagramm, jede Grafik, jede Abbildung und jedes visuelle Element, das MinerU extrahiert hat -- wird an die Vision-Fähigkeiten des LLM gesendet. Das LLM analysiert das Bild und führt die gleichen zwei Operationen durch:

1. Entitäts- und Beziehungsextraktion aus visuellen Inhalten -- Das Modell betrachtet ein Balkendiagramm und extrahiert Entitäten wie "Q1 Umsatz: 2,4 Mio. $" und "Q3 Umsatz: 3,1 Mio. $" und die Beziehung "Umsatz stieg von Q1 zu Q3 um 29%." Diese werden zu Knoten und Kanten in einem bildspezifischen Wissensgraphen.
2. Einbettungsgenerierung aus visuellen Beschreibungen -- Das Modell generiert reichhaltige Textbeschreibungen jedes Bildes, und diese Beschreibungen werden in Einbettungen umgewandelt und in einer bildspezifischen Vektordatenbank gespeichert.

Jetzt hast du vier Datenstrukturen:

Die Zusammenführung

RAG Anything führt diese vier Strukturen dann zu zwei zusammen: eine einheitliche Vektordatenbank und einen einheitlichen Wissensgraphen. Die Text- und Bildentitäten koexistieren im gleichen Graphen. Die Text- und Bildeinbettungen leben im gleichen Vektorraum. Wenn du das System abfragst, erfolgt der Abruf über beide Modalitäten gleichzeitig.

Das ist der Teil, der mein "paralleles Universum"-Problem gelöst hat. Als ich Bild-zu-Text-Konvertierung als Vorverarbeitungsschritt durchführte, waren die bildabgeleiteten Entitäten und die textabgeleiteten Entitäten getrennt. RAG Anyth­ings Zusammenführungsschritt stellt sicher, dass sie verknüpft sind. Wenn der Text "Q3-Umsatz" erwähnt und ein Balkendiagramm Q3-Umsatzdaten zeigt, existieren beide Entitäten im gleichen Wissensgraphen mit überlappenden Beziehungen. Die Abrufschicht kann aus beiden Quellen schöpfen, um eine vollständige Antwort zu konstruieren.

Und hier ist der Teil, den ich nicht erwartet hatte: Die zusammengeführte RAG Anything-Datenbank kombiniert sich dann mit deiner bestehenden LightRAG-Datenbank. Wenn du bereits LightRAG mit Textdokumenten betrieben hast, überschreibt RAG Anything das nicht. Es fügt hinzu. Du landest bei einer konsolidierten Vektordatenbank und einem konsolidierten Wissensgraphen, der alles überspannt -- deine ursprünglichen Textdokumente UND deine neu aufgenommenen multimodalen Dokumente.

Das Abfrageerlebnis ändert sich überhaupt nicht. Gleiche API. Gleiche Prompts in natürlicher Sprache. Gleiche Abrufmodi. Das System handhabt die Komplexität des Mehrquellen- und Mehrmodalitätsabrufs hinter den Kulissen.

Diese Nahtlosigkeit hat mich überzeugt, es zu adopieren. Ich musste nichts neu aufbauen. Ich musste meine Abfragemuster nicht ändern. Ich erhielt einfach die Fähigkeit, eine ganz neue Kategorie von Dokumenten aufzunehmen.

Wie Ich Alles Eingerichtet Habe (Schritt für Schritt)

Ich werde das nicht schönreden: Das initiale Setup ist schwerer als Vanilla-LightRAG. Du fügst einen Dokumentenparser mit ML-Modellen, eine OCR-Engine und zusätzliche Python-Abhängigkeiten hinzu. Aber einmal konfiguriert, ist die tägliche Erfahrung reibungslos.

Hier ist das genaue Setup, das ich befolgt habe.

Schritt 1: Sicherstellen, dass LightRAG bereits läuft.

Wenn du LightRAG noch nicht eingerichtet hast, fang dort an. RAG Anything umschließt LightRAG -- es braucht eine funktionierende Installation zum Erweitern. Das LightRAG GitHub-Repository hat klare Anweisungen. Ich betrieb LightRAG mit der Docker-basierten Benutzeroberfläche, die eine Weboberfläche zum Hochladen von Textdokumenten und Abfragen des Wissensgraphen bietet.

Schritt 2: RAG Anything und seine Abhängigkeiten installieren.

RAG Anything ist über pip installierbar:

pip install raganything

Damit wird das Kernframework heruntergeladen. Aber du brauchst auch MinerU für das Dokumenten-Parsing:

pip install mineru

Beim ersten Ausführen lädt MinerU seine Layout-Erkennungs- und Klassifizierungsmodelle herunter. Erwarte etwa 2 GB Downloads. PaddleOCR wird als MinerU-Abhängigkeit mitgeliefert, du musst es nicht separat installieren.

Schritt 3: Den Claude Code One-Shot-Setup-Prompt verwenden.

Das war der Teil, der mir Stunden gespart hat. Das RAG Anything-Repo enthält einen Claude Code-Prompt, der die Konfiguration automatisiert:

• Aktualisiert Speicherpfade, um deinem bestehenden LightRAG-Datenverzeichnis zu entsprechen
• Konfiguriert die KI-Modelle (GPT-4o mini für die Entitätsextraktion, text-embedding-3-large für Einbettungen standardmäßig)
• Behebt einen bekannten Fehler, bei dem Einbettungen während des Zusammenführungsschritts doppelt verpackt werden

Ich führte den Prompt in Claude Code aus, der auf mein LightRAG-Projektverzeichnis gerichtet war, und es erledigte die Konfiguration in etwa 90 Sekunden. Ohne das hätte ich manuell Konfigurationsdateien bearbeiten und wahrscheinlich eine Stunde lang gegen den Double-Wrap-Bug kämpfen müssen, bevor ich das GitHub-Issue dazu gefunden hätte.

Schritt 4: API-Schlüssel konfigurieren.

RAG Anything benötigt Zugang zu einem LLM mit Vision-Fähigkeiten für die Bildverarbeitung. Ich verwendete GPT-4o mini, weil die Kosten gering sind und die Vision-Qualität für Diagramm- und Grafikinterpretation solide ist. Du benötigst deinen OpenAI-API-Schlüssel in der Umgebung oder Konfigurationsdatei.

Für Einbettungen ist der Standard text-embedding-3-large. Derselbe API-Schlüssel deckt das ab.

Schritt 5: Mit einem einfachen Dokument testen.

Bevor ich komplexe gescannte PDFs damit fütterte, testete ich mit einem einseitigen Dokument mit einem Textabsatz und einem Balkendiagramm. Das validiert, dass MinerU korrekt parsed, PaddleOCR Text extrahiert, das Vision-Modell das Diagramm interpretiert und der Zusammenführungsschritt eine einheitliche Datenbank produziert.

from raganything import RAGAnything

rag = RAGAnything(
    working_dir="./rag_storage",
    llm_model="gpt-4o-mini",
    embedding_model="text-embedding-3-large"
)

# Ein multimodales Dokument aufnehmen
rag.insert("./test_document.pdf")

# Über Text- und Bildinhalte abfragen
result = rag.query("Was zeigt das Balkendiagramm über den Umsatz?")
print(result)

Als das tatsächliche Zahlendaten aus dem Diagramm zurückgab -- keine Beschreibung des Diagramms, sondern die spezifischen Werte, die es enthielt -- wusste ich, dass die Pipeline funktionierte.

Schritt 6: Deine echten Dokumente aufnehmen.

Hier ist ein wichtiges operatives Detail: Die Aufnahme von Nicht-Text-Dokumenten kann nicht über die LightRAG-Web-UI erfolgen. Die UI weiß nichts von MinerU oder der Dual-Pipeline-Architektur. Du musst die Aufnahme über das Python-Skript ausführen (oder eine Claude Code-Skill, die es umschließt).

Textdokumente können weiterhin wie gewohnt über die LightRAG-UI aufgenommen werden. Nur multimodale Dokumente benötigen den skriptbasierten Ansatz.

Nach der Aufnahme stellte ich fest, dass ein Neustart des Docker-Containers, auf dem die LightRAG-UI läuft, manchmal notwendig war, damit die neu zusammengeführte Datenbank erkannt wurde. Nicht jedes Mal, aber häufig genug, dass ich einen Container-Neustart zu meinem Aufnahmeskript hinzugefügt habe.

Wenn du lieber jemanden diese Art von Pipeline von Grund auf für deinen spezifischen Dokumenten-Workflow aufbauen lassen möchtest, nehme ich KI-Integrationsprojekte an. Du kannst sehen, was ich gebaut habe, unter fiverr.com/s/EgxYmWD.

Pro-Tipp: MinerU auf GPU-Verarbeitung umstellen. Auf der CPU ist MinerU funktional, aber langsam für große Dokumente. Wenn du eine NVIDIA-GPU hast (oder einen Mac der M-Serie mit Metal-Unterstützung), macht die Konfiguration von MinerU zur Nutzung von GPU-Beschleunigung einen dramatischen Unterschied. Mein 50-seitiges gescanntes PDF ging von 45 Sekunden auf 12 Sekunden. Claude Code kann dir helfen, die MinerU-Konfiguration zu ändern, um GPU zu aktivieren -- es ist eine Konfigurationsflag-Änderung, keine Neuinstallation.

Was Ich Tatsächlich Damit Verarbeitet Habe (Und Was Zurückkam)

Der echte Test war dieser Finanzbericht. 47 Seiten. Aus einem gedruckten Dokument eingescannt. Balkendiagramme mit monatlichem Umsatz von Januar bis September 2025. Tabellen als Bilder gerendert. Unternehmenslogos. Fußnoten in kleiner Schrift. Die Art von Dokument, die den schlimmsten Fall für traditionelle RAG darstellt.

Ich ließ es durch das Aufnahmeskript laufen und beobachtete die Logs. MinerU verarbeitete jede Seite, klassifizierte die Komponenten und teilte sie in die zwei Buckets auf. PaddleOCR extrahierte Text aus den Hauptabsätzen und Überschriften. Die Balkendiagramme, Tabellen und Logos gingen in den Bild-Bucket. Das LLM verarbeitete beide Buckets, extrahierte Entitäten und Beziehungen, generierte Einbettungen und führte alles in der einheitlichen Datenbank zusammen.

Gesamtverarbeitungszeit: etwa 3 Minuten für alle 47 Seiten auf der GPU. API-Kosten für die LLM-Aufrufe: rund 0,08 $. Die lokale Verarbeitung (MinerU + PaddleOCR) war kostenlos.

Dann fragte ich es ab.

"Was waren die monatlichen Umsatztrends von Januar bis September 2025?"

Die Antwort kam mit spezifischen Zahlen zurück. Januar: 1,2 Mio. $. Februar: 1,4 Mio. $. März: 1,3 Mio. $. Durchgehend bis September: 2,1 Mio. $. Es identifizierte den allgemeinen Aufwärtstrend, notierte den Einbruch im März und verwies auf die Q3-Beschleunigung. Diese Daten existierten nur in einem Balkendiagramm. Es gab keinen Text im Dokument, der diese Zahlen auflistete. Das Vision-Modell hatte das Diagramm gelesen, die Werte extrahiert, Entitäten für jeden Datenpunkt erstellt und Beziehungen zwischen ihnen im Wissensgraphen aufgebaut.

Ich führte eine zweite Abfrage aus: "Welche Abteilungen zeigten das höchste Wachstum?"

Diese zog aus beiden Modalitäten. Die Textabschnitte des Berichts diskutierten die Abteilungsleistung in Prosa. Die Diagramme zeigten die Zahlen. Die Antwort kombinierte beides -- zitierte spezifische Wachstumsprozentsätze aus den Diagrammen und kontextuelle Analyse aus dem Text. Einheitlicher Abruf, genau wie geplant funktionierend.

Zum Vergleich ließ ich dasselbe Dokument durch meine alte Pipeline laufen -- Vanilla-LightRAG mit grundlegender Textextraktion. Die erste Abfrage gab nichts Nützliches zurück. Die zweite Abfrage gab einen vagen Absatz aus der Zusammenfassung zurück, der "starke Abteilungsleistung" ohne Zahlen erwähnte. Tag und Nacht.

Die Ehrlichen Kompromisse, Die Niemand Erwähnt

RAG Anything ist beeindruckend. Es hat wirklich ein Problem gelöst, mit dem ich seit Monaten zu kämpfen hatte. Aber es ist nicht ohne Reibung, und ich würde dir einen schlechten Dienst erweisen, wenn ich die Nachteile nicht klar darlegen würde.

Das Setup ist schwerer als Vanilla-LightRAG. Du betreibst MinerUs ML-Modelle lokal, was bedeutet, dass du ~2 GB Modellgewichte herunterlädst, zusätzliche Python-Abhängigkeiten verwaltest und gelegentlich Versionskonflikte zwischen PaddleOCR und anderen Paketen behebst. Mein erster Installationsversuch scheiterte wegen einer numpy-Versionsinkompatibilität zwischen MinerU und einer anderen Bibliothek in meiner Umgebung. Eine saubere virtuelle Umgebung löste das, aber das Debuggen kostete mich 30 Minuten.

Nicht-Text-Aufnahme erfordert die Befehlszeile. Du kannst kein gescanntes PDF in die LightRAG-Web-UI ziehen und es durch die multimodale Pipeline verarbeiten lassen. Du musst das Python-Skript ausführen. Für einen Entwickler ist das eine geringfügige Unannehmlichkeit. Für jemanden, der auf einen rein GUI-basierten Workflow gehofft hatte, ist es eine Einschränkung.

Docker-Container-Neustarts nach der Aufnahme sind lästig. Die LightRAG-UI erkennt die zusammengeführte Datenbank nicht immer sofort. Einen Container neu zu starten ist eine 10-Sekunden-Lösung, aber es unterbricht aktive Sitzungen. Ich habe das bei etwa 60% der Zeit nach der multimodalen Aufnahme gesehen.

Vision-Modell-Genauigkeit variiert. GPT-4o mini macht einen soliden Job bei der Interpretation von Standard-Balkendiagrammen, Liniendiagrammen und einfachen Tabellen. Aber es hat Schwierigkeiten mit dicht gepackten Streudiagrammen, komplexen Flussdiagrammen und Diagrammen mit überlappenden Beschriftungen. Ich hatte eine Infografik mit einer farbcodierten Matrix, bei der das Modell zwei der sechs Kategorien falsch identifizierte. Für kritische Finanzdaten empfehle ich, die extrahierten Entitäten stichprobenartig gegen das Quelldokument zu prüfen.

Kosten skalieren mit der Bildanzahl, nicht der Dokumentlänge. Jedes Bild im Bild-Bucket macht einen separaten API-Aufruf an das Vision-Modell. Ein 10-seitiges Dokument mit 2 Diagrammen kostet ungefähr dasselbe wie ein nur-Text 100-seitiges Dokument. Aber ein 10-seitiges Dokument mit 30 eingebetteten Bildern? Das sind 30 Vision-API-Aufrufe. Die Kosten pro Aufruf sind klein (Bruchteile eines Cents mit GPT-4o mini), aber sie summieren sich, wenn du bildintensive Dokumente in großem Maßstab verarbeitest. Überwache deine Nutzung für die ersten paar Batches.

MinerUs Klassifizierung ist nicht perfekt. Etwa 5% der Zeit in meinen Tests hat MinerU einen Textblock als Bild oder umgekehrt falsch klassifiziert. Ein in einer ungewöhnlichen Schriftart gerenderter Absatz wurde als Screenshot erfasst, anstatt per OCR verarbeitet zu werden. Ein dekoratives Header-Bild wurde an die OCR-Pipeline statt an die Vision-Pipeline gesendet. Diese Randfälle brechen das System nicht -- sie bedeuten nur, dass einige Inhalte über den weniger optimalen Pfad verarbeitet werden.

Trotz dieser Kompromisse ist das Nettoresultat überwältigend positiv. Ich ging von einem RAG-System, das vielleicht 30% meiner echten Dokumente verarbeiten konnte, zu einem, das 90%+ bewältigt. Dieser Sprung in der Abdeckung veränderte, welche Arten von Fragen ich stellen konnte und welche Arten von Workflows ich aufbauen konnte.

Wohin Das Führt (Und Was Ich Beobachte)

RAG Anything wurde Anfang 2026 gestartet und ist bereits an einem Punkt, an dem ich es für die meisten Anwendungsfälle als produktionsreif betrachte. Aber es gibt einige Entwicklungen, die ich im Blick behalte.

MinerU-Diffusion, ein Forschungspapier des MinerU-Teams, das 2026 veröffentlicht wurde, schlägt vor, Dokument-OCR als "inverse Renderung" mittels Diffusionsmodellen zu behandeln. Wenn das in das Produktions-MinerU einfließt, könnte der OCR-Qualitätssprung erheblich sein -- insbesondere für beschädigte Scans und handschriftliche Anmerkungen.

Multi-Parser-Unterstützung. RAG Anything unterstützt bereits sowohl MinerU als auch Docling als Dokumentenparser und wählt automatisch den besseren basierend auf dem Dokumenttyp aus. Wenn weitere Parser hinzugefügt werden, wird die Abdeckung von Rand-Dokumentenformaten weiter expandieren.

Lokale LLM-Integration. Momentan erfordern die Entitätsextraktions- und Bildbeschreibungsschritte ein Cloud-LLM mit Vision-Fähigkeiten. Aber die Ollama-Community experimentiert bereits damit, RAG Anything gegen lokale Vision-Modelle wie LLaVA zu betreiben. Wenn lokale Vision-Modelle GPT-4o-mini-Qualität für die Diagramminterpretation erreichen, könnte die gesamte Pipeline ohne Cloud-API-Aufrufe laufen. Null Daten, die dein Gerät verlassen. Null Kosten pro Dokument nach der initialen Einrichtung.

LightRAGs eigene Evolution. LightRAG passierte Anfang 2026 28.000 GitHub-Sterne und wurde auf der EMNLP 2025 akzeptiert. Das Projekt wird aktiv mit inkrementellen Updates gepflegt, die die Graphstruktur nicht stören -- was bedeutet, dass RAG Anyth­ings Zusammenführungsschritt kompatibel bleiben sollte, wenn LightRAG sich weiterentwickelt.

Der breitere Trend ist klar: RAG-Systeme bewegen sich von reinem Text zu wirklich multimodal. Die Frage ist nicht, ob deine RAG-Pipeline in der Lage sein muss, Bilder und Diagramme zu verarbeiten. Es ist, ob du bereit sein wirst, wenn das nächste wichtige Dokument als gescanntes PDF voller visueller Daten auf deinem Schreibtisch landet.

Das Setup, Das Jetzt Für Mich Funktioniert

Nach zwei Wochen täglicher Nutzung ist hier die Konfiguration, auf die ich mich eingependelt habe:

• Dokumentenparser: MinerU mit aktivierter GPU-Beschleunigung
• OCR-Engine: PaddleOCR (mit MinerU gebündelt) -- verarbeitet meine englischen und bengalischen Dokumente ohne Probleme
• LLM für Entitätsextraktion: GPT-4o mini -- schnell, günstig und gut genug für die Diagramminterpretation
• Einbettungsmodell: text-embedding-3-large -- der Qualitätsunterschied gegenüber kleineren Modellen ist bei der Abrufgenauigkeit spürbar
• Speicher: Lokales Dateisystem mit Docker-Volumes für die LightRAG-UI
• Aufnahme-Workflow: Claude Code-Skill, die das Python-Aufnahmeskript umschließt, den Container-Neustart handhabt und Verarbeitungsstatistiken protokolliert
• Abfrage-Interface: LightRAG-Web-UI für Ad-hoc-Abfragen, Python-API für programmatischen Zugriff

Die monatlichen Gesamtkosten für den Betrieb dieses Setups über meine Dokumentenbibliothek betragen etwa 3-5 $ an API-Aufrufen. Der Großteil davon entfällt auf die initiale Aufnahme von bildintensiven Dokumenten. Sobald Dokumente aufgenommen sind, treffen Abfragen zuerst auf den lokalen Wissensgraphen und die Vektordatenbank -- das LLM wird nur für die Antwortgenerierung aufgerufen, nicht für den Abruf.

Zum Vergleich: Mein früherer Ansatz -- jedes Bild durch die Vision-API von GPT-4o als Vorverarbeitungsschritt zu schicken -- kostete mich 15-20 $ pro Monat für eine kleinere Dokumentenbibliothek. RAG Anyth­ings lokal-first-Parsing mit selektiver Cloud-Verarbeitung senkte meine Kosten um etwa 75%.

Was Als Nächstes Kommt, Wenn Du Das Aufbauen Möchtest

Hier ist, was ich täte, wenn ich heute von vorne anfangen würde.

Zuerst, lass Vanilla-LightRAG laufen. Nehme ein paar Textdokumente auf. Führe einige Abfragen durch. Verstehe, wie der Wissensgraph funktioniert, wie Entitäten und Beziehungen extrahiert werden und wie sich der Zweistufenabruf (niedrige Ebene für spezifische Fakten, hohe Ebene für konzeptionelle Themen) verhält. Mein vorheriger Beitrag über das Aufbauen von KI-Forschungssystemen behandelt die Wissensmanagement-Muster, die hier zutreffen.

Zweitens, installiere RAG Anything und MinerU in einer sauberen virtuellen Umgebung. Mische es nicht mit anderen ML-Projekten -- der Abhängigkeitsbaum ist tief genug, dass Versionskonflikte wahrscheinlich sind, wenn du eine Umgebung teilst.

Drittens, teste mit einem einzigen, mäßig komplexen Dokument. Nicht dein schwierigster Fall. Etwas mit einem Mix aus Text und ein paar Diagrammen. Verifiziere, dass die vier Datenstrukturen korrekt generiert und zusammengeführt werden.

Viertens, erweitere schrittweise. Füge mehr Dokumente hinzu. Probiere verschiedene Typen -- gescannte PDFs, Foliensätze, bildintensive Berichte. Notiere, wo die Klassifizierungs- oder Extraktionsqualität nachlässt und ob das für deine Abfragen relevant ist.

Fünftens, richte die Aufnahmeautomatisierung ein. Ob es eine Claude Code-Skill, ein Cron-Job oder ein manuelles Skript ist, das du wöchentlich ausführst -- habe einen zuverlässigen Prozess, um neue Dokumente in die Pipeline zu bringen.

Die Lücke zwischen "Ich habe Dokumente" und "Ich kann meine Dokumente intelligent abfragen" war früher für alles außer sauberem Text riesig. RAG Anything verkleinert diese Lücke auf etwas Handhabbares. Nicht null -- das Setup ist echte Arbeit. Aber handhabbar.

Dieser Finanzbericht, der drei Wochen auf meinem Desktop lag? Ich frage ihn jetzt täglich ab. Letzten Dienstag fragte ein Kunde nach saisonalen Umsatzmustern und ich hatte die Antwort -- mit spezifischen monatlichen Zahlen, die aus gescannten Balkendiagrammen entnommen wurden -- in unter zehn Sekunden. Nicht weil ich die Daten auswendig kannte. Weil ich ein System aufgebaut hatte, das die Dokumente, die ich ihm gebe, wirklich versteht, visuelle Daten und alles.

Das gescannte PDF hörte auf, eine tote Datei zu sein, in dem Moment, als ich aufhörte, Bilder als Bürger zweiter Klasse in meiner RAG-Pipeline zu behandeln.

Häufig Gestellte Fragen

Kann RAG Anything Dokumente ohne Cloud-API-Aufrufe verarbeiten?

Die Dokumentenparse-Phase (MinerU + PaddleOCR) läuft vollständig lokal ohne Cloud-Aufrufe. Entitätsextraktion und Einbettungsgenerierung erfordern derzeit ein Cloud-LLM mit Vision-Fähigkeiten, obwohl lokale Alternativen mit Ollama und LLaVA von der Community aktiv entwickelt werden.

Welche Dokumentenformate unterstützt RAG Anything?

RAG Anything verarbeitet PDFs (sowohl native als auch gescannte), DOCX, PPTX, XLSX und gängige Bildformate. MinerU identifiziert Layout-Komponenten in all diesen, routet Text automatisch zur OCR und visuelle Elemente zur Screenshot-Erfassung.

Wie viel kostet es, RAG Anything pro Dokument zu betreiben?

Nur-Text-Dokumente kosten Bruchteile eines Cents. Bei bildintensiven Dokumenten macht jedes visuelle Element einen LLM-Vision-API-Aufruf -- ungefähr 0,001-0,003 $ pro Bild mit GPT-4o mini. Ein 50-seitiges gescanntes PDF mit 20 Diagrammen kostet insgesamt etwa 0,04-0,08 $. Die vollständige Kostenaufschlüsselung findest du im Setup-Abschnitt oben.

Ersetzt RAG Anything LightRAG?

Nein. RAG Anything ist ein Wrapper, der LightRAG um multimodale Fähigkeiten erweitert. Deine bestehende LightRAG-Datenbank, der Wissensgraph und die Abfrageschnittstelle bleiben unverändert. RAG Anything fügt hinzu, indem es multimodale Daten in die gleichen einheitlichen Strukturen zusammenführt.

Wie genau ist die Diagramm- und Grafikdatenextraktion?

Für Standard-Balkendiagramme, Liniendiagramme und einfache Tabellen ist die Genauigkeit hoch -- GPT-4o mini identifiziert in der großen Mehrheit der Fälle korrekt Werte und Trends. Die Genauigkeit sinkt bei dicht gepackten Streudiagrammen, überlappenden Beschriftungen und komplexen Mehrach-Diagrammen. Überprüfe kritische Finanzdaten stichprobenartig gegen Quelldokumente.

Lass Uns Zusammenarbeiten

Möchtest du KI-Systeme aufbauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (individuelle Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Unternehmenslösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io