Ein Nutzer tippt „Mein Handy mit dem Authenticator ist weg“ in die Hilfesuche. Der passende Artikel heißt jedoch „Zweiten Faktor verloren“ – kein einziges Hauptwort stimmt überein. Gleichzeitig liegt im selben System eine interne Admin-Notiz zum Zurücksetzen von Konten, die niemals öffentlich auftauchen darf. Wie findet deine Suche die richtige Anleitung, ohne interne Dokumente preiszugeben?
Eine semantische Suche übersetzt Dokumentabschnitte und Suchanfragen über ein Embedding-Modell in denselben Vektorraum und vergleicht ihre Richtung. Dadurch erkennt sie inhaltliche Nähe auch bei völlig anderen Formulierungen. In der Praxis liefert der reine Vektorvergleich aber nur Rohkandidaten: Erst serverseitige Berechtigungs- und Versionsfilter, saubere Quellmetadaten und eine begleitende Keyword-Suche für exakte Fehlercodes machen daraus eine verlässliche Produktsuche.
Der Vektorvergleich überbrückt den Wortschatz zwischen Frage und Dokument – ob ein Treffer erlaubt, aktuell und fachlich richtig ist, entscheiden aber deine Filter und Metadaten.
Was gehört neben dem Vektor in den Suchindex?
Ein Vektor speichert keine lesbaren Sätze, sondern nur Koordinaten. Wenn deine Suche Treffer anzeigen, nach Produktversionen filtern oder Zugriffsrechte prüfen soll, muss jeder Eintrag im Index neben dem Embedding auch sein eigenes Kontextpaket mitführen:
- Stabile Dokument- und Abschnitt-ID: Damit mehrere Treffer aus demselben Artikel zusammengeführt und Quellen eindeutig verlinkt werden können.
- Lesbarer Quelltext und Titel: Ohne gespeicherten Text oder direkten Verweis auf die Primärdatenbank kann die Oberfläche nur IDs und Zahlenwerte ausgeben.
- Zugriffs- und Versionsmerkmale: Felder wie
visibility: "public"oderversion: 2müssen direkt am Eintrag hängen, damit unberechtigte oder veraltete Inhalte gar nicht erst in die engere Auswahl gelangen. - Modell-Signatur: Speichere die genaue Modellkennung (z. B.
multilingual-e5-base) zusammen mit dem Indexstand.
Unser deutscher Support-Datensatz (CC0) bildet genau dieses Spannungsfeld ab: Neben aktuellen Hilfeartikeln zu Passwort-Reset und verlorenem zweiten Faktor enthält er bewusst eine veraltete Anleitung (v1) und ein internes Admin-Dokument. Eine produktive Suche für Version 2 muss solche Einträge bereits auf Datenbankebene ausschließen.
Warum müssen Anfrage und Dokument denselben Modellraum teilen?
Damit die Suche zur Laufzeit nicht jedes Mal alle Dokumente neu durch ein Sprachmodell schicken muss, setzt man auf einen (Architektur, bei der Suchanfrage und Dokument getrennt voneinander in Vektoren übersetzt werden; Dokumentvektoren lassen sich dadurch vorab berechnen und indizieren.). Die Dokumente werden einmalig beim Indexieren eingebettet; bei einer Suchanfrage berechnet der Server nur noch den einzelnen Anfragevektor und sucht die nächsten Nachbarn im Index.
Dabei gilt eine harte technische Grenze: Vektoren sind nur innerhalb desselben Modells und derselben Konfiguration vergleichbar. Zwei Vektoren mit jeweils 768 Dimensionen aus unterschiedlichen Modellen teilen keinen gemeinsamen Bedeutungsraum – ihr Kosinus-Vergleich liefert Zufallszahlen. Selbst ein Versionswechsel desselben Modells erfordert eine vollständige Neuindexierung aller Dokumente.
Achte außerdem auf asymmetrische Eingabeformate: Wenn Nutzer kurze Fragen stellen („Authenticator weg“), die Zieltexte aber längere Absätze sind, verlangen viele Modelle unterschiedliche Präfixe oder Task-Typen für Anfrage (query) und Dokument (passage). Wie die Sentence-Transformers-Dokumentation zu Semantic Search zeigt, verschlechtert das Weglassen dieser Rollen die Trefferqualität spürbar.
Ein Kosinus-Score von 0.82 bedeutet nicht, dass der Treffer mit 82 % Sicherheit die Frage beantwortet. Ein allgemeiner Artikel über „Passwort vergessen“ liegt im Vektorraum oft sehr nah an „Zweiten Faktor verloren“, hilft dem Nutzer ohne Authenticator-App aber überhaupt nicht weiter.
Die 5 Schritte einer produktiven Suchanfrage
- Suchraum serverseitig eingrenzen: Ermittle Mandant, Nutzerrolle und Produktversion aus der authentifizierten Sitzung auf dem Server – vertraue niemals Filterparametern, die der Browser mitschickt.
- Anfrage einbetten: Berechne das Embedding der Suchanfrage mit exakt demselben Modell, Tokenizer und Query-Präfix, das beim Aufbau des aktuellen Index verwendet wurde.
- Top-k-Kandidaten abrufen: Suche die ähnlichsten Vektoren innerhalb des freigegebenen Teilbestands. (Begrenzt die Rückgabe auf die k Kandidaten mit dem höchsten Ähnlichkeitswert – unabhängig davon, ob tatsächlich k sinnvolle Antworten im Bestand existieren.) liefert dabei immer bis zu
kEinträge, selbst wenn die Frage nichts mit deinen Dokumenten zu tun hat. - Dubletten bündeln und Quellen anreichern: Wenn drei Treffer aus verschiedenen Absätzen desselben Artikels stammen, fasse sie für die Anzeige unter der gemeinsamen Dokument-ID zusammen.
- Qualität gegen feste Testfragen prüfen: Sichere mit automatisierten Regressionstests ab, dass nahe Themen (wie MFA-Verlust vs. Passwort-Reset) in der richtigen Reihenfolge erscheinen.
- Zugriffsrechte und Versionsfilter greifen vor oder während der Indexabfrage auf dem Server.
- Mehrere Chunks desselben Hilfeartikels werden auf Dokumentebene zusammengefasst.
- Modell- und Indexversion werden über einen gemeinsamen Alias atomar umgeschaltet.
- Alle Top-k-Treffer inklusive interner Texte an den Browser senden und dort per UI-Filter ausblenden.
- Anfragevektoren mit einem neuen Modell berechnen, während der Index noch alte Vektoren enthält.
- Jeden Top-k-Treffer ungeprüft als sichere Antwort darstellen, auch wenn das Thema im Bestand fehlt.
Wann reicht ein einfacher Vektorvergleich – und wann nicht?
| Szenario | Empfohlene Umsetzung | Worauf du im Betrieb achten musst |
|---|---|---|
| Kleine bis mittlere Doku (wenige Tausend Abschnitte) | Exakter Vergleich aller freigegebenen Vektoren (Flat Search) | Kein Recall-Verlust durch Näherungsindizes; Speicher und Abfragezeit unter Last messen |
| Große, dynamische Wissensbasis | Indexgestützte Näherungssuche (z. B. HNSW in pgvector oder Qdrant) | Zusammenspiel aus Filterselektivität und ANN-Suchbreite prüfen |
| Exakte Fehlercodes, SKUs und Versionsnummern | Hybrid Search aus Keyword- (BM25) und Vektorsuche | Reine Embeddings verwechseln ähnliche Kennungen wie ERR-1042 und ERR-1043 leicht |
| Mandantenfähige oder interne Dokumente | Serverseitige Zugriffskontrolle im Datenbank-Query | Niemals private Vektoren oder Quelltext-Snippets in öffentliche Client-Bundles legen |
Miss im Betrieb nicht nur die reine Vektordistanzberechnung: In der Praxis bestimmen oft der Netzwerkaufruf zum Embedding-Modell und das Nachladen der Texte die tatsächliche Antwortzeit.
Checkliste vor dem Go-Live
- Die Suchanfrage zum verlorenen Authenticator rankt die MFA-Anleitung stabil vor dem allgemeinen Passwort-Artikel.
- Interne Dokumente und veraltete Produktversionen sind selbst bei manipulierten API-Parametern ausgeschlossen.
- Fragen außerhalb des Dokumentbestands werden erkannt oder zurückhaltend behandelt, statt irrelevante Top-k-Treffer als Fakten zu präsentieren.
- Modellkennung und Indexversion sind gekoppelt, sodass bei einem Modell-Upgrade kein gemischter Vektorraum entsteht.
Quellen und nächste Schritte
- Sentence Transformers: Semantic Search – technische Grundlagen zu symmetrischer vs. asymmetrischer Suche und Bi-Encodern.
- Sentence Transformers: Semantic Textual Similarity – Berechnung und Einordnung von Kosinus-Ähnlichkeit und Distanzmaßen.
Wenn dir die Funktionsweise des Vektorraums selbst noch fehlt, starte mit den Embeddings-Grundlagen. Wie du anschließend mit Metriken wie Recall und nDCG überprüfst, ob deine Suche sich durch Änderungen wirklich verbessert, zeigt Retrieval-Evaluation.