M-flow: Graph-RAG, bei dem der Graph die Bewertung übernimmt
A bio-inspired cognitive memory engine — a new paradigm for Graph RAG.
Auf einen Blick
- Was ist das?
- M-flow speichert Wissen in einem vierstufigen Cone Graph und bewertet Treffer über den kostengünstigsten Evidenzpfad statt über Vektorähnlichkeit. Eine Analyse der Architektur, der Startbefehle und der Grenzen des Ansatzes.
- Für wen ist es gedacht?
- M-flow ist für Teams interessant, deren Fragen sich auf Ereignisse, Entscheidungen und deren Begründung beziehen, nicht auf einzelne Fakten. Wer überwiegend technische Dokumentation oder Code durchsucht, bleibt bei Vektorsuche oder einem schlankeren GraphRAG-Aufbau besser bedient, weil der Aufwand für die vierstufige Pflege dort keinen Gegenwert erzeugt.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 14 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, 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
Welches Problem M-flow adressiert
Vektorsuche beantwortet die Frage, welcher Text einer Anfrage sprachlich am nächsten liegt. Sie beantwortet nicht die Frage, welcher Text die Ursache eines Ereignisses erklärt. Das README führt dafür ein Beispiel an: die Frage, warum Maria im Montags-Standup verärgert war. Ein Dokument über die Moderation effektiver Daily Standups teilt mit der Anfrage die Wörter standup, upset und team und landet deshalb weit oben im Ranking. Es erklärt den konkreten Vorfall nicht. M-flow richtet sich an Entwickler, die Agenten mit Langzeitgedächtnis bauen, an Teams mit Wissensbeständen aus Vorfällen, Entscheidungsprozessen und Workflows, und an alle, die MCP als Anbindung nutzen wollen. Für eine reine FAQ-Suche über Produkthandbücher ist der Ansatz überdimensioniert.
Der Cone Graph als Speichermodell
M-flow legt Wissen in vier Ebenen ab. Episode bezeichnet einen abgegrenzten semantischen Fokus, etwa einen Vorfall oder einen Entscheidungsprozess. Facet ist eine Dimension dieser Episode, also ein thematischer Querschnitt. FacetPoint ist eine atomare Aussage, die aus einem Facet abgeleitet wird. Entity ist eine benannte Sache, eine Person, ein Werkzeug oder eine Kennzahl, die über alle Episoden hinweg verknüpft wird. Das README ordnet jeder Ebene eine typische Frageform zu: Was ist mit der Tech-Stack-Entscheidung passiert, welche Leistungsziele wurden gesetzt, lag das P99-Ziel unter 500 Millisekunden, und welche Kontexte betreffen GPT-4o. Diese vier Ebenen sind der Kern des Modells. Wer sein Wissen nicht in Episoden und Facetten zerlegen kann, hat mit M-flow ein Datenmodellierungsproblem, kein Retrievalproblem.
Retrieval als Pfadkostenrechnung
Der Ablauf laut README: Eine Vektorsuche wirft ein breites Netz über alle Granularitäten und liefert Einstiegspunkte. Danach übernimmt der Graph. Evidenz breitet sich entlang typisierter, semantisch gewichteter Kanten aus, und jede Kante erhöht die Kosten des Pfades. Jede Episode wird anschließend über ihre stärkste Evidenzkette bewertet. Entscheidend ist die Formulierung, dass eine starke Kette genügt. Das Modell verhält sich damit nicht wie ein Ranking, das Mittelwerte bildet, sondern wie eine Maximumssuche über Pfade. Die Abfrage landet auf der Granularität, die zu ihr passt: ein präziser Hinweis auf einem FacetPoint, ein breiteres Thema auf einem Facet oder einer Episodenzusammenfassung. Im Beispiel verankert der Hinweis, dass jemand nicht über die Frist informiert wurde, auf einem FacetPoint. Die Propagation läuft über das zugehörige Facet nach oben zur Episode, und das Ergebnisbündel ist genau eine Episode samt ihren Facets und FacetPoints. Der nachgelagerte LLM formuliert die Antwort aus diesem Bündel. Die vollständige Pfadkostenmechanik liegt laut README in docs/RETRIEVAL_ARCHITECTURE.md. Wer beurteilen will, ob die Gewichtungen zu seinem Korpus passen, muss diese Datei lesen; aus dem README allein lässt sich nicht ableiten, wie die Kantengewichte zustande kommen.
Installation und erste Schritte
Das README verweist auf einen Quick-Start-Abschnitt und auf das Verzeichnis examples/. Konkrete Installationsbefehle, Konfigurationsschlüssel oder Umgebungsvariablen gibt der oben vorliegende Ausschnitt nicht her. Ich kann deshalb nicht sagen, ob M-flow über pip install m-flow oder aus dem Quellbaum gestartet wird, und ebenso wenig, welche Verbindungsdaten für die Graph- und Vektorkomponenten nötig sind. Wer das prüfen will, liest den Quick-Start-Abschnitt und die Beispiele im Repository. Gesichert ist die Sprachversion: Das README nennt Python 3.10 bis 3.13. Als Anbindung für Agenten existiert ein OpenClaw Skill unter clawhub.ai/flowelement-alexunbridled/mflow-memory, der als MCP-Schnittstelle dient. Das Repository liegt unter der Apache-2.0-Lizenz.
Wo der Ansatz an seine Grenzen stößt
Der wichtigste Vorbehalt steht im README selbst: Der Satz, dass der Unterschied zu pfadbasiertem Retrieval den Vorteil in den berichteten Benchmarks treibt, verweist auf Berichte, nicht auf nachvollziehbare Messungen. Wer adoptiert, sollte diese Zahlen selbst nachfahren, statt sie zu übernehmen. Dazu kommt ein struktureller Punkt. Ein System, das Episoden und Facetten verlangt, verschiebt Arbeit nach vorn: Jedes neue Dokument muss in die vier Ebenen eingeordnet werden, sonst bleibt es für das Graph-Routing unsichtbar. Bei einem Korpus, der wöchentlich wächst, ist das ein laufender Posten, kein einmaliger Import. Ein weiterer Fall: Fragen nach einem einzelnen, klar benannten Fakt. Wenn die Antwort in einem Absatz steht und die Ähnlichkeitssuche sie findet, bringt der Pfadkostenapparat keinen Zusatznutzen, kostet aber Graphdurchläufe. Und schließlich die Kantengewichte. Das README beschreibt Kanten als semantisch gewichtet, ohne im vorliegenden Ausschnitt zu erklären, wie diese Gewichte entstehen. Solange das unklar ist, ist die Qualität des Routings eine Annahme, keine Zusicherung.
Was M-flow von GraphRAG und Vektorsuche unterscheidet
Microsofts GraphRAG baut Entitäten, Relationen und Community-Strukturen auf und nutzt sie vor allem, um Kontext zu organisieren, zusammenzufassen und zu erweitern. Das README grenzt sich davon ausdrücklich ab: Die Struktur bleibt dort unterstützend, während bei M-flow der Graph die Bewertungsinstanz ist. Der praktische Unterschied liegt im Rückgabewert. Ein GraphRAG-System liefert typischerweise Textblöcke oder Community-Zusammenfassungen, aus denen das Modell eine Antwort baut. M-flow liefert laut README ein Bündel aus einer Episode mit ihren Facets und FacetPoints und dazu den Pfad, der zu diesem Bündel geführt hat. Reine Vektorsuche liefert dagegen eine nach Abstand sortierte Liste, in der Struktur keine Rolle spielt. Wer bereits GraphRAG betreibt und mit den Ergebnissen zufrieden ist, hat wenig Grund zu wechseln, weil der Wechsel eine Neumodellierung des gesamten Korpus in das Cone-Schema bedeutet. Interessant wird M-flow dort, wo die Begründung eines Ergebnisses Teil der Antwort sein muss.
Wartung, Versionen und Lizenz
Das Repository ist nicht archiviert. Der letzte Push liegt laut Metadaten auf dem 1. September 2026, die letzte Veröffentlichung ist v0.3.4 vom 12. April 2026. Zwischen beiden Daten liegen viereinhalb Monate ohne Release, bei gleichzeitiger Aktivität auf dem Hauptzweig. Das ist kein Warnsignal, aber ein Hinweis darauf, dass die Versionsnummer noch im Nullbereich liegt und sich Schnittstellen ändern können. Für die Upgrade-Planung heißt das: die Release Notes vor jedem Sprung lesen, statt automatisch zu aktualisieren. Das README nennt 963 bestandene Tests, was den Umfang der Testsuite beschreibt, nicht die Reife des Projekts. Die Apache-2.0-Lizenz erlaubt kommerzielle Nutzung und Modifikation und verlangt, dass Lizenz- und Urheberrechtshinweise erhalten bleiben; geänderte Dateien müssen gekennzeichnet werden. Ob das für Ihre Weitergabe relevant ist, hängt davon ab, ob Sie M-flow unverändert einsetzen oder forken. Eine Rechtsberatung ersetzt das nicht.
Für wen sich der Aufwand lohnt
Der Fall, in dem M-flow seine Stärke ausspielt, ist im README klar umrissen: eine Frage nach einem Ereignis, dessen Ursache über mehrere Dokumente verteilt ist. Wenn Ihre Nutzer fragen, warum eine Entscheidung getroffen wurde, was zu einem Vorfall geführt hat oder welche Zusammenhänge zwischen zwei Vorgängen bestehen, dann ist die Pfadkostenrechnung das passende Werkzeug, weil die Antwort genau in dieser Kette liegt. Wenn Ihre Nutzer dagegen nachschlagen, was ein Parameter bedeutet oder wo eine Funktion definiert ist, ist die Ähnlichkeitssuche schneller und billiger. Der aussagekräftigste erste Schritt ist nicht die Installation, sondern ein Blick in docs/RETRIEVAL_ARCHITECTURE.md: Wer die dort beschriebene Pfadkostenberechnung nicht nachvollziehen kann, wird die Ergebnisse im Betrieb auch nicht erklären können.
Redaktionelles Fazit
M-flow ist für Teams interessant, deren Fragen sich auf Ereignisse, Entscheidungen und deren Begründung beziehen, nicht auf einzelne Fakten. Wer überwiegend technische Dokumentation oder Code durchsucht, bleibt bei Vektorsuche oder einem schlankeren GraphRAG-Aufbau besser bedient, weil der Aufwand für die vierstufige Pflege dort keinen Gegenwert erzeugt. Vor einer Übernahme sollten Sie prüfen, ob die Schema-Definitionen für Episode, Facet und FacetPoint zu Ihren Daten passen und ob die in docs/RETRIEVAL_ARCHITECTURE.md beschriebene Pfadkostenberechnung auf Ihrem Korpus stabile Ergebnisse liefert. Prüfen Sie außerdem, welche Python-Version Ihr Produktivsystem nutzt: Das README nennt 3.10 bis 3.13, ältere Interpreter werden nicht genannt.
Community-Notizen