Semantische Suche: Von Embeddings zu passenden Treffern

Wenn Menschen ein Problem beschreiben, die Suche aber nur die Formulierungen aus den Dokumenten erkennt, lohnt sich semantische Suche (Semantic Search). Ihr Aufbau umfasst 4 Aufgaben: Embeddings erzeugen, indexieren, Kandidaten abrufen und Ergebnisse sortieren. Für exakte Namen, Fehlercodes und Artikelnummern (SKUs) bleibt der Wortabgleich wichtig. Bevor eine funktionierende Suche ersetzt wird, sollte eine hybride Ergebnisliste im Vergleich geprüft werden.

Die folgenden Implementierungsdetails wurden am 21. Oktober 2026 anhand der aktuellen Dokumentation der jeweiligen Anbieter und Projekte geprüft. Das ausgearbeitete Beispiel verwendet eine dokumentierte Suchanfrage samt Ergebnis und benennt seine Annahmen ausdrücklich. Es handelt sich weder um einen Benchmark noch um den Nachweis eines produktiven Einsatzes.

Was ist semantische Suche?

Semantische Suche findet Informationen anhand von Bedeutung und Kontext. Eine Frage kann so zu einer Antwort führen, die ganz andere Wörter verwendet. Moderne Implementierungen arbeiten häufig mit Embeddings: numerischen Darstellungen, die inhaltlich verwandte Texte in einem erlernten Raum nahe beieinander anordnen. Das System vergleicht die Darstellung einer Suchanfrage mit denen der Inhalte und liefert passende Kandidaten zurück. Die Dokumentation von Sentence Transformers beschreibt dieses Suchprinzip.

Eine Ausstellung macht das Prinzip anschaulich: Ihre Exponate sind nach Themen geordnet, nicht alphabetisch nach ihren Beschriftungen. Wer etwas sucht, das ein Getränk warm hält, gelangt zu den Isolierbehältern, ohne den Begriff auf dem Schild zu kennen. Die Embeddings liefern die erlernte Anordnung; die Suche findet benachbarte Exponate. Diese Ordnung kann nützlich sein, ohne unfehlbar zu sein.

Für Unternehmen liegt der Nutzen darin, dass Kunden weniger Fachvokabular mitbringen müssen. Niemand sollte erst die Begriffe eines Hilfeportals lernen müssen, um die Anleitung zu finden, die das eigene Problem löst.

Semantische Suche und Vektorsuche: Was ist der Unterschied?

Semantische Suche beschreibt das Ziel: Informationen nach ihrer Bedeutung finden. Vektorsuche bezeichnet einen Mechanismus: numerische Darstellungen finden, die nahe beieinanderliegen. Ein Vektor kann Text repräsentieren, und Vektorähnlichkeit kann semantische Suche ermöglichen. Austauschbar sind die Begriffe deshalb nicht. Semantische Systeme können auch Kontext, Beziehungen zwischen Entitäten und Wissensgraphen nutzen, also strukturierte Verbindungen zwischen Dingen. Die Erklärung von Elastic behandelt diesen weiteren Rahmen.

Nicht jede denkbare Komponente muss Teil der eigenen Lösung sein. Für ein Hilfeportal sind Embeddings und gut aufbereitete Textpassagen ein sinnvoller Einstieg. Der Grundlagenartikel zu Vektordatenbanken erklärt die Speicher- und Suchschicht gesondert.

RAG und semantische Suche: Wo liegt die Grenze?

Semantische Suche kann mit einer Liste aus Links und Textauszügen enden. Retrieval-augmented generation, kurz RAG, ergänzt ein Modell, das aus den gefundenen Inhalten eine Antwort formuliert. Eine bessere Suche setzt also nicht voraus, dass das Hilfeportal zum Chatbot wird.

Diese Entscheidungen sollten getrennt fallen. Wer die richtige Einrichtungsanleitung sucht, sollte die Anleitung erhalten. Wird dagegen eine Antwort benötigt, die mehrere Passagen zusammenführt, lässt sich die Textgenerierung prüfen, sobald die Suche funktioniert. Der Leitfaden zu RAG und Fine-Tuning erklärt, warum das Auffinden aktueller Informationen etwas anderes ist als die Veränderung des Modellverhaltens.

Semantische Suche am Beispiel: Wenn der Wortabgleich scheitert

Ein Treffer nach Bedeutung wird dann interessant, wenn der passende Datensatz die eingegebenen Wörter gar nicht enthält.

Algolia NeuralSearch, ein gehosteter Suchdienst, der Stichwort- und Vektorsuche kombiniert, dokumentiert dieses Beispiel:

• Suchanfrage: „something to keep coffee hot“ – etwas, das Kaffee heiß hält
• Passendes Ergebnis: „insulated travel mug“ – isolierter Reisebecher

Laut Algolia kann diese Anfrage das genannte Ergebnis liefern, obwohl sich die Suchwörter nicht überschneiden. Ein Vergleich der beiden englischen Zeichenfolgen nach Umwandlung in Kleinbuchstaben bestätigt: 0 gemeinsame Wörter. Hier wird ein dokumentiertes Beispiel um eine Berechnung der Wortüberschneidung ergänzt; die Suchqualität wird damit nicht gemessen. Zum Beispiel des Anbieters.

Wie die Anfrage durch die Suche läuft

Angenommen, der durchsuchbare Datensatz enthält ausschließlich diesen Produkttitel. Die Suche gleicht gewöhnliche Wörter ab; Synonyme oder eine Erweiterung der Suchanfrage sind nicht eingerichtet. Keines der Suchwörter kommt im Titel vor, also liefert der Stichwortzweig keinen Treffer. An dieser Stelle scheitert der Wortabgleich.

Der Embedding-Zweig stellt die Anfrage und den Produkttitel anhand ihrer erlernten Bedeutung dar. Ein Getränk warm zu halten und ein isoliertes Trinkgefäß sind verwandte Konzepte. Deshalb kann das Produkt in die Kandidatenliste gelangen. Diesen semantischen Treffer veranschaulicht die Dokumentation. Ein erfundener Ähnlichkeitswert ist zur Erklärung nicht nötig.

Wird die Anfrage auf „mug“ geändert, also auf „Becher“, hat die Stichwortsuche einen direkten Treffer und kann völlig ausreichen. Ergänzt man die Produktbeschreibung um „keeps coffee hot“, findet sie auch die ursprüngliche Anfrage. Semantische Suche ist nützlich, weil sie über ausdrücklich gepflegte Wortzuordnungen hinaus verallgemeinert. Das heißt nicht, dass lexikalische Systeme keine Synonyme oder ausführlicheren Beschreibungen nutzen könnten.

Ändert sich die Absicht, muss sich die Reihenfolge ändern

Zwei weitere beispielhafte Anfragen an denselben Katalog zeigen den Unterschied:

„Insulated travel mug replacement lid“ fragt nach einem Zubehörteil, einem Ersatzdeckel. Ein ganzer Becher ist thematisch passend, erfüllt aber möglicherweise nicht den Bedarf. Die Bewertung sollte zwischen „handelt vom selben Thema“ und „löst die konkrete Aufgabe“ unterscheiden. Hier kann ein Reranker helfen: ein Modell, das die gefundenen Kandidaten im Hinblick auf die Suchanfrage erneut bewertet.

„MUG-BLUE“, eine erfundene SKU, fragt nach genau einem Artikel. Diese Kennung gehört in ein eigenes Feld für den exakten Abgleich. Ein semantisch ähnlicher roter Becher darf nicht allein deshalb vor dem angefragten blauen erscheinen, weil seine Beschreibung aussagekräftiger ist.

Dasselbe Muster zeigt sich im Support. Eine alltagssprachliche Symptombeschreibung braucht eine Suche nach Bedeutung; ein eingefügter Fehlercode muss zuverlässig wortgetreu gefunden werden. Ein Suchfeld sollte beides leisten.

Wie funktioniert semantische Suche?

Der Aufbau umfasst vorbereitende Arbeit und Verarbeitung während der Suchanfrage. Neue oder geänderte Inhalte werden in Embeddings umgewandelt und indexiert. Bei einer Suche codiert das System die Anfrage, ruft Kandidaten ab und bringt sie in eine Reihenfolge.

1. 1

   Embeddings erzeugen: Inhalte und Fragen repräsentieren

   Lange Dokumente werden in inhaltlich zusammenhängende Passagen aufgeteilt, oft Chunks genannt. Eine Anweisung und die Ausnahme, die ihre Bedeutung verändert, müssen zusammenbleiben. Ebenso gehören der Titel oder der zum Verständnis nötige Abschnittskontext dazu. Jede Passage durchläuft ein Embedding-Modell; neben dem erzeugten Vektor wird ihre Quellenkennung gespeichert.

   Bei der Suche wird die Anfrage mit einem kompatiblen Modell und einer passenden Konfiguration codiert. Manche Suchmodelle unterscheiden zwischen Eingaben für Suchanfragen und für Dokumente. Diese Betriebsarten sollten genutzt werden, statt für jeden Text denselben Prompt vorauszusetzen. Die Hinweise zur Codierung von Suchanfragen und Dokumenten erklären den Unterschied. Der Vergleich von Embedding-Modellen hilft bei der Vorauswahl; anschließend müssen sich die Modelle an den eigenen Inhalten bewähren.

2. 2

   Indexieren: Darstellungen durchsuchbar machen

   Die Vektoren werden mit stabilen Datensatz-IDs und nützlichen Metadaten gespeichert, etwa Produkt, Sprache, Veröffentlichungsstatus und Mandant. Der ursprüngliche Text muss weiterhin erreichbar sein. Ein Vektor ist eine Darstellung für die Suche, kein Ersatz für die Quellpassage, die später angezeigt werden soll.

   Ein Index ist eine zusätzliche Struktur, die den Abruf beschleunigt. Eine exakte Nächste-Nachbarn-Suche findet nach dem gewählten Abstandsmaß die nächstgelegenen gespeicherten Vektoren. Eine approximative Suche spart Arbeit und gewinnt dadurch Geschwindigkeit, kann dabei aber Nachbarn übersehen. Die Indexdokumentation von pgvector beschreibt diese Abwägung. Ein approximativer Index sollte eingesetzt werden, wenn Messungen ihn rechtfertigen, nicht weil jeder Prototyp einen bräuchte.

3. 3

   Abrufen: Zulässige Kandidaten sammeln

   Der Anfragevektor wird mit den indexierten Inhalten verglichen, um wahrscheinliche Treffer zu sammeln. Bei hybrider Suche läuft zusätzlich eine lexikalische Suche, die Wörter und Kennungen abgleicht. Produkt- und Zugriffsbeschränkungen müssen für beide Zweige gelten, damit weder unpassende Versionen noch für den Nutzer gesperrte Dokumente als Antwortmaterial infrage kommen.

   Filtern und Relevanzbewertung sind unterschiedliche Aufgaben. „In dieser Region verfügbar“ oder „für diesen Kunden sichtbar“ sind Bedingungen, die die Anwendung durchsetzen muss. Das Embedding soll sie nicht aus der Bedeutung erschließen. Die Dokumentation zur hybriden Suche von Pinecone unterscheidet zwischen der Zulässigkeit anhand von Metadaten und den Signalen für die Rangfolge der Kandidaten.

4. 4

   Sortieren: Das nützliche Ergebnis nach vorn bringen

   Die Kandidatenlisten werden zusammengeführt, Duplikate entfernt und die Reihenfolge festgelegt. Ein separater Reranker kann jeden Kandidaten gemeinsam mit der Suchanfrage lesen und die Passung genauer beurteilen als ein Vergleich unabhängig erzeugter Embeddings.

   Die endgültigen Links oder Passagen sollten mit verständlichen Titeln und Quellenkontext ausgegeben werden. Eine generierte Antwort kommt nur hinzu, wenn die Oberfläche sie benötigt. Die Architektur aus Abruf und Reranking erklärt, warum eine aufwendige Relevanzbewertung üblicherweise auf einer Vorauswahl arbeitet und nicht auf dem gesamten Bestand.

Bei einer internen Richtliniensuche bedeutet das: Eine Passage muss relevant, aktuell und für den jeweiligen Mitarbeiter zugänglich sein. Ein hoher Ähnlichkeitswert erfüllt nur einen Teil dieser Anforderungen.

Semantische Suche oder Stichwortsuche?

Semantische Suche eignet sich für Beschreibungen und Umformulierungen. Lexikalischer und strukturierter Abgleich bleiben für Bedingungen nötig, die wortgetreu erhalten bleiben müssen. Der Vergleich von Pinecone nennt Produktcodes, Fehlerzeichenfolgen und Namen ausdrücklich als Fälle, in denen das Stichwortsignal zählt.

Stichwortsuche beschränkt sich nicht auf einen simplen Vergleich von Zeichenfolgen. Suchmaschinen können Sprachverarbeitung, Tippfehlerkorrektur und konfigurierte Synonyme einsetzen. Ein leistungsfähiges lexikalisches System ist deshalb die faire Vergleichsbasis. Eine absichtlich schwache Basis lässt Embeddings besser aussehen, als sie sind.

Semantische Suche hat ihrerseits eine vorhersehbare Schwäche: Ähnliche Bedeutung ist nicht dasselbe wie eine exakt erfüllte Bedingung. „Eine Bestellung stornieren“ und „Eine Bestellung kann nicht storniert werden“ behandeln dasselbe Thema, doch die Ausnahme entscheidet über die Antwort. Auch eine Budgetgrenze, ein Produktstand oder ein Ausschluss kann einen strukturierten Filter erfordern statt eines höheren Ähnlichkeitswerts.

Eine reine Stichwortsuche kann bleiben, wenn überwiegend bekannte Einträge gesucht werden und sie dabei bereits gute Ergebnisse liefert. Semantische Suche lohnt sich, wenn fehlgeschlagene Anfragen wiederholt Unterschiede in der Wortwahl zeigen. Fehlt das Quelldokument vollständig, kann keine der beiden Methoden es finden.

Warum hybride Suche und Reranking zusammengehören

Hybride Suche verbessert die Auswahl der Kandidaten; Reranking verbessert deren Reihenfolge. Beide beheben unterschiedliche Fehler.

Der Stichwortzweig findet die wörtliche Kennung, der semantische Zweig die Umformulierung. Ihre Ergebnisse sollten über stabile Dokument- oder Passagen-IDs zusammengeführt werden, damit dieselbe Quelle andere Treffer nicht verdrängt. Reciprocal rank fusion, kurz RRF, ist eine Methode dafür: Sie verwendet die Position eines Ergebnisses in den Eingangslisten, statt unterschiedliche Bewertungsskalen als austauschbar zu behandeln. Die Dokumentation zur hybriden Suche von OpenSearch unterscheidet zwischen rangbasierter Zusammenführung und der Normalisierung von Bewertungswerten.

Ein roher Stichwortwert und ein Vektorähnlichkeitswert ergeben nicht automatisch eine sinnvolle Summe. Stattdessen sollte eine unterstützte Zusammenführungsmethode verwendet oder eine gezielt normalisierte Kombination geprüft werden. Elastic empfiehlt RRF, um Volltext- und Vektorrangfolgen zu verbinden.

Ein Cross-Encoder ist ein Reranker, der Suchanfrage und Kandidat gemeinsam betrachtet. Im Becherbeispiel kann er beurteilen, ob nach dem Becher selbst oder nach seinem Ersatzdeckel gefragt wird. Dieser genauere Vergleich benötigt zusätzliche Rechenleistung und Zeit. Deshalb kommt es auf die Größe der Vorauswahl an. Sentence Transformers dokumentiert das zweistufige Vorgehen.

Für ein produktives Hilfeportal mit einer Mischung aus natürlichsprachlichen Anfragen und exakten Codes ist hybride Suche eine gute Ausgangsarchitektur. Ein Reranker sollte hinzukommen, wenn die Bewertung zeigt, dass die bessere Reihenfolge die zusätzliche Latenz und die Betriebskosten rechtfertigt. Das ist eine technische Empfehlung, keine Behauptung, dass alle produktiven Suchsysteme denselben Aufbau verwenden.

Eine Anwendung kann eine Anfrage außerdem umformulieren oder erneut suchen, wenn die gefundenen Belege zu schwach sind. Das ergänzt eine weitere Entscheidungsschleife, ersetzt aber nicht den eigentlichen Suchvorgang. Der Leitfaden zu agentischem RAG behandelt diese komplexere Architektur.

Welche semantische Suchmaschine passt zur vorhandenen Infrastruktur?

Vor der Anbieterwahl steht die Entscheidung, wo die Grenze der eigenen Implementierung verläuft. Welche Teile von Indexierung, Modellinferenz, Suchkonfiguration und Betrieb soll die Anwendung selbst verantworten? Die folgenden vier Wege sind unterschiedliche Aufbauoptionen, keine Rangliste.

Pinecone: eine verwaltete Vektordatenbank

Pinecone ist eine verwaltete Datenbank für den Informationsabruf und kommt infrage, wenn die Suche als eigenständiger Dienst laufen soll. Die aktuelle Dokumentation behandelt Vektor- und Volltextsuche, hybride Suche, Metadatenfilter und Reranking. Vektoren lassen sich selbst bereitstellen oder über unterstützte, integrierte Embedding-Workflows erzeugen. Zum Überblick über Pinecone.

Das passt zu einem Produkt, dessen Suche einen eigenständigen Dienst benötigt und dessen Entwicklungsteam den Betrieb der Suchinfrastruktur dem Anbieter überlassen möchte. Die Anwendung entscheidet weiterhin, welche Inhalte sie übermittelt und wie aus den Suchergebnissen eine nützliche Oberfläche wird.

Die Hürde ist die Synchronisierung. Wird ein Dokument geändert, entfernt oder auf privaten Zugriff umgestellt, muss die Kopie im Suchsystem nachziehen. Vor dem Anschluss privater Inhalte muss geklärt sein, wer für fehlgeschlagene Aktualisierungen und die Weitergabe von Löschungen zuständig ist. Eine verwaltete Datenbank nimmt der Anwendung diese Verantwortung nicht ab.

PostgreSQL mit pgvector: Suche direkt bei den Daten

pgvector ist eine Open-Source-Erweiterung für PostgreSQL, die der relationalen Datenbank eine Vektorähnlichkeitssuche hinzufügt. Sie lässt sich neben der Volltextsuche von PostgreSQL einsetzen; SQL-Joins und Transaktionen bleiben verfügbar. Die README des Projekts dokumentiert sowohl die Vektorindizes als auch den Ansatz für hybride Suche.

Wenn Dokumente, Kundendaten und Zugriffsregeln bereits in PostgreSQL liegen, ist das ein sinnvoller erster Kandidat für die Erprobung. Es müssen weniger Datenspeicher synchron gehalten werden. Ein Workflow für die Erzeugung von Embeddings und die Aktualisierung der Inhalte bleibt dennoch nötig.

Die Hürden sind gefilterte approximative Suche und gemeinsam genutzte Kapazitäten. Bei approximativen pgvector-Indizes wird nach dem Durchsuchen der Kandidaten gefiltert. Enge Bedingungen können deshalb zu wenige Ergebnisse übrig lassen. Die Dokumentation beschreibt iterative Scans und weitere Indexierungsstrategien, um dem zu begegnen. Das Filterverhalten sollte mit den tatsächlichen Mandanten- und Berechtigungsbedingungen geprüft werden. Die Suchleistung muss dabei zusammen mit der übrigen Anwendungslast gemessen werden.

Semantische Suche mit Elasticsearch: eine vorhandene Suchmaschine erweitern

Elasticsearch, die Suchmaschine von Elastic, kann Volltext- und Vektorsuche in einer Anfrage kombinieren. Das Feld semantic_text kann bei der Datenaufnahme Embeddings über einen Inferenzendpunkt erzeugen, also einen konfigurierten Dienst, der das Modell ausführt. Das Tutorial von Elastic zur semantischen Suche zeigt die Einrichtung.

Wer Elasticsearch bereits betreibt und auf dessen lexikalisches Suchverhalten angewiesen ist, sollte zunächst die Ergänzung um Vektorsuche dort prüfen, bevor eine weitere Datenbank eingeführt wird. Bestehende Möglichkeiten zur Relevanzsteuerung zu erhalten, kann wichtiger sein als ein Austausch der Infrastruktur.

Die Hürde ist die Verantwortung für Inferenz und Konfiguration. Elastic empfiehlt ausdrücklich, den Inferenzendpunkt für den Produktivbetrieb festzulegen, statt sich auf eine Standardeinstellung zu verlassen, die sich zwischen Bereitstellungen oder Versionen ändern kann. Werden über mehrere Indizes hinweg unterschiedliche Embedding-Modelle gemischt, kann das die Rangfolge verschlechtern. Eine verwaltete Embedding-Erzeugung vereinfacht die Einrichtung; Modellwahl und Migrationsplanung bleiben trotzdem nötig.

Algolia: eine gehostete Such-API

Algolia passt, wenn der Anbieter einen größeren Teil der Suchfunktion abdecken soll, einschließlich der Mischung aus Stichwort- und semantischen Ergebnissen. Die NeuralSearch-Dokumentation beschreibt einen Vorschauvergleich beider Suchweisen sowie Voreinstellungen, die steuern, wann semantische Treffer einbezogen werden. Dieser Vergleich sollte mit eigenen Suchanfragen erfolgen, bevor die Ergebnisse im laufenden Betrieb geändert werden. Zur Konfigurationsanleitung.

Die Hürden sind die Eignung für das Produkt und die Verfügbarkeit der Funktionen. NeuralSearch ist nicht in jedem Tarif enthalten. Seine verwalteten Einstellungsmöglichkeiten müssen den exakten Abgleich und die Filteranforderungen der Anwendung abdecken. Klickereignisse sind in der aktuellen Einrichtung optional; ohne sie kann der Dienst Vektorattribute anhand der Datensatzstruktur auswählen. Aussagekräftige Datensätze und Relevanzprüfungen bleiben erforderlich.

Aus dem Begriff „Ranking“ bei einem gehosteten Produkt lässt sich nicht ableiten, dass es die oben beschriebene Architektur mit separatem Cross-Encoder verwendet. Entscheidend ist, ob das benötigte Verhalten dokumentiert ist. Ein verwalteter Workflow lohnt sich, wenn seine Steuerungsmöglichkeiten passen. Müssen diese selbst gestaltet werden, eignet sich eher ein grundlegender Baustein.

Welche Grenzen über den Erfolg im Produktivbetrieb entscheiden

Inhaltsqualität, Zugriffsbedingungen und Aktualisierungen entscheiden meist darüber, ob aus einer überzeugenden Demo eine verlässliche Suche wird. Sie gehören in die Erprobung der Suche, nicht auf eine Aufräumliste für die Zeit nach dem Start.

Passagengrenzen und kompatible Modelle

Kurze Passagen können eine Antwort gezielt erfassen. Fehlen einem Fragment aber die Überschrift oder eine Ausnahme, kann es irreführend werden. Lange Passagen bewahren mehr Kontext, vermischen jedoch mitunter unabhängige Themen. Ausgangspunkt sollte die Struktur des Inhalts sein: eine Supportanleitung, ein Richtlinienabschnitt oder ein Produktdatensatz. Erst nach der Analyse von Fehlern sollten die Passagengrößen geändert werden.

Quellen-ID, Passagenkennung und Embedding-Konfiguration müssen nachvollziehbar bleiben. Bei einem Modellwechsel sind die Inhaltsdarstellungen mit der zur Anfragekonfiguration passenden Einstellung neu zu erzeugen, bevor die Suchanfragen umgeschaltet werden. Es darf nicht vorausgesetzt werden, dass ein neues Anfragemodell den Koordinatenraum eines alten Modells versteht.

Berechtigungen, Löschungen und Aktualität

Bei internen Dokumenten müssen die Zugriffsrechte serverseitig aus dem authentifizierten Nutzer abgeleitet werden. Für lexikalische und Vektorkandidaten gilt dieselbe Zugriffsregel. Sie muss geprüft sein, bevor Passagen an einen Reranker oder ein Antwortmodell eines Drittanbieters gelangen. Ein Ergebnis erst in der fertigen Oberfläche auszublenden, ist zu spät, wenn sein Text diese Grenze bereits überschritten hat.

Der gesamte Lebenszyklus muss ausdrücklich getestet werden: ein Dokument veröffentlichen, überarbeiten, den Zugriff entziehen und es anschließend löschen. In jeder Phase ist zu prüfen, was berechtigte und unberechtigte Nutzer finden können. Wird ein separater Index asynchron aktualisiert, braucht es eine festgelegte erwartete Verzögerung und eine Ersatzlösung für sensible Änderungen. Das sind Abnahmekriterien der Anwendung, keine Zusagen eines Embedding-Modells.

Kosten für Embeddings, Speicherung und Suchanfragen einplanen

Die Rechnung hängt von der Arbeitslast ab, nicht vom Etikett „semantische Suche“. Vor einer Kostenschätzung sollten diese Einflussgrößen erfasst werden:

• Embedding-Aufwand: die Textmenge, die beim Erstimport, bei späteren Änderungen und bei der Verarbeitung von Suchanfragen codiert wird. Ein Modellwechsel kann durch die erneute Embedding-Erzeugung eine weitere Datenaufnahme auslösen. Gehostete Dienste rechnen diesen Aufwand möglicherweise gesondert ab; ein selbst betriebenes Modell verbraucht eigene Rechenkapazität.
• Speicherung und Indizes: Anzahl der Passagen, Vektordimensionen, Zahlenformat, Metadaten und zusätzlicher Speicherbedarf des Index. Mehr Überlappung zwischen Passagen dupliziert Text und erzeugt zusätzliche Datensätze. Replikate und Sicherungen können über die primäre Kopie hinaus Speicher benötigen.
• Suchanfragen und Reranking: Anfragevolumen, Suchaufwand, gleichzeitige Zugriffe und die Zahl der Kandidaten, die für eine weitere Modellbewertung übergeben werden. Eine größere Reranking-Vorauswahl verursacht mehr Arbeit, selbst wenn am Ende gleich viele Ergebnisse angezeigt werden.

Die Kostendokumentation von Pinecone veranschaulicht die getrennte Erfassung von Speicherung, Indexoperationen, Embeddings und Reranking. Andere Betriebsmodelle bündeln diese Posten anders; einen seriösen, allgemein gültigen Preis pro Anfrage gibt es deshalb nicht. Eine Schätzung muss vom eigenen Datenbestand, der Änderungsrate und dem Anfrageaufkommen ausgehen und die aktuellen Konditionen des gewählten Anbieters berücksichtigen.

Kandidatenabruf und Rangfolge getrennt bewerten

Für jede repräsentative Suchanfrage sollte festgehalten werden, welche Quelle sie beantworten würde. Dazu gehören alltagssprachliche Beschreibungen, exakte Kennungen, mehrdeutige Fragen und Anfragen nach Informationen, die gar nicht vorhanden sind. Schwierige Negativbeispiele wie der Ersatzdeckel im Vergleich zum ganzen Becher gehören ebenfalls in den Bestand.

Anschließend sind zwei Fragen unabhängig voneinander zu prüfen: War die richtige Quelle unter den Kandidaten, und stand sie im endgültigen Ranking dort, wo sie gefunden würde? Der Recall der Kandidatenauswahl misst, wie vollständig relevante Einträge erfasst wurden. Die endgültige Reihenfolge zeigt, ob nützliche Einträge nach oben gelangen. Ein einzelner Durchschnittswert kann Fehler bei der Suche nach exakten Codes verdecken, auf die der Support angewiesen ist.

Die Antwortzeit muss mit den tatsächlichen Filtern und unter realer Last gemessen werden. Eine breite Suche im gesamten Bestand kann sich anders verhalten als die Suche eines Kunden, der nur auf einen kleinen Teil zugreifen darf. Es muss einen vorgesehenen Umgang mit „kein nützliches Ergebnis“ geben: Der nächste Treffer ist nicht zwangsläufig relevant.

Was semantische Suche nicht löst

Embeddings beheben keine fehlenden, widersprüchlichen oder veralteten Quellinhalte. Fehlt die Stornierungsrichtlinie, bleibt ein ähnlicher Artikel über Erstattungen der falsche Beleg.

Sie garantieren auch nicht, dass jede Einschränkung bei der Suche berücksichtigt wird. Eine Produktversion, ein Verbot oder eine exakte Kennung kann über die richtige Antwort entscheiden, selbst wenn die übrige Formulierung ähnlich ist. Solche Fälle gehören in den Bewertungsbestand. Ein besseres Modell macht ihre Prüfung nicht überflüssig.

Der teuerste Fehler besteht darin, irgendein zurückgegebenes Ergebnis als Beweis für Verständnis zu behandeln. Eine Vektorsuche kann auch zu einer unbeantwortbaren Frage die nächstgelegenen Kandidaten liefern. Die Anwendung muss entscheiden, ob diese Kandidaten nützlich genug sind, um angezeigt oder an ein Antwortmodell weitergegeben zu werden.

Schließlich machen zusätzliche Komponenten ein Produkt nicht automatisch besser. Anfrageumformulierung, Reranking und wiederholte Suche bringen jeweils weiteres Verhalten mit, das geprüft werden muss. Eine Komponente sollte bleiben, wenn sie einen beobachteten Fehler zu vertretbaren Betriebskosten behebt.

Was Gründer, Entwicklungsteams und Betreiber jetzt tun sollten

Gründer sollten die erfolglosen Anfragen einordnen, bevor sie einen Neuaufbau finanzieren. Beschreiben Kunden ihre Probleme mit anderen Wörtern als die vorhandenen Inhalte, lohnt sich ein Pilotprojekt für semantische Suche. Geht es bei den erfolglosen Anfragen überwiegend um SKUs oder Namen, sind zunächst exakte Felder, die Vollständigkeit der Indexierung und die lexikalische Konfiguration zu verbessern. Fehlen Suchprotokolle oder Relevanzbewertungen, sollten diese vor der Infrastrukturwahl gesammelt werden.

Entwicklungsteams sollten dieselben Fragen mit einer leistungsfähigen lexikalischen Basis, hybrider Suche und hybrider Suche mit Reranking vergleichen. Quellenbestand und Zugriffsbedingungen müssen dabei gleich bleiben. Gesucht sind Verbesserungen bei Problembeschreibungen, ohne dass die Suche nach Kennungen schlechter wird. Ein Reranker gehört dazu, wenn er die Reihenfolge verbessert, nicht bloß, weil er in einem Architekturdiagramm vorkommt.

Betriebsteams sollten die Verantwortung für die Inhalte klären. Es muss feststehen, wer fehlende Artikel ergänzt, überholte Anleitungen zurückzieht und Synchronisierungsfehler überwacht. Suchqualität hängt auch von Veröffentlichungs- und Berechtigungsabläufen ab, selbst wenn der Suchdienst verwaltet wird.

Der konkrete Schritt für Montag: Eine repräsentative Auswahl erfolgloser Suchanfragen der Website nehmen, jeweils die erwartete Quelle zuordnen und Unterschiede in der Wortwahl von fehlenden Inhalten und Fehlern beim exakten Nachschlagen trennen. Anhand dieses Bestands lässt sich die kleinste Änderung wählen, die das vorherrschende Problem behebt. Eine gut funktionierende Suche braucht keine Migration, nur um ein KI-Etikett zu erhalten.

Häufige Fragen

Was bedeutet semantische Suche?

Dabei werden Informationen anhand von Bedeutung und Kontext gefunden, ohne dass dieselben Wörter vorkommen müssen. Embeddings sind eine verbreitete Umsetzung. Nützliche Ergebnisse hängen aber weiterhin von Inhalten, Filtern und Rangfolge ab.

Ist semantische KI kostenlos?

Hinter semantischer Suche steht kein einzelner Dienst mit einem festen Preis. Open-Source-Komponenten können Softwaregebühren senken, doch Modellinferenz, Speicherung und die Bereitstellung im Betrieb benötigen weiterhin Ressourcen. Eine kostenlose Softwarelizenz macht den Betrieb eines Systems nicht kostenlos.

Was sind semantische Merkmale?

Das sind Muster, die Bedeutung repräsentieren helfen, etwa Beziehungen zwischen Konzepten oder der Kontext einer Formulierung. In einem erlernten Embedding verteilt sich die Bedeutung über die gesamte Darstellung. Einzelne Koordinaten müssen keine leicht verständliche Bezeichnung für Menschen haben.

Was unterscheidet Elasticsearch von semantischer Suche?

Elasticsearch ist ein Suchmaschinenprodukt. Semantische Suche ist ein Ansatz, den Elasticsearch neben der Volltextsuche umsetzen kann. Die beiden Begriffe bezeichnen keine konkurrierenden Kategorien.

Nutzt ChatGPT semantische Suche?

Es sollte nicht vorausgesetzt werden, dass jede Antwort dieselbe Suchmethode verwendet. OpenAI dokumentiert Suche und Informationsabruf über verbundene Dienste, einschließlich der Vorabindexierung bei synchronisierten Verbindungen. Das belegt Suchfunktionen, aber keinen einheitlichen Embedding-Algorithmus hinter jeder Antwort. Zur Dokumentation von OpenAI über Verbindungen.

Heißt Elasticsearch jetzt OpenSearch?

Nein. OpenSearch ist ein eigenständiges Projekt, das als Fork entstanden ist, und kein neuer Name für das heutige Elasticsearch. Die FAQ von OpenSearch erklärt den Zusammenhang.

Warum wechseln Unternehmen von Elasticsearch weg?

Die Frage setzt einen allgemeinen Trend voraus, ohne ihn zu belegen. Für die eigene Entscheidung zählen Betriebsaufwand, benötigte Funktionen, bevorzugte Bereitstellungsformen und kommerzielle Konditionen. Allein der Wunsch nach semantischer Suche erfordert keinen Abschied von Elasticsearch.

Was ist besser: Elasticsearch oder OpenSearch?

Eine allgemeingültige Antwort gibt es nicht. Entscheidend sind das benötigte Suchverhalten und das Betriebsmodell; Ausgangspunkt sollte das bereits betreute System sein. Beide dokumentieren hybride Suche: der Leitfaden von Elastic und der Leitfaden von OpenSearch.

Welche Nachteile hat OpenSearch?

Der Suchablauf muss weiterhin konfiguriert und gepflegt werden. Die Dokumentation zur hybriden Suche verlangt eine Pipeline zur Anfragezeit und eine Methode, um Relevanzsignale zu kombinieren. Je nach Hosting liegt der Infrastrukturbetrieb bei einer anderen Stelle. Relevanzbewertung und Qualität der Anwendungsdaten bleiben dennoch in der eigenen Verantwortung.

Praxisleitfäden zum Aufbau nützlicher KI-Systeme gibt es im Newsletter.