GraphRAG vs RAG: Wann sich ein Wissensgraph lohnt

Dokumentation am 26. Oktober 2026 geprüft: Grundlage waren die GraphRAG-Dokumentation von Microsoft, das zugehörige Repository sowie die Dokumentationen von Neo4j und LlamaIndex. Der folgende Vergleich analysiert die dort beschriebenen Mechanismen; er ist kein Leistungstest. Die Beispiele zum Produktfeedback dienen der Veranschaulichung.

Was ist GraphRAG?

Microsoft GraphRAG erstellt einen Überblick über den Dokumentenbestand, bevor jemand danach fragt. Ein großes Sprachmodell, kurz LLM, extrahiert Entitäten und Beziehungen aus den Dokumenten. Zusammenhängende Entitäten werden zu Communities gruppiert, für die anschließend Zusammenfassungen entstehen. Bei einer Abfrage kann das System auf diese Strukturen zurückgreifen. Microsofts Überblick beschreibt das Verfahren und seine wichtigsten Retrieval-Modi.

Eine Entität ist etwas, das in den Daten benannt wird, etwa ein Kunde, ein Produkt, eine Person oder ein Projekt. Eine Beziehung verbindet solche Entitäten: Ein Kunde nutzt ein Produkt, ein Projekt hängt von einem Dienst ab. Zusammen bilden sie einen Wissensgraphen. Eine Community ist eine Gruppe miteinander verbundener Entitäten. Ihre Zusammenfassung beschreibt, was in diesem Teil des Bestands vor sich geht.

Ein Dokumentenbestand lässt sich mit einem Campus vergleichen. Die Vektorsuche findet Räume, deren Inhalt zur Frage passt. Die Beziehungen im Graphen verbinden diese Räume. Community-Zusammenfassungen verschaffen von den oberen Verbindungsgängen aus einen Überblick. Geht es darum, was auf dem gesamten Campus passiert, reicht eine Handvoll ähnlicher Räume nicht aus: Ganze Gebäudeflügel können dabei fehlen.

Das erklärt ein bekanntes Problem: Eine Anwendung mit Retrieval-Augmented Generation stellt dem Modell vor der Antwort abgerufene Belege bereit. Sie findet die Exportrichtlinie zuverlässig, beantwortet die Frage „Was frustriert Kunden über alle diese Interviews hinweg?“ aber nur oberflächlich. Die zweite Frage verlangt einen Überblick über den gesamten Bestand. Möglicherweise gibt es keine einzelne Textstelle, die die Antwort direkt enthält.

„Graph RAG“ bezeichnet auch eine größere Familie von Retrieval-Systemen, die Graphen nutzen. Dieser Artikel konzentriert sich auf Microsofts Implementierung. Eine graphgestützte Anwendung auf Basis eines anderen Frameworks erstellt nicht automatisch Microsofts Community-Berichte und verwendet auch nicht zwangsläufig dessen Global-Search-Verfahren.

Wie funktioniert GraphRAG?

Die entscheidende Veränderung findet beim Indexieren statt: GraphRAG erzeugt aus den Daten abgeleitete Beschreibungen, die sich bei späteren Abfragen wiederverwenden lassen. Microsofts Standardverfahren zur Indexierung nutzt LLMs für die Extraktion und Zusammenfassung. Die Community-Struktur entsteht durch Graph-Clustering.

Die Schritte bauen aufeinander auf:

1. Dokumente in Texteinheiten aufteilen. Diese Einheiten sind Abschnitte des Quelltexts, sogenannte Chunks. Ihre Verknüpfungen zu den Dokumenten sichern den Herkunftsnachweis: Ein extrahiertes Element lässt sich so bis zu seiner Quelle zurückverfolgen.
2. Entitäten und Beziehungen extrahieren. Das LLM liest jede Texteinheit und beschreibt die Entitäten und Verbindungen, die es darin erkennt.
3. Den Graphen konsolidieren. Beschreibungen übereinstimmender Entitäten und Beziehungen werden zusammengeführt und zusammengefasst. Laut Dokumentation erfolgt die Zuordnung bei Entitäten anhand von Bezeichnung und Typ, bei Beziehungen anhand von Ausgangs- und Zielentität.
4. Communities ermitteln. Hierarchical Leiden, ein Algorithmus für Graph-Clustering, gruppiert verbundene Entitäten auf unterschiedlichen Detailebenen.
5. Community-Berichte und Embeddings erstellen. Das LLM fasst die Communities zusammen. Durchsuchbare Artefakte erhalten außerdem Embeddings: numerische Darstellungen für die Ähnlichkeitssuche.

Diese Abfolge entspricht Microsofts Datenfluss bei der Indexierung. Die Extraktion von Aussagen ist ein optionaler zusätzlicher Workflow und standardmäßig deaktiviert. Für den Standardgraphen und seine Berichte ist sie nicht erforderlich.

In einem Bestand mit Produktfeedback könnte ein Interview das Projekt Atlas, fehlgeschlagene Exporte und einen Freigabeprozess erwähnen. Ein anderes Gespräch könnte Atlas mit einem gemeinsam genutzten Arbeitsbereich verknüpfen. Erfasst die Extraktion diese Beziehungen, können Community-Berichte zusammengehörige Probleme bündeln, obwohl die Dokumente unterschiedliche Formulierungen verwenden.

Hier liegt zugleich eine Schwachstelle. Übersieht die Extraktion eine Beziehung, führt sie verschiedene Entitäten zusammen oder trennt sie Bezeichnungen, die dieselbe Entität meinen, übernehmen spätere Zusammenfassungen diese verzerrte Struktur. Auch ein sauber vernetzter Graph bleibt eine Interpretation des Textes.

Microsoft speichert die Ausgaben des Standardindex als Parquet-Tabellen, also in einem spaltenorientierten Dateiformat. Die Embeddings werden in den konfigurierten Vektorspeicher geschrieben. Diese Standardstruktur erfordert keine separate Graphdatenbank. Überblick zur Indexierung.

Die Suchmodi Global, Local, DRIFT und Basic

Welcher Abfragemodus passt, hängt davon ab, welche Belege die Antwort braucht. Global Search erschließt Muster im gesamten Bestand; Local Search setzt bei relevanten Entitäten an. Die weiteren Modi ermöglichen eine breitere Erkundung oder liefern eine Vergleichsbasis mit Vektorsuche.

Global Search: Themen im gesamten Bestand erkennen

Global Search ist der wichtigste Grund, Microsoft GraphRAG für Fragen wie „Was sind die zentralen Themen in all diesen Dokumenten?“ zu prüfen. Als Grundlage für die Antwort dienen Community-Berichte einer ausgewählten Hierarchieebene.

Das Verfahren arbeitet nach dem Map-Reduce-Prinzip: Zunächst werden Gruppen von Berichten getrennt verarbeitet, anschließend werden die Ergebnisse zusammengeführt. In der Map-Phase entstehen Teilantworten mit bewerteten Aussagen. Die Reduce-Phase wählt nützliche Aussagen aus und formuliert daraus die endgültige Antwort. Detailliertere Community-Berichte können sowohl die Antwort vertiefen als auch den Ressourcenbedarf erhöhen. Dokumentation zu Global Search.

Bei der Auswertung von Kundenfeedback soll das Produktverantwortlichen eine breitere Themenabdeckung ermöglichen: Onboarding, Freigaben und Zusammenarbeit könnten jeweils in die Antwort einfließen. Einfach mehr ähnliche Textstellen abzurufen, stellt noch nicht sicher, dass all diese Bereiche vertreten sind.

Dabei gilt eine wichtige Grenze: Global Search verdichtet Berichte. Das Verfahren zählt nicht exakt, wie viele Kunden ein bestimmtes Problem genannt haben. Wird für eine Entscheidung eine Rangfolge nach Häufigkeit benötigt, braucht es ein Zählverfahren mit klar definierten Einheiten und Dublettenbereinigung. Ein Modell kann anschließend die Ergebnisse erläutern.

Local Search: Eine Entität und ihr Umfeld untersuchen

Local Search passt zu Fragen wie „Wie hängt das Projekt Atlas mit Exportproblemen zusammen?“ Der Modus findet semantisch verwandte Entitäten, sammelt verbundene Informationen aus dem Graphen und zugehörige Quellpassagen und filtert das Material so, dass es in das Kontextfenster für die Antwort passt. Dokumentation zu Local Search.

Das hilft, wenn die Antwort von Beziehungen abhängt, die über mehrere Dokumente verstreut sind. Der Graph liefert Einstiegspunkte und Verbindungen, die Originalpassagen liefern die Belege im Detail. Auch Local Search arbeitet mit Ähnlichkeitssuche und einem begrenzten Kontext. Es gibt daher keine Garantie, dass jede relevante Beziehung in der Antwort auftaucht.

DRIFT Search: Vom Überblick zu weiterführenden Fragen

DRIFT beginnt mit relevanten Community-Informationen und entwickelt daraus Folgefragen, die mithilfe von Local Search bearbeitet werden. Der Modus eignet sich für offene Erkundungen, bei denen die erste übergreifende Antwort konkretere Untersuchungsrichtungen aufzeigt. Dokumentation zu DRIFT.

Die Frage „Warum fällt diesen Kunden die Zusammenarbeit schwer?“ kann beispielsweise zu getrennten Untersuchungen von Freigaben, gemeinsamer Verantwortung und Übergaben beim Export führen. Bevor DRIFT zum Standard für Routinefragen wird, sollte geprüft werden, ob diese zusätzlichen Suchvorgänge tatsächlich nützliche Belege erschließen.

Basic Search: Die Vergleichsbasis beibehalten

Basic Search ruft mithilfe der Vektorsuche ähnliche Textabschnitte ab. Microsoft stellt den Modus bereit, um verschiedene Abfragetypen leichter vergleichen zu können. Für eine eng umrissene Frage wie „Was steht in der Exportrichtlinie?“ ist er eine sinnvolle Kontrollvariante. Dokumentation zur Abfrage-Engine.

GraphRAG vs RAG: Welche Frage passt zu welchem Index?

Sinnvoll ist das einfachste Retrieval-Verfahren, das die jeweilige Frage zuverlässig abdeckt. Der folgende Vergleich betrachtet die Eignung für bestimmte Fragen, den Indexierungsaufwand und die Pflege des Index getrennt. Es handelt sich um architektonische Einschätzungen, nicht um gemessene Ranglisten zu Kosten oder Geschwindigkeit.

Hybride Suche löst ein anderes Problem als die übergreifende Zusammenführung von Inhalten. Microsofts Dokumentation zur hybriden Suche beschreibt, wie Volltext- und Vektorergebnisse kombiniert werden. Findet eine Anwendung einen exakten Produktcode nicht, ist hybride Suche der passende Ausgangspunkt. Eine globale Community-Zusammenfassung wäre für ein Problem der lexikalischen Suche ein Umweg.

Agentic RAG verändert den Suchablauf. Ein Modell kann einen Abruf auslösen, die Relevanz beurteilen, die Frage umschreiben und erneut suchen. Das zeigt etwa LangGraphs Tutorial zu agentengestütztem Retrieval. Agentic RAG eignet sich, wenn die Anwendung entscheiden muss, welche Belege sie als Nächstes beschafft.

Diese Ansätze lassen sich kombinieren. Ein Agent kann einen Graph-Retriever aufrufen, und ein graphgestützter Retriever kann mit hybrider Suche beginnen. Entscheidend ist, welcher zusätzliche Mechanismus einen beobachteten Fehler behebt. Werden alle zugleich eingebaut, lässt sich das schwerer feststellen.

Warum GraphRAG beim Indexieren mehr Aufwand verursacht

Standard-GraphRAG ergänzt die Embedding-Verarbeitung eines einfachen Vektorindex um generative Arbeitsschritte. Für die Anzahl der Dokumente lässt sich kein allgemeingültiger Kostenfaktor angeben: Der Aufwand hängt vom Text, der Extraktionskonfiguration sowie dem erzeugten Graphen und seinen Berichten ab.

Für die Planung hilft folgendes Modell:

Indexierungsaufwand = Chunk-Verarbeitung + Extraktionsdurchläufe + Zusammenfassungen von Beschreibungen + Community-Berichte + Embeddings.

Das ist ein Modell zur Aufwandserfassung im Pilotprojekt, keine Preisformel eines Anbieters. Der Aufwand sollte je Verarbeitungsschritt erfasst werden. So wird sichtbar, welche Anteile mit zusätzlichen Daten wachsen.

Die Chunks bestimmen, wie oft extrahiert werden muss. Mehr Chunks bedeuten mehr Texteinheiten zur Analyse. Chunk-Größe und Überlappung beeinflussen, wie viel wiederholten Kontext der Extraktor verarbeitet. Microsoft bietet in der Konfiguration außerdem max_gleanings an, um zusätzliche Extraktionszyklen zu steuern. Es wäre falsch, für jeden Chunk grundsätzlich genau einen LLM-Aufruf anzusetzen. Konfigurationsreferenz.

Die Graphgröße bestimmt den Umfang der nachgelagerten Verarbeitung. Ein Bestand mit vielen unterschiedlichen Entitäten und Beziehungen kann mehr zu konsolidierende Beschreibungen erzeugen als ein ähnlich großer Bestand zu einem eng begrenzten Thema. Wiederholte Erwähnungen liefern Beschreibungen, die zusammengeführt werden müssen. Vielfältige Verbindungen prägen die Communities, für die Berichte entstehen. Maßgeblich sind also die Extraktions- und Zusammenfassungsschritte, nicht allein die Dokumentanzahl.

Berichte verursachen weiteren Generierungsaufwand. Die Inhalte der Communities müssen zusammengefasst werden, und die Hierarchie erzeugt Übersichten auf unterschiedlichen Ebenen. Auch Embeddings bleiben Teil des Index. Die Aufgabenliste des Standardverfahrens ist der richtige Ausgangspunkt, um diese Aufwandstreiber zu erfassen.

Ein Cache kann wiederholte Modellarbeit vermeiden. Microsoft speichert Ergebnisse von LLM-Aufrufen für spätere Indexierungsläufe zwischen. Ein Neuaufbau und eine Aktualisierung sollten getrennt gemessen werden: Ein erneuter Lauf mit gefülltem Cache zeigt nicht, welchen Aufwand ein neuer Bestand verursacht. Cache-Konfiguration.

Der Aufwand für Abfragen braucht ein eigenes Budget. Global Search mit Map-Reduce und die Erkundung mit DRIFT können auch nach abgeschlossener Indexierung mehrere Modelloperationen erfordern. Ein erfolgreicher Indexierungspilot belegt deshalb noch keine akzeptablen Antwortzeiten.

Aktuelle Dokumente garantieren keine aktuellen Themenübersichten

Ein neues Dokument im Speicher macht die Berichte von Global Search noch nicht aktuell. Anforderungen an die Aktualität müssen den abgeleiteten Index einschließen, auf den die Abfrage tatsächlich zugreift.

Microsoft stellt graphrag update bereit. Laut aktueller CLI-Dokumentation wird der neue Index standardmäßig nach update_output geschrieben. Die Konfiguration sieht zudem einen separaten Speicher für Aktualisierungen vor, um vorhandene Ausgaben zu erhalten. Inkrementelle Aktualisierung ist also möglich. Ein Update-Befehl allein ersetzt jedoch keine vollständige Synchronisierungsstrategie. CLI-Referenz, Speicher für Aktualisierungen.

Angenommen, ein Supportgespräch korrigiert eine frühere Aussage zu Atlas. Das neue Dokument kann bereits vorliegen, während ein im Betrieb verwendeter Community-Bericht noch den alten Stand beschreibt. Das ist ein Fehler in der Datenpflege, selbst wenn eine direkte Suche die Korrektur findet.

Ergänzungen, Korrekturen und Löschungen müssen mit genau der Version und Konfiguration geprüft werden, die später zum Einsatz kommt. Dabei sind Quell-Chunks, extrahierte Beziehungen sowie lokale und globale Antworten zu kontrollieren. Die zitierte CLI-Dokumentation belegt nicht, dass jede Änderung automatisch mit der von der Anwendung benötigten Semantik weitergegeben wird.

Für den Betrieb bedeutet das: Die Indexversion muss sichtbar und der berücksichtigte Stand der Quelldaten bekannt sein. Zuerst wird ein konsistenter Satz von Artefakten bereitgestellt, anschließend werden die Abfragen auf diese Version umgestellt. Braucht das Unternehmen sofortige Antworten aus schnell wechselnden Datensätzen, sollte während der Prüfung des Berichtsaktualisierungsprozesses ein direkter Retrieval-Pfad verfügbar bleiben.

Zwei weitere Wege zu Graph RAG

Neo4j und LlamaIndex bieten Bausteine für Graph-Retrieval mit jeweils eigenen Ansätzen für Extraktion, Speicherung und Abfragen. Entscheidend ist der dokumentierte Mechanismus. „GraphRAG“ sollte nicht wie ein einziges, beliebig austauschbares Produkt behandelt werden.

GraphRAG mit Neo4j

Neo4j GraphRAG for Python enthält VectorCypherRetriever: Der Retriever findet zunächst ähnliche Knoten und führt anschließend eine Abfrage aus, um zusätzlichen Kontext einzusammeln. Cypher ist die Graphabfragesprache von Neo4j. Das Paket bietet außerdem hybrides Retrieval mit Vektor- und Volltextindizes sowie Text2Cypher, um Fragen in Datenbankabfragen zu übersetzen. Neo4js Leitfaden zu Retrievern.

Dieser Weg eignet sich für die Entwicklung von Anwendungen, bei denen ausdrücklich festgelegt werden soll, welchen Beziehungen nach dem Finden eines relevanten Knotens gefolgt wird. Beispielsweise lässt sich ein Projekt abrufen, um anschließend über eine definierte Graphabfrage seine verknüpften Abhängigkeiten zu laden.

Neo4js Werkzeuge zum Graphaufbau unterstützen zudem die LLM-basierte Extraktion von Entitäten und Beziehungen, das Speichern des Graphen und die Bereinigung doppelter Entitäten. Die Dokumentation beschreibt eine Fehlerbehandlung bei der Extraktion, die fehlerhafte Chunks überspringen kann, sofern sie nicht anders konfiguriert wird. Deshalb muss neben der Funktionsfähigkeit der Abfrage auch die Vollständigkeit der Datenübernahme geprüft werden. Leitfaden zum Knowledge Graph Builder.

Die Grenze dieses Ansatzes: Eine Vektorsuche mit anschließender Graphabfrage erzeugt für sich genommen noch keine Hierarchie von Community-Berichten wie bei Microsoft. Werden übergreifende Themenzusammenfassungen benötigt, muss festgelegt werden, wie diese zusätzliche Ebene entsteht.

Property Graphs mit LlamaIndex

Der PropertyGraphIndex von LlamaIndex steuert den Graphaufbau und das Retrieval. Ein Property Graph enthält Entitäten mit Labels, ihre Attribute und ihre Beziehungen. Die Extraktoren arbeiten auf Chunks; SchemaLLMPathExtractor kann die Extraktion auf erlaubte Muster von Entitäten und Beziehungen begrenzen. VectorContextRetriever findet Graphknoten anhand ihrer Embeddings und ruft verbundene Pfade ab. Über die Retrieval-Optionen ist auch der Quelltext verfügbar. Leitfaden zu Property Graphs.

Dieser Weg passt, wenn konfigurierbare Extraktoren und Retriever innerhalb eines Anwendungsframeworks benötigt werden. Die dokumentierten Operationen zum Einfügen, für Upserts und zum Löschen liefern Bausteine für die Graphpflege. Die Anwendung braucht trotzdem Regeln für Änderungen an Quellen und den daraus abgeleiteten Fakten.

Die Grenze liegt hier beim jeweiligen Graphspeicher: Von ihm hängt ab, welche Operationen verfügbar sind. Der standardmäßige SimplePropertyGraphStore ist keine Graphdatenbank und unterstützt kein Cypher. Speicherung und Retrieval müssen deshalb gemeinsam ausgewählt werden. Ebenso wenig sollte vorausgesetzt werden, dass ein Property-Graph-Index Microsofts Workflow für globale Zusammenfassungen mitbringt.

GraphRAG-Tutorial: Den konkreten Fehler zum Maßstab machen

Am Anfang sollten ein begrenzter Dokumentenbestand und Fragen stehen, deren Antworten sich überprüfen lassen. Microsofts Repository weist darauf hin, dass die Indexierung teuer werden kann. Der Einstiegsleitfaden empfiehlt, das Verfahren zunächst mit einem kleinen Datensatz kennenzulernen, bevor ein großer Lauf gestartet wird.

Sind Arbeitsverzeichnis und Zugangsdaten eingerichtet, entsprechen diese Befehle der aktuell dokumentierten CLI-Syntax:

graphrag index --method standard
graphrag query "What are the main themes across these documents?" --method basic
graphrag query "What are the main themes across these documents?" --method global

Die Abfrage wird laut aktueller CLI-Referenz als Positionsargument übergeben.

Bei der Bewertung zählen Themenabdeckung und Belegbarkeit gemeinsam. Eine Antwort, die mehr Themen aufzählt, dabei aber Verbindungen erfindet, löst das Problem nicht. Eine prüfende Person sollte jedes wichtige Thema bis zu den Belegen zurückverfolgen, fehlende erwartete Themen notieren und kontrollieren, ob unterschiedliche Gruppen zu einer bequemen Verallgemeinerung zusammengezogen wurden.

Für die Entwicklung gilt: Den Graphen nur übernehmen, wenn er die problematische Klasse von Fragen verbessert und zugleich Faktenabfragen weiterhin akzeptabel funktionieren. Im Betrieb braucht es ein Aktualisierungsverfahren, das auch Korrekturen und Löschungen standhält. Wer ein System beauftragt, sollte sich genau diese Fähigkeiten an repräsentativen Dokumenten zeigen lassen, bevor eine Graphvisualisierung als Beleg für bessere Antworten akzeptiert wird.

Liegen die Belege bereits vor, verwendet das Modell aber wiederholt das falsche Format oder zeigt das falsche Verhalten, lohnt sich ein Blick auf RAG vs. Fine-Tuning. Ein aufwendigerer Index verbessert den Zugang zu Belegen. Er ist nicht automatisch die passende Maßnahme für jeden Fehler bei der Textgenerierung.

Welche Erwartungen an GraphRAG gehen zu weit?

Die belastbare Aussage ist enger gefasst als „Graphen machen RAG besser“: Ein bestimmter Graph und ein bestimmtes Abfrageverfahren können eine bestimmte Art der Belegsuche verbessern.

Verbindungen belegen keine Wahrheit. Extrahierte Beziehungen und Community-Berichte können falsch sein. Sie sollten als durchsuchbare Interpretationen behandelt werden, deren Quellen nachvollziehbar bleiben. Ein Graphpfad kann die Prüfung des Retrievals erleichtern, ohne damit die zugrunde liegende Aussage zu beweisen.

Stärker vernetzte Antworten sind nicht zwangsläufig vollständiger. Auch eine umfassend wirkende Zusammenfassung kann ein isoliertes Problem auslassen. Seltene Themen und unbequeme Ausnahmen gehören deshalb in den Prüfsatz, besonders wenn sie eine Produktentscheidung verändern könnten.

Eine Community-Zusammenfassung ist keine Häufigkeitstabelle. Wiederholte Erwähnungen, die Vernetzung von Entitäten und die Wichtigkeitseinschätzung eines Modells sind etwas anderes als das Zählen einzelner Kunden. Bevor ein Thema als das häufigste bezeichnet wird, muss die Analyseeinheit feststehen.

Das Repository ist kein verwalteter Microsoft-Dienst. Microsofts Hinweise zum Repository beschreiben den Code als Demonstration der Methodik, nicht als offiziell unterstütztes Microsoft-Angebot. Für Bereitstellung, Überwachung und Datenaktualisierung müssen weiterhin Verantwortliche benannt werden.

Häufige Fragen zu GraphRAG

Was sich nächste Woche konkret prüfen lässt

Ausgangspunkt ist die thematische Frage, die die bestehende Anwendung derzeit schlecht beantwortet. Zunächst festlegen, welche Belege eine gute Antwort aus dem gesamten Bestand benötigen würde. Anschließend eine kleine GraphRAG-Evaluation um genau diesen Fehler aufbauen und den bisherigen Retriever als Kontrollvariante beibehalten.

Ein Einstieg lohnt sich, wenn die übergreifende Zusammenführung von Inhalten regelmäßig gebraucht wird und jemand die Verantwortung für den abgeleiteten Index übernehmen kann. Abwarten ist sinnvoll, wenn sich der Korpus schneller ändert, als sich die Berichte validieren lassen, oder niemand beurteilen kann, ob eine thematische Antwort vollständig ist. Besteht die Aufgabe überwiegend aus zuverlässigen Faktenabfragen, kann die bisherige Architektur bleiben. Das nützliche Ergebnis ist eine begründete Retrieval-Entscheidung, unabhängig davon, ob der Graph am Ende bleibt.

Praktische Anleitungen zum Aufbau von KI-Systemen gibt es im Newsletter.