Ob sich RAGFlow lohnt, hängt davon ab, ob Ihre Dokumente wirklich „schwer verdaulich" sind. Es ist die RAG-Engine, die InfiniFlow auf GitHub als Open Source veröffentlicht hat, mit Schwerpunkt auf tiefem Dokumenten-Parsing: gescannte PDFs, Dokumente mit Tabellen und Layouts sowie gemischtes Text- und Bildmaterial können zunächst in strukturierte Stücke zerlegt und indexiert werden, mit Zitaten an den Antworten. Wenn Ihre Wissensdatenbank nur aus wenigen sauberen Klartext-Webseiten besteht, bleibt diese Parsing-Leistung ungenutzt, und der Aufwand lohnt sich deutlich weniger.
Die offiziellen Repository-Angaben stehen hier im Text: Die Plattform ist GitHub, die Organisation ist InfiniFlow, das Projekt ist RAGFlow und die Lizenz ist Apache 2.0. Das System besteht aus mehreren Containern: RAGFlow selbst übernimmt Oberfläche, API und Aufgabenausführung; Elasticsearch oder Infinity dient als Dokumenten-Engine; MySQL speichert Metadaten; Redis reiht Parsing-Aufgaben ein; und Objektspeicher hält hochgeladene Dateien. Modelle müssen selbst angebunden werden; in der Open-Source-Version 1.0 läuft der zum Parsen verwendete DeepDoc per CPU-Inferenz und übernimmt Layoutanalyse, OCR und Tabellenerkennung.
Bereitstellungskosten: von der empfohlenen Konfiguration ausgehen
Die offiziell empfohlene Startkonfiguration ist 4 CPU-Kerne, 16 GB Arbeitsspeicher und 50 GB Platte, mit Docker 24.0.0 oder neuer und Docker Compose v2.26.1 oder neuer. Die Bereitstellung läuft so: Repository klonen, in das docker-Verzeichnis wechseln und die vorgefertigten Images mit Docker Compose starten; bei Verwendung von Elasticsearch muss vm.max_map_count auf dem Host auf mindestens 262144 gesetzt werden. Vorgefertigte Images gibt es derzeit nur für x86, Maschinen mit ARM64 sollten die offiziellen Hinweise prüfen. Die tatsächlichen Kosten folgen Dokumentenvolumen, Parsing-Aufgaben und Gleichzeitigkeit; bei der Massenverarbeitung gescannter Dokumente ist die CPU der Engpass, also testen Sie zuerst mit einigen Dutzend echten Dokumenten den vollständigen Ablauf und legen Sie dann die Produktionskonfiguration fest.
Es gibt vier echte Fallstricke. Erstens hängt die Parsing-Qualität von den Dokumenten selbst ab: verschwommene Scans, seitenübergreifende Tabellen und ungewöhnliche Layouts müssen zuerst stichprobenartig geprüft werden, denn wenn das Parsing falsch ist, rettet nachträgliches Chunking-Tuning nichts mehr. Zweitens müssen Modelle selbst konfiguriert werden: Wird das Chat-Modell, das Embedding-Modell oder das Reranking-Modell falsch gewählt, gehen Antwortqualität und Kosten gemeinsam in die falsche Richtung, also legen Sie vor der Bereitstellung Quelle und Abrechnung der drei Modelle fest. Drittens ist der Betrieb eines Multi-Container-Stacks ein laufender Kostenfaktor: Upgrades, Backups und Plattenbereinigung brauchen eine verantwortliche Person, und wer „einmal installieren und vergessen" will, steht Monate später leicht vor einer ungepflegten alten Version. Viertens bedeutet ein Zitat an einer Antwort nicht, dass das Zitat zwangsläufig stimmt; bei Verträgen oder Compliance-Material muss der Originaltext stichprobenartig geprüft werden, und die Berechtigungstrennung muss der tatsächlichen Organisationsstruktur entsprechen.
Es eignet sich für Personen, die große Mengen an PDFs, Scans und tabellarischen Dokumenten haben, nachvollziehbare Antworten brauchen und bereit sind, einen Docker-Stack selbst zu pflegen, ob Team oder einzelne Entwickler. Es eignet sich nicht für Personen, deren Dokumente wenige, sauber formatiert sind und die nur schnell eine Q&A-Demo bauen wollen – die sind mit einer leichteren Lösung oder einem gehosteten Dienst schneller; ebensowenig für Personen ohne Betriebszeit, die etwas wollen, das sofort funktioniert, denn Parsing-Leistung kann eine betriebliche Lücke nicht ausgleichen. Testen Sie das Parsing zuerst mit dem offiziellen Cloud-Dienst und entscheiden Sie sich erst für Self-Hosting, wenn die Ergebnisse bestätigt gut sind.
