Dokumente in MongoDB speichern
Viele Unternehmen verfügen über eine beachtliche Menge an technischem Wissen – nicht in Form von Tabellen oder strukturierten Datenbanken, sondern in Formaten wie PDF-Handbüchern, internen Richtlinien oder archivierten E-Mail-Anhängen. Genau dort steckt oft das Expertenwissen, das in der operativen Praxis gebraucht wird. Wer beispielsweise einen digitalen Assistenten für Wartungstechnik, Support oder interne Prozesse entwickeln will, benötigt Zugriff auf diese Informationen. Doch wie macht man daraus eine durchsuchbare, kontextfähige Wissensquelle für ein KI-Modell?
Im Zentrum steht die Fähigkeit, Binärdaten zu speichern, sie zu analysieren und mit zusätzlichem Kontext auszustatten. MongoDB bietet mit GridFS dafür ein robustes Werkzeug: ein eingebautes Dateisystem, das große Binärdateien direkt innerhalb der Datenbank verwalten kann – strukturiert, versionierbar und nahtlos integriert.
Vom PDF zur semantisch suchbaren Information
Stellen wir uns eine Anwendung vor, in der Techniker und Technikerinnen auf Handbuchinhalte für Maschinen unseres Unternehmens zugreifen sollen, um Fragen wie „Was bedeutet Fehlercode 317-B beim Modell ZX900?“ zu klären. Die Inhalte liegen als mehrsprachige PDF-Dateien vor, unter anderem in unterschiedlichen Versionen für verschiedene Regionen. Klassische Datenbanken stoßen hier schnell an ihre Grenzen – nicht nur wegen der Dateigröße, sondern vor allem wegen der fehlenden Semantik.
Mit GridFS wird das PDF zunächst als Byte-Array geladen und in der Datenbank abgelegt:
var bucket = new GridFSBucket(database);
await bucket.UploadFromBytesAsync("zx900_manual_de.pdf", pdfBytes);
Die Rückgabe dieses Befehls enthält eine ObjectId, die als Referenzpunkt für spätere Verknüpfungen dient. Während die Datei im Hintergrund gespeichert ist, extrahieren wir ihren Text – etwa mit einer .NET-kompatiblen Bibliothek wie PdfPig oder TikaOnDotNet – und bereiten ihn für die semantische Analyse vor. In einem weiteren Schritt wird ein Embedding erzeugt, das die Bedeutung des Textes als Vektor im semantischen Raum abbildet. Hierzu müssen die Inhalte vorab aufgeteilt werden, um nicht ein gesamtes Handbuch als ein einzelnes Objekt zu verarbeiten – dazu aber später mehr.
Wir können also anhand der ausgelesenen Texte und unseres KI-Modells die Vektordaten generieren lassen. Dies geht für OpenAI zum Beispiel mit dem OpenAI-SDK unter .NET. Wir erhalten hierbei immer ein mehrdimensionales Array an Zahlenwerten, welche die Vektoren repräsentieren.
Der Textinhalt, das Embedding sowie die Referenz zur PDF werden schließlich gemeinsam in einem Dokument abgelegt:
var entry = new ManualEntry
{
Title = "Diagnosehandbuch ZX900",
Content = extractedText,
Embedding = embedding.Data[0].Embedding.ToArray(),
GridFsId = gridFsId
};
await collection.InsertOneAsync(entry);
So entsteht ein dreiteiliges Konstrukt: Das Originaldokument verbleibt im Dateisystem, der relevante Text ist direkt abfragbar, und die semantische Bedeutung wird durch das Embedding repräsentiert.
Semantische Suche im KI-Kontext
Der wahre Nutzen dieses Aufbaus zeigt sich, wenn Inhalte nicht nach exakten Begriffen, sondern nach ihrer Bedeutung gefunden werden sollen. Wer „Wie wechsle ich das Plasmaventil?“ fragt, meint semantisch dasselbe wie „Wie ersetze ich die Ventilgruppe 4B?“ – auch wenn kein einziges Wort übereinstimmt. Genau hier kommen Vektorindizes ins Spiel, die die Inhalte semantisch durchsuchen können.
MongoDB Atlas bietet dafür einen eigenen Vektor-Index, der über das relevante Embedding-Feld gelegt wird. Die Suche funktioniert wie eine semantische Ähnlichkeitsabfrage – schnell, skalierbar und filterbar. Eine solche Suche kann aus .NET heraus mittels folgender MongoDB-Syntax durchgeführt werden:
var pipeline = new BsonDocument[]
{
new BsonDocument("$vectorSearch", new BsonDocument
{
{ "index", "embedding_index" },
{ "queryVector", new BsonArray(queryEmbedding) },
{ "path", "embedding" },
{ "numCandidates", 100 },
{ "limit", 5 },
{ "similarity", "cosine" }
})
};
Damit dieser Mechanismus funktioniert, muss auch der Suchtext des Nutzers – etwa eine eingetippte Frage – zunächst in ein semantisches Embedding umgewandelt werden. Erst durch diese Übersetzung lässt sich die Anfrage in denselben Vektorraum überführen, in dem auch die Dokumentinhalte bereits abgelegt wurden. Der eigentliche Vektorvergleich erfolgt dann über ein Ähnlichkeitsmaß – in diesem Fall die Kosinus-Ähnlichkeit. Das Feld "numCandidates" legt fest, wie viele potenzielle Treffer geprüft werden, während "limit" angibt, wie viele Ergebnisse zurückgegeben werden sollen. Die Suche wird über das Feld "embedding" geführt, in dem sich das gespeicherte Vektor-Array befindet.
Das Ergebnis der Abfrage enthält nicht nur die Inhalte, sondern auch einen Relevanz-Score, der angibt, wie ähnlich das jeweilige Segment zur ursprünglichen Anfrage ist. Die besondere Stärke liegt in der Möglichkeit, diese semantische Suche mit klassischen Filtern (zum Beispiel nach Sprache, Kategorie oder Dokumentdatum) zu kombinieren – ein echter Vorteil gegenüber spezialisierten Vektordatenbanken.
Segmentierung entscheidet über Qualität
Ein Aspekt, der häufig unterschätzt wird, aber maßgeblich über die Qualität der Ergebnisse entscheidet, ist die Segmentierung der Texte. Denn Large Language Models wie GPT arbeiten am effektivsten mit klar abgegrenzten, thematisch konsistenten Einheiten – sogenannten Chunks.
Diese Einheiten sollten weder zu groß noch zu klein sein, und vor allem sinnvoll getrennt. Wird ein Segment beispielsweise mitten im Satz abgebrochen, sinkt die semantische Aussagekraft und das Modell verliert den Kontext. Besonders kritisch ist das bei technischen Inhalten: In einem Handbuch ergeben Absätze oft nur in Kombination mit ihrer Einleitung oder Abschlussbemerkung Sinn. In Codebeispielen wiederum führt eine Chunkgrenze, die mitten in einer verschachtelten Klammerstruktur liegt, zu Fragmenten, die beim Auffinden keinen verwertbaren Mehrwert bieten.
Um solche Situationen zu vermeiden, kommen unterschiedliche Techniken zum Einsatz – von einfachen Heuristiken (zum Beispiel Trennung nach Absätzen oder Satzende) bis hin zu semantischer Segmentierung, bei der Textteile nach Themenclustern analysiert und aufgeteilt werden. Letztlich gilt: Je durchdachter die Segmentierung und je gezielter die Auswahl der Suchparameter, desto präziser wird die spätere Kontextgenerierung. Und genau das ist entscheidend, wenn der Nutzer am Ende nicht nur irgendeine Antwort will – sondern die richtige.
Vom Projekt zur produktiven Plattform
In realen KI-Projekten im .NET-Umfeld zeigt sich immer wieder, wie wertvoll diese Architektur ist. Ein häufiges Szenario ist die Erweiterung bestehender Wissensdatenbanken oder Content-Management-Systeme. Statt bestehende Inhalte zu migrieren oder Systeme zu ersetzen, lassen sich Binärdaten, extrahierte Texte und Embeddings einfach ergänzen. Entwickler:innen können mit typisierten Klassen, vertrauten Tools und bekannten Workflows arbeiten – aber erhalten Zugriff auf semantische Suche, KI-Funktionen und moderne Abfragekonzepte.
Konsistenz als Schlüssel zur Robustheit
Die Datenbasis wächst dabei kontinuierlich. Jedes neue Dokument, jede zusätzliche Sprache oder Version kann als weiteres GridFS-Objekt gespeichert werden. Die Verarbeitung erfolgt im Hintergrund – idealerweise asynchron in einer .NET-Worker-Queue –, während die Inhalte indiziert, segmentiert und mit Embeddings versehen werden. Diese Modularität erlaubt nicht nur technische Skalierbarkeit, sondern auch inhaltliche Erweiterung: Wartungsprotokolle, Changelogs, Präsentationen – alles lässt sich in die bestehende Struktur integrieren.
Eine Plattform für Daten, Kontext und Bedeutung
MongoDB erweist sich im Zusammenspiel mit .NET als weit mehr als ein Dokumentenspeicher. In Verbindung mit GridFS, semantischer Vektorsuche und einer typisierten .NET-Integration entsteht eine skalierbare, robuste und durchgängige Lösung für KI-getriebene Systeme.
Von der Speicherung binärer Inhalte über die Aufbereitung relevanter Texte bis hin zur semantischen Suche deckt MongoDB den gesamten Lebenszyklus von KI-Wissensdaten ab. Besonders im Microsoft-Umfeld, wo .NET Core, Azure und OpenAI häufig bereits im Einsatz sind, bietet sich diese Kombination als ideale Architekturplattform an – nicht als Speziallösung, sondern als produktionsreifer, integrativer Bestandteil intelligenter Anwendungen.
Diese Architektur setzen auch wir aktiv in unseren KI-Projekten ein, wenn es darum geht, große Dokumentenmengen und Informationen als natürlichen Text zu verarbeiten.
Wer also mit LLMs nicht nur experimentieren, sondern echte Antworten liefern will, findet in dieser Architektur, welche die Basis eines RAG bildet, einen durchdachten, skalierbaren und wartbaren Weg – für Supportsysteme, interne Assistenzlösungen oder smarte Wissensportale gleichermaßen.
