Semantischer Suchdienst mit einer Pinecone-Vektordatenbank hinter einem MCP-Server

Ein Sprachmodell kann nur auf Basis dessen antworten, was es während des Trainings gesehen hat. Ingenieurstandards, Richtlinienhandbücher, Produktbeschreibungen und interne Wikis sind für es unsichtbar, es sei denn, dieses Material wird beim Stellen einer Frage bereitgestellt. Der hier beschriebene Prozess kümmert sich um solche Fälle bei PDF-Sammlungen: Die Dokumente werden einmal in Pinecone eingebettet, und jeder KI-Agent kann sie über einen mit dem FastMCP SDK erstellten MCP-Server abfragen.

Warum die Schlüsselwortsuche unzureichend ist

Die einfache Schlüsselwortsuche scheint die offensichtliche Lösung zu sein, doch die Menschen formulieren ihre Fragen selten mit genau den Worten, die in der Dokumentation verwendet werden, wodurch relevante Passagen übersehen werden. Synonymwörterbücher und Abfragerweiterungen helfen zwar, doch beide setzen voraus, dass Wortbeziehungen von Hand definiert wurden. Keines dieser Verfahren versteht die Bedeutung der Wörter.

Die semantische Suche verfolgt einen anderen Ansatz. Sowohl Dokumente als auch Abfragen werden in Vektordarstellungen umgewandelt, die die Bedeutung kodieren, und die Relevanz wird durch den Vergleich dieser Vektoren mithilfe der Kosinusähnlichkeit bestimmt – einem Maß dafür, inwieweit zwei Vektoren im Darstellungsraum in dieselbe Richtung zeigen. Ein höherer Wert bedeutet eine stärkere semantische Verbindung, sodass auch dann relevante Passagen angezeigt werden, wenn das Vokabular völlig unterschiedlich ist. Eine Frage wie „Wie wandeln Pflanzen Sonnenlicht in Energie um?“ kann Texte über Chloroplasten und Photosynthese zutage fördern, obwohl keiner dieser Begriffe darin vorkommt.

Zwei Komponenten: die Vektordatenbank und der MCP-Server

Das System besteht aus zwei unabhängig voneinander veränderbaren Teilen: einem Eingabepipeline-Modul und einem MCP-Server. Die Eingabe erfolgt einmal pro Dokument. Danach kann jeder verbundene Agent immer wieder über den Server auf dasselbe indizierte Wissen zugreifen.

Der Eingabepipeline wandelt Roh-PDFs in suchbare Vektoren um. Sie extrahiert den Text, teilt ihn in überschneidende Abschnitte auf, erstellt Embeddings mithilfe von Pinecone Inference und schreibt die Vektoren in einen Pinecone-Index. Das Erstellen von Embeddings für eine große Anzahl von Dateien erfordert erhebliche Rechenleistung, weshalb ein einfaches Protokoll davor schützt, dieselbe Arbeit mehrfach durchzuführen. Für jede indizierte Datei speichert die Pipeline das Zeitstempel des letzten Embeddings. Beim nächsten Ausführungsvorgang vergleicht die Pipeline die aktuelle Änderungszeit jeder Datei mit der gespeicherten Zeit. Geänderte Dokumente erhalten neue Embeddings, während unveränderte Dokumente ihre bestehenden Vektoren beibehalten. Dadurch bleibt die Datenbank stets auf dem neuesten Stand bezüglich der Dokumentänderungen, und es kommen keine redundanten Embedding-Aufrufe zustande.

Der auf FastMCP basierende MCP-Server erhält eine Frage in natürlicher Sprache von einem Agenten, embeddet sie, führt eine Ähnlichkeitssuche in Pinecone durch und gibt diejenigen Fragmente zurück, die die höchste Bewertung erhalten. Da die Schnittstelle MCP ist, können mehrere KI-Anwendungen denselben Abrufdienst teilen, ohne etwas über die Vektordatenbank oder das dahinterliegende Embedding-Modell zu wissen.

Die Trennung der beiden Komponenten war beabsichtigt. Das Wechseln von Embedding-Modellen, die Anpassung der Fragmentierungsmethode oder das Neubauen des Vektorindex kann ohne Berührung der MCP-Schnittstelle oder irgendeines darauf angewiesenen Agents erfolgen.

Erstellung der Embeddings und des Fragmentierungsprozesses

PDFs sind für menschliche Augen gedacht, nicht für die Maschinenabfrage, daher müssen sie zunächst in eine Darstellung umgewandelt werden, die die Bedeutung erfassen kann. Der Prozess beginnt damit, mit der Python-Bibliothek pypdf Text aus jeder Datei abzurufen, Seite für Seite zu lesen und das Ergebnis zu einem einzigen String zusammenzufügen, um es später leichter verarbeiten zu können. Er akzeptiert sowohl einzelne Dateien als auch ganze Verzeichnisse, sodass neue Dokumentensätze ohne Änderungen auf der Abfrageseite indiziert werden können.

Wahl der Aufteilung in Blöcke

Durch die Extraktion des Textes wird das Dokument in kleinere Teile namens Blöcke aufgeteilt, und diese Entscheidung erwies sich als eine der entscheidendsten in der gesamten Verarbeitungskette. Embedding-Modelle haben feste Kontextfenster, was die Einbettung eines gesamten Dokuments als einen einzigen Vektor ausschließt. Selbst wenn ein Dokument hineinpasst, liefert eine einzige Embedding-Verarbeitung des gesamten Files eine allgemeine, unklare Darstellung, da mehrere unzusammenhängende Themen zusammengepresst werden und dadurch die Genauigkeit der Suche abnimmt.

Jedes Dokument wird somit in überschneidende Blöcke fester Größe aufgeteilt, wodurch jede Embedding-Struktur einen kleineren, präziseren Textabschnitt repräsentieren kann. Die Wahl der Größe erfordert ein Gleichgewicht zwischen Kontext und Spezifität. Kleine Blöcke liefern in der Regel genauere Ergebnisse, da jede Embedding-Struktur eine engere Idee erfassen kann, doch sie erzeugen mehr Vektoren und erhöhen die Indexierungszeit sowie den Speicherbedarf. Große Blöcke beinhalten mehr umliegenden Kontext und verringern die Anzahl der Vektoren, doch jede Embedding-Struktur umfasst einen größeren Informationsumfang, was die Genauigkeit beeinträchtigen kann. Semantische oder satzorientierte Aufteilungsmethoden bieten eine fortgeschrittendere Alternative, doch die einfache Aufteilung in feste Blöcke hat sich als einfache und effektive Grundlage für allgemeine Suchanwendungen erwiesen.

chunks = [
    text[i:i+500]
    for i in range(0, len(text), 450)
]

/*
Fixed-size overlapping chunk generation used during document ingestion.
A chunk length of 500 characters and a stride of 450 characters preserve
contextual continuity while maintaining semantic specificity.
*/

Embeddings mit Pinecone

Dann werden die Textabschnitte zu Embeddings. Ein Embedding ist eine dichte numerische Darstellung von Text, die seine Bedeutung kodiert. Anstatt Schlüsselwörter abzugleichen, vergleicht die semantische Suche Vektoren, sodass verwandte Abschnitte trotz unterschiedlicher Vokabulare übereinstimmen. Die Vektoren für „Katze“ und „Hund“ liegen im Embedding-Raum nah beieinander, während „Katze“ und „Flugzeug“ weit voneinander entfernt sind – dadurch kann die Ähnlichkeit mathematisch berechnet werden, anstatt durch eine exakte Wortübereinstimmung.

Das hier verwendete Embedding-Modell ist Pinecones gehostetes multilingual-e5-large, das über die Pinecone Inference API zugänglich ist. Ein gehosteter Service bedeutet, dass es kein separates Machine-Learning-Modell gibt, das bereitgestellt oder gewartet werden muss, wodurch der Eingabekod sich auf die Dokumentverarbeitung konzentrieren kann und die Architektur einfacher bleibt.

Dieses Modell wurde ausgewählt, weil es für die semantische Suche optimiert ist und mehr als hundert Sprachen abdeckt. Die E5-Familie behandelt zudem Abfragen sowie Dokumentabschnitte als unterschiedliche Eingabetypen, was der Suche zugutekommt. Bei der Indizierung werden die Blöcke als Abschnitte eingebettet, da es sich dabei um den suchbaren Inhalt handelt. Bei der Abfrage wird die Frage des Benutzers als Abfrage eingebettet. Beide landen im selben semantischen Raum, was die Chancen erhöht, das richtige Material zu finden – selbst wenn die Formulierung stark abweicht.

Was die Durchsatzrate betrifft, so werden die Datenblöcke in Gruppen zu je 96 Stück an die API gesendet – das ist die größte Gruppengröße, die Pinecone Inference derzeit für den Modus multilingual-e5-large zulässt. Das Senden vieler Datenblöcke pro Anfrage verringert die Anzahl der API-Aufrufe, nutzt die Ressourcen effizienter aus und verkürzt den Indexierungsprozess im Vergleich zum Schicken der Datenblöcke einzeln. Die fertigen Embeddings sowie ihre Metadaten werden anschließend in der Pinecone-Vektordatenbank gespeichert und sind somit für die Abfrage bereit.

embeddings = pc.inference.embed(
    model="multilingual-e5-large",
    inputs=batch,
    parameters={"input_type": "passage"}
)

Der MCP-Server für semantische Suche

Sobald die Dokumente indiziert sind, benötigen die Agenten einen Zugang dazu. Anstatt die Vektordatenbank direkt den Anwendungen zur Verfügung zu stellen, wird sie durch einen mit FastMCP erstellten Model Context Protocol-Server abgelegt. MCP bietet KI-Anwendungen eine einheitliche Methode, um Tools aufzurufen, sodass jeder kompatible Client Suchfunktionen nutzen kann, ohne etwas über die zugrunde liegende Datenbank oder das Embedding-Modell zu wissen. Die zusätzliche Schicht ermöglicht es, den Suchcode wiederverwendbar zu halten, seine Wartung zu erleichtern und ihn von den Anwendungen zu entkoppeln, die ihn nutzen.

Die Suche ist die Hauptaufgabe des Servers. Wenn ein Agent eine Frage einreicht, embeddet der Server diese mithilfe desselben multilingual-e5-large-Modells, das auch bei der Indizierung verwendet wurde, führt eine Ähnlichkeitssuche im Pinecone-Index durch und gibt die am besten bewerteten Ergebnisse zurück. Die Verwendung desselben Modells auf beiden Seiten sorgt dafür, dass Ergebnisse und Abfragen im selben semantischen Raum bleiben, was einen sinnvollen Vergleich ermöglicht.

Zur Verbesserung der Ergebnisqualität zeigt das Suchtool nur Ergebnisse an, deren Kosinusähnlichkeit über 0,82 liegt. In Experimenten bedeuteten Werte über dieser Schwelle in der Regel eine starke semantische Übereinstimmung zwischen Abfrage und Textabschnitt, während niedrigere Werte höchstens eine lose Beziehung nahelegten. Durch das Ausschließen der schwächeren Ergebnisse erhalten nachgeschaltete Sprachmodelle relevantere Kontexte. Eine Frage wie „Wie reiche ich einen Ausgabenbericht ein?“ kann die richtige Richtlinienseite erreichen, selbst wenn der Dokumenttext dies anders formuliert. Neben der Suche stellt der Server auch Werkzeuge zur Verwaltung der Vektordatenbank bereit: zum Einfügen von Vektoren, zum Löschen derselben sowie zur Auflistung der verfügbaren Indizes.

Da das System für den Einsatz in Unternehmen konzipiert ist, ist die Sicherheit bereits bei der Gestaltung berücksichtigt. Die Anmeldeinformationen stammen aus Azure Key Vault, und jeder Anfrage muss vor jeder Abfrage eine gültige API-Schlüssel vorliegen. Sensible Infrastrukturdaten bleiben von Client-Anwendungen getrennt, und der Zugriff auf die indizierten Dokumente ist geschützt.

results = index.query(
    vector=query_embedding,
    top_k=5,
    include_metadata=True
)

Was das Projekt über RAG für interne Dokumente zeigt

Ein effektives semantisches Suchsystem hängt genauso stark von ingenieurtechnischen Entscheidungen ab wie von den zugrunde liegenden Sprachmodellen. Die Chunking-Strategie, das Embedding-Modell, der Batching-Ansatz sowie die Sucharchitektur prägen direkt Qualität, Skalierbarkeit und Wartbarkeit. Die Verwaltung von Eingabe- und Suchvorgängen über einen MCP-Server ergibt ein modulares System, das wiederverwendbar ist, einfach zu warten und bei sich ändernden Anforderungen leicht erweiterbar.

Die aktuelle Version bildet eine solide Grundlage mit ausreichend Raum für weitere Entwicklung. Semantisches Chunking, Modell-Umranking, hybride Suchverfahren sowie umfangreichere Metadaten könnten die Suchleistung weiter verbessern, ohne die modulare Struktur zu beeinträchtigen. Da die suchunterstützte Generierung in der UnternehmenskI zur Routine wird, entwickelt sich eine zuverlässige semantische Suche zu einem grundlegenden Baustein von Produktionsystemen. Die Kombination von Pinecone Inference mit einer MCP-Suchschicht ist eine praktische und skalierbare Methode, um wiederverwendbare semantische Suchfunktionen zu erstellen.