karlsCORE KI-Gemeinschaft KI-Wissen Systemisch Denken Erstgespräch Anmelden

Wie bereite ich meine Dokumente, Emails etc. sauber für mein KI-System auf?

"Alles einfach nur in die Datenbank reinschmeissen"? Das funktioniert nur kurz ...

Kompakt Details

In vielen KI-Systemen werden Dokumente, E-Mails, Tickets etc. "einfach in eine Collection in einer Vektor-Datenbank" gespeichert. Die wilde Hoffnung dabei: Man erhält daraus später im RAG-Prozess (Retrieval Augmented Generation = die KI sucht sich relevante Textstücke und baut daraus eine Antwort zusammen) sinnvolle Antworten.

Das funktioniert im kleinen Umfang erstaunlich gut, vor allem wenn man große, leistungsfähige Modelle verwendet. Sobald es allerdings in einen echten, operativen Betrieb geht, sinkt die Antwortqualität plötzlich drastisch: Die Menschen werden unzufrieden, greifen wieder zu "externen" Lösungen wie Google oder ChatGPT. Das interne System verkümmert.

Wie kann man so eine Entwicklung vermeiden (und sogar die Qualität und Akzeptanz systemisch erhöhen)? Darum geht's in diesem Beitrag.

Die konkreten Probleme naiver RAG-Implementierungen

Wenn Du Dokumente einfach in eine Vektor-Datenbank wirfst, passiert etwas Merkwürdiges: Die KI findet zwar syntaktisch ähnliche Textstellen (also Wörter, die ähnlich klingen), aber nicht unbedingt die semantisch passenden (also die, die inhaltlich zu Deiner Frage passen).

Das liegt daran, dass wichtige Informationen fehlen: Zu welchem Thema gehört dieser Text? Wie hängt er mit anderen Konzepten zusammen? Was bedeutet ein Begriff in diesem speziellen Kontext? Ohne diese Strukturen arbeitet die KI mit fragmentiertem Wissen, wie ein Puzzle, bei dem die Hälfte der Teile fehlt.

Bei 100 Dokumenten fällt das kaum auf. Bei 1.000 Dokumenten wird es kritisch. Bei 10.000 Dokumenten ist das System praktisch unbrauchbar, weil die Treffgenauigkeit unter 40% sinkt.

Warum strukturierte Aufbereitung den Unterschied macht

Der alte Programmierer-Grundsatz gilt auch für KI-Systeme: "Garbage In = Garbage Out". Wenn Du der KI schlecht aufbereitete Daten gibst, bekommst Du schlechte Antworten zurück, egal wie leistungsfähig das Modell ist.

Strukturierte Aufbereitung bedeutet: Jedes Textfragment erhält Kontext. Zu welcher Kategorie gehört es? Mit welchen anderen Konzepten hängt es zusammen? Welche Begriffe werden hier verwendet? Diese Zusatzinformationen (Metadaten genannt) ermöglichen der KI eine präzise Filterung. Sie kann gezielt nach relevanten Stellen suchen, statt blind alle ähnlich klingenden Texte zu nehmen.

Die Folge: Die Treffgenauigkeit steigt von unter 40% auf über 70%, Halluzinationen sinken drastisch, und das System bleibt auch bei vielen tausend Dokumenten nutzbar.

Die konkrete Implementierung: 5 Haupt-Phasen, 17 Detail-Schritte

Die hier gezeigte Verarbeitungskette arbeitet in fünf Haupt-Phasen (die sich in 17 Detail-Schritte gliedern, die Du weiter unten live beobachten kannst):

  1. Konvertierung: PDF/HTML → reiner Text
  2. Seitenweise Analyse: Jede Seite einzeln untersuchen
  3. Modell-Extraktion: Taxonomie, Ontologie, Semantik herausziehen
  4. Konsolidierung: Alle Seiten zusammenführen
  5. Speicherung: In ChromaDB und MariaDB

Das Besondere: Die Extraktion läuft lokal mit Ollama, ohne API-Kosten oder Cloud-Abhängigkeit. Es kommen zwei verschiedene Modelle zum Einsatz: Ein kleineres, schnelles für Taxonomie (gemma3:4b) und ein größeres, präziseres für Ontologie und Semantik (gpt-oss:20b).

Zwischen jedem Schritt gibt es Quality Gates:

  1. JSON-Validierung: Prüft, ob die Ausgabe korrekt formatiert ist
  2. Vollständigkeits-Checks: Stellen sicher, dass keine wichtigen Felder fehlen
  3. Konsistenz-Prüfungen: Erkennen Widersprüche

Nur wenn alles passt, geht es weiter zum nächsten Schritt.

Messbare Verbesserungen

Der Unterschied zwischen naiver und strukturierter Implementierung lässt sich in Zahlen ausdrücken: Die Retrieval-Präzision steigt erfahrungsgemäß von 30-40% auf 70-85%. Das bedeutet: Von fünf gefundenen Textfragmenten sind drei bis vier wirklich relevant (statt nur ein bis zwei bei naiven Systemen).

Halluzinationen sinken, weil die KI präziseren Kontext erhält und weiß, woher die Informationen stammen. Das System bleibt auch bei 10.000+ Dokumenten nutzbar, während naive Implementierungen schon bei 1.000-2.000 Dokumenten an ihre Grenzen stoßen.

Hinzu kommt: Die extrahierten Strukturen (Taxonomie, Ontologie, Glossar) sind eigenständige Artefakte, die unabhängig von RAG genutzt werden können, beispielsweise für:

  1. Automatische Dokumenten-Kategorisierung
  2. Knowledge-Graph-Visualisierung
  3. Compliance-Reports

Systemische Langzeitwirkungen

Der größte Unterschied zeigt sich erst über Zeit: Wenn Du 100, 500, 1.000 Dokumente durch diese Pipeline laufen lässt, entsteht ein unternehmensweiter Wissensgraph. Die Taxonomien verschiedener Dokumente konvergieren (ähnliche Begriffe werden zusammengeführt). Die Ontologien verbinden sich zu einem Netzwerk, das zeigt, wie alles zusammenhängt.

Das ist dann deutlich cooler als nur eine "Suche". Das wird quasi zum "organisatorischen Lernen": Implizites Wissen (was einzelne Experten wissen) wird explizit (dokumentiert und maschinenlesbar). Widersprüche zwischen Dokumenten werden sichtbar. Versteckte Abhängigkeiten kommen ans Licht ("Funktion A hängt von Technologie B ab, die wiederum C voraussetzt").

Diese Strukturen machen Organisationen weniger abhängig von Einzelpersonen und besser skalierbar über Teams und Domänen hinweg.

In vielen KI-Systemen werden Dokumente, E-Mails, Support-Tickets und andere Textquellen nach einem simplen Muster verarbeitet: Text extrahieren, in Chunks schneiden, Embeddings generieren, ab in die Vektor-Datenbank. Das nennt sich dann "RAG-System" (Retrieval Augmented Generation, also die KI durchsucht die Datenbank nach relevanten Textfragmenten und generiert daraus eine Antwort).

Das naive RAG-Muster und seine Grenzen

Diese Vorgehensweise hat einen verführerischen Charme: Sie ist schnell implementiert, funktioniert im Proof-of-Concept beeindruckend gut und liefert bei 50-100 Dokumenten mit leistungsfähigen Modellen (zum Beispiel GPT-4, Claude Opus) durchaus brauchbare Ergebnisse. Die Entwickler sind zufrieden, das Management nickt ab, das System geht in Produktion.

Dann beginnt die schleichende Erosion: Bei 500 Dokumenten werden die Antworten schwammiger. Bei 1.000 Dokumenten tauchen erste Halluzinationen auf (die KI erfindet plausibel klingende, aber falsche Details). Bei 10.000 Dokumenten ist das System praktisch nicht mehr nutzbar, weil die Retrieval-Qualität unter 30-40% Precision@5 fällt (von 5 gefundenen Textfragmenten sind nur 1-2 wirklich relevant).

Die Menschen merken das. Sie vergleichen mit Google, mit ChatGPT, mit ihren bisherigen Workflows. Das interne System verliert. Sie kehren zurück zu "externen" Lösungen. Das Projekt wird still und leise begraben (oder vor sich hinvegetierend geduldet, bis irgendwann jemand den Stecker zieht).

Warum "einfach in die Datenbank schieben" nicht skaliert

Das Problem liegt nicht am RAG-Prinzip selbst, sondern an der fehlenden Struktur. Wenn Du Dokumente ohne Kontext speicherst, verlierst Du entscheidende Informationen:

Der differenzierte Weg: Wissen strukturieren, bevor es in die Datenbank geht

Die Alternative ist aufwendiger, aber sie funktioniert: Dokumente werden vor der Speicherung analysiert und angereichert. Jedes Dokument durchläuft eine Pipeline, die drei komplementäre Wissensmodelle extrahiert:

Diese Strukturen werden als Metadaten an jeden Textchunk gehängt. Wenn die KI später eine Suche durchführt, kann sie gezielt filtern: Nur Chunks aus der richtigen Taxonomie-Kategorie, nur solche mit verwandten Ontologie-Entitäten, nur solche mit den relevanten Glossar-Begriffen. Was dabei entsteht: Die Retrieval-Precision steigt typischerweise auf 70-85%, Halluzinationen sinken, die Antwortqualität bleibt auch bei 10.000+ Dokumenten hoch.

Systemische Auswirkungen: Von der Werkzeug-Frage zur Organisationsfrage

Dieser Unterschied ist nicht nur technisch, er ist organisatorisch und kulturell. Ein naives RAG-System suggeriert: "KI löst das schon". Ein strukturiertes System macht explizit: "Wir müssen verstehen, was in unseren Dokumenten steht". Das erzwingt eine Auseinandersetzung mit dem eigenen Wissen, mit widersprüchlichen Begriffen, mit veralteten Inhalten.

Manche Organisationen wollen das nicht. Sie wünschen sich die Illusion, dass Technologie Struktur ersetzt. In solchen Fällen ist ein naives RAG-System möglicherweise sogar die ehrlichere Wahl, weil es schneller scheitert und weniger Ressourcen verschwendet.

Andere Organisationen erkennen: Qualität entsteht nicht durch mehr Rechenleistung, sondern durch mehr Klarheit. Für die ist dieser Beitrag.

Die konkreten Probleme naiver RAG-Implementierungen

Die naive Implementierung (Dokumente chunken, embedden, speichern) hat systematische Schwächen, die sich gegenseitig verstärken:

Context Pollution: Wenn die KI mit Irrelevantem gefüttert wird

Die Ähnlichkeitssuche in Vektordatenbanken arbeitet nach einem simplen Prinzip: Sie sucht Textfragmente, deren numerische Repräsentation (Embedding-Vektor) möglichst nah am Query-Vektor liegt. Das funktioniert für syntaktische Ähnlichkeit hervorragend, versagt aber bei semantischer Relevanz.

Ein Beispiel: Die Frage "Wie implementiere ich Caching in Python?" findet möglicherweise Chunks über "Python-Schlangen in der Terraristik" oder "Monty Python Filmzitate", weil das Wort "Python" prominent vorkommt. Die KI erhält irrelevante oder sogar widersprüchliche Informationen, aus denen sie eine Antwort konstruieren soll. Die Konsequenz: Halluzinationen steigen exponentiell. Das Modell versucht, inkonsistente Inputs zu einem kohärenten Output zu verbinden, und scheitert dabei.

Fehlende Hierarchie: Konzepte ohne Einordnung

Ohne taxonomische Struktur (= hierarchische Klassifikation in Kategorien) kann die KI Konzepte nicht einordnen. Ist "Python" hier Teil der Kategorie "Programmiersprachen → Skriptsprachen" oder "Tiere → Reptilien → Schlangen"? Diese Frage erscheint trivial, ist aber in der Praxis der Hauptgrund für falsche Retrieval-Ergebnisse.

Das Problem verschärft sich bei Fachbegriffen mit mehreren Bedeutungen: "Java" (Programmiersprache, Insel, Kaffee), "Ruby" (Programmiersprache, Edelstein), "Atlas" (Karte, Anatomie, griechische Mythologie). Ohne Hierarchie ist jede Suche ein Glücksspiel.

Isolierte Fragmente: Beziehungen gehen verloren

Wenn Du ein Dokument in Chunks zerschneidest, zerreißt Du auch die Beziehungen zwischen Konzepten. Die Information "Funktion A benötigt Technologie B und setzt C voraus" wird zu drei isolierten Textfragmenten ohne erkennbaren Zusammenhang.

Ohne Ontologie (= explizites Netzwerk aus Entitäten und ihren Beziehungen) muss die KI diese Zusammenhänge aus dem Kontext erraten. Das funktioniert bei offensichtlichen Fällen, scheitert aber bei komplexen Abhängigkeiten. Daraus folgt: Unvollständige oder falsche Antworten. Wichtige Constraints werden nicht erkannt.

Mehrdeutigkeit ohne Auflösung

Viele Begriffe haben mehrere Bedeutungen, die sich nur aus dem Kontext erschließen. Ohne semantische Anreicherung (= explizite Definitionen und Glossare) bleibt diese Mehrdeutigkeit unaufgelöst.

Ein praktisches Beispiel: In einem Projekt-Handbuch steht "Die Pipeline verarbeitet Events asynchron". Ist hier "Pipeline" die CI/CD-Pipeline, die Data-Pipeline oder eine Message-Processing-Pipeline? Ohne Definition kann die KI das nicht entscheiden und liefert möglicherweise eine Antwort basierend auf der falschen Interpretation.

Skalierung ohne Struktur: Das Roulette-Problem

Bei wenigen Dokumenten ist die Wahrscheinlichkeit hoch, dass die Top-5-Retrieval-Ergebnisse das Richtige enthalten. Bei 1.000+ Dokumenten wird Retrieval zum Roulette-Spiel: Die Datenbank liefert fünf zufällig ähnlich aussehende Chunks, von denen keiner wirklich passt.

Das liegt daran, dass die Anzahl der False Positives (syntaktisch ähnlich, aber inhaltlich irrelevant) schneller wächst als die Anzahl der True Positives. Ohne strukturierte Metadaten zur Filterung gibt es keinen Mechanismus, um die Spreu vom Weizen zu trennen.

Warum strukturierte Aufbereitung den Unterschied macht

Die Qualität eines RAG-Systems wird nicht durch die Größe des verwendeten Sprachmodells bestimmt, sondern durch die Qualität des Retrievals. Erfahrungen zeigen: Der überwiegende Teil der Fehler in RAG-Systemen (geschätzt 60-80%) stammt aus unzureichendem Retrieval, nicht aus schwachen Modellen. Ein GPT-4 mit schlechtem Kontext liefert schlechtere Ergebnisse als ein kleineres Modell mit präzisem Kontext.

Kontext-Präzision durch Taxonomie

Eine taxonomische Struktur (= hierarchische Klassifikation) ermöglicht exakte thematische Filterung. Wenn eine Frage sich auf "Machine Learning → Neuronale Netze → Transformer" bezieht, können alle Chunks außerhalb dieser Kategorie ausgeschlossen werden, bevor die Ähnlichkeitssuche überhaupt startet.

Das reduziert die Kandidatenmenge typischerweise um 90-95% und erhöht gleichzeitig die Relevanz der verbleibenden Chunks. Das ist der Unterschied zwischen "suche in 10.000 Chunks" und "suche in 500 thematisch passenden Chunks". Die Retrieval-Geschwindigkeit steigt, die Präzision steigt, der Ressourcenverbrauch sinkt.

Beziehungs-Kontext durch Ontologie

Ein Ontologie-Graph liefert Dependency-Informationen: Wenn Konzept A erwähnt wird, sind wahrscheinlich auch die Konzepte B und C relevant (weil A von B abhängt oder C verwendet). Diese Beziehungen können automatisch in die Suche einbezogen werden.

Ein praktisches Beispiel: Die Frage "Wie funktioniert BERT?" könnte automatisch Chunks über "Transformer-Architektur" und "Attention-Mechanismus" mit abrufen, auch wenn diese Begriffe in der Frage nicht vorkommen. Die KI erhält vollständigeren Kontext, ohne dass der Nutzer alle relevanten Begriffe kennen muss.

Semantische Anreicherung durch Glossare

Extrahierte Definitionen und Kernkonzepte lösen Mehrdeutigkeiten auf. Jeder Chunk wird mit den in ihm verwendeten Glossar-Begriffen verknüpft. Wenn die Suche nach "Pipeline" läuft, kann das System unterscheiden zwischen "CI/CD Pipeline" (DevOps-Kontext), "Data Pipeline" (ETL-Kontext) und "HTTP Request Pipeline" (Web-Framework-Kontext).

Diese semantische Ebene ergänzt die syntaktische Ähnlichkeitssuche mit bedeutungsorientierter Filterung. Das führt dazu, dass die Frage nicht mehr "was klingt ähnlich?" lautet, sondern "was bedeutet dasselbe?".

Validierung durch Konsolidierung

Wenn mehrere Seiten oder Dokumente analysiert werden, lassen sich die extrahierten Modelle zusammenführen und vergleichen. Widersprüche werden sichtbar: Dokument A behauptet X, Dokument B behauptet Y. Diese Konflikte können markiert und bei der Antwortgenerierung explizit kommuniziert werden ("Es gibt widersprüchliche Informationen zu diesem Thema").

Das ist ehrlicher als das Verhalten naiver Systeme, die entweder einen Widerspruch ignorieren (und zufällig eine der beiden Varianten wählen) oder versuchen, beide zu kombinieren (und dabei eine dritte, falsche Variante erfinden).

Hybrid-Search: Das Beste aus beiden Welten

Strukturierte Metadaten ermöglichen Kombination aus semantischer und strukturierter Suche. Queries wie "Finde Konzepte aus Kapitel 3, die mit Entity X verbunden sind und im Glossar als 'kritisch' markiert wurden" kombinieren drei Filterebenen:

Diese Kombination ist deutlich präziser als jede einzelne Methode allein.

Nachvollziehbarkeit: Provenance für jeden Chunk

Jedes Textfragment erhält Herkunftsinformationen: Von welcher Seite stammt es? Aus welchem Abschnitt? Welche verwandten Entitäten und Konzepte sind in der Nähe? Diese Provenance-Daten ermöglichen es, jede Antwort auf ihre exakte Quelle zurückzuverfolgen.

Das ist nicht nur für Compliance und Audit wichtig, sondern auch für die Nutzerakzeptanz: Menschen vertrauen Systemen mehr, die ihre Quellen offenlegen können.

Die konkrete Implementierung: 5-Stufen-Pipeline

Stufe 1: Konvertierung und Textextraktion

Dokumente kommen in verschiedenen Formaten: PDF, HTML, TXT, Markdown. Der erste Schritt konvertiert alle in ein einheitliches Format und extrahiert reinen Text mit Strukturinformationen (Überschriften, Listen, Tabellen bleiben als Metadaten erhalten, auch wenn sie zu Text werden).

Für PDFs nutzt die Pipeline pdfplumber, das nicht nur Text extrahiert, sondern auch Layout-Informationen bewahrt (welcher Text ist eine Überschrift, welcher ist normaler Absatz, welcher gehört zu einer Tabelle). Diese strukturellen Informationen werden später bei der Analyse genutzt, um Kontext zu verstehen.

Stufe 2: Seitenweise Analyse mit lokalen LLMs

Jede Seite wird einzeln an ein Sprachmodell übergeben, das drei Aufgaben erfüllt:

Die Modelle laufen lokal über Ollama, ohne Cloud-Kosten oder Datenschutz-Bedenken. Die Wahl unterschiedlicher Modelle basiert auf einem Trade-off: Taxonomie ist relativ einfach (hierarchische Einordnung), dafür reicht ein kleines, schnelles Modell. Ontologie und Semantik sind komplexer (Beziehungen und Bedeutungen erkennen), dafür kommt ein größeres Modell zum Einsatz.

Stufe 3: Quality Gates zwischen Stufen

Nach jeder LLM-Ausgabe laufen automatische Validierungen:

Wenn eine Validierung fehlschlägt, wird die Seite mit angepasstem Prompt erneut verarbeitet (maximal 3 Versuche). Das verhindert, dass fehlerhafte Daten in die Datenbank gelangen.

Stufe 4: Konsolidierung über gesamtes Dokument

Die seitenweisen Modelle werden zu einem Gesamt-Modell zusammengeführt. Das ist notwendig, weil Konzepte über mehrere Seiten verteilt sein können:

Diese Konsolidierung ist der Schritt, der naive Implementierungen nicht haben. Hier entsteht das kohärente Wissensmodell über das gesamte Dokument.

Stufe 5: Dual Storage mit Metadaten-Anreicherung

Die Chunks werden in zwei Datenbanken gespeichert:

Diese Dual-Storage-Architektur ermöglicht Hybrid-Search: Semantische Ähnlichkeit (ChromaDB) kombiniert mit strukturierter Filterung (MariaDB).

Messbare Verbesserungen

Retrieval-Qualität: Von 30-40% auf 70-85% Precision@5

Die Standard-Metrik für Retrieval-Qualität ist Precision@K: Von den Top-K gefundenen Ergebnissen, wie viele sind relevant? Bei K=5 (was typisch ist für RAG-Systeme) liegen naive Implementierungen bei 30-40% Precision. Das bedeutet: Von fünf Chunks sind ein bis zwei wirklich relevant, drei bis vier sind Rauschen.

Mit strukturierter Aufbereitung steigt diese Zahl auf 70-85% Precision@5. Das ist eine Verdopplung der Relevanz bei gleicher Chunk-Anzahl. Oder anders formuliert: Man kann mit drei Chunks die gleiche Qualität erreichen, für die naive Systeme sieben Chunks benötigen.

Diese Verbesserung hat praktische Konsequenzen: Weniger Chunks bedeuten kürzere Context-Windows für das LLM, was wiederum schnellere Antworten und niedrigere API-Kosten bedeutet (falls man Cloud-Modelle nutzt).

Halluzinations-Reduktion durch Provenance

Strukturierter Kontext mit Quellenangaben reduziert Halluzinationen aus zwei Gründen: Erstens erhält das Modell relevantere Informationen (weniger irrelevante Chunks = weniger Gelegenheit für Konfabulation). Zweitens kann das System explizit mitteilen, woher jede Information stammt, was das Modell "ehrlicher" macht ("laut Seite 15..." statt "ich denke...").

In der Praxis sinkt die Halluzinations-Rate erfahrungsgemäß von etwa 20-30% bei naiven Systemen auf unter 10% bei strukturierten Systemen (gemessen als "Aussagen, die nicht auf Quelldokumenten basieren").

Skalierbarkeit: Linear statt überproportional

Naive Systeme zeigen überproportionale Qualitäts-Degradation mit steigender Dokumentenzahl: Doppelt so viele Dokumente können zu deutlich mehr Falsch-Treffern führen (die Fehlerrate steigt schneller als die Datenmenge). Strukturierte Systeme zeigen lineare Skalierung: Doppelt so viele Dokumente bedeuten doppelt so viel Suchraum, aber die Metadaten-Filterung hält die Falsch-Treffer-Rate weitgehend konstant.

Das praktische Limit naiver Systeme liegt erfahrungsgemäß bei circa 1.000-2.000 Dokumenten (je nach Domäne). Strukturierte Systeme bleiben auch bei 10.000+ Dokumenten nutzbar, weil die Taxonomie-Filterung den Suchraum typischerweise um 90-95% reduziert.

Wiederverwendbarkeit: Artefakte jenseits von RAG

Die extrahierten Modelle haben Wert über RAG hinaus:

Diese Artefakte entstehen als "Nebenprodukt" der RAG-Vorbereitung, haben aber eigenständigen Nutzen.

Transparenz und Audit-Fähigkeit

Jede Antwort kann auf exakte Quellen zurückverfolgt werden: Welche Chunks wurden verwendet? Von welchen Seiten stammen sie? Welche Taxonomie-Kategorien sind beteiligt? Diese Transparenz ist kritisch für regulierte Branchen (Finance, Healthcare, Legal), wo Audit-Trails gesetzlich vorgeschrieben sind.

Systemische Langzeitwirkungen

Wissens-Graph über Dokumentensammlung

Wenn Du Ontologie-Daten aus 100 Dokumenten zusammenführst, entsteht ein unternehmensweiter Knowledge Graph. Entitäten, die in verschiedenen Dokumenten erwähnt werden, sind dieselben Knoten. Beziehungen werden verknüpft. Das Ergebnis ist eine Karte des organisatorischen Wissens.

Diese Karte zeigt Dinge, die in Einzeldokumenten nicht sichtbar sind: Welche Technologien werden am häufigsten verwendet? Welche Personen sind in den meisten Projekten involviert? Welche Konzepte tauchen überall auf (und sollten möglicherweise standardisiert werden)?

Taxonomie-Konvergenz: Vom Begriffschaos zur einheitlichen Sprache

Verschiedene Teams und Dokumente nutzen unterschiedliche Begriffe für gleiche Konzepte: "ML", "Machine Learning", "Maschinelles Lernen", "KI-Training". Durch Konsolidierung über viele Dokumente hinweg werden diese Varianten erkannt und zusammengeführt.

Das Ergebnis ist ein einheitliches Vokabular, das nicht top-down vorgeschrieben, sondern bottom-up aus den Dokumenten extrahiert wurde. Diese organisch gewachsene Taxonomie hat höhere Akzeptanz als ein künstlich definiertes Glossar, weil sie die tatsächlich verwendeten Begriffe widerspiegelt.

Dependency-Mapping: Versteckte Abhängigkeiten sichtbar machen

Ontologie-Beziehungen über viele Dokumente hinweg zeigen systemische Abhängigkeiten: "Funktion A benötigt Technologie B und C", "System X kommuniziert mit Y und Z", "Prozess P setzt Q voraus". Diese Informationen sind in Einzeldokumenten verstreut, werden aber durch Konsolidierung sichtbar.

Das ermöglicht Impact-Analyse: Was passiert, wenn Technologie B deprecated wird? Welche Funktionen sind betroffen? Welche Systeme müssen angepasst werden? Diese Fragen lassen sich aus dem Knowledge Graph beantworten, ohne alle Dokumente manuell durchsuchen zu müssen.

Konzept-Evolution: Wie sich Verständnis über Zeit ändert

Wenn Du Wissensmodelle versionierst (zum Beispiel monatliche Snapshots), kannst Du verfolgen, wie sich das organisatorische Verständnis entwickelt: Welche neuen Konzepte tauchen auf? Welche verschwinden? Wie ändern sich Beziehungen?

Das ist wertvoll für strategische Planung: Welche Technologien gewinnen an Bedeutung? Welche verlieren? Gibt es neue Abhängigkeiten, die Risiken darstellen? Diese Trends sind in versionierten Knowledge Graphs ablesbar.

Qualitätssicherung durch Struktur

Widersprüche zwischen Dokumenten werden automatisch sichtbar: Dokument A definiert Begriff X als Y, Dokument B als Z. Diese Inkonsistenzen können markiert und an die verantwortlichen Teams zurückgemeldet werden.

Das ist ehrlicher als das Verhalten naiver Systeme, die Widersprüche stillschweigend ignorieren oder durch "Averaging" (beide Definitionen kombinieren und etwas Neues erfinden) verschleiern.

Foundation für Automation

Strukturierte Wissensrepräsentation erlaubt automatische Entscheidungen ohne menschliche Intervention: Routing (welches Team ist zuständig?), Klassifikation (welcher Kategorie gehört dieses Ticket an?), Empfehlungen (welche Dokumente sind für diesen User relevant?).

Diese Automatisierung basiert auf expliziten Regeln (Taxonomie, Ontologie, Semantik), nicht auf Black-Box-ML-Modellen. Das macht sie nachvollziehbar, debugbar und anpassbar.

Organisatorisches Lernen: Von implizit zu explizit

Der tiefste Effekt ist kulturell: Strukturierte Wissensaufbereitung zwingt zur Auseinandersetzung mit dem eigenen Wissen. Was bedeuten unsere Begriffe wirklich? Wie hängen unsere Konzepte zusammen? Wo haben wir Widersprüche?

Organisationen, die diesen Prozess durchlaufen, entwickeln klarere mentale Modelle ihrer eigenen Arbeit. Implizites Expertenwissen (was nur einzelne Personen wissen) wird explizit und maschinenlesbar. Das reduziert Abhängigkeit von Einzelpersonen und macht Wissen skalierbar über Teams und Domänen hinweg.

Manche Organisationen empfinden das als unbequem, weil es Unklarheiten offenlegt. Andere sehen darin eine Chance für systematische Verbesserung. Das ist letztlich eine Frage der Kultur, nicht der Technologie.

Probiere es aus!

Lade ein eigenes Dokument (bis 2 MB) hoch oder verwende das Demo-Dokument.

Datei hochladen

PDF, TXT oder MD (max 2 MB)

LLM-Modell:

gemma3:4b-it-qat (schnell) gpt-oss:20b (ausführlich) Hochladen & Verarbeiten

Demo-Dokument

Mein Lieblings-Test-Dokument zum Thema Die Wirklichkeit emergenter Eigenschaften (Heidelberger)

Demo starten

Dokument:

Document ID: | Job ID:

Jetzt kommt die Validierung & Korrektur durch den Kritiker!

Die automatische Extraktion ist abgeschlossen. Jetzt bist Du dran.

Im Modul "Systemische Integration von KI in Unternehmensprozesse" haben wir die Wichtigkeit von Kritiker-Systemen kennengelernt: KI kann uns unterstützen, strukturieren und Vorschläge machen. Aber letzten Endes sind wir für die Einordnung, Validierung und Freigabe verantwortlich. Das ist keine lästige Pflicht, das ist eine Chance.

Wo menschliche Expertise die KI übertrifft

An genau dieser Stelle findet die Einordnung von Begriffen auf Basis der eigenen Fachexpertise statt. Die LLMs haben Taxonomien, Ontologien und Semantik-Modelle extrahiert, basierend auf allgemeinem Sprachwissen und Mustern im Dokument. Das ist ein solider Ausgangspunkt, aber es fehlt etwas Entscheidendes: domänenspezifisches Tiefenwissen.

Hier werden fachspezifische Begriffe geformt, die generelle KI-Systeme meist nicht kennen oder möglicherweise gar nicht kennen können. Ein Beispiel: In der Systemtheorie bedeutet "Emergenz" etwas anderes als in der Physik, in der Soziologie oder in der Informatik. Die KI erkennt das Wort, kann es taxonomisch einordnen, vielleicht sogar Beziehungen extrahieren. Aber die präzise fachliche Bedeutung in Deinem spezifischen Kontext? Die kennst nur Du.

Was Du jetzt validieren solltest

Scrolle nach oben zu den einzelnen Steps (11-15) und prüfe die extrahierten Ergebnisse:

  1. Entitäten (Step 11): Sind die erkannten Personen, Organisationen und Konzepte vollständig? Fehlen wichtige Akteure? Wurden unwichtige als wichtig markiert?
  2. Relationen (Step 12): Stimmen die Beziehungen zwischen Entitäten? Nutzt A wirklich B? Hängt C tatsächlich von D ab? Sind Abhängigkeiten korrekt erfasst oder wurden Zusammenhänge missverstanden?
  3. Taxonomie (Step 13): Ist die hierarchische Einordnung fachlich korrekt? Gehört "Konzept X" wirklich unter "Kategorie Y"? Oder würdest Du es anders strukturieren? Hier kannst Du die Taxonomie an Dein mentales Modell anpassen.
  4. Semantik (Step 14): Sind die extrahierten Definitionen präzise genug? Trifft die Bedeutungsbeschreibung den Kern? Oder fehlen Nuancen, die für Deine Domäne kritisch sind? Hier kannst Du Definitionen schärfen, ergänzen oder korrigieren.
  5. Konsolidierung (Step 15): Wurden Duplikate richtig zusammengeführt? Sind Varianten korrekt als Synonyme erkannt? Oder hat die KI zwei unterschiedliche Konzepte fälschlich gleichgesetzt?

Wo Einzigartigkeit entsteht

Durch diese Validierung und Korrektur entsteht etwas, das über automatische Extraktion hinausgeht: Domänenspezifisches, validiertes Wissen. Die Taxonomie spiegelt nicht nur das Dokument wider, sondern Dein Verständnis davon. Die Ontologie zeigt nicht nur erkannte Muster, sondern bestätigte Beziehungen. Die Semantik definiert nicht nur statistisch häufige Bedeutungen, sondern fachlich präzise Konzepte.

Hier entsteht Einzigartigkeit: Zwei Organisationen können dasselbe Dokument verarbeiten, aber durch unterschiedliche Validierung entstehen unterschiedliche Wissensmodelle. Das eine Team gewichtet Konzept A höher, das andere Team sieht Beziehung B als kritischer. Diese Unterschiede sind wertvoll, weil sie organisatorische Perspektiven explizit machen.

Hier entsteht Unterschiedlichkeit: Die extrahierten Modelle sind nicht generisch (wie ein Wikipedia-Artikel), sondern spezifisch für Deinen Kontext, Deine Sprache, Deine Prioritäten. Das macht RAG-Antworten später nicht nur korrekt, sondern relevant für Deine spezifische Anwendung.

Hier entsteht tiefes Wissen durch die präzise Zuordnung in Taxonomien (Wo gehört das wirklich hin?), Ontologien (Wie hängt das tatsächlich zusammen?) und die genaue Definition der Bedeutung (Was meinen wir wirklich, wenn wir "X" sagen?). Diese Präzision unterscheidet Expertensysteme von oberflächlichen Datenbanken.

Der Kritiker als Co-Architekt des Wissens

Die Rolle des Kritikers ist nicht, Fehler zu suchen. Die Rolle ist, Wissen zu formen. Die KI liefert Rohmaterial (extrahierte Strukturen), der Mensch formt es zu brauchbarem Wissen (validierte, kontextualisierte Modelle). Dieser Dialog zwischen automatischer Extraktion und menschlicher Expertise ist das, was strukturierte Wissensrepräsentation von bloßer Datensammlung unterscheidet.

Manche Teams überspringen diesen Schritt. Sie verlassen sich auf die automatische Extraktion, weil "die KI wird das schon richtig machen". Das funktioniert für generische Inhalte, versagt aber bei fachspezifischem Wissen. Andere Teams investieren hier Zeit und Aufmerksamkeit. Die Qualitätssteigerung ist messbar: RAG-Systeme mit validierten Modellen haben deutlich höhere Nutzerakzeptanz als solche mit roh extrahierten Strukturen.

Wichtig: Iterativer Prozess

Validierung ist kein einmaliger Schritt. Wenn neue Dokumente durch die Pipeline laufen, können sich Taxonomien erweitern, Ontologien wachsen, Semantik-Modelle verfeinern. Der Kritiker begleitet diesen Prozess kontinuierlich: Neue Kategorien werden geprüft, neue Beziehungen validiert, neue Definitionen geschärft.

Das ist organisatorisches Lernen in Aktion: Das Wissensmodell entwickelt sich mit der Organisation, wird präziser, umfassender, nützlicher.

Fragen zu Deinem Dokument

Nachdem Dein Dokument durch die Pipeline gelaufen ist, kannst Du nun Fragen dazu stellen. Das RAG-System (Retrieval Augmented Generation) kombiniert semantische Suche in ChromaDB mit LLM-basierter Antwortgenerierung.

Wie funktioniert RAG?

RAG (Retrieval Augmented Generation) kombiniert semantische Suche mit LLM-Generierung in 3 Phasen:

Phase 1: Semantische Suche (ChromaDB)

  1. Frage vektorisieren: Deine Frage wird mit mxbai-embed-large in einen 1024-dimensionalen Vektor umgewandelt
  2. Similarity-Search: ChromaDB durchsucht die Collection des Dokuments (doc2vector_doc_{id}) und findet die Top-K ähnlichsten Chunks via Cosine-Similarity
  3. Ergebnis: Die relevantesten Textfragmente werden zurückgegeben

Phase 2: Wissens-Anreicherung (MariaDB)

  1. Entitäten laden: Aus doc2vector_entities werden alle Entitäten des Dokuments abgerufen
  2. Relationen laden: Aus doc2vector_relationships werden Beziehungen zwischen Entitäten geladen
  3. Taxonomie laden: Aus doc2vector_taxonomy wird die hierarchische Struktur abgerufen
  4. Konzepte laden: Aus doc2vector_concepts werden semantische Definitionen geladen
  5. Ergebnis: Strukturiertes Wissen ergänzt die Textfragmente

Phase 3: LLM-Generierung

  1. Kontext aufbauen: Chunks aus ChromaDB + Wissen aus MariaDB werden kombiniert
  2. Prompt erstellen: System-Prompt + Kontext + Deine Frage
  3. LLM-Call: Das gewählte Modell (gemma3 oder gpt-oss) generiert die Antwort
  4. Quellenangabe: Verwendete Chunks werden mit Similarity-Score referenziert

Vorteil dieser Hybrid-Architektur: Semantische Vektorsuche (ChromaDB) findet ähnliche Texte, strukturiertes Wissen (MariaDB) liefert Kontext und Beziehungen. Das Ergebnis: Präzisere, faktenbasierte Antworten.

Konfiguration

Top-K Chunks

3 Chunks 5 Chunks 7 Chunks 10 Chunks Anzahl relevanter Chunks aus ChromaDBSimilarity Threshold

0.5 Minimale Cosine Similarity (0.0 - 1.0)Context anzeigen

Retrieved Chunks vor der Antwort anzeigen

Chat

gemma3:4b-it-qat (schnell) gpt-oss:20b

Chatverlauf löschen

Stelle Fragen zu Deinem hochgeladenen Dokument. Das System durchsucht die ChromaDB-Collection und generiert kontextbasierte Antworten.

Beispielfragen:

Fragen Tipp: Formuliere spezifische Fragen für bessere Ergebnisse

Technische Details: RAG-Pipeline

1. Query Embedding

query = "Was ist Emergenz?"
query_embedding = ollama.embeddings(
    model="mxbai-embed-large:latest",
    prompt=query
)  # → [1024 float values]

2. Semantic Search in ChromaDB

results = collection.query(
    query_embeddings=[query_embedding],
    n_results=5,  # Top-K
    where={"doc_id": "doc_691b8c4a2f3e1"}
)  # → Top-5 ähnlichste Chunks

3. Context Injection + LLM Generation

context = "\n\n".join([chunk["text"] for chunk in results])

prompt = f"""Beantworte die Frage basierend auf folgendem Kontext:

KONTEXT:
{context}

FRAGE: {query}

ANTWORT (mit Quellenangabe):"""

response = ollama.generate(
    model="gemma3:4b-it-qat",
    prompt=prompt
)

4. Response mit Quellen

{
  "answer": "Emergenz bezeichnet...",
  "sources": [
    {"page": 1, "chunk_id": "chunk_001", "similarity": 0.89},
    {"page": 1, "chunk_id": "chunk_002", "similarity": 0.82}
  ],
  "model": "gemma3:4b-it-qat",
  "chunks_retrieved": 5,
  "generation_time": 2.3
}

Wissensrepräsentation: Taxonomie

Kompakt Details

Eine Taxonomie ist eine hierarchische Ordnung von Konzepten, ähnlich wie ein Dateibaum auf Deinem Computer. Oben steht die Hauptkategorie (der Root-Ordner), darunter kommen Unterkategorien (Unterordner), und so weiter bis zu den einzelnen Konzepten (den Dateien).

Das Prinzip kennst Du aus dem Alltag: In einer Bibliothek stehen Bücher nicht zufällig herum, sondern sind klassifiziert: Sachbücher → Naturwissenschaften → Physik → Quantenmechanik. Dieser hierarchische Pfad gibt jedem Buch einen eindeutigen Kontext. "Wellen" im Physik-Regal bedeutet etwas anderes als "Wellen" im Friseur-Handbuch.

Für KI-Systeme funktioniert das genauso: Wenn ein Textfragment über "Python" in der Taxonomie unter "Programmierung → Sprachen → Python" eingeordnet ist, weiß die KI sofort: Hier geht es um die Programmiersprache, nicht um Reptilien oder Monty Python. Diese Eindeutigkeit ist der Grund, warum taxonomische Klassifikation die Retrieval-Präzision von 30% auf über 70% steigert.

Wie Taxonomie extrahiert wird

Die Pipeline nutzt ein lokales Sprachmodell (gemma3:4b), das jede Seite einzeln analysiert und fragt: Welche Hauptthemen werden hier behandelt? Wie hängen sie hierarchisch zusammen? Das Modell generiert eine Baumstruktur im JSON-Format, die dann validiert wird (sind alle Pflichtfelder da? Ist die Hierarchie logisch?).

Das Besondere: Jede Seite erhält ihr eigenes lokales Taxonomie-Modell. Später werden alle Seiten-Taxonomien zusammengeführt (konsolidiert). Ähnliche Kategorien werden zusammengelegt, Duplikate entfernt, Varianten erkannt ("Vektordatenbank", "Vector DB", "Embedding Store" werden zu einer Kategorie mit Alias).

Das Ergebnis ist ein kohärenter Wissensbaum über das gesamte Dokument, der als Metadaten an jeden Textchunk gehängt wird. Bei der Suche kann die KI dann gezielt filtern: "Zeige nur Chunks aus der Kategorie 'KI-Modelle → LLMs'", statt blind alle Chunks mit dem Wort "Modell" zu durchsuchen.

Warum Taxonomie allein nicht reicht

Taxonomie liefert hierarchische Einordnung, aber keine Beziehungen zwischen Konzepten. Sie sagt "Python ist eine Programmiersprache", aber nicht "Python wird oft mit Django kombiniert" oder "Python benötigt einen Interpreter". Diese Beziehungen liefert die Ontologie (das nächste Kapitel).

Taxonomie klärt auch nicht, was ein Begriff bedeutet. Sie ordnet "Embedding" unter "KI → Vektordatenbanken" ein, aber definiert nicht "Embedding = numerische Repräsentation von Text in hochdimensionalem Vektorraum". Diese Bedeutungsebene liefert die Semantik (das übernächste Kapitel).

Alle drei Modelle (Taxonomie, Ontologie, Semantik) ergänzen sich. Taxonomie ist die Grundstruktur, auf der die anderen aufbauen.

Eine Taxonomie ist ein hierarchisches Klassifikationssystem, das Konzepte in eine Baumstruktur einordnet. Jedes Konzept hat einen eindeutigen Pfad von der Wurzel (Root) zu seinem Blatt (Leaf), der seinen Kontext definiert.

Die Grundprinzipien taxonomischer Klassifikation

Taxonomien folgen einer simplen Logik: Von allgemein zu spezifisch. An der Wurzel steht die Hauptkategorie (beispielsweise "Dokumentverarbeitung"). Darunter kommen Unterkategorien (etwa "KI-Modelle", "Datenbanken", "Pipeline-Prozess"). Unter diesen wiederum weitere Unterkategorien, bis man bei den konkreten Konzepten ankommt.

Jedes Element im Baum hat zwei wesentliche Eigenschaften:

Diese hierarchische Struktur ermöglicht kontextuelle Disambiguierung: Ein Begriff erhält Bedeutung durch seinen Pfad. "Embedding" unter "KI → Vektordatenbanken → Techniken" ist etwas anderes als "Embedding" unter "Physik → Materialwissenschaft → Verfahren".

Warum hierarchische Klassifikation für RAG kritisch ist

Naive RAG-Implementierungen haben ein fundamentales Problem: Sie können Konzepte nicht einordnen. Wenn Du nach "Python" suchst, findet eine Volltext-Suche oder Vektor-Ähnlichkeitssuche alle Vorkommen des Wortes, unabhängig vom Kontext.

Das führt zu dem, was ich Context Pollution nenne: Die KI erhält Chunks über Python-Schlangen, Monty Python Sketche und Python-Programmierung durcheinandergewürfelt. Das Modell muss dann versuchen, aus diesem inkonsistenten Input eine kohärente Antwort zu generieren. Das geht meist schief.

Mit Taxonomie kannst Du gezielt filtern: "Zeige nur Chunks aus 'Programmierung → Sprachen → Python'". Das reduziert die Kandidatenmenge um 90-95% und erhöht gleichzeitig die Relevanz dramatisch. Von 500 Treffern bleiben 50 übrig, aber die passen.

LLM-basierte Taxonomie-Extraktion

Die Pipeline nutzt ein spezialisiertes Sprachmodell für Taxonomie-Extraktion: gemma3:4b-it-qat. Warum gerade dieses Modell? Es ist klein (4 Milliarden Parameter), schnell (unter 2 Sekunden pro Seite auf modernem Desktop) und trotzdem präzise für hierarchische Klassifikation.

Der Ablauf ist einfach: Jede Seite wird einzeln an das Modell übergeben mit dem Prompt "Erstelle hierarchische Taxonomie aus diesem Text". Das Modell analysiert den Inhalt, identifiziert Hauptthemen und strukturiert sie in eine Baumform. Die Ausgabe ist JSON, das sofort validiert wird.

Die Prompt-Strategie im Detail

Der Prompt für Taxonomie-Extraktion ist bewusst restriktiv gehalten, um konsistente Ergebnisse zu erzwingen:

Diese Constraints sind wichtig, weil LLMs ohne klare Vorgaben zu überdetaillierter oder inkonsistenter Klassifikation neigen. Das eine Modell erstellt 10 Ebenen, das andere nur 2. Das eine nutzt abstrakte Kategorien, das andere konkrete. Mit festen Regeln entstehen vergleichbare Taxonomien über alle Seiten hinweg.

Validierung nach Extraktion

Nach jeder LLM-Ausgabe laufen automatische Checks:

Wenn eine Validierung fehlschlägt, wird die Seite erneut verarbeitet mit angepasstem Prompt (maximal 3 Versuche). Erst wenn alles passt, geht die Taxonomie in die Konsolidierung.

Taxonomie-Konsolidierung: Von seitenweise zu dokumentweit

Jede Seite hat jetzt ihr eigenes Taxonomie-Modell. Das Problem: Diese Modelle sind inkonsistent. Seite 1 klassifiziert "Ollama" unter "Tools", Seite 10 unter "KI-Infrastruktur", Seite 15 unter "LLM-Runtime". Alle drei Varianten beschreiben dasselbe, nutzen aber unterschiedliche Begriffe und Hierarchien.

Die Konsolidierung löst das mit einem zweiten LLM-Call (dieses Mal gpt-oss:20b, weil Zusammenführung komplexer ist als Extraktion). Das Modell erhält alle seitenweisen Taxonomien und die Aufgabe: "Finde Gemeinsamkeiten, führe Varianten zusammen, erstelle einheitliche Hierarchie".

Fuzzy-Matching für Synonyme und Varianten

Das Konsolidierungs-Modell erkennt semantisch ähnliche Begriffe automatisch:

Diese Varianten werden als Synonyme unter einer primären Bezeichnung konsolidiert. Die Wahl der primären Bezeichnung folgt einer Heuristik: Die häufigste Variante wird bevorzugt, außer eine andere ist deutlich präziser. Zum Beispiel "Large Language Model" statt "LLM", weil vollständig.

Hierarchie-Zusammenführung

Wenn verschiedene Seiten unterschiedliche Hierarchien vorschlagen, muss das Modell entscheiden, welche Struktur die beste ist. Beispiel:

Das Konsolidierungs-Modell wählt die präziseste Hierarchie basierend auf Kontext: "Ollama" ist primär ein LLM-Werkzeug, also gehört es unter "KI → LLMs → Runtime". Die anderen Kategorisierungen werden als "alternative Pfade" gespeichert, sind aber nicht primär.

Referenzen und Provenance

Während der Konsolidierung gehen keine Informationen verloren: Jede Kategorie merkt sich, auf welchen Seiten sie vorkommt. Wenn "Ollama" auf Seite 1, 5 und 10 erwähnt wird, enthält die finale Taxonomie diese Referenzen.

Das ermöglicht Queries wie "Zeige Seiten, auf denen 'KI-Modelle → LLMs' behandelt wird" oder "Auf welchen Seiten wird die Kategorie 'Datenbanken' erwähnt?". Diese Provenance-Informationen machen die Taxonomie zu mehr als nur einer Klassifikation. Sie wird zur Navigation durch das Dokument.

Speicherung in MariaDB

Die konsolidierte Taxonomie wird in der MariaDB-Tabelle classes gespeichert. Jede Kategorie ist eine Zeile mit folgenden Feldern:

Die Hierarchie wird über parent_id-Referenzen abgebildet. Das ermöglicht rekursive SQL-Queries, die den gesamten Pfad von einem Blatt zur Wurzel rekonstruieren oder alle Unterkategorien einer Kategorie finden.

Praktischer Nutzen für RAG-Systeme

Wenn die Taxonomie als Metadaten an jeden Chunk gehängt wird, kannst Du taxonomie-basierte Filterung nutzen:

Das ist der Unterschied zwischen Volltext-Suche (findet "Python" überall, 500 Treffer) und taxonomischer Filterung (findet "Python" nur in relevanter Kategorie, 50 Treffer). Die Präzision steigt, die Menge sinkt, die Relevanz steigt.

Taxonomie vs. Volltext: Ein Vergleich

Warum Volltext allein nicht reicht

Volltext-Suche findet Wörter, Taxonomie findet Konzepte. Ein praktischer Vergleich:

  • Volltext-Query "Python": 500 Treffer (Programmiersprache, Reptil, Comedy-Gruppe, Python-Bibliotheken, Python-Frameworks, Python-Tutorials)
  • Taxonomie-Query "Programmierung → Sprachen → Python": 50 Treffer (alle relevant für Python-Programmierung)

Das Problem verschärft sich bei Synonymen: Volltext braucht separate Queries für "Vektordatenbank", "Vector DB", "Embedding Store". Taxonomie hat alle unter einer Kategorie konsolidiert. Eine Query reicht.

JSON-Struktur der extrahierten Taxonomie

Die Taxonomie wird als verschachteltes JSON gespeichert. Hier ein Beispiel aus einem tatsächlich verarbeiteten Dokument über die doc2vector Pipeline:

{
  "taxonomy": "doc2vector Technical Documentation",
  "root": {
    "name": "Dokumentverarbeitung",
    "description": "Gesamtsystem zur semantischen Dokumentanalyse",
    "children": [
      {
        "name": "KI-Modelle",
        "description": "Lokal laufende LLMs und Embedding-Modelle",
        "children": [
          {
            "name": "LLMs",
            "description": "Large Language Models für Extraktion",
            "children": [
              {
                "name": "gemma3:4b-it-qat",
                "description": "Schnelles Modell für Taxonomie"
              },
              {
                "name": "gpt-oss:20b",
                "description": "Komplexes Modell für Ontologie/Semantik"
              }
            ]
          },
          {
            "name": "Embedding-Modelle",
            "description": "Vektorisierung für semantische Suche",
            "children": [
              {
                "name": "mxbai-embed-large",
                "description": "1024-dim Embeddings, DE/EN optimiert"
              }
            ]
          }
        ]
      },
      {
        "name": "Datenbanken",
        "description": "Speicher-Schichten für Vektoren und Metadaten",
        "children": [
          {
            "name": "ChromaDB",
            "description": "Vektordatenbank für Embeddings",
            "properties": ["API v2", "HttpClient", "Collection-basiert"]
          },
          {
            "name": "MariaDB",
            "description": "Relationale DB für strukturierte Metadaten",
            "properties": ["8 Tabellen", "ACID", "Joins möglich"]
          }
        ]
      }
    ]
  }
}

Diese Struktur zeigt auf einen Blick: Das Dokument behandelt Dokumentverarbeitung mit zwei Hauptaspekten, nämlich KI-Modelle und Datenbanken. Unter KI-Modelle fallen LLMs und Embedding-Modelle. Unter Datenbanken ChromaDB und MariaDB. Jedes Element hat eine präzise Beschreibung.

Die Prompting-Strategie für konsistente Extraktion

Damit verschiedene Seiten vergleichbare Taxonomien liefern, braucht es einen präzisen, restriktiven Prompt. Hier der tatsächlich verwendete Prompt (leicht vereinfacht):

SYSTEM_PROMPT = """Du bist ein Experte für hierarchische Klassifikation.
Erstelle aus dem folgenden Text eine Taxonomie.

REGELN:
- Root = Hauptkategorie (1 Wort, prägnant)
- Jede Kategorie hat: name, description
- Hierarchie-Tiefe: max. 4 Ebenen
- Nur konkrete Konzepte (keine abstrakten Meta-Kategorien)
- JSON-Format (validierbar)

OUTPUT-FORMAT:
{
  "root": {
    "name": "Hauptkategorie",
    "description": "...",
    "children": [...]
  }
}

Text:
{page_text}

Antworte NUR mit JSON."""

Dieser Prompt erzwingt Konsistenz durch klare Constraints. Das Modell kann nicht "kreativ" werden oder eigene Strukturen erfinden, es muss sich an die Vorgaben halten.

Validierung: Drei Ebenen der Qualitätssicherung

Nach jeder Taxonomie-Extraktion laufen automatische Validierungen:

Ebene 1: Syntaktische Validierung

Ist die Ausgabe überhaupt valides JSON? Klingt trivial, aber LLMs produzieren manchmal fast-korrektes JSON mit subtilen Fehlern (fehlende Kommata, unkorrekte Escaping). Ein simpler json.loads()-Try-Catch fängt das ab.

Ebene 2: Schema-Validierung

Hat das JSON die erwartete Struktur? Existiert root? Hat jeder Knoten name und description? Sind children (falls vorhanden) ein Array? Diese strukturelle Validierung stellt sicher, dass downstream-Prozesse sich auf feste Felder verlassen können.

Ebene 3: Semantische Validierung

Ist die Hierarchie logisch? Gibt es Duplikate auf gleicher Ebene? Sind die Beschreibungen aussagekräftig (mindestens 10 Zeichen)? Ist die Tiefe im erlaubten Bereich (maximal 4 Ebenen)? Diese Checks verhindern sinnlose oder überdetaillierte Taxonomien.

Wenn eine Validierung fehlschlägt, wird die Extraktion wiederholt mit ergänztem Prompt: "Vorheriger Versuch ungültig wegen [Fehler]. Bitte korrigieren." Das funktioniert in circa 90% der Fälle. Die restlichen 10% werden manuell überprüft.

Konsolidierung über alle Seiten: Das Puzzle zusammensetzen

Wenn alle Seiten ihre lokalen Taxonomien haben, beginnt der spannendste Schritt: Die dokumentweite Konsolidierung. Ein zweites, größeres Modell (gpt-oss:20b) erhält alle Seiten-Taxonomien und führt sie zusammen.

Schritt 1: Gemeinsame Wurzeln finden

Verschiedene Seiten haben möglicherweise unterschiedliche Root-Kategorien. Seite 1: "Dokumentverarbeitung", Seite 5: "KI-Pipeline", Seite 10: "Wissensextraktion". Das Modell erkennt: Alle drei beschreiben dasselbe System aus verschiedenen Blickwinkeln. Die finale Root wird zum umfassendsten Begriff: "Dokumentverarbeitung".

Schritt 2: Duplikate deduplizieren

Wenn "Ollama" in 5 verschiedenen Taxonomien auftaucht, wird es zu einem Eintrag zusammengeführt. Die Beschreibungen werden verglichen, die präziseste wird übernommen. Die Seiten-Referenzen (auf welchen Seiten kommt "Ollama" vor?) werden alle behalten.

Schritt 3: Hierarchien vereinigen

Unterschiedliche hierarchische Pfade werden zusammengeführt. Wenn Seite 1 "Ollama" unter "Tools" einordnet und Seite 10 unter "KI-Infrastruktur → LLM-Runtime", muss das Modell entscheiden: Was ist die bessere Einordnung?

Die Entscheidung basiert auf Kontexthäufigkeit: Wenn "Ollama" in den meisten Kontexten als LLM-Runtime verwendet wird (nicht als generisches Werkzeug), gewinnt die spezifischere Kategorisierung. Die alternative Einordnung wird als "alias_paths" gespeichert; sie geht nicht verloren, ist nur nicht primär.

Schritt 4: Best Description Selection

Jede Kategorie hat möglicherweise mehrere Beschreibungen aus verschiedenen Seiten. Das Modell wählt die präziseste, vollständigste Beschreibung. Beispiel:

Die finale Beschreibung kombiniert die besten Aspekte: "1024-dim Embeddings, DE/EN optimiert". Kurz, präzise, informativ.

Taxonomie in Aktion: Praktische Anwendungsfälle

Use Case 1: Taxonomie-basierte Filterung

Statt "Suche alle Chunks mit 'Modell'" (vage, viele False Positives) kannst Du fragen: "Zeige alle Chunks aus Kategorie 'KI-Modelle → LLMs'". Das ist eine strukturierte Abfrage in MariaDB, kombiniert mit Vektor-Suche in ChromaDB.

Der Unterschied: Von 1.000 Chunks mit dem Wort "Modell" bleiben 80 Chunks übrig, die wirklich zu LLMs gehören. Die Retrieval-Präzision steigt von circa 35% auf über 75%.

Use Case 2: Hierarchisches Browsen

Taxonomie ermöglicht Navigation statt nur Suche. Ein Nutzer kann den Wissensbaum explorieren:

An jedem Punkt werden relevante Chunks angezeigt. Der Nutzer kann die Hierarchie hinauf- und hinabsteigen, ohne Suchbegriffe formulieren zu müssen. Das ist besonders wertvoll für explorative Fragen ("Was gibt es alles zu KI-Modellen?").

Use Case 3: Kontext-Injektion für bessere LLM-Antworten

Wenn ein Chunk an das LLM übergeben wird, kann der Taxonomie-Pfad mitgeliefert werden:

Kontext: Dieser Text stammt aus der Kategorie "Programmierung → Sprachen → Python"
Frage: Wie funktioniert Caching?
Text: [Chunk über Python-Caching]

Antwort: In Python nutzt Du das functools-Modul...

Der Taxonomie-Pfad gibt dem Modell domänenspezifischen Kontext, ohne dass dieser im Chunk selbst stehen muss. Das reduziert Mehrdeutigkeiten und verbessert die Antwortqualität.

Grenzen der Taxonomie: Was sie nicht kann

Taxonomie ist mächtig, aber nicht allmächtig. Sie hat systematische Limitationen:

Keine Beziehungen zwischen Kategorien

Taxonomie sagt Dir, dass "Python" und "Django" beide unter "Programmierung" fallen, aber nicht, dass Django ein Python-Framework ist. Diese Beziehung ("Django basiert_auf Python") ist nicht hierarchisch, sondern lateral, die Knoten auf gleicher oder verschiedener Ebene verbindet.

Für solche Beziehungen brauchst Du Ontologie (das nächste Kapitel). Ontologie ergänzt die Baum-Struktur mit einem Beziehungs-Graphen.

Keine Bedeutungsdefinitionen

Taxonomie ordnet "Embedding" unter "KI → Vektordatenbanken" ein, aber sie definiert nicht, was ein Embedding ist. Die Description ("Vektorisierung für semantische Suche") ist eine grobe Einordnung, keine präzise Definition.

Für Definitionen, Kernkonzepte und Glossare brauchst Du Semantik (das übernächste Kapitel). Semantik liefert die Bedeutungsebene, die Taxonomie nicht hat.

Mehrfach-Kategorisierung ist schwierig

Manche Konzepte gehören in mehrere Kategorien gleichzeitig. "Docker" ist sowohl ein Werkzeug (Programmierung → Tools) als auch eine Infrastruktur-Komponente (DevOps → Container-Runtime). In einer Baumstruktur muss man sich für einen primären Pfad entscheiden.

Die Lösung ist alternative Pfade (alias_paths), aber die machen die Taxonomie komplexer. In der Praxis hält man die Taxonomie meist einfach und nutzt Ontologie für Multi-Kategorisierung ("Docker has_role Werkzeug", "Docker has_role Infrastructure").

Praktisches Beispiel: Extrahierte Taxonomie aus 6-Seiten-Dokument

Hier die tatsächlich extrahierte und konsolidierte Taxonomie eines kleinen Testdokuments über die doc2vector Pipeline:

Extrahierte Taxonomie (hierarchische Darstellung)

Dokumentverarbeitung
├── KI-Modelle
│   ├── LLMs
│   │   ├── gemma3:4b-it-qat (Taxonomie)
│   │   └── gpt-oss:20b (Ontologie, Semantik)
│   └── Embedding-Modelle
│       └── mxbai-embed-large (1024-dim)
├── Datenbanken
│   ├── ChromaDB (Vektordatenbank, API v2)
│   └── MariaDB (8 Tabellen, strukturiert)
├── Wissensrepräsentation
│   ├── Taxonomie (hierarchisch)
│   ├── Ontologie (Beziehungen)
│   └── Semantik (Bedeutung)
└── Pipeline-Prozess
    ├── Konvertierung (PDF/HTML/TXT/MD)
    ├── Extraktion (seitenweise)
    ├── Konsolidierung (dokumentweit)
    └── Speicherung (Dual Storage)

Ergebnis: Klare hierarchische Struktur zeigt Dokumentinhalt auf einen Blick. Jede Kategorie ist eindeutig eingeordnet, Duplikate sind konsolidiert, Beschreibungen sind präzise.

Integration mit ChromaDB: Taxonomie als Chunk-Metadaten

Die extrahierte Taxonomie wird nicht nur in MariaDB gespeichert, sondern auch als Metadaten an jeden Chunk gehängt. Wenn ein Textfragment in ChromaDB gespeichert wird, erhält es zusätzlich zu seinem Embedding-Vektor auch taxonomische Informationen:

{
  "chunk_id": "doc_123_page_5_chunk_2",
  "text": "Ollama ist eine Runtime für lokale LLMs...",
  "embedding": [0.123, -0.456, ...],  // 1024 Dimensionen
  "metadata": {
    "taxonomy_path": "Dokumentverarbeitung → KI-Modelle → LLMs",
    "taxonomy_category": "LLMs",
    "taxonomy_root": "Dokumentverarbeitung",
    "page": 5,
    "position": 2
  }
}

Diese Metadaten ermöglichen Hybrid-Queries, die semantische Suche mit taxonomischer Filterung kombinieren: "Finde semantisch ähnliche Chunks zu 'lokale Modelle', aber nur aus Kategorie 'KI-Modelle → LLMs'". ChromaDB durchsucht die Embeddings, filtert aber gleichzeitig nach Taxonomie-Metadaten.

Skalierung: Was passiert bei 100 Dokumenten?

Wenn Du nicht ein, sondern 100 Dokumente durch die Pipeline laufen lässt, entstehen 100 dokumentspezifische Taxonomien. Diese können übergreifend konsolidiert werden, um eine unternehmensweite Taxonomie zu schaffen.

Das Prinzip bleibt gleich (Fuzzy-Matching, Hierarchie-Zusammenführung, Duplikate deduplizieren), aber die Skala ändert sich: Statt "Seite 1 sagt X, Seite 10 sagt Y" ist es jetzt "Dokument A sagt X, Dokument B sagt Y". Das Ergebnis ist eine konvergierte Taxonomie, die die tatsächlich verwendeten Begriffe und Hierarchien widerspiegelt.

Diese organisch gewachsene Struktur hat einen entscheidenden Vorteil gegenüber top-down definierten Taxonomien: Sie spiegelt die reale Begriffsverwendung wider, nicht ein theoretisches Idealmodell. Das erhöht die Akzeptanz bei den Nutzern, weil die Taxonomie ihre Sprache spricht.

Taxonomie als Grundlage für Ontologie und Semantik

Taxonomie ist die erste Schicht der Wissensrepräsentation. Sie liefert die hierarchische Grundstruktur, auf der die anderen Modelle aufbauen:

Ohne Taxonomie würden Ontologie und Semantik im luftleeren Raum schweben. Die Taxonomie ist das Koordinatensystem, in dem alle anderen Modelle operieren.

Wissensrepräsentation: Ontologie

Kompakt Details

Während die Taxonomie eine Baumstruktur ist (alles hat seinen festen hierarchischen Platz), ist eine Ontologie ein Netzwerk. Sie definiert Entitäten (Dinge, die es gibt) und Beziehungen (wie diese Dinge zusammenhängen). Das kennst Du von sozialen Netzwerken: Menschen (Entitäten) sind miteinander verbunden (Beziehungen), und diese Verbindungen haben verschiedene Typen (Freund, Kollege, Familie).

In technischen Dokumenten funktioniert das genauso: "Ollama" (eine Software) nutzt "gemma3:4b" (ein Sprachmodell), "doc2vector Pipeline" benötigt "ChromaDB" (eine Datenbank), "mxbai-embed-large" ist ein Embedding-Modell. Diese Beziehungen sind nicht hierarchisch. Sie verbinden Konzepte lateral, quer durch alle Ebenen.

Der praktische Nutzen: Wenn Du nach "Ollama" suchst, kann das System automatisch verwandte Entitäten mit abrufen. Es weiß aus der Ontologie: "Ollama nutzt gemma3 und gpt-oss, läuft auf localhost, wird von doc2vector Pipeline verwendet". Diese Beziehungen liefern Kontext, den die Taxonomie nicht hat.

Unterschied zur Taxonomie

Taxonomie fragt: "Was ist übergeordnet?" (Python gehört zu Programmiersprachen). Ontologie fragt: "Wie hängt das zusammen?" (Python wird genutzt von Django, konkurriert mit JavaScript, hat die Eigenschaft "dynamisch typisiert").

Ein konkretes Beispiel: Taxonomie ordnet "Docker" unter "DevOps → Tools" ein. Ontologie ergänzt: "Docker benötigt Linux-Kernel, wird genutzt von Kubernetes, konkurriert mit Podman, läuft auf Server X". Diese Beziehungen machen aus einer simplen Einordnung ein Netzwerk von Abhängigkeiten.

Beide Modelle ergänzen sich: Taxonomie liefert die hierarchische Grundstruktur, Ontologie verbindet die Konzepte quer durch diese Struktur. Zusammen ergeben sie ein vollständigeres Bild als jedes Modell allein.

Wie Ontologie extrahiert wird

Die Pipeline nutzt ein größeres Sprachmodell (gpt-oss:20b) für Ontologie-Extraktion, weil Beziehungserkennung komplexer ist als hierarchische Einordnung. Das Modell analysiert jede Seite und fragt: Welche Dinge werden erwähnt? Wie hängen sie zusammen? Welche Eigenschaften haben sie?

Die Ausgabe ist JSON mit zwei Teilen: entities (Liste aller Entitäten mit Typ, Beschreibung und Eigenschaften) und relationships (Liste aller Beziehungen zwischen Entitäten). Diese Struktur wird validiert und später über alle Seiten hinweg konsolidiert, ähnlich wie bei der Taxonomie.

Das Besondere: Während der Konsolidierung entstehen transitive Beziehungen. Wenn Seite 3 sagt "A nutzt B" und Seite 7 sagt "B benötigt C", erkennt das System: "A hängt indirekt von C ab". Diese Dependency-Ketten sind wertvoll für Impact-Analyse ("Was passiert, wenn C ausfällt?").

Praktischer Nutzen für RAG

Ontologie ermöglicht kontextuelle Retrieval-Expansion: Wenn Du nach "Ollama" fragst, kann das System automatisch verwandte Entitäten mit abrufen (gemma3, gpt-oss, mxbai-embed-large), weil die Ontologie diese Beziehungen kennt. Die KI erhält vollständigeren Kontext, ohne dass Du alle Begriffe in Deine Frage packen musst.

Ein zweiter Nutzen: Dependency-basierte Suche. Fragen wie "Was benötigt ChromaDB?" oder "Welche Technologien hängen von Ollama ab?" können direkt aus dem Ontologie-Graphen beantwortet werden. Diese Informationen sind in unstrukturierten Texten verstreut, werden aber durch Ontologie-Extraktion explizit und abfragbar.

Eine Ontologie ist ein formales Beziehungsmodell, das definiert, welche Dinge (Entitäten) es gibt, wie sie zusammenhängen (Relationen) und welche Eigenschaften sie haben (Attribute). Während Taxonomie eine Baumstruktur mit fester Hierarchie ist, ist Ontologie ein Graph mit flexiblen, gerichteten Verbindungen.

Die Grundprinzipien ontologischer Modellierung

Ontologien basieren auf drei Konzepten:

Diese drei Elemente bilden einen gerichteten, gelabelten Graphen. Knoten sind Entitäten, Kanten sind Beziehungen mit Typ-Labels. Im Gegensatz zur Taxonomie gibt es keine feste Hierarchie. Stattdessen gibt es flexible Verbindungen, die auch zwischen Ebenen oder lateral verlaufen können.

Warum Ontologie für RAG kritisch ist

Taxonomie allein hat eine systematische Limitierung: Sie kann Konzepte einordnen, aber nicht verbinden. Wenn Du nach "BERT" suchst, liefert Taxonomie die Einordnung "KI → NLP → Sprachmodelle → BERT". Das ist wertvoll, aber unvollständig.

Ontologie ergänzt: "BERT basiert-auf Transformer-Architektur, nutzt Attention-Mechanismus, wurde-entwickelt-von Google, hat-Varianten RoBERTa und ALBERT". Diese Beziehungen liefern Kontext, der für eine vollständige Antwort auf "Wie funktioniert BERT?" notwendig ist.

Ohne Ontologie muss die KI diese Zusammenhänge aus dem Text erraten. Mit Ontologie sind sie explizit und können automatisch in die Suche einbezogen werden. Das ist der Unterschied zwischen "finde Text über BERT" (isoliert) und "finde Text über BERT und seine Dependencies" (kontextuell vollständig).

Entity-Typen: Die Dinge, die es gibt

Die Pipeline klassifiziert Entitäten in sechs Standard-Typen, weil unterschiedliche Entitäts-Typen unterschiedlich behandelt werden müssen:

Person

Menschen, die in Dokumenten erwähnt werden: Autoren, Entwickler, Forscher, Experten. Beispiele: "Karl Kratz", "Linus Torvalds", "Geoffrey Hinton". Properties können sein: Rolle, Organisation, Expertise-Bereich.

Organisation

Firmen, Institutionen, Open-Source-Projekte, Abteilungen. Beispiele: "Anthropic", "Linux Foundation", "Mixedbread AI". Properties können sein: Branche, Größe, Standort, Gründungsjahr.

Konzept

Abstrakte Ideen, Methoden, Prinzipien, Paradigmen. Beispiele: "RAG" (Retrieval Augmented Generation), "Semantic Search", "Embedding", "Supervised Learning". Properties können sein: Definition, Anwendungsbereich, verwandte Konzepte.

Technologie

Software, Tools, Frameworks, Bibliotheken, Hardware. Beispiele: "Ollama", "ChromaDB", "mxbai-embed-large", "pdfplumber". Properties können sein: Version, Lizenz, Sprache, Plattform.

Ort

Server, Standorte, Verzeichnisse, URLs. Beispiele: "localhost", "/var/www/doc2vector", "localhost:8000". Properties können sein: IP-Adresse, Region, Verfügbarkeit.

Datum

Zeitpunkte, Deadlines, Versionen, Events. Beispiele: "2025-11-17", "ChromaDB API v2", "Python 3.13 Release". Properties können sein: Zeitzone, Format, Kontext.

Diese Typisierung ermöglicht typ-spezifische Queries: "Zeige alle Technologien" oder "Welche Personen werden in diesem Dokument erwähnt?". Ohne Typen wären alle Entitäten eine undifferenzierte Menge.

Relationship-Typen: Wie Dinge zusammenhängen

Beziehungen haben Typen, weil unterschiedliche Beziehungen unterschiedliche semantische Bedeutung haben. Die Pipeline nutzt sieben Standard-Relationship-Typen:

Diese Typisierung ermöglicht Relationship-basierte Queries: "Welche Technologien nutzen Ollama?" (Query nach "uses"-Beziehungen) oder "Was hängt von ChromaDB ab?" (Query nach "depends-on"-Beziehungen mit ChromaDB als Ziel).

LLM-basierte Ontologie-Extraktion

Für Ontologie kommt ein größeres Modell zum Einsatz (gpt-oss:20b statt gemma3:4b), weil Beziehungserkennung komplexere Reasoning-Fähigkeiten erfordert. Das Modell muss nicht nur Konzepte identifizieren (das kann auch ein kleineres Modell), sondern auch verstehen, wie sie zusammenhängen.

Der Ablauf: Jede Seite wird analysiert mit dem Prompt "Extrahiere Entitäten und ihre Beziehungen". Das Modell liefert JSON mit zwei Arrays: entities (name, type, description, properties) und relationships (from, to, relationship, type).

Nach der Extraktion läuft eine Validierung, die prüft: Referenzieren alle Beziehungen existierende Entitäten? Haben alle Entitäten einen Typ? Sind die Properties valide Key-Value-Paare? Nur wenn diese Checks bestanden sind, geht die Ontologie in die Konsolidierung.

Ontologie-Konsolidierung: Entitäten zusammenführen

Genau wie bei der Taxonomie hat jede Seite ihr eigenes lokales Ontologie-Modell. Diese Modelle müssen zusammengeführt werden, weil dieselbe Entität auf verschiedenen Seiten unterschiedlich erwähnt wird:

Die Konsolidierung erkennt: Alle drei meinen dasselbe. Die Entitäten werden zusammengeführt, die Properties werden aggregiert (port, models, location landen alle in einer Entity). Die beste Bezeichnung wird gewählt ("Ollama" statt "ollama" oder "Ollama-Server").

Für Beziehungen gilt dasselbe: Wenn mehrere Seiten dieselbe Beziehung erwähnen ("Ollama uses gemma3"), wird sie nur einmal gespeichert, aber mit Referenzen auf alle Seiten, auf denen sie vorkommt.

Dependency-Graphen und transitive Beziehungen

Das Spannende an Ontologien: Sie ermöglichen Reasoning über mehrere Schritte. Wenn "A nutzt B" und "B benötigt C", dann hängt A indirekt von C ab. Diese transitiven Abhängigkeiten werden während der Konsolidierung automatisch erkannt und als Dependency-Ketten gespeichert.

Ein praktisches Beispiel: "doc2vector Pipeline" nutzt "Ollama", "Ollama" nutzt "gemma3:4b". Daraus folgt: Die Pipeline hängt indirekt von gemma3 ab. Wenn gemma3 nicht verfügbar ist, kann die Pipeline nicht laufen. Diese Kette ist in Einzeltexten nicht explizit erwähnt, wird aber durch Ontologie-Reasoning sichtbar.

Praktischer Nutzen für RAG

Ontologie macht RAG-Systeme kontextuell intelligenter. Drei konkrete Anwendungsfälle:

Das ist der Unterschied zwischen naivem RAG (sucht nur nach Wort-Ähnlichkeit) und ontologie-angereichertem RAG (versteht Zusammenhänge und erweitert Kontext automatisch).

Eine Ontologie ist ein formales Modell einer Domäne, das Entitäten, ihre Beziehungen und Eigenschaften explizit definiert. In der Informatik werden Ontologien genutzt, um Wissen maschinenlesbar und logisch abfragbar zu machen.

Der fundamentale Unterschied zur Taxonomie

Taxonomien und Ontologien lösen unterschiedliche Probleme:

Taxonomie vs. Ontologie

Fragestellung Taxonomie Ontologie
Was ist übergeordnet? ✓ (Hierarchie) ✗ (keine Hierarchie)
Wie hängt das zusammen? ✗ (nur Einordnung) ✓ (Beziehungen)
Welche Eigenschaften hat X? ✗ (keine Properties) ✓ (Properties definiert)
Kategorien filtern ✓ (Hierarchie) ✗ (Graph, nicht Baum)
Dependencies verstehen ✗ (keine Relationen) ✓ (depends-on, uses)

Fazit: Taxonomie für Einordnung, Ontologie für Beziehungen. Beide zusammen für vollständige Wissensrepräsentation.

Ein praktisches Beispiel verdeutlicht den Unterschied: Taxonomie sagt "Docker gehört zu DevOps → Tools". Ontologie ergänzt: "Docker benötigt Linux-Kernel, wird genutzt von Kubernetes, konkurriert mit Podman, hat die Eigenschaft 'Container-Runtime', läuft auf Server X, Y und Z".

Die Taxonomie gibt hierarchischen Kontext, die Ontologie gibt relationalen Kontext. Beides zusammen ergibt ein vollständigeres Bild als jedes Modell allein.

Entity-Typen im Detail

Die Pipeline unterscheidet sechs Entity-Typen, weil unterschiedliche Typen unterschiedliche Properties und Beziehungen haben:

Person (Typ: Menschen)

Personen, die in Dokumenten erwähnt werden: Autoren, Entwickler, Forscher, Experten, Stakeholder. Typische Properties: role (Rolle), affiliation (Organisation), expertise (Fachgebiet), contact (Kontaktinfo).

Typische Beziehungen: works-for (arbeitet für Organisation), created (hat erschaffen), contributes-to (trägt bei zu Projekt), collaborates-with (arbeitet zusammen mit).

Organisation (Typ: Institutionen)

Firmen, Institutionen, Open-Source-Projekte, Teams. Typische Properties: industry (Branche), size (Größe), location (Standort), founded (Gründungsjahr).

Typische Beziehungen: owns (besitzt Technologie), develops (entwickelt Produkt), partners-with (kooperiert mit), acquires (übernimmt).

Konzept (Typ: Abstrakte Ideen)

Ideen, Methoden, Prinzipien, Paradigmen, die nicht physisch existieren. Beispiele: "RAG", "Semantic Search", "Embedding", "Supervised Learning", "KISS-Prinzip". Typische Properties: definition, domain (Anwendungsbereich), complexity.

Typische Beziehungen: is-instance-of (ist Beispiel für), requires (benötigt Vorwissen), contradicts (widerspricht), extends (erweitert).

Technologie (Typ: Software/Hardware)

Konkrete technische Artefakte: Software, Tools, Frameworks, Bibliotheken, Hardware-Komponenten. Beispiele: "Ollama", "ChromaDB", "mxbai-embed-large", "pdfplumber", "NVIDIA A100".

Typische Properties: version, license, language, platform, size, port.

Typische Beziehungen: depends-on (benötigt andere Technologie), is-compatible-with (kompatibel mit), replaces (ersetzt), integrates-with (integriert mit).

Ort (Typ: Locations)

Physische oder virtuelle Orte: Server, Standorte, Verzeichnisse, URLs, Cloud-Regionen. Typische Properties: ip, region, availability, path.

Typische Beziehungen: hosts (hostet Service), located-in (befindet sich in), replicates-to (repliziert nach).

Datum (Typ: Zeitpunkte)

Zeitliche Informationen: Deadlines, Versionen, Events, Releases. Typische Properties: timezone, format, context (wozu gehört dieser Zeitpunkt).

Typische Beziehungen: occurred-on (fand statt am), released-on (veröffentlicht am), deprecated-on (veraltet seit).

LLM-basierte Ontologie-Extraktion: Warum ein größeres Modell?

Für Ontologie-Extraktion kommt gpt-oss:20b zum Einsatz (20 Milliarden Parameter statt 4 Milliarden bei Taxonomie). Der Grund: Beziehungserkennung ist deutlich komplexer als hierarchische Klassifikation.

Ein kleineres Modell kann Entitäten identifizieren ("Ollama", "gemma3", "ChromaDB" werden erwähnt), scheitert aber oft bei subtilen Beziehungen. Wenn im Text steht "Die Pipeline nutzt Ollama für LLM-Inferenz, wobei gemma3 für Taxonomie und gpt-oss für Ontologie zum Einsatz kommen", muss das Modell verstehen:

Diese Inferenz erfordert Kontextverständnis und logisches Reasoning, was größere Modelle deutlich besser beherrschen. Der Trade-off: Doppelt so lange Verarbeitungszeit (circa 4 Sekunden pro Seite statt 2), aber deutlich präzisere Beziehungen.

Die Prompting-Strategie für konsistente Extraktion

Der Prompt für Ontologie-Extraktion definiert exakt, welche Entity- und Relationship-Typen erlaubt sind:

SYSTEM_PROMPT = """Du bist ein Experte für Knowledge Graph Extraktion.
Extrahiere aus dem folgenden Text Entitäten und ihre Beziehungen.

ENTITY-TYPEN: Person, Organisation, Konzept, Technologie, Ort, Datum

RELATIONSHIP-TYPEN: is-a, has-a, uses, depends-on, relates-to, created-by, runs-on

REGELN:
- Jede Entität: name, type, description, properties (dict)
- Jede Beziehung: from, relationship, to, type
- Nur konkrete Entitäten (keine abstrakten Meta-Begriffe)
- Properties als Key-Value-Paare
- JSON-Format (validierbar)

OUTPUT-FORMAT:
{
  "entities": [
    {
      "name": "...",
      "type": "...",
      "description": "...",
      "properties": {...}
    }
  ],
  "relationships": [
    {
      "from": "...",
      "relationship": "...",
      "to": "...",
      "type": "..."
    }
  ]
}

Text:
{page_text}

Antworte NUR mit JSON."""

Dieser Prompt erzwingt ein festes Schema. Das Modell kann nicht eigene Entity-Typen erfinden ("Super-Wichtige-Technologie") oder unstrukturierte Beziehungen ausgeben. Alles muss in das definierte Format passen.

Validierung: Referenz-Integrität sicherstellen

Nach der Ontologie-Extraktion laufen drei Validierungs-Ebenen:

Ebene 1: Struktur-Validierung

Existieren entities und relationships Arrays? Haben alle Entitäten die Pflichtfelder name, type, description, properties? Haben alle Beziehungen from, to, relationship, type?

Ebene 2: Referenz-Integrität

Hier wird geprüft: Referenzieren alle Beziehungen existierende Entitäten? Wenn eine Beziehung sagt "Ollama uses gemma3", müssen sowohl "Ollama" als auch "gemma3" in der entities-Liste sein. Diese Validierung verhindert kaputte Links im Graphen (Beziehungen, die ins Leere zeigen).

Ebene 3: Typ-Konsistenz

Sind die Entity-Typen valide (einer der sechs Standard-Typen)? Sind die Relationship-Typen valide? Passen Beziehungen zu Entity-Typen (zum Beispiel "created-by" sollte von Technology zu Person/Organisation zeigen, nicht von Concept zu Concept)?

Diese semantische Validierung erkennt unsinnige Beziehungen und fordert Korrektur an.

Ontologie-Konsolidierung über gesamtes Dokument

Wenn alle Seiten ihre lokalen Ontologien haben, beginnt die dokumentweite Konsolidierung. Diese ist komplexer als bei Taxonomie, weil sowohl Entitäten als auch Beziehungen konsolidiert werden müssen.

Entity-Merging: Duplikate zusammenführen

Dieselbe Entität wird auf verschiedenen Seiten möglicherweise unterschiedlich erwähnt:

Das Konsolidierungs-Modell erkennt via Fuzzy-Matching: Diese drei meinen dasselbe (ähnlicher Name, gleicher Typ, ähnliche Beschreibung). Die Entitäten werden zu einer zusammengeführt:

{
  "name": "Ollama",
  "type": "Technology",
  "description": "Lokaler LLM-Inferenz-Server",
  "properties": {
    "port": 11434,
    "models": ["gemma3:4b-it-qat", "gpt-oss:20b", "mxbai-embed-large"],
    "location": "localhost"
  },
  "mentioned_on_pages": [1, 5, 10]
}

Alle Properties werden aggregiert. Die beste Beschreibung wird gewählt (die präziseste und vollständigste). Die Seiten-Referenzen werden behalten (Provenance).

Relationship-Konsolidierung: Beziehungen deduplizieren

Wenn mehrere Seiten dieselbe Beziehung erwähnen, wird sie nur einmal gespeichert. Beispiel: Seite 3 und Seite 8 erwähnen beide "Pipeline uses Ollama". Diese Beziehung wird einmal gespeichert mit Referenzen auf beide Seiten.

Komplizierter wird es bei widersprüchlichen Beziehungen: Seite 3 sagt "Ollama uses gemma3", Seite 7 sagt "Ollama uses gpt-oss". Beide sind korrekt (Ollama kann mehrere Modelle nutzen). Die Konsolidierung erkennt: Das sind keine Widersprüche, sondern komplementäre Informationen. Beide Beziehungen werden behalten.

Echte Widersprüche (Seite 3: "A depends-on B", Seite 7: "A does-not-depend-on B") werden markiert und an die Validierung zurückgemeldet.

Property-Aggregation: Eigenschaften sammeln

Verschiedene Seiten liefern verschiedene Properties für dieselbe Entität. Alle werden gesammelt und als Key-Value-Paare in einem JSON-Objekt gespeichert. Duplikate (gleicher Key, gleicher Value) werden dedupliziert. Konflikte (gleicher Key, unterschiedlicher Value) werden als Array gespeichert.

Beispiel: Seite 3 sagt "ChromaDB port: 8000", Seite 7 sagt "ChromaDB api: v2". Beide Properties landen in der finalen Entität. Wenn Seite 10 sagt "ChromaDB port: 8001", entsteht ein Konflikt. Beide Werte werden behalten: "port": [8000, 8001] mit Marker "conflict detected".

Transitive Beziehungen: Dependency-Ketten bilden

Das Konsolidierungs-Modell kann transitive Abhängigkeiten erkennen und explizit machen:

Diese transitiven Beziehungen werden als derived relationships gespeichert (im Gegensatz zu explicit relationships, die direkt im Text stehen). Sie sind wertvoll für Dependency-Analyse und Impact-Assessment.

Speicherung in MariaDB: Zwei Tabellen für Graph-Daten

Die Ontologie wird in zwei relationalen Tabellen gespeichert:

Tabelle: entities

Felder: id, doc_id, entity_name, entity_type, description, properties (JSON-Feld).

Das properties-Feld ist ein JSON-Objekt, das beliebige Key-Value-Paare enthalten kann. MariaDB bietet JSON-Funktionen (JSON_EXTRACT, JSON_CONTAINS), um in diesen Properties zu suchen.

Tabelle: relationships

Felder: id, doc_id, source_entity_id (Foreign Key zu entities), target_entity_id (Foreign Key zu entities), relationship_type, relationship_label.

Die Beziehungen sind gerichtete Kanten: source_entity_id zeigt auf die Quelle, target_entity_id auf das Ziel. Das ermöglicht Graph-Traversierung via SQL-JOINs.

Graph-Queries mit rekursiven CTEs

MariaDB unterstützt rekursive Common Table Expressions (CTEs), die für Graph-Traversierung genutzt werden können. Beispiel: "Finde alle Technologien, von denen ChromaDB direkt oder indirekt abhängt":

WITH RECURSIVE dependencies AS (
  -- Basis: Direkte Dependencies
  SELECT target_entity_id FROM relationships
  WHERE source_entity_id = (SELECT id FROM entities WHERE entity_name = 'ChromaDB')
    AND relationship_type = 'depends-on'

  UNION

  -- Rekursion: Transitive Dependencies
  SELECT r.target_entity_id FROM relationships r
  JOIN dependencies d ON r.source_entity_id = d.target_entity_id
  WHERE r.relationship_type = 'depends-on'
)
SELECT e.entity_name FROM entities e
JOIN dependencies d ON e.id = d.target_entity_id;

Diese Query traversiert den Dependency-Graphen rekursiv und findet alle direkten und indirekten Abhängigkeiten. Das ist die Grundlage für Impact-Analyse.

Praktisches Beispiel: Extrahierte Ontologie

Hier die tatsächlich extrahierte Ontologie aus einem 6-seitigen Testdokument über die doc2vector Pipeline:

Extrahierter Knowledge Graph

Entitäten (Auswahl):

  • Ollama (Technology) → properties: {port: 11434, models: [gemma3, gpt-oss, mxbai]}
  • gemma3:4b-it-qat (Technology) → properties: {size: "3.7 GB", purpose: "taxonomie"}
  • ChromaDB (Technology) → properties: {api: "v2", client: "HttpClient", port: 8000}
  • mxbai-embed-large (Technology) → properties: {dimensions: 1024, lang: ["de", "en"]}
  • doc2vector Pipeline (Concept) → properties: {stages: 5, steps: 15}

Beziehungen (Auswahl):

  • doc2vector Pipeline uses Ollama
  • Ollama runs gemma3:4b-it-qat
  • Ollama runs gpt-oss:20b
  • doc2vector Pipeline depends-on ChromaDB
  • ChromaDB stores Embeddings
  • mxbai-embed-large is-a Embedding-Modell

Ergebnis: Wissens-Graph zeigt alle Abhängigkeiten und Beziehungen zwischen Komponenten. Jede Entität kann über ihre Beziehungen gefunden werden, nicht nur über ihren Namen.

Ontologie in Aktion: Praktische Anwendungsfälle

Use Case 1: Kontextuelle Retrieval-Expansion

Wenn ein Nutzer nach "Ollama" fragt, kann das System automatisch verwandte Entitäten mit abrufen. Es traversiert den Graphen via "uses"-Beziehungen und findet: gemma3, gpt-oss, mxbai-embed-large. Diese werden als erweiterte Kontext-Chunks mit abgerufen.

Der Unterschied: Naive RAG findet nur Chunks, in denen "Ollama" vorkommt. Ontologie-angereichertes RAG findet zusätzlich Chunks über die Modelle, die Ollama nutzt. Die Antwort wird vollständiger.

Use Case 2: Dependency-basierte Suche

Fragen wie "Was benötigt ChromaDB?" oder "Welche Technologien hängen von Ollama ab?" können direkt aus dem Ontologie-Graphen beantwortet werden, ohne Textsuche. Das System traversiert "depends-on"-Beziehungen und liefert eine Liste.

Das ist schneller und präziser als Volltext-Suche, die Sätze mit "benötigt" suchen muss und möglicherweise False Positives liefert ("X benötigt Y nicht" wird trotzdem gefunden, weil "benötigt" vorkommt).

Use Case 3: Property-Filter

Queries wie "Alle Technologien mit property 'lokal'" nutzen JSON-Funktionen in MariaDB, um im properties-Feld zu suchen. Das liefert alle Entitäten, die eine bestimmte Eigenschaft haben, ohne dass diese im Namen oder in der Beschreibung vorkommen muss.

Use Case 4: Graph-Traversierung für Impact-Analyse

Wenn eine Technologie deprecated wird, kann man den Graphen traversieren, um alle betroffenen Systeme zu finden: "Was nutzt diese Technologie?" (direkte Abhängigkeit), "Was nutzt Systeme, die diese Technologie nutzen?" (transitive Abhängigkeit).

Diese Impact-Analyse basiert auf expliziten Beziehungen, nicht auf Textsuche. Sie ist vollständig (findet alle Abhängigkeiten), präzise (keine False Positives) und schnell (Graph-Traversierung statt Volltext-Scan).

Integration mit ChromaDB: Ontologie als Chunk-Metadaten

Genau wie Taxonomie wird auch Ontologie als Metadaten an jeden Chunk gehängt:

{
  "chunk_id": "doc_123_page_5_chunk_3",
  "text": "Ollama läuft auf localhost und stellt Modelle bereit...",
  "embedding": [0.234, -0.567, ...],
  "metadata": {
    "taxonomy_path": "Dokumentverarbeitung → KI-Modelle → LLMs",
    "mentioned_entities": ["Ollama", "gemma3:4b-it-qat", "localhost"],
    "entity_types": ["Technology", "Technology", "Ort"],
    "relationships": [
      {"from": "Ollama", "rel": "runs-on", "to": "localhost"},
      {"from": "Ollama", "rel": "runs", "to": "gemma3:4b-it-qat"}
    ],
    "page": 5,
    "position": 3
  }
}

Diese Metadaten ermöglichen Entity-basierte Filterung: "Finde Chunks, in denen 'Ollama' erwähnt wird UND die eine 'runs-on'-Beziehung haben". Das ist präziser als Volltext-Suche nach "Ollama läuft auf".

Ontologie über viele Dokumente: Der unternehmensweite Knowledge Graph

Wenn Du 100 Dokumente verarbeitest, entstehen 100 dokumentspezifische Ontologien. Diese können übergreifend konsolidiert werden, um einen unternehmensweiten Knowledge Graph zu schaffen.

Das Prinzip: Entitäten, die in verschiedenen Dokumenten erwähnt werden, sind dieselben Knoten. Beziehungen werden verknüpft. Das Ergebnis ist ein globales Netzwerk, das zeigt:

Diese Metrik-Analysen sind nur möglich, weil die Ontologie Beziehungen explizit macht. In unstrukturierten Texten sind diese Muster verborgen.

Grenzen der Ontologie: Was sie nicht kann

Ontologie liefert Beziehungen und Eigenschaften, aber keine Bedeutungsdefinitionen. Sie sagt "Embedding ist ein Konzept mit property 'dimensions: 1024'", aber nicht "Embedding = numerische Repräsentation von Text in hochdimensionalem Vektorraum, die semantische Ähnlichkeit als geometrische Distanz abbildet".

Für solche präzisen Definitionen, Kernkonzepte und Glossare brauchst Du Semantik (das nächste Kapitel). Semantik ergänzt Ontologie mit Bedeutungsebenen.

Zusammen bilden Taxonomie (Hierarchie), Ontologie (Beziehungen) und Semantik (Bedeutung) eine dreifache Wissensrepräsentation, die vollständiger ist als jedes Modell allein.

Wissensrepräsentation: Semantik

Kompakt Details

Taxonomie ordnet Konzepte ein (hierarchisch), Ontologie verbindet sie (durch Beziehungen), Semantik erklärt, was sie bedeuten. Das ist die dritte und letzte Schicht der Wissensrepräsentation, und sie beantwortet die Frage: "Was heißt das eigentlich?"

Ein Beispiel macht den Unterschied klar: Taxonomie sagt "Embedding gehört zu KI → Vektordatenbanken". Ontologie ergänzt "Embedding wird genutzt von ChromaDB, benötigt mxbai-embed-large". Semantik definiert: "Embedding = numerische Repräsentation von Text in einem hochdimensionalen Vektorraum (etwa 1024 Dimensionen), die semantische Ähnlichkeit als geometrische Distanz abbildet".

Diese Definition ist das, was Taxonomie und Ontologie nicht liefern können. Sie erklären Struktur und Beziehungen, aber nicht Bedeutung. Semantik schließt diese Lücke.

Vier Abstraktionsebenen: Von Details zu Meta-Aussagen

Die semantische Extraktion arbeitet mit vier verschiedenen Ebenen (Layers), weil unterschiedliche Fragen unterschiedliche Detailgrade brauchen:

Ein RAG-System kann je nach Fragetyp die passende Ebene wählen: Detail-Frage ("Wie groß ist gemma3?") → Layer 1. Überblicks-Frage ("Was macht doc2vector?") → Layer 3. Meta-Frage ("Warum scheitern naive RAG-Systeme?") → Layer 4.

Wie Semantik extrahiert wird

Die Pipeline nutzt dasselbe große Sprachmodell wie für Ontologie (gpt-oss:20b), weil semantische Extraktion tiefes Verständnis erfordert. Das Modell analysiert jede Seite und extrahiert drei Dinge:

Die Ausgabe ist JSON mit drei Arrays: concepts, summaries und conceptual_relationships. Nach der Validierung werden alle seitenweisen Modelle konsolidiert, ähnlich wie bei Taxonomie und Ontologie.

Praktischer Nutzen für RAG

Semantik macht RAG-Systeme bedeutungsorientiert statt wortorientiert. Wenn Du nach "Wie funktioniert semantische Suche?" fragst, findet das System nicht nur Chunks mit diesen exakten Worten, sondern auch Chunks über "Embedding-basierte Ähnlichkeitssuche", "Vektor-Retrieval" oder "hochdimensionale Distanzberechnung".

Der Grund: Die extrahierten Konzepte zeigen semantische Verwandtschaft. "Semantic Search", "Embedding-basierte Suche" und "Vektor-Retrieval" sind unterschiedliche Begriffe für dasselbe Konzept. Ohne Semantik-Modell muss die KI das erraten. Mit Semantik-Modell ist es explizit.

Ein zweiter Nutzen: Automatische Begriffsklärung. Wenn ein unklarer Begriff in einer Frage auftaucht, kann das System in den extrahierten Definitionen nachschlagen und diese zur Klärung nutzen. Das reduziert Mehrdeutigkeiten und verbessert die Antwortqualität.

Semantische Repräsentation extrahiert Bedeutungsebenen aus Text. Während Taxonomie fragt "Wo gehört das hin?" und Ontologie fragt "Wie hängt das zusammen?", fragt Semantik: "Was bedeutet das, und warum ist es wichtig?"

Die drei Komponenten semantischer Extraktion

Die Pipeline extrahiert drei komplementäre Elemente:

1. Konzepte mit Definitionen

Ein Konzept ist eine zentrale Idee oder ein Schlüsselbegriff, der für das Verständnis des Dokuments wichtig ist. Jedes Konzept hat:

Diese Struktur ist bewusst umfassend, weil Konzepte nur mit vollständigem Kontext wirklich verständlich sind. Eine Definition allein ("RAG = Retrieval Augmented Generation") ist wenig hilfreich. Erst mit Kontext ("wird in KI-Systemen genutzt"), Beispielen ("Query findet Chunks, LLM generiert Antwort") und Implikationen ("Qualität hängt von Retrieval-Präzision ab") wird es greifbar.

2. Zusammenfassungen auf vier Abstraktionsebenen

Jede Seite wird auf vier verschiedenen Ebenen zusammengefasst. Diese Multi-Level-Summaries ermöglichen es, je nach Fragetyp die passende Detailtiefe zu wählen:

Layer 1 (Detail-Ebene): Konkrete Aussagen, Fakten, technische Spezifikationen. Beispiel: "doc2vector ist eine 5-Stufen-Pipeline zur automatisierten Wissensextraktion aus Dokumenten. Sie nutzt LLMs (gemma3:4b-it-qat, gpt-oss:20b) für Taxonomie-, Ontologie- und Semantik-Extraktion. Embeddings werden mit mxbai-embed-large generiert und in ChromaDB gespeichert."

Layer 2 (Konzept-Ebene): Kernkonzepte, zentrale Ideen, abstrahiert aber noch greifbar. Beispiel: "Kernkonzepte: RAG-Systeme profitieren von strukturierter Datenaufbereitung. Dreifache Wissensrepräsentation (Taxonomie, Ontologie, Semantik) liefert Kontext für Retrieval. Quality Gates sichern Konsistenz."

Layer 3 (Summary-Ebene): Gesamtaussage, stark komprimiert. Beispiel: "doc2vector transformiert unstrukturierte Dokumente in strukturierte, durchsuchbare Wissensbasis. Messbare Verbesserung: 70-85% Precision@5 statt 30-40% bei naivem RAG."

Layer 4 (Meta-Ebene): Intentionen, Implikationen, Schlussfolgerungen. Beispiel: "Implikation: Naive RAG-Implementierungen scheitern an Context Pollution. Strukturierte Wissensrepräsentation ist Voraussetzung für produktionsreife RAG-Systeme. Langfristiger Effekt: Unternehmensweiter Knowledge Graph aus Dokumentensammlung."

Diese vier Ebenen ermöglichen granulare Kontext-Auswahl. Ein Detail-orientierter Query bekommt Layer 1 (volle Fakten). Ein Überblicks-Query bekommt Layer 3 (komprimierte Essenz). Ein strategischer Query bekommt Layer 4 (Meta-Aussagen und Implikationen).

3. Konzeptuelle Beziehungen

Zusätzlich zu strukturellen Beziehungen (Ontologie) extrahiert Semantik konzeptuelle Beziehungen: Wie hängen Ideen zusammen? Welche Konzepte bauen aufeinander auf, widersprechen sich oder ergänzen sich?

Beispiele:

Diese Beziehungen sind abstrakter als Ontologie-Beziehungen. Sie verbinden nicht konkrete Entitäten ("Ollama nutzt gemma3"), sondern Ideen ("Das Konzept RAG setzt das Konzept Semantic Search voraus").

Der Unterschied zwischen Ontologie und Semantik

Ontologie und Semantik überlappen sich teilweise, haben aber unterschiedliche Fokussierungen:

Ontologie vs. Semantik

  • Ontologie: Strukturelle Beziehungen zwischen konkreten Entitäten ("Ollama uses gemma3", "Pipeline depends-on ChromaDB")
  • Semantik: Konzeptuelle Bedeutungen und abstrakte Zusammenhänge ("RAG setzt Retrieval-Qualität voraus", "Embedding ermöglicht Semantic Search")
  • Ontologie: Graph aus Dingen und ihren Verbindungen (was existiert und wie es verbunden ist)
  • Semantik: Netzwerk aus Ideen und ihren Bedeutungen (was Dinge bedeuten und warum sie wichtig sind)

Ein praktisches Beispiel: Ontologie sagt "Ollama runs gemma3:4b-it-qat" (strukturelle Tatsache). Semantik erklärt "gemma3 wird für Taxonomie-Extraktion genutzt, weil es schnell ist und hierarchische Klassifikation gut beherrscht" (Bedeutung und Begründung).

LLM-basierte Semantik-Extraktion

Für Semantik kommt gpt-oss:20b zum Einsatz (dasselbe Modell wie für Ontologie), weil Bedeutungsextraktion tiefes Textverständnis erfordert. Das Modell muss nicht nur erkennen, was erwähnt wird, sondern auch verstehen, was es bedeutet und warum es wichtig ist.

Der Prompt ist der komplexeste der drei Extraktionstypen:

SYSTEM_PROMPT = """Du bist ein Experte für semantische Wissensextraktion.
Extrahiere aus dem folgenden Text Konzepte, Definitionen und Bedeutungsebenen.

KONZEPT-EXTRAKTION:
- Name (prägnant, 1-5 Wörter)
- Definition (präzise, 1-2 Sätze)
- Kontext (wofür relevant, wo verwendet)
- Verwandte Konzepte (Liste)
- Beispiele (konkrete Anwendungsfälle)
- Implikationen (was folgt daraus, Voraussetzungen)

ZUSAMMENFASSUNGS-EBENEN:
- Layer 1 (Detail): Konkrete Aussagen, Fakten, Beispiele
- Layer 2 (Konzept): Kernkonzepte, zentrale Ideen
- Layer 3 (Summary): Gesamtaussage, übergeordnete Bedeutung
- Layer 4 (Meta): Intentionen, Implikationen, Voraussetzungen

KONZEPTUELLE BEZIEHUNGEN:
- concept_1, concept_2, relationship (depends-on, uses, complements, contrasts)
- Explanation (warum diese Beziehung)

REGELN:
- Mindestens 3 Konzepte pro Seite
- Alle 4 Summary-Layer erstellen
- Nur konkrete Konzepte (keine Meta-Begriffe)
- Definitionen präzise, nicht allgemein
- JSON-Format (validierbar)

Text:
{page_text}

Antworte NUR mit JSON."""

Dieser Prompt erzwingt Vollständigkeit: Jedes Konzept braucht Definition, Kontext, Beispiele und Implikationen. Alle vier Summary-Layer müssen vorhanden sein. Das verhindert oberflächliche Extraktion.

Validierung: Vollständigkeit und Mindestanzahl

Nach der Semantik-Extraktion laufen strengere Validierungen als bei Taxonomie oder Ontologie:

Diese Checks stellen sicher, dass die semantische Extraktion substanziell ist, nicht nur formal korrekt.

Semantik-Konsolidierung: Definitionen zusammenführen

Wenn alle Seiten ihre semantischen Modelle haben, beginnt die Konsolidierung. Diese ist anders als bei Taxonomie oder Ontologie, weil Konzepte oft über mehrere Seiten verteilt definiert werden.

Beispiel: Seite 2 definiert "RAG = Retrieval Augmented Generation". Seite 8 ergänzt "RAG kombiniert Retrieval mit Generation". Seite 15 präzisiert "RAG nutzt externe Wissensquellen zur Kontextanreicherung". Die Konsolidierung führt diese Fragmente zu einer vollständigen, präzisen Definition zusammen.

Das Konsolidierungs-Modell wählt die beste Definition basierend auf Vollständigkeit, Präzision und Klarheit. Wenn mehrere gleichwertige Definitionen existieren, werden sie als Varianten gespeichert.

Praktischer Nutzen für RAG

Semantik ermöglicht drei fortgeschrittene RAG-Funktionen:

Das macht den Unterschied zwischen einem System, das Texte findet, und einem System, das Bedeutung versteht.

Der fundamentale Unterschied zu Taxonomie und Ontologie

Taxonomie, Ontologie und Semantik beantworten unterschiedliche Fragen:

Wann welches Modell?

Fragestellung Taxonomie Ontologie Semantik
Wo gehört das hin? ✓ (Klassifikation) ✗ ✗
Wie hängt das zusammen? ✗ ✓ (Relationen) ✗
Was bedeutet das? ✗ ✗ ✓ (Konzepte)
Nach Kategorie filtern ✓ (Hierarchie) ✗ ✗
Dependencies verstehen ✗ ✓ (depends-on) ✗
Konzepte erklären ✗ ✗ ✓ (Definitionen)
Zusammenfassungen ✗ ✗ ✓ (Multi-Level)

Fazit: Taxonomie ordnet ein, Ontologie verbindet, Semantik erklärt. Alle drei zusammen für vollständige Wissensrepräsentation.

Ein vollständiges Beispiel zeigt die Komplementarität:

Die Taxonomie gibt Position, die Ontologie gibt Beziehungen, die Semantik gibt Bedeutung und Kontext. Erst zusammen ergeben sie ein vollständiges Bild.

Die vier Abstraktionsebenen im Detail

Layer 1: Detail-Ebene (Fakten und Spezifikationen)

Diese Ebene extrahiert konkrete Aussagen aus dem Original-Text: Zahlen, technische Spezifikationen, genaue Beschreibungen, Code-Beispiele. Sie ist die wortgetreueste Repräsentation des Textes.

Beispiel aus doc2vector-Dokumentation: "doc2vector ist eine 5-Stufen-Pipeline: Konvertierung (PDF/HTML → Text), Seitenweise Analyse (LLMs), Modell-Extraktion (Taxonomie, Ontologie, Semantik), Konsolidierung (Zusammenführung), Speicherung (ChromaDB + MariaDB). Genutzt werden gemma3:4b-it-qat (Taxonomie), gpt-oss:20b (Ontologie, Semantik), mxbai-embed-large (Embeddings, 1024 Dimensionen)."

Diese Ebene ist wertvoll für Detail-Fragen ("Welches Modell wird für Taxonomie genutzt?") oder technische Nachfragen ("Wie viele Dimensionen haben die Embeddings?").

Layer 2: Konzept-Ebene (Kernideen)

Diese Ebene abstrahiert von Details zu Kernkonzepten: Was sind die zentralen Ideen? Welche Hauptargumente werden gemacht? Sie ist komprimierter als Layer 1, aber noch konkret genug, um greifbar zu sein.

Beispiel: "Kernkonzepte: RAG-Systeme profitieren von strukturierter Datenaufbereitung. Dreifache Wissensrepräsentation (Taxonomie, Ontologie, Semantik) liefert Kontext für Retrieval. Quality Gates zwischen Pipeline-Stufen sichern Konsistenz. Dual Storage (ChromaDB für Vektoren, MariaDB für Metadaten) ermöglicht Hybrid-Search."

Diese Ebene ist wertvoll für Konzept-orientierte Fragen ("Was sind die Hauptideen?") oder als Einstieg für Nutzer, die sich einen Überblick verschaffen wollen.

Layer 3: Summary-Ebene (Gesamtaussage)

Diese Ebene komprimiert auf die Essenz: Was ist die zentrale Botschaft in einem Satz oder Absatz? Sie ist stark abstrahiert, verliert aber keine kritischen Informationen.

Beispiel: "doc2vector transformiert unstrukturierte Dokumente in strukturierte, durchsuchbare Wissensbasis durch seitenweise Extraktion von Taxonomie, Ontologie und Semantik. Messbare Verbesserung: 70-85% Precision@5 statt 30-40% bei naivem RAG."

Diese Ebene ist wertvoll für Überblicks-Fragen ("Was macht doc2vector in einem Satz?") oder für Executive Summaries.

Layer 4: Meta-Ebene (Implikationen und Voraussetzungen)

Diese Ebene extrahiert implizites Wissen: Was wird vorausgesetzt? Was folgt daraus? Welche Intentionen stecken dahinter? Sie ist die abstrakteste Ebene und erfordert das tiefste Textverständnis.

Beispiel: "Implikation: Naive RAG-Implementierungen scheitern an Context Pollution (irrelevante Chunks). Strukturierte Wissensrepräsentation ist Voraussetzung für produktionsreife RAG-Systeme. Langfristiger Effekt: Unternehmensweiter Knowledge Graph aus Dokumentensammlung. Voraussetzung: Organisationen müssen bereit sein, sich mit ihrem eigenen Wissen auseinanderzusetzen."

Diese Ebene ist wertvoll für strategische Fragen ("Warum scheitern naive Systeme?") oder Meta-Reflexion ("Was sind die Voraussetzungen für erfolgreiche Implementierung?").

Konzeptuelle Beziehungen: Ideen verbinden

Zusätzlich zu konkreten Entitäts-Beziehungen (Ontologie) extrahiert Semantik abstrakte Konzept-Beziehungen:

Diese Beziehungen sind abstrakter als "Ollama nutzt gemma3" (konkrete Entitäten). Sie verbinden Ideen: "Das Prinzip der strukturierten Aufbereitung ermöglicht das Konzept des Hybrid-Retrievals".

Semantik-Konsolidierung: Definitionen vereinheitlichen

Wenn alle Seiten ihre semantischen Modelle haben, werden die Konzepte konsolidiert. Das ist komplexer als Entity-Merging, weil Konzepte oft fragmentiert über mehrere Seiten definiert sind.

Concept-Merging: Varianten erkennen

Dasselbe Konzept wird möglicherweise mit verschiedenen Namen erwähnt:

Das Konsolidierungs-Modell erkennt via semantischem Matching: Alle vier meinen dasselbe Konzept. Sie werden zusammengeführt, wobei "RAG (Retrieval Augmented Generation)" als primärer Name gewählt wird (Akronym mit Vollform in Parenthese).

Definition-Aggregation: Die beste Definition wählen

Verschiedene Seiten liefern verschiedene Definitionen für dasselbe Konzept. Das Konsolidierungs-Modell bewertet sie nach drei Kriterien:

Die beste Definition wird als primäre übernommen. Alternative Definitionen werden als "variants" gespeichert, falls sie zusätzliche Perspektiven bieten.

Summary-Hierarchie: Von Seiten zu Kapiteln zu Gesamtdokument

Die seitenweisen Summaries werden zu einer hierarchischen Zusammenfassung konsolidiert:

Diese Hierarchie ermöglicht granulare Kontext-Auswahl: RAG kann die passende Abstraktionsebene wählen (Seiten-Level für Details, Dokument-Level für Überblick).

Konsistenz-Prüfung: Widersprüchliche Bedeutungen

Wenn verschiedene Seiten widersprüchliche Definitionen liefern, werden diese markiert:

Das Konsolidierungs-Modell erkennt: Die zweite Definition ist präziser. Sie wird als primär gewählt, die erste als "simplified variant" gespeichert. Echte Widersprüche (A sagt X, B sagt NOT-X) werden als "conflict" markiert und manuell überprüft.

JSON-Struktur der extrahierten Semantik

Hier ein Beispiel aus einem tatsächlich verarbeiteten Dokument:

{
  "semantic_model": "doc2vector Technical Documentation",
  "concepts": [
    {
      "name": "RAG (Retrieval Augmented Generation)",
      "definition": "Technik zur Anreicherung von LLM-Antworten mit kontextspezifischen Informationen aus Wissensquellen",
      "context": "Semantic Search in Vektordatenbanken + LLM-basierte Generierung",
      "related_concepts": ["Semantic Search", "ChromaDB", "Embedding", "Context Injection"],
      "examples": [
        "Query: 'Was ist Ollama?' → Retrieval findet 5 Chunks über Ollama → LLM generiert Antwort mit Kontext"
      ],
      "implications": [
        "RAG-Qualität abhängig von Retrieval-Präzision",
        "Kontext-Qualität direkt korreliert mit Antwort-Qualität"
      ]
    },
    {
      "name": "Semantic Search",
      "definition": "Suche nach Bedeutungsähnlichkeit statt Keyword-Matching",
      "context": "Embedding-basierte Vektorsuche in hochdimensionalen Räumen",
      "related_concepts": ["Embedding", "Cosine Similarity", "Vector Database", "mxbai-embed-large"],
      "examples": [
        "Query: 'Wie funktioniert KI-Suche?' findet auch 'Semantic Retrieval', 'Embedding-basierte Suche'"
      ],
      "implications": [
        "Versteht Synonyme ohne explizite Mapping",
        "Findet konzeptuell ähnliche Inhalte"
      ]
    }
  ],
  "summaries": [
    {
      "layer": 1,
      "level": "detail",
      "text": "doc2vector ist eine 5-Stufen-Pipeline zur automatisierten Wissensextraktion aus Dokumenten..."
    },
    {
      "layer": 2,
      "level": "concept",
      "text": "Kernkonzepte: RAG-Systeme profitieren von strukturierter Datenaufbereitung..."
    },
    {
      "layer": 3,
      "level": "summary",
      "text": "doc2vector transformiert unstrukturierte Dokumente in strukturierte Wissensbasis..."
    },
    {
      "layer": 4,
      "level": "meta",
      "text": "Implikation: Naive RAG-Implementierungen scheitern an Context Pollution..."
    }
  ],
  "conceptual_relationships": [
    {
      "concept_1": "RAG",
      "concept_2": "Semantic Search",
      "relationship": "depends-on",
      "explanation": "RAG benötigt Semantic Search für Retrieval-Phase"
    }
  ]
}

Speicherung in MariaDB: Drei Tabellen für semantische Daten

Tabelle: concepts

Felder: id, doc_id, concept_name, definition, context, related_concepts (JSON-Array), examples (JSON-Array), implications (JSON-Array).

Diese Tabelle ermöglicht Volltext-Suche über Definitionen via MATCH() AGAINST() oder präzise Lookup nach concept_name.

Tabelle: summaries

Felder: id, doc_id, page_id, layer (1-4), level (detail/concept/summary/meta), summary_text.

Diese Tabelle ermöglicht Layer-basierte Queries: "Gib mir Layer 3 Summary für Dokument X" oder "Zeige alle Detail-Layer für Seite 5-10".

Tabelle: conceptual_relationships

Felder: id, doc_id, concept_1_id (Foreign Key zu concepts), concept_2_id (Foreign Key zu concepts), relationship_type, explanation.

Diese Tabelle speichert konzeptuelle Beziehungen. Im Gegensatz zur relationships-Tabelle (Ontologie, konkrete Entitäten) verbindet sie abstrakte Konzepte.

Semantik in Aktion: Praktische Anwendungsfälle

Use Case 1: Concept-Based Retrieval

Statt nach Keywords zu suchen ("RAG"), sucht das System nach semantisch verwandten Konzepten. Es kennt aus dem semantischen Modell: "RAG", "Retrieval Augmented Generation", "Retrieval-basierte Generierung", "Kontextanreicherung für LLMs" sind verwandte Begriffe.

Ein Query nach "Wie funktioniert RAG?" findet also auch Chunks, die diese Synonyme verwenden, ohne dass sie das exakte Wort "RAG" enthalten. Das erhöht Recall (mehr relevante Ergebnisse) ohne Precision zu senken (weil semantische Verwandtschaft geprüft wird).

Use Case 2: Adaptive Detailtiefe via Summary-Layers

Wenn ein Nutzer eine Detail-Frage stellt ("Welche LLMs werden genutzt?"), liefert das System Layer 1 (Detail-Ebene) mit konkreten Fakten. Bei einer Überblicks-Frage ("Was macht doc2vector?") liefert es Layer 3 (Summary-Ebene) mit komprimierter Essenz.

Diese Anpassung erfolgt automatisch basierend auf Query-Analyse: Enthält die Frage spezifische Begriffe ("welche", "wie viele", "genau")? → Layer 1. Ist sie allgemein ("was", "warum", "Überblick")? → Layer 3.

Use Case 3: Automatische Glossar-Funktion

Wenn ein unklarer Begriff in einer Frage auftaucht, kann das System in den extrahierten Definitionen nachschlagen. Beispiel: Nutzer fragt "Wie nutze ich Ollama?". Das System erkennt "Ollama" als Entität, findet die Definition in der concepts-Tabelle und fügt sie der Antwort hinzu: "Ollama ist ein lokaler LLM-Inferenz-Server, der Modelle wie gemma3 bereitstellt..."

Diese automatische Begriffsklärung reduziert Mehrdeutigkeiten und macht Antworten verständlicher.

Use Case 4: Implikations-basiertes Reasoning

Die extrahierten Implikationen helfen dem LLM bei logischen Schlussfolgerungen. Wenn im Semantik-Modell steht "Implikation: RAG-Qualität hängt von Retrieval-Präzision ab", kann das System diese Information für Reasoning nutzen:

Frage: "Warum sind meine RAG-Antworten schlecht?" System-Reasoning: Laut Semantik-Modell hängt RAG-Qualität von Retrieval-Präzision ab → prüfe Retrieval-Precision → wenn niedrig, ist das die Ursache. Antwort: "Deine RAG-Antworten sind möglicherweise schlecht, weil die Retrieval-Präzision niedrig ist. Laut Dokumentation hängt RAG-Qualität direkt von Retrieval ab..."

Diese kausalen Zusammenhänge sind in unstrukturierten Texten implizit. Semantik macht sie explizit und maschinenlesbar.

Integration mit ChromaDB: Semantik als Chunk-Metadaten

Genau wie Taxonomie und Ontologie wird auch Semantik als Metadaten an jeden Chunk gehängt:

{
  "chunk_id": "doc_123_page_5_chunk_4",
  "text": "RAG kombiniert Retrieval aus Wissensquellen mit generativer KI...",
  "embedding": [0.345, -0.678, ...],
  "metadata": {
    "taxonomy_path": "Dokumentverarbeitung → KI-Modelle → RAG",
    "mentioned_entities": ["RAG", "Retrieval", "LLM"],
    "mentioned_concepts": ["RAG", "Semantic Search", "Context Injection"],
    "concept_definitions": {
      "RAG": "Technik zur Anreicherung von LLM-Antworten mit kontextspezifischen Informationen"
    },
    "summary_layer_3": "RAG kombiniert Retrieval mit Generierung für kontextbewusste Antworten",
    "page": 5,
    "position": 4
  }
}

Diese Metadaten ermöglichen Concept-basierte Filterung: "Finde Chunks, die Konzept 'RAG' behandeln (nicht nur das Wort erwähnen)". Das System prüft mentioned_concepts statt Volltext.

Die dreifache Wissensrepräsentation im Zusammenspiel

Taxonomie, Ontologie und Semantik sind keine konkurrierenden Modelle, sondern komplementäre Schichten:

Für RAG-Systeme bedeutet das: Ein Chunk hat taxonomischen Kontext (Kategorie-Pfad), ontologischen Kontext (verwandte Entitäten) und semantischen Kontext (Konzept-Definitionen). Diese dreifache Anreicherung macht den Unterschied zwischen 30% und 75% Retrieval-Precision.

Grenzen der Semantik: Was sie nicht kann

Semantik extrahiert Bedeutung aus bestehendem Text, generiert aber kein neues Wissen. Sie kann definieren, was "Embedding" bedeutet (basierend auf den Erklärungen im Dokument), aber nicht ableiten, wie Embeddings in einem nicht erwähnten Kontext funktionieren würden.

Semantik ist auch sprachabhängig: Deutsche Konzepte werden auf Deutsch extrahiert, englische auf Englisch. Bei mehrsprachigen Dokumenten braucht es zusätzliche Übersetzungs- oder Mapping-Schritte.

Trotz dieser Limitationen ist Semantik die entscheidende dritte Schicht, die Taxonomie (Struktur) und Ontologie (Beziehungen) mit Bedeutung anreichert. Zusammen bilden alle drei ein vollständiges Wissensmodell.

Pipeline-Prozess: Überblick

Die doc2vector Verarbeitungskette besteht aus 3 technischen Haupt-Bereichen mit insgesamt 17 Verarbeitungsschritten. Jedes Dokument durchläuft diese Schritte automatisch und sequentiell. Konzeptionell lassen sich diese in 5 Haupt-Phasen gliedern: Konvertierung, Seitenweise Analyse, Modell-Extraktion, Konsolidierung und Speicherung.

Bereich 1: Preprocessing (Steps 1-5)

Vorbereitung und Strukturierung des Dokuments.

Bereich 2: Embedding & Storage (Steps 6-10)

Vektorisierung und Speicherung in ChromaDB.

Bereich 3: Analysis (Steps 11-17)

LLM-basierte Wissensextraktion und Konsolidierung.

Technische Details

  • LLM-Modell: gpt-oss:20b (alle Analysis-Steps)
  • Embedding-Modell: mxbai-embed-large (1024 Dimensionen)
  • Datenbanken: ChromaDB (Vektoren) + MariaDB (Metadaten)
  • Chunk-Größe: Max. 800 Tokens (ca. 3200 Zeichen)
  • Durchsatzzeit: Ca. 60 Sekunden pro Dokument

Was wird gespeichert?

  • ChromaDB: Chunk-Embeddings für semantische Suche
  • MariaDB Tabellen:
    • doc2vector_documents - Dokument-Metadaten
    • doc2vector_chunks - Chunk-Daten
    • doc2vector_entities - Extrahierte Entitäten
    • doc2vector_taxonomy - Hierarchische Kategorien
    • doc2vector_concepts - Semantische Konzepte
    • doc2vector_relationships - Beziehungen zwischen Entitäten
    • doc2vector_jobs - Job-Status
    • doc2vector_step_log - Step-Protokoll

Modell-Konsolidierung: Von Seiten zu Gesamtdokument

Kompakt Details

Nach der seitenweisen Extraktion hat jede Seite ihr eigenes Taxonomie-, Ontologie- und Semantik-Modell. Das Problem: Diese Modelle sind inkonsistent. Seite 3 nennt ein Konzept "Vektordatenbank", Seite 7 "Vector Database", Seite 12 "Embedding Store". Alle drei meinen dasselbe, nutzen aber unterschiedliche Begriffe.

Die Konsolidierung ist der Schritt, der diese fragmentierten Seiten-Modelle zu einem kohärenten Gesamtmodell zusammenführt. Ein größeres LLM (gpt-oss:20b) erhält alle Seiten-Modelle und die Aufgabe: "Finde Gemeinsamkeiten, führe Varianten zusammen, erstelle einheitliches Modell".

Was dabei entsteht: Ein konsolidiertes Taxonomie-Modell (eine Hierarchie statt 50 fragmentierter Bäume), ein konsolidiertes Ontologie-Modell (ein Knowledge Graph statt isolierter Entitäts-Listen) und ein konsolidiertes Semantik-Modell (einheitliche Definitionen statt widersprüchlicher Fragmente).

Die drei Konsolidierungs-Prozesse

Taxonomie-Konsolidierung: Ähnliche Kategorien werden zusammengelegt ("Machine Learning" und "ML" werden zu einer Kategorie mit Alias). Duplikate werden entfernt. Die präziseste Hierarchie wird gewählt. Daraus ergibt sich ein einheitlicher Wissensbaum über das gesamte Dokument.

Ontologie-Konsolidierung: Entitäten, die mehrfach erwähnt werden, werden zusammengeführt ("Ollama", "ollama", "Ollama-Server" werden zu einer Entity). Properties werden aggregiert (alle Eigenschaften landen in einer Entity). Beziehungen werden dedupliziert. Was herauskommt, ist ein vollständiger Knowledge Graph.

Semantik-Konsolidierung: Konzepte mit ähnlichen Namen werden zusammengeführt ("RAG", "Retrieval Augmented Generation" werden zu einem Konzept). Die beste Definition wird gewählt (die präziseste und vollständigste). Zusammenfassungen werden zu einer Gesamt-Summary hierarchisch konsolidiert. Das führt zu einem einheitlichen Glossar.

Quality Gates: Konsistenz prüfen

Nach der Konsolidierung laufen automatische Konsistenz-Checks:

Erkannte Konflikte werden markiert und können manuell überprüft werden. Das verhindert, dass fehlerhafte Daten in die Datenbank gelangen.

Warum Konsolidierung kritisch ist

Ohne Konsolidierung hättest Du 50 isolierte Seiten-Modelle ohne Zusammenhang. Mit Konsolidierung hast Du ein kohärentes Modell über das Gesamtdokument. Das ist der Unterschied zwischen fragmentiertem Wissen (jede Seite für sich) und strukturiertem Wissen (alles sinnvoll verbunden).

Diese Kohärenz ist entscheidend für RAG-Qualität: Die KI kann Konzepte über Seitengrenzen hinweg verfolgen, Beziehungsketten erkennen und Widersprüche auflösen. Die Konsequenz: Präzisere Antworten, weniger Halluzinationen, höhere Nutzerakzeptanz.

Die Konsolidierung ist der kritische Schritt zwischen seitenweiser Extraktion und finaler Speicherung. Nach der LLM-basierten Analyse hat jede Seite ihr eigenes Taxonomie-, Ontologie- und Semantik-Modell. Diese Modelle sind lokal korrekt (für ihre jeweilige Seite), aber global inkonsistent (über das Gesamtdokument).

Das Fragmentierungs-Problem

Wenn ein 50-seitiges Dokument durch die Pipeline läuft, entstehen:

Diese 150 Modelle sind isoliert. Sie kennen sich nicht gegenseitig. Das führt zu systematischen Problemen:

Problem 1: Inkonsistente Terminologie

Verschiedene Seiten nutzen unterschiedliche Begriffe für dasselbe Konzept: "Vektordatenbank" (Seite 3), "Vector Database" (Seite 7), "Embedding Store" (Seite 12), "ChromaDB" (Seite 15). Ohne Konsolidierung bleiben das vier separate Konzepte, obwohl sie dasselbe meinen.

Problem 2: Fragmentierte Entitäten

Dieselbe Entität wird auf verschiedenen Seiten unterschiedlich erwähnt: "Ollama" (Seite 5), "ollama" (Seite 8, kleingeschrieben), "Ollama-Server" (Seite 12). Jede Seite hat unterschiedliche Properties: Seite 5 erwähnt port: 11434, Seite 8 erwähnt models: [gemma3], Seite 12 erwähnt location: localhost. Ohne Konsolidierung gehen diese Informationen verloren oder bleiben fragmentiert.

Problem 3: Isolierte Beziehungen

Beziehungen sind über Seiten verteilt: Seite 5 sagt "Pipeline uses Ollama", Seite 8 sagt "Ollama runs gemma3", Seite 12 sagt "gemma3 is-used-for Taxonomie". Diese Kette (Pipeline → Ollama → gemma3 → Taxonomie) ist nur sichtbar, wenn man alle drei Seiten zusammenführt.

Problem 4: Widersprüchliche Definitionen

Verschiedene Seiten definieren dasselbe Konzept unterschiedlich: Seite 3 "Embedding = Vektorisierung von Text", Seite 9 "Embedding = numerische Repräsentation in hochdimensionalem Raum". Die zweite ist präziser, aber ohne Konsolidierung bleiben beide als separate, möglicherweise widersprüchliche Definitionen bestehen.

Die Konsolidierungs-Strategie

Die Pipeline nutzt ein zweites, größeres LLM (gpt-oss:20b) für Konsolidierung. Warum ein größeres Modell? Weil Zusammenführung komplexeres Reasoning erfordert als Extraktion:

Diese Aufgaben erfordern Textverständnis über einzelne Seiten hinaus. Ein kleineres Modell würde oberflächlich konsolidieren (nur exakte Matches), ein größeres erkennt semantische Zusammenhänge.

Taxonomie-Konsolidierung: Hierarchien vereinigen

Die Taxonomie-Konsolidierung führt seitenweise Hierarchien zu einem einheitlichen Baum zusammen:

Schritt 1: Gemeinsame Wurzel finden

Verschiedene Seiten haben möglicherweise unterschiedliche Root-Kategorien. Seite 1: "Dokumentverarbeitung", Seite 5: "KI-Pipeline", Seite 10: "Wissensextraktion". Das Modell erkennt: Alle beschreiben dasselbe System aus verschiedenen Blickwinkeln. Die umfassendste Bezeichnung wird gewählt ("Dokumentverarbeitung").

Schritt 2: Fuzzy-Matching für Kategorien

Das Modell erkennt semantisch ähnliche Kategorien:

Die häufigste oder präziseste Variante wird als primärer Name gewählt. Alternative Bezeichnungen werden als Aliases gespeichert.

Schritt 3: Hierarchie-Zusammenführung

Wenn verschiedene Seiten unterschiedliche hierarchische Pfade vorschlagen, muss das Modell die beste Struktur wählen. Das basiert auf Kontext-Häufigkeit: Wie wird das Konzept in den meisten Kontexten verwendet?

Beispiel: "Ollama" wird auf Seite 1 unter "Tools" eingeordnet, auf Seite 8 unter "KI-Infrastruktur", auf Seite 12 unter "LLM-Runtime". Das Modell analysiert die Kontexte und wählt "KI-Modelle → LLMs → Runtime" als präziseste Einordnung.

Schritt 4: Provenance bewahren

Während der Konsolidierung werden Seiten-Referenzen behalten: Jede Kategorie merkt sich, auf welchen Seiten sie vorkommt. Das ermöglicht später Queries wie "Auf welchen Seiten wird 'KI-Modelle' behandelt?".

Ontologie-Konsolidierung: Knowledge Graph vereinigen

Die Ontologie-Konsolidierung führt Entitäten, Beziehungen und Properties zusammen:

Entity-Merging: Duplikate zusammenführen

Dieselbe Entität erscheint möglicherweise mit Varianten:

Das Modell erkennt via Fuzzy-Matching: Alle drei meinen dasselbe (ähnlicher Name, gleicher Typ). Die Entitäten werden zu einer zusammengeführt, alle Properties werden aggregiert:

{
  "name": "Ollama",
  "type": "Technology",
  "description": "Lokaler LLM-Inferenz-Server",
  "properties": {
    "port": 11434,
    "models": ["gemma3:4b-it-qat", "gpt-oss:20b", "mxbai-embed-large"],
    "location": "localhost"
  },
  "mentioned_on_pages": [5, 8, 12]
}

Relationship-Konsolidierung: Beziehungen deduplizieren

Wenn mehrere Seiten dieselbe Beziehung erwähnen, wird sie nur einmal gespeichert. Seite 5 und Seite 10 erwähnen beide "Pipeline uses Ollama". Diese Beziehung wird einmal gespeichert mit Referenzen auf beide Seiten.

Komplementäre Beziehungen werden zusammengeführt: Seite 5 sagt "Ollama uses gemma3", Seite 10 sagt "Ollama uses gpt-oss". Beide sind korrekt (Ollama nutzt mehrere Modelle). Beide Beziehungen werden behalten.

Transitive Beziehungen: Dependency-Ketten bilden

Das Konsolidierungs-Modell erkennt transitive Abhängigkeiten: Wenn Seite 5 sagt "A uses B" und Seite 8 sagt "B depends-on C", dann hängt A indirekt von C ab. Diese Kette wird als derived relationship gespeichert.

Das ermöglicht Impact-Analysen: "Was passiert, wenn C ausfällt?" → traversiere Dependency-Graph → finde alle direkten und indirekten Abhängigkeiten.

Semantik-Konsolidierung: Definitionen vereinheitlichen

Die Semantik-Konsolidierung führt Konzepte, Definitionen und Summaries zusammen:

Concept-Merging: Begriffsvarianten erkennen

Dasselbe Konzept erscheint mit verschiedenen Namen: "RAG", "Retrieval Augmented Generation", "Retrieval-Augmented-Generation". Das Modell erkennt die semantische Identität und führt sie zusammen zu "RAG (Retrieval Augmented Generation)".

Definition-Aggregation: Beste Definition wählen

Verschiedene Seiten liefern verschiedene Definitionen. Das Modell wählt die vollständigste, präziseste und klarste Definition als primäre. Alternative Definitionen werden als Varianten gespeichert.

Beispiel: "Embedding = Vektorisierung" (zu kurz) vs. "Embedding = numerische Repräsentation von Text in hochdimensionalem Vektorraum" (präzise). Die zweite wird gewählt.

Summary-Hierarchie: Von Seiten zu Dokument

Die seitenweisen Summaries (jede Seite hat 4 Layer) werden zu Kapitel-Summaries aggregiert, die wiederum zur Gesamt-Dokument-Summary konsolidiert werden. Daraus entstehen: Multi-Level-Summaries auf Seiten-, Kapitel- und Dokument-Ebene.

Das finale Ergebnis: Drei konsolidierte Modelle

Nach der Konsolidierung existieren drei finale JSON-Dateien:

Diese Modelle sind die Grundlage für die Speicherung in ChromaDB und MariaDB. Ohne Konsolidierung würde man fragmentierte, inkonsistente Daten speichern. Mit Konsolidierung sind die Daten kohärent, konsistent und vollständig.

Taxonomie-Konsolidierung im Detail

Aggregationsstrategie: Merge oder Select?

Bei der Taxonomie-Konsolidierung gibt es zwei Ansätze:

Die Pipeline nutzt einen Hybrid-Ansatz: Häufige Kategorien (die auf mehreren Seiten vorkommen) werden gemerged. Seltene Kategorien (die nur auf einer Seite vorkommen) werden nur übernommen, wenn sie thematisch passen. Das verhindert, dass der Baum mit Einzel-Kategorien überladen wird.

Hierarchie-Deduplizierung

Wenn verschiedene Seiten ähnliche, aber nicht identische Hierarchien haben, muss das Modell entscheiden:

Das Modell analysiert: Welcher Pfad ist präziser? "KI → LLMs" ist spezifischer als "Infrastruktur → LLM-Server". Der erste wird als primärer Pfad gewählt, der zweite als alternativer Pfad gespeichert.

Kategorie-Beschreibungen konsolidieren

Jede Kategorie hat eine Description. Wenn dieselbe Kategorie auf verschiedenen Seiten erscheint, hat sie möglicherweise unterschiedliche Beschreibungen. Das Modell wählt die präziseste und vollständigste Beschreibung.

Beispiel: "LLMs: Sprachmodelle" (zu kurz) vs. "LLMs: Large Language Models für Text-Generierung und -Verarbeitung" (vollständig). Die zweite wird gewählt.

Ontologie-Konsolidierung im Detail

Entity-Merging: Name Normalization

Entitäten werden via Fuzzy-Matching zusammengeführt. Der Algorithmus prüft:

Nur wenn alle drei Kriterien erfüllt sind, werden Entitäten gemerged. Das verhindert False Positives (zum Beispiel "Python" die Programmiersprache vs. "Python" das Reptil, beide vom Typ "Concept").

Property-Aggregation: Konflikte erkennen

Properties werden gesammelt. Duplikate (gleicher Key, gleicher Value) werden dedupliziert. Konflikte (gleicher Key, unterschiedlicher Value) werden als Array gespeichert mit Marker "conflict".

Beispiel: Seite 5 sagt "ChromaDB port: 8000", Seite 10 sagt "ChromaDB port: 8001". Beide werden behalten: "port": [8000, 8001] mit Flag "conflict_detected": true. Das wird im Quality-Report gemeldet.

Relationship-Deduplizierung

Beziehungen werden dedupliziert basierend auf Tripel (source, relationship_type, target). Wenn mehrere Seiten "A uses B" erwähnen, wird es einmal gespeichert mit allen Seiten-Referenzen.

Komplizierter wird es bei inversen Beziehungen: Seite 5 sagt "A uses B", Seite 8 sagt "B used-by A". Das Modell erkennt: Das ist dieselbe Beziehung in unterschiedliche Richtungen. Eine wird als kanonisch gewählt (uses), die andere als inverse gespeichert.

Transitive Closure: Dependency-Ketten explizit machen

Das Konsolidierungs-Modell bildet transitive Closures über Dependency-Beziehungen:

Die Kette: Pipeline → Ollama → gemma3 → Model-Weights wird explizit als derived relationship gespeichert: "Pipeline depends-on Model-Weights (transitive, via Ollama, gemma3)". Das ermöglicht Impact-Analyse ohne Graph-Traversierung zur Laufzeit.

Semantik-Konsolidierung im Detail

Concept-Merging: Synonyme und Akronyme

Konzepte werden via semantischer Ähnlichkeit gemerged. Das Modell erkennt:

Die finale Bezeichnung folgt einer Heuristik: Bei Akronymen wird "Akronym (Vollform)" gewählt. Bei Synonymen wird die häufigste Variante gewählt. Bei mehrsprachigen Varianten wird die Dokumentsprache bevorzugt.

Definition-Selection: Kriterien für beste Definition

Das Modell bewertet Definitionen nach fünf Kriterien:

Die Definition mit dem höchsten Gesamt-Score wird als primäre gewählt. Definitionen mit Score > 80% der besten werden als alternative Varianten gespeichert.

Summary-Hierarchie: Aggregation über Ebenen

Die Konsolidierung erstellt drei Summary-Ebenen:

Diese Hierarchie ermöglicht granulare Kontext-Auswahl: RAG kann Seiten-Summary für Details nutzen, Dokument-Summary für Überblick.

Quality Gates: Konsistenz-Prüfung nach Konsolidierung

Nach der Konsolidierung laufen automatische Validierungen:

Check 1: Referenz-Integrität

Zeigen alle Beziehungen auf existierende Entitäten? Sind alle parent_id-Referenzen in der Taxonomie valide? Werden in konzeptuellen Beziehungen nur existierende Konzepte referenziert?

Check 2: Widerspruchs-Erkennung

Gibt es widersprüchliche Aussagen? Seite 3: "A depends-on B", Seite 9: "A does-not-depend-on B". Solche Konflikte werden als "conflict" markiert und im Quality-Report aufgelistet.

Check 3: Vollständigkeits-Prüfung

Haben alle Konzepte Definitionen? Haben alle Entitäten Typen? Sind alle 4 Summary-Layer vorhanden? Diese Checks stellen sicher, dass keine unvollständigen Daten in die Datenbank gelangen.

Check 4: Hierarchie-Validierung

Ist die Taxonomie-Hierarchie zyklenfrei? Gibt es keine zirkulären Referenzen (A ist Kind von B, B ist Kind von A)? Ist die maximale Tiefe eingehalten (4 Ebenen)?

Erkannte Fehler werden im quality_report.json protokolliert mit Severity (critical, warning, info) und Kontext (auf welcher Seite, welches Modell).

Output: Konsolidierte Modelle

Die Konsolidierung produziert drei finale JSON-Dateien:

Zusätzlich: quality_report.json mit allen erkannten Konflikten, Warnings und Validierungs-Ergebnissen.

Diese vier Dateien sind die Grundlage für die finale Speicherung in ChromaDB (Vektoren mit Metadaten) und MariaDB (strukturierte Modelle).

Warum Konsolidierung den Unterschied macht

Konsolidierung ist der Schritt, den naive Implementierungen nicht haben. Sie speichern seitenweise Fragmente direkt in die Datenbank. Das führt zu:

Mit Konsolidierung entstehen kohärente, vollständige Modelle, die als Grundlage für hochwertige RAG-Systeme dienen. Das ist der Unterschied zwischen 30% und 75% Retrieval-Precision.

Danke, dass Du bis hierher gelesen hast!

Wenn Du Fragen zu diesem Werkzeug, zur strukturierten Dokumentenaufbereitung oder zu RAG-Systemen hast, dann schreib mir gerne an i@karlkratz.de.

Oder komm direkt in die KI-Gemeinschaft in den Chat! Dort tauschen wir uns regelmäßig über praktische KI-Implementierungen, Herausforderungen bei der Integration und Erfahrungen mit verschiedenen Ansätzen aus.

Liebe Grüße, Karl