Neo4j + GraphRAG in Aktion: Live-Refactor
mit Jennifer ReifEin zweistündiger Live-Refactor, der eine Dateisuche-App mit GraphRAG und LangChain4j von PostgreSQL auf Neo4j umstellen sollte. Das Ziel wurde nicht erreicht, aber vier Learnings machten den Versuch trotzdem wertvoll.

YouTube
Neo4j + GraphRAG in Aktion: Live-Refactor
YouTube-Video laden
Dieses Video wird von YouTube eingebettet und erst nach Ihrer Einwilligung geladen. Beim Laden können personenbezogene Daten an YouTube oder Google übermittelt und Cookies gesetzt werden.
Mehr dazu in der Datenschutzerklärung.
Projektquelle
Arbeits-Repository
Hier findest du Prompts, Instructions und Beispiele aus dem gezeigten Modernisierungs-Workflow.
Repository öffnenTimestamps der Session
- 00:00Einführung
- 01:11ai4jvm.com
- 02:02Den Plan erklären
- 06:05Bestehendes Projekt mit Neo4j-Änderungen
- 10:10Abhängigkeiten korrigieren
- 15:13Entitäten modellieren
- 34:30application.properties korrigieren
- 38:45Entitäten speichern und laden
- 42:58Daten ingestieren
- 01:02:30Die App testen (Spoiler: sie scheitert)
- 01:10:50Die Abhängigkeit korrigieren
- 01:13:00Den KnowledgeGraphWriter integrieren
- 01:25:00Entitäten neu modellieren
- 01:34:30Entitäten erneut speichern und laden
- 01:42:55Erneut Embeddings erzeugen
- 02:09:30Startup-Probleme beheben (scheitert)
- 02:20:50Fazit
Jennifer Reif von Neo4j war zu Gast, um mit mir Quanta, eine App zur Dateisuche, live von PostgreSQL auf Neo4j umzubauen. Die Idee war, flache Vektorähnlichkeitssuche durch GraphRAG zu ersetzen: Dateien, Embeddings und ihre Beziehungen als nativen Graphen zu modellieren, um reichhaltigere KI-Retrievals zu bekommen. Stack: Quarkus, LangChain4js KnowledgeGraphWriter, Neo4j.
Es hat nicht funktioniert. Nach zwei Stunden gab es kein funktionierendes Ergebnis. Aber genau dieses Scheitern war lehrreicher als eine saubere Demo es gewesen wäre.
Was ist GraphRAG?
Standard-RAG holt die ähnlichsten Text-Chunks und gibt sie an das LLM weiter. GraphRAG ergänzt Struktur: Es holt Knoten und ihre Beziehungen aus einem Wissensgraphen, sodass das LLM nicht nur versteht, dass zwei Dinge ähnlich sind, sondern auch warum sie verbunden sind. Für eine Dateisuche-App bedeutet das Kontext, der wie die echten Daten geformt ist und nicht wie eine flache sortierte Liste.
LangChain4js KnowledgeGraphWriter schreibt Entitäten und Beziehungen während des Ingestionsprozesses nach Neo4j und hängt sich zur Laufzeit in die Retrieval-Pipeline ein.
Wie die Session lief
Die Abstimmung der Abhängigkeiten zwischen Neo4j OGM, der Quarkus-Neo4j-Extension und LangChain4j verbrauchte den ersten Block, bevor überhaupt sinnvoller Code geschrieben wurde. Nach dem Modellieren der Entitäten und dem Verdrahten des KnowledgeGraphWriter lief die Ingestion. Beim Testen bei 1:02:30 traten dann Fehler dabei auf, wie Embeddings gespeichert und geladen wurden. Der Rest der Session war eine Schleife aus Ummodellieren, neu einbetten und erneut ausführen. Bei 2:09:30 kämpften wir immer noch mit Startup-Fehlern. Das ehrliche Fazit: Wir haben es nicht geschafft.
Vier Learnings
1. GraphRAG ist noch nicht Plug-and-Play
Das Konzept ist klar, das Tooling ist eng. Die Neo4j-Unterstützung von LangChain4j ist noch begrenzt und die Dokumentation lässt echte Lücken. Was in einem Diagramm offensichtlich wirkt, also Entitäten schreiben, Beziehungen verknüpfen und den Graphen abfragen, wird in der Praxis schnell zu einer Kette aus Versionskonflikten und undokumentierten Randfällen. Plane mehr Vorbereitungszeit ein, als du zunächst denkst.
2. OGM war die falsche Abstraktion
Neo4j OGM mappt Java-Objekte auf Graph-Knoten. Das ist in vielen Kontexten nützlich, war hier aber der falsche Fit. LangChain4js KnowledgeGraphWriter arbeitet auf Cypher-Ebene mit einfachen String-Werten und passt nicht zu OGM zusammen. OGM direkt aus dem Weg zu räumen und näher an rohem Cypher zu arbeiten, hätte eine große Reibungsquelle entfernt. Wirklich hilfreich wäre es, wenn das KnowledgeGraph-Tooling irgendwann OGM-artige Abstraktionen unterstützen würde und die Dokumentation klarer zeigen würde, welche Integrationsstile tatsächlich unterstützt werden.
3. Erst auf das Konzept einigen, dann Code schreiben
Zwei Minuten Einführung und dann direkt in den Code. Das war zu schnell. Das Graph-Modell des KnowledgeGraphWriter war zwischen uns nie vollständig abgestimmt, bevor die Session begann. Unterschiedliche mentale Modelle desselben Problems verwandeln fast jede technische Entscheidung in Reibung. Ein fünfminütiges Diagramm zu Beginn hätte uns sauber ausgerichtet und das OGM-Problem wahrscheinlich viel früher sichtbar gemacht.
4. Projekte brauchen Dokumentation, kein Onboarding aus dem Stegreif
Quanta ist klein, aber klein heißt nicht selbsterklärend. Gleichzeitig die Projektstruktur zu erklären und daran zu refactoren bedeutet, dass beides nicht die Aufmerksamkeit bekommt, die es braucht. Jennifer brachte starke Neo4j-Expertise mit. Was fehlte, war ein klares Gesamtbild davon, was Quanta macht, wie es aufgebaut ist und was ich ändern wollte. Ein kurzer schriftlicher Überblick hätte sich sofort ausgezahlt.
Nützliche Links
- Neo4j + LangChain4j GraphRAG Blog Post
- LangChain4j Neo4j Embedding Store Docs (KnowledgeGraphWriter)
- Neo4j OGM Manual
- Session-Code: Quanta, Branch
Add-Tags-and-Relations-with-neo4j - Jennifers Podcast: Break Time Tech Talks
Abschließender Gedanke
GraphRAG ist eine gute Idee und Neo4j ist dafür ein naheliegender Fit. Das Tooling ist nur noch nicht reibungslos, und genau diese Lücke wird erst sichtbar, wenn man es an einem echten Projekt ausprobiert. Diese Session war ein ehrlicher Blick darauf, wo diese Lücke aktuell liegt.
Kommentare
Kommentare optional von GitHub laden
Die Kommentarfunktion wird über Giscus und GitHub Discussions bereitgestellt. Sie wird erst nach Ihrer ausdrücklichen Einwilligung geladen. Beim Laden können personenbezogene Daten wie Ihre IP-Adresse und technische Metadaten an GitHub übermittelt sowie Cookies oder ähnliche Technologien gesetzt werden.
Bitte bestätigen Sie zuerst Ihre Einwilligung, bevor die Kommentare geladen werden.