ROE gegen TechRAG: GraphRAG auf Docker und Qdrant oder auf SQLite und LanceDB

Es ist ein nützlicher Test, ob ein Design tatsächlich von den verwendeten Werkzeugen abhängt, wenn man sieht, wie dieselbe Architektur unabhängig von jemand anderem mit unterschiedlichen Werkzeugen neu implementiert wird. Das gilt für den RAGraph Ontological Engine (ROE), ein lokales GraphRAG-Design, sowie für TechRAG, ein open-source-Projekt unter MIT-Lizenz, das die zugrundeliegende These übernimmt, aber nahezu alle Infrastrukturentscheidungen ändert. Der Vergleich der beiden zeigt, welche Ideen übernommen wurden und welche neu interpretiert wurden.

Die gemeinsame These

Ein herkömmliches RAG-System zieht Fragmente heran, die der Frage ähneln, und überlässt den schwierigsten Teil dem Modell: die eigenständige Wiederherstellung von Beziehungen, Ursachen, Abhängigkeiten und Einschränkungen zwischen Konzepten. ROE antwortet mit einem dreischichtigen Hybridmodell:

1. Vektorabfrage über Qdrant, wobei bge-m3-Embeddings lokal von Ollama erzeugt werden
2. Ein Konzeptwörterbuch (die Domänenontologie), das anhand eines aus dem Dokument entnommenen Beispiels erstellt wird
3. Ein Wissensgraph mit Knoten, Kanten und atomaren Fakten, die auf ihre ursprünglichen Quellen verweisen

Das Ziel ist bescheiden. Es ist nicht notwendig, einen vollständigen Handbuchtext in die Anweisung aufzunehmen. Stattdessen erhält das Modell einen kleinen Arbeitsumfang: einige Textabschnitte, einige atomare Fakten sowie wenige Graphpfade. Dadurch entsteht weniger Überfluss, der Kontext bleibt präziser und die Antworten können vom Leser überprüft werden. Die ursprüngliche ROE lief unter Docker (Qdrant plus MongoDB) und bot eine Web-Oberfläche mit ontologischem Chat und Graphvisualisierung sowie ein Prüfsystem, das Abdeckungsmetriken und Schlussfolgerungswerte auswertete.

TechRAG beibehält dieses Konzept und trifft Entscheidungen, die diesen nahekommen.

Speicherung: von zwei Diensten zu einer Datei

ROE speichert Vektoren in Qdrant und alles andere (Dokumente, Ontologie, Audits) in MongoDB. Das bedeutet zwei externe Dienste, Docker sowie offene Ports. TechRAG benötigt keine externe Infrastruktur. LanceDB, eine eingebettete serverlose Vektordatenbank, schreibt direkt in das Dateisystem, während SQLite über SQLAlchemy den Rest speichert: Dokumente, Blöcke, Entitäten, atomare Fakten, semantische Pfade sowie die serialisierte Ontologie – alles in einer einzigen roe.db-Datei.

Die erste Struktur sieht so aus:

# ROE (original)
Qdrant (vectors) + MongoDB (docs/ontology/audit)
→ Docker, ports 6333 and 27017

Und so sieht TechRAG aus:

# TechRAG
LanceDB (vectors) + SQLite (everything else)
→ Zero external services, one .db file

Die Einrichtung unterscheidet sich völlig. ROE benötigt Docker mit beiden laufenden Containern, während TechRAG mit uv run roe ingest document.pdf startet und direkt funktioniert. Ein Design eignet sich für ein kontrolliertes Umfeld, das andere funktioniert fast überall – sogar auf einem Entwickler-Laptop.

Das Graph als relationale Tabellen

ROE plante Neo4j für sein Graph, wobei MongoDB als leichtere Alternative zum Speichern von Dokumenten diente. TechRAG verwendet etwas anderes: SQLGraph. Knoten und Kanten werden zu relationellen Tabellen in SQLAlchemy, wobei keine Graph-Datenbank verwendet wird. Die entities-Tabelle speichert Knoten mit Name, ontologischem Typ und Beschreibung. Die facts-Tabelle speichert Kanten mit subject_id, predicate, object_id, source_text und confidence.

Es handelt sich zwar nicht um ein natives Graphenmodell, funktioniert aber gut, kann einfache SQL JOINs verarbeiten und bietet einen Vorteil, den Neo4j nicht bieten kann: keine Abhängigkeit von Infrastruktur. Eine Breitensuche, die in reinem Python geschrieben ist, durchläuft die Beziehungen, um den an das Modell übergebenen Kontext zusammenzustellen. Für Prototypen und Dokumente mittlerer Größe reicht ein Graphenmodell auf SQLite mehr als aus.

Ein weitaus kleineres Modell

Der Unterschied in der Modellgröße ist groß. ROE verwendet gpt-oss:120b-cloud, ein Modell mit 120 Milliarden Parametern, während TechRAG mit qwen2.5:7b auskommt, das etwa 17 Mal kleiner ist, und dennoch gute Ergebnisse liefert. Laut der README ergibt ein Smoke-Test an einem technischen PDF mit 50 Abschnitten 263 Entitäten und 213 atomare Fakten. Die Antworten weisen anschließend einen evidence_coverage-Wert von 0,6 auf, basierend auf einem Kontext von nur 4 Abschnitten und 10 Fakten.

Das deutet darauf hin, dass die Qualität der hybriden Suche – bei der vektorbasierte Ähnlichkeit mit einem ontologischen Graphen kombiniert wird – ausreicht, um Schwächen eines schwächeren Modells auszugleichen. Wenn der Kontext so sorgfältig ausgewählt wird, liefert selbst ein einfaches LLM kohärente und überprüfbare Antworten.

CLI anstelle einer Webanwendung

ROE stellt eine Webanwendung bereit: ein Chat-Fenster, eine Graphenanzeige, einen Facts Composer zum Bearbeiten von Fakten sowie einen Audit Trail früherer Abfragen. TechRAG hingegen ist ausschließlich über die Kommandozeile verfügbar:

uv run roe ingest manual.pdf
uv run roe query "Which procedure reduces the risk associated with alarm A1?"
uv run roe stats

Es gibt weder eine GUI noch einen Graphenanzeigebereich, nur die Konsole. Dennoch gibt query ein vollständiges JSON-Dokument aus, das die Antwort sowie die zugehörigen Prüfdaten enthält: verwendete Blöcke, Fakten, Knoten, Kanten, Pfade, evidence_coverage, reasoning_score und recovered. Der Komfort wird zugunsten einer einfacheren Verwendung in automatisierten Pipelines geopfert.

Was unverändert blieb

Trotz der architektonischen Unterschiede folgt der Kernalgorithmus eng der ursprünglichen Spezifikation. Beide Systeme verfolgen denselben Ablauf: Sie analysieren Dokumente (PDF über pypdf, Markdown oder reinen Text), teilen sie in Abschnitte à 1000 Zeichen mit einer Überlappung von 200 Zeichen auf, fügen diese mit bge-m3 an einen Ollama-Endpunkt ein, initialisieren die Ontologie aus einer verteilten Stichprobe dieser Abschnitte und extrahieren für jeden Abschnitt atomare Fakten unter Rückverweis auf die Quelle. Die Extraktionsanfragen unterscheiden sich in der Form, da die von TechRAG auf Deutsch verfasst sind, doch die Idee bleibt dieselbe: Das Modell soll JSON-Triple mit Subjekt, Prädikat, Objekt und Quelle zurückgeben.

Die Suchparameter stimmen fast exakt überein. Die folgende Tabelle zeigt sie nebeneinander:

Die Werte sind identisch, genauso wie die Philosophie: Man beginnt mit einem kleinen, gezielt ausgewählten Kontext und erweitert ihn nur, wenn es notwendig ist.

Auch die Wiederherstellungslogik wird gemeinsam genutzt. Wenn die besten Ergebnisse unter 0,45 liegen, erweitert keines der Systeme den Kontext blind. Beide schreiben die Anfrage neu – TechRAG durch einen speziellen Prompt, der das Modell bittet, zwei alternative Anfragen mit unterschiedlicher Terminologie zu erstellen, und versuchen anschließend erneut, Informationen abzurufen. Falls die Abdeckung der Belege unter 40 % fällt, starten beide einen zweiten Versuch mit mehr Kontext, wobei TechRAG dies mit max_recovery_rounds=1 umsetzt.

Entscheidungen außerhalb des ursprünglichen Designs

Mehrere Entscheidungen von TechRAG gehen über die Spezifikation hinaus.

Provider-unabhängiger Client. Anstelle der nativen API von Ollama verwendet er openai.OpenAI, das auf Ollamas /v1-Endpunkt abzielt, sodass derselbe Code mit Ollama, OpenAI, vLLM oder jedem anderen OpenAI-kompatiblen Endpunkt verwendet werden kann:

# TechRAG clients.py
self._client = OpenAI(api_key=self.api_key, base_url=self.base_url)
resp = self._client.chat.completions.create(model=self.model, ...)

ROE ist mit Ollama verbunden, während TechRAG das nicht ist. Es handelt sich um einen subtilen Unterschied mit tatsächlicher Bedeutung: Ein späterer Wechsel auf GPT-4o erfordert keine Codeänderungen.

Modernes Packaging. TechRAG ist ein vollwertiges Python-Paket mit pyproject.toml, das vom Paketmanager uv von Astral verwaltet wird – dieser läuft deutlich schneller als pip. Ein sauberes roe/-Paket, eine CLI in __main__.py sowie explizite Abhängigkeiten sorgen für Wiederholbarkeit, da lediglich uv sync benötigt wird.

Ein günstigerer Schlussfolgerungs-Score. ROE ermittelt seinen Schlussfolgerungs-Score aus der Klassifizierung der Aussagen (Bestätigt, Widersprochen, Ununtermauert), die vom Modell durchgeführt wird. TechRAG macht dasselbe, fügt jedoch eine Heuristik hinzu: Es passt die Wörter „verified“/„verifiziert“, „contradicted“/„widerspr“ und „unsupported“/„nicht belegbar“ in der Antwort mithilfe einer Regex ab, sodass kein zweiter Modellaufruf erforderlich ist. Dadurch ist es schneller, aber weniger präzise.

Ein echtes BFS über SQL. Die Funktion graph_context_for beginnt mit Ausgangselementen aus den abgerufenen Datenabschnitten, durchläuft die Knoten breitstrahlend, sammelt einlaufende und ausgehende Kanten und stoppt bei max_nodes oder max_edges. Der Speicher ist kein natives Graphenstruktur, doch die Durchquerung verhält sich genauso wie bei einem.

Sorgfältige Handhabung der Ähnlichkeit. In vector_store.py werden Vektoren vor der Einfügung sowie vor jeder Abfrage L2-normalisiert. Anschließend wird die Kosinus-Ähnlichkeit mit einer doppelten Fallback-Methode berechnet: Zunächst wird die quadratische L2-Distanz, der Standard bei Faiss, angenommen, und falls das Ergebnis außerhalb des Bereichs [-1, 1] liegt, wird die lineare-L2-Formel angewendet. Der zurückgegebene Score ist daher stets ein sauberer Kosinuswert zwischen 0 und 1, unabhängig davon, welche Methode LanceDB im Hintergrund verwendet. Solche Details unterscheiden ein Prototyp, das manchmal funktioniert, von einem, das immer funktioniert.

Lektionen

Erstens ist da die Bestätigung. Wenn ein unabhängiger Entwickler eine Architektur mit einem anderen Stack neu implementiert und funktionierende Ergebnisse erzielt, ist die Idee nicht an ihre ursprüngliche Umsetzung gebunden. Es handelt sich dabei um ein übertragbares Prinzip. Die Schichten für Vektoren, Ontologien und Graphen benötigen weder Qdrant noch Neo4j – sie passen genauso gut in LanceDB und SQLite.

Zweitens ist da die Einfachheit. ROE erfordert Docker, Qdrant, MongoDB sowie eine Webanwendung. TechRAG hingegen benötigt LanceDB, SQLite und eine CLI. Für Prototypen, Konzeptionsbelege sowie die Integration in CI/CD ist der zweite Ansatz objektiv besser – dieser Vergleich erinnert daran, wie oft Entwickler Infrastrukturen überdimensionieren, die für das Problem gar nicht notwendig sind.

Drittens betrifft es das Modell. Ein 7B-Modell, das bei gut strukturiertem Kontext Ergebnisse vergleichbar mit denen eines 120B-Modells erzielt, zeigt, dass die Qualität der Informationsabrufung in GraphRAG mindestens genauso wichtig ist wie die Modellgröße – vielleicht sogar noch wichtiger. Ein sorgfältig ausgewählter Kontext mit wenigen Abschnitten, relevanten Fakten und Graphenpfaden ermöglicht es einem eher einfachen LLM, präzise zu reasoningen, während ein störender Kontext selbst das leistungsstärkste Modell verwirrt.

Im Hinblick auf TechRAG würde eine Neugestaltung von ROE voraussichtlich mehrere Schritte erfordern:

• Verwendung der mit OpenAI kompatiblen Abstraktion, damit jeder Anbieter integriert werden kann
• Bewertung von LanceDB als eingebetteter Ersatz für Qdrant, um die Einrichtung zu vereinfachen
• Beibehaltung von SQLite für die Dokumentenspeicherung in leichteren Fällen sowie Einsatz von Neo4j nur dann, wenn die Komplexität des Graphen dies rechtfertigt
• Beibehaltung der Web-Oberfläche zur Graphenerkundung und Faktenkorrektur, die weiterhin unverzichtbar ist, ergänzt durch eine CLI für skriptbasierte Ausführungen

TechRAG ist kein besseres ROE – es handelt sich um eine andere Variante, die auf Zugänglichkeit und Einrichtungsgeschwindigkeit ausgerichtet ist, und in vielen Szenarien ist das die richtige Priorität.

Warum das wichtig ist

Sowohl Projekte weisen auf denselben Schluss hin: Halten Sie Ontologie, Wissensgraph und Vektorabfrage getrennt, extrahieren Sie atomare Fakten mit Quellen-Referenzen, beschränken Sie den Kontext auf wenige sorgfältig ausgewählte Elemente und überprüfen Sie Antworten mit Abdeckungsmetriken. Sie zeigen außerdem, dass derselbe Ergebnis aus völlig unterschiedlichen Technologien erzielt werden kann, und dass die einfachere Wahl – LanceDB statt Qdrant, SQLite statt MongoDB sowie qwen2.5 statt eines 120B-Modells – oft der richtige Ausgangspunkt ist.