Semantische Suche und Embeddings im Unternehmen

Die meisten Unternehmenswissensdatenbanken werden immer noch volltextbasiert durchsucht: Finde Dokumente, die diese Wörter enthalten. Das funktioniert, wenn der Mitarbeiter die Terminologie kennt. Es funktioniert nicht, wenn der Kunde anders schreibt als die Dokumentation, wenn Fragen Konzepte betreffen, die in verstreuten Fragmenten beschrieben sind, oder wenn mehrere Abteilungen denselben Prozess unterschiedlich benennen. Die semantische Suche löst genau dieses Problem – ohne Dokumente umschreiben zu müssen.

Ein Embedding ist eine Darstellung von Text als Zahlenvektor. Ein Embedding-Modell (ein auf einem großen Korpus trainiertes neuronales Netz) bildet jeden Satz in einen mehrdimensionalen Raum ab, sodass Sätze mit ähnlicher Bedeutung nahe beieinander landen und Sätze mit unterschiedlicher Bedeutung weiter voneinander entfernt. Das ist keine Suche nach Hashes oder N-Grammen – es ist die Geometrie der Bedeutung.

Praktischer Effekt: Der Satz „wie storniere ich eine Bestellung“ und der Satz „Verfahren zum Rücktritt vom Vertrag“ landen in benachbarten Punkten im Raum, obwohl sie kein gemeinsames Wort haben. Eine klassische Volltextsuche behandelt diese Anfragen als disjunkt. Eine semantische Suchmaschine behandelt sie als bedeutungsähnlich.

Mechanismus kurz zusammengefasst:

1. Jeder Ausschnitt der Wissensdatenbank wird einmal in einen Embedding umgewandelt (während der Indizierung).
2. Die Anfrage des Benutzers wird in Echtzeit in einen Embedding umgewandelt.
3. Die Engine berechnet die kosinusähnlichkeit zwischen dem Anfragevektor und den Dokumentvektoren.
4. Es werden Fragmente mit der höchsten semantischen Übereinstimmung zurückgegeben, unabhängig von den verwendeten Wörtern.

Die Wahl des Embedding-Modells hat direkten Einfluss auf die Suchqualität, Geschwindigkeit und ob Daten überhaupt Ihre Infrastruktur verlassen. Grundregel der Sicherheit: Interne Inhalte (Verträge, Verfahren, Kundendaten) sollten lokal eingebettet werden, bevor etwas an ein externes generatives Modell gesendet wird.

Wir nutzen BGE-M3, das lokal über Ollama ausgeführt wird. BGE-M3 erzeugt 1024-dimensionale Vektoren, unterstützt Mehrsprachigkeit (inkl. Polnisch) ohne Übersetzung der Anfragen und läuft auf der CPU Ihres Firmenservers – keine Inhalte verlassen Ihr Netzwerk während der Indizierung.

Wenn Daten vertraulich oder durch RODO geschützt sind, wählen wir lokales Hosting. Bei öffentlichen Inhalten (z. B. Produktkataloge ohne personenbezogene Daten) ist ein Cloud-Endpunkt akzeptabel, sofern PII-Maskierung vor dem Senden erfolgt.

Vektoren werden in einer Vektordatenbank gespeichert. In unserem Stack ist das Qdrant, das auf einem eigenen Server läuft (lokaler Storage, keine ausgehenden Verbindungen). Qdrant unterstützt:

• ANN-Suche (Approximate Nearest Neighbor) mit HNSW-Index – eine Million Vektoren in wenigen Millisekunden,
• Payload-Filterung – suche semantisch nur in Dokumenten der Kategorie „HR-Verfahren“ oder nur in aktiven Produkten,
• Named Vectors – dasselbe Dokument hat einen Embedding für die Suche und einen separaten für das Reranking.

Alternativen sind pgvector (PostgreSQL-Erweiterung – gute Option, wenn Sie eine einzige Datenbank für alles möchten) und Weaviate (vollständige Plattform mit eigenem Schema). Qdrant wählen wir für Projekte, die hohe Abfrage-Durchsatzraten und Datentrennung auf Sammlungsebene erfordern.

Hybride Suche kombiniert Volltextergebnisse (BM25) mit semantischen Ergebnissen und vereint sie durch Reranking. Das ist entscheidend bei:

• Anfragen nach Codes oder Nummern – „Gesetz 2025/0048“ wird präzise durch BM25 gefunden, nicht durch Semantik,
• Anfragen nach Eigennamen – Embedding-Modelle kommen mit einzigartigen Produktnamen, SKUs oder Nachnamen schlechter zurecht,
• kurzen einsilbigen Anfragen – zu wenig Kontext, als dass Semantik einen Vorteil bringen würde.

In der Praxis sucht die Hybrid-Engine parallel mit BM25 und ANN, vereint die Ergebnisse mit Reciprocal Rank Fusion (RRF) und lässt dann einen Reranker (Cross-Encoder) sie unter Berücksichtigung des vollständigen Kontexts Anfrage+Fragment neu bewerten. Ergebnis: höhere Qualität bei variierenden Fragetypen, als ein einzelner Mechanismus liefern könnte.

Mehr zu diesem Muster im Artikel RAG oder Fine-Tuning – die Hybride ist einer der Gründe, warum sich RAG so gut auf diversen Wissensdatenbanken skalieren lässt.

RAG (Retrieval-Augmented Generation) ist eine Architektur, bei der das generative Modell nicht „aus dem Kopf“ antwortet, sondern zunächst abgerufene Fragmente Ihres Wissens erhält und dann eine Antwort mit Quellenangaben konstruiert. Embeddings und die Vektordatenbank sind genau diese „Suche“ im Inneren von RAG.

Praktischer Pipeline:

1. Das Dokument wird in Fragmente unterteilt (Chunking – normalerweise 256–512 Token mit Überlappung).
2. Jedes Fragment wird eingebettet (Embedding) und in Qdrant mit Metadaten (Kategorie, Datum, Abteilung) gespeichert.
3. Die Benutzeranfrage wird eingebettet und in Qdrant gesucht.
4. Die Top-k-Fragmente gelangen als Kontext über einen Modell-Router an das LLM.
5. Das Modell antwortet ausschließlich auf Basis dieser Fragmente und gibt Zitate an.

Wenn die Suche kein Fragment mit ausreichender Übereinstimmung findet (Ähnlichkeitsschwelle), sagt das System „ich weiß es nicht“ und eskaliert an einen Menschen – statt zu erfinden. Das ist Human-Handoff, kein Architekturfehler.

Den gesamten Pipeline beschreiben wir auch im Artikel Wo anfangen mit der AI-Einführung – die semantische Suche ist eine der am schnellsten rentablen Implementierungen, weil sie auf dem bestehenden Unternehmenswissen aufbaut.

Nicht jede Wissensdatenbank braucht Embeddings. Es lohnt sich, sie einzuführen, wenn:

• Benutzer nicht die richtigen Dokumente finden, obwohl sie existieren – weil sie anders fragen, als die Dokumentation geschrieben ist.
• Das Unternehmen über einige hundert Dokumente verfügt und verschiedene Abteilungen dieselben Konzepte unterschiedlich benennen.
• Sie einen Assistenten aufbauen möchten, der auf Basis interner Daten Fragen beantwortet (RAG).
• Die Daten mehrere Sprachen betreffen oder Kunden informell schreiben (Kundenservice, E-Commerce).

Führen Sie keine semantische Suche als ersten Schritt ein, wenn die Wissensdatenbank nicht existiert oder chaotisch ist. Embeddings spiegeln die Qualität der Eingabedaten wider. Die Ordnung eines engen Ausschnitts für einen ausgewählten Prozess ist schneller und liefert bessere Ergebnisse als das Einbetten inkonsistenter Dateien.

Prüfen Sie die Bereitschaft Ihrer Organisation mit der AI-Bereitschaftsbewertung – eine der Dimensionen betrifft direkt den Zustand der Wissensdatenbank.

Die Kosten hängen vom Dokumentenvolumen, der Modellwahl und der Zielarchitektur ab. Richtwerte für ein Pilotprojekt:

• Die Indizierung von einigen tausend Fragmenten auf einem Standard-CPU-Server dauert Minuten.
• BGE-M3 lokal: keine Lizenzkosten, Kosten für Hardware oder VPS-Server.
• Cloud-Embeddings: einige Cent pro Million Token (unter 1 USD für eine typische KMU-Wissensdatenbank).
• Qdrant Self-Hosted: kostenlos (Open-Source), Hosting-Kosten.

Die Rendite lässt sich am einfachsten im Kundenservice-Szenario berechnen: Wenn das semantische System 30 % der Anfragen ohne menschliches Zutun abschließt und ein Agent N Zł/h kostet, haben Sie einen einfachen Rechner. Berechnen Sie es selbst mit dem ROI-Rechner.

Ein vollständiges Projekt (Indizierung + RAG + Interface + Guardrails) schätzen wir nach einer Datenprüfung. Ein Pilot für einen Wissensbereich ist in der Regel innerhalb weniger Wochen abgeschlossen. Kontaktieren Sie uns über das Kontaktformular, um den Umfang zu besprechen.

Der folgende Sandbox führt denselben semantischen Mechanismus aus wie unsere Implementierungen – fügen Sie einen Dokumentenausschnitt ein und stellen Sie eine Frage. Das Modell antwortet ausschließlich auf Basis Ihres Textes, nicht aus dem eigenen Gedächtnis. PII wird vor dem Modell maskiert, keine Speicherung.

Die Volltextsuche (z. B. Elasticsearch, PostgreSQL FTS) sucht nach Dokumenten, die die angegebenen Wörter oder deren Abwandlungen enthalten. Die semantische Suche wandelt die Anfrage in einen Embedding um und sucht nach Dokumenten mit ähnlicher Bedeutung, unabhängig von den verwendeten Wörtern. In der Praxis: Ein Kunde, der nach „Reklamation“ fragt, findet eine Prozedur, die mit dem Wort „Meldung“ beschrieben ist – was eine klassische Suchmaschine nicht verbindet.

Nur, wenn Sie ein Cloud-basiertes Embedding-Modell wählen. Bei lokalem BGE-M3 (Ollama) verlassen die Inhalte Ihre Infrastruktur während der Indizierung nicht. Zum generativen Modell gelangen nur die Kontextfragmente der Suche, zuvor durch unseren Router mit PII-Maskierung. Sensible Daten können während des gesamten Pipelines lokal bleiben.

Die semantische Suche beginnt bereits ab einigen Dutzend Dokumenten einen deutlichen Vorteil gegenüber der Volltextsuche zu bieten, wenn die Anfragen sprachlich vielfältig sind. Unter einem Dutzend Dokumenten reicht ein einfacher BM25 aus. Bei mehr als einigen tausend Fragmenten lohnt es sich, auf Chunking und Metadaten zu achten – die Qualität der Dokumentenaufteilung beeinflusst die Antwortqualität stärker als die Wahl des Embedding-Modells.

Ein Pilot für einen Wissensbereich (z. B. FAQ-Kundenservice oder HR-Verfahren) dauert in der Regel einige Wochen, abhängig vom Zustand und Umfang der Daten. Die Implementierung verzögert sich bei einer inkonsistenten Wissensdatenbank, die aufgeräumt werden muss, oder bei der Notwendigkeit der Integration mit externen Systemen (CRM, ERP). Mehr zu den Implementierungsschritten im Artikel Wo anfangen mit der AI-Einführung.

Die semantische Suche selbst verstößt nicht gegen RODO. Entscheidend ist, was Sie indizieren und wo Sie die Vektoren speichern. Wenn Dokumente personenbezogene Daten enthalten, gilt RODO: Rechtsgrundlage, Datenminimierung, Recht auf Löschung. Bei lokalem Hosting (Qdrant on-prem, BGE-M3 lokal) verlassen die Daten Ihre Infrastruktur nicht. Rechtliche Details beschreibt der Artikel AI Act und RODO 2026.