Was ist semantische Suche? Die kurze Antwort
Semantische Suche heißt: Die Suche findet Ergebnisse nach Bedeutung, nicht nach Zeichenkette. Tippt jemand «Mittel gegen quietschende Tür», liefert sie das Silikonspray — obwohl kein einziges Wort der Anfrage im Produkttext vorkommt. Eine klassische Keyword-Suche findet hier: nichts.
Technisch funktioniert das über Embeddings: Ein KI-Modell übersetzt Texte in Zahlenvektoren, die Bedeutung abbilden. Ähnliche Bedeutung ergibt ähnliche Vektoren. Die Suche vergleicht den Vektor deiner Anfrage mit den Vektoren deiner Dokumente und sortiert nach Nähe. Wie Embeddings im Detail entstehen, erkläre ich in RAG vs. Fine-Tuning und im Artikel zum eigenen KI-Modell — hier reicht: Bedeutung wird messbar.
Zur Einordnung: Nicht jedes Suchproblem ist ein Bedeutungsproblem. «Dichtungsrng» ist ein Tippfehler: Das löst Typo-Toleranz, keine KI. «Womit dichte ich ein Rohr ab?» ist eine Bedeutungsfrage: Das löst semantische Suche. Diese Unterscheidung zieht sich durch den ganzen Artikel, denn sie entscheidet am Ende, ob du überhaupt zahlen musst.
Der Begriff hat übrigens eine Vorgeschichte: Früher meinte semantische Suche Ontologien und Wissensgraphen, also handgepflegte Begriffsnetze. Der Wikipedia-Artikel zum Thema beschreibt bis heute fast nur diese alte Welt (de.wikipedia.org, Abruf 04.09.2026). Wenn du 2026 nach semantischer Suche fragst, meinst du fast sicher die Embedding-Variante — und um die geht es hier.
Der Rest dieses Artikels ist Praxis: wo Keyword-Suche verliert, welcher Stack zu welchem Problem passt, was der Einbau kostet — und wann du dir das alles sparen kannst.
Wo Keyword-Suche verliert — und wo sie gewinnt
Keyword-Suche vergleicht Zeichenketten. Sie verliert überall dort, wo Menschen anders formulieren als deine Texte. Drei typische Fälle:
Synonyme: Dein Shop sagt «Akkuschrauber», der Kunde sucht «Schrauber kabellos». Null Treffer.
Umschreibungen: Deine Hilfeseite heißt «Retourenprozess», gesucht wird «Ware zurückschicken». Null Treffer.
Natürliche Fragen: «Welches Öl für Buchenholz?» trifft keine Produktbezeichnung, obwohl das passende Pflegeöl im Sortiment liegt.
Solche Null-Treffer sind still: Der Besucher, der nichts findet, beschwert sich nicht beim Support, er geht zum nächsten Anbieter. Sichtbar wird das Problem erst in deiner Suchanalyse — dazu später mehr.
Semantische Suche löst genau diese Fälle: Sie erkennt, dass «kabellos» und «Akku» im selben Bedeutungsraum liegen. Deshalb wirkt sie am stärksten bei Inhalten mit viel Sprache: Blogartikel, Hilfe-Center, Dokumentationen, beratungsintensive Sortimente.
Eine Übung aus der Praxis hilft bei der Einschätzung: Nimm hundert echte Suchanfragen aus deinem Log und markiere, wie viele davon Umschreibungen statt exakter Begriffe sind. In beratungsintensiven Sortimenten ist dieser Anteil nach meiner Erfahrung regelmäßig höher, als die Betreiber schätzen — im reinen Ersatzteilgeschäft dafür oft verschwindend klein.
Und wo gewinnt Keyword-Suche? Bei allem, was exakt sein muss. Wer «HC-4711-B» sucht, will genau diesen Artikel und keinen bedeutungsähnlichen Nachbarn. Artikelnummern, SKUs, Fehlercodes, Eigennamen: Hier ist die exakte Übereinstimmung das richtige Ergebnis, und ein Bedeutungsmodell macht die Trefferliste eher schlechter.
Vorab die Konsequenz daraus: Die Frage lautet selten «Keyword oder semantisch», sondern fast immer «wie viel von beidem». Genau dafür gibt es hybride Suche — dazu gleich mehr.
Vektorsuche, hybride Suche, RAG: drei Begriffe, drei Baustellen
Drei Begriffe fallen in jedem Gespräch über semantische Suche, und sie werden ständig vermischt. Dabei bezeichnen sie drei verschiedene Baustellen mit unterschiedlichen Werkzeugen.
Vektorsuche: Ähnlichkeit statt Übereinstimmung
Vektorsuche ist der Maschinenraum der semantischen Suche: Jedes Dokument bekommt einen Embedding-Vektor, jede Anfrage auch, gesucht wird nach den nächsten Nachbarn im Vektorraum. Das Ergebnis ist eine Rangliste nach Bedeutungsnähe. Ihre Schwäche kennst du schon aus dem letzten Abschnitt: Exakte Codes und Artikelnummern gehen im Bedeutungsraum unter.
Wichtig für dein Budget: Die Vektoren entstehen einmal pro Dokument beim Indexieren, nicht bei jeder Suche. Live eingebettet wird nur die Anfrage selbst, und die ist kurz. Diese Asymmetrie macht die Kostenrechnung weiter unten so freundlich.
Hybride Suche: beide Welten, ein Ranking
Hybride Suche kombiniert beide Verfahren in einer einzigen Anfrage: Keyword-Treffer und Vektor-Treffer fließen in ein gemeinsames Ranking. In Meilisearch steuert das ein Parameter namens semanticRatio: 0.0 heißt reine Keyword-Suche, 1.0 heißt rein semantisch, der Standardwert liegt bei 0.5 (meilisearch.com/docs, Abruf 04.09.2026). Für Endnutzer-Suche auf Websites und in Shops ist hybrid der praxistaugliche Normalfall.
Ein Beispiel, wie das Zusammenspiel aussieht: Die Anfrage «Bosch Akkuschrauber leise» trifft «Bosch» und «Akkuschrauber» als Keywords exakt, während der Vektor-Anteil Geräte mit «geräuscharmem Getriebe» in der Beschreibung nach oben zieht. Keines der beiden Verfahren allein hätte diese Reihenfolge gebaut.
RAG: keine Suche, sondern eine Antwortmaschine
RAG (Retrieval-Augmented Generation) nutzt zwar dieselbe Vektortechnik, ist aber ein anderes Produkt: Ein Sprachmodell holt sich passende Textstellen und formuliert daraus eine Antwort in ganzen Sätzen. Der Nutzer sieht keine Trefferliste, sondern eine Auskunft. Das ist keine Website-Suche mehr, sondern eine Wissens-Schnittstelle für Anwendungen. Typische Einsatzorte: interne Wissensdatenbanken, Support-Assistenten, Vertragsrecherche.
Meilisearch findet Dokumente, RAG beantwortet Fragen — wer beides braucht, baut zwei Systeme, nicht eins.
Diese Trennlinie klingt akademisch, hat aber handfeste Folgen: Beide Welten haben unterschiedliche Werkzeuge, unterschiedliche Kostenprofile und unterschiedliche Fehlerbilder. Der nächste Abschnitt macht daraus eine konkrete Stack-Entscheidung.
Die Stack-Entscheidung: Endnutzer-Suche oder Wissenssuche
Bevor du Werkzeuge vergleichst, beantworte eine Frage: Wer sucht da eigentlich — ein Besucher deiner Website oder eine Anwendung, die Wissen braucht? Die Antwort bestimmt den kompletten Stack.
Für Website und Shop: Meilisearch hybrid
Endnutzer-Suche heißt: Suchschlitz, Tippfehler, Facetten, Ergebnisse während des Tippens. Dafür setze ich auf Meilisearch: Typo-Toleranz und Facetten sind eingebaut, die hybride Suche steckt im Standard-Binary. Der Hersteller verspricht Antworten «in unter 50 Millisekunden» — das ist eine Vendor-Angabe, aber die Instant-Search-Architektur dahinter ist real. Was Meilisearch genau ist und wo seine Grenzen liegen, steht in meinem Meilisearch-Guide.
Wichtig für die Einordnung: Oft brauchst du nicht einmal das. Die Such-Hierarchie beginnt bei der Postgres-Volltextsuche, die in vielen Projekten völlig reicht. Erst wenn Instant Search, Facetten oder eben Semantik gefragt sind, lohnt ein eigener Suchdienst. Elasticsearch steht noch eine Stufe höher und ist für die meisten Websites überdimensioniert — die Elasticsearch-Alternativen habe ich separat verglichen.
Für RAG in Anwendungen: pgvector auf Supabase
Wissenssuche in Anwendungen ist die andere Baustelle: Ein internes Tool soll Fragen zu Verträgen beantworten, ein Kundenportal soll Wissen aus der Dokumentation ausspielen. Dafür nutze ich pgvector auf PostgreSQL, konkret auf Supabase: Die Vektoren liegen dann in derselben Datenbank wie die übrigen Anwendungsdaten, mit denselben Zugriffsrechten und Backups. Ein separater Suchdienst wäre hier nur ein Umweg — und ein Dienst mehr, der Zugriff auf deine Daten braucht.
Die Faustregel für die Abgrenzung: Sichtbare Trefferliste für Menschen heißt Meilisearch. Textbausteine als Futter für ein Sprachmodell heißen pgvector. Braucht ein Projekt beides (Shop-Suche plus Beratungs-Chat), sind das zwei Komponenten mit klar getrennten Aufgaben — nicht ein System, das beides halb kann.
Bewusst außen vor bleibt hier Elasticsearch mit seinen eigenen Vektor-Funktionen: Es kann semantische Suche ebenfalls, spielt aber in einer anderen Gewichtsklasse — mit entsprechendem Betriebsaufwand. Für die meisten Websites und Shops ist es nicht der erste sinnvolle Schritt.
So baust du hybride Suche mit Meilisearch ein
Der Einbau ist überschaubar: Du brauchst einen laufenden Meilisearch-Index, einen Embedder und zwei Konfigurationsentscheidungen. So gehe ich in Projekten vor.
Vorab zur Aktualität: Die hybride Suche steckt im normalen Meilisearch-Binary, aktuell in Version 1.53.1 vom 13.08.2026 (github.com/meilisearch/releases, Abruf 04.09.2026). Du brauchst also weder ein Sonder-Binary noch einen Enterprise-Vertrag, um loszulegen.
Embedder wählen und konfigurieren
Der Embedder ist der Dienst, der deine Texte in Vektoren übersetzt. Meilisearch bringt Anbindungen für OpenAI, Cohere, Mistral, Gemini, Cloudflare, Voyage AI, Jina, AWS Bedrock und HuggingFace mit, dazu einen REST-Embedder für beliebige APIs (meilisearch.com/docs, Abruf 04.09.2026). Über den REST-Embedder schließt du auch ein selbst gehostetes Embedding-Modell an — relevant, wenn deine Daten die EU nicht verlassen sollen.
Mein Standard-Einstieg: OpenAI text-embedding-3-small. Es kostet 0,02 $ pro Million Token und ist damit so günstig, dass die Modellwahl selten die Kostenfrage ist (developers.openai.com, Abruf 04.09.2026). Wichtiger ist Konsistenz: Dokumente und Suchanfragen müssen mit demselben Modell eingebettet werden, sonst passen die Vektorräume nicht zusammen.
semanticRatio: der eine Regler, der zählt
Bei jeder Suchanfrage gibst du den Embedder an (das Feld ist Pflicht) und setzt das semanticRatio zwischen 0.0 und 1.0. Der Default 0.5 gewichtet Keyword- und Vektor-Treffer gleich (meilisearch.com/docs, Abruf 04.09.2026).
Meine Erfahrung aus Projekten: Starte beim Default, teste mit echten Anfragen aus deinem Suchlog und justiere in Schritten von 0.1. Sortimente mit vielen Artikelnummern vertragen eher wenig Semantik, textlastige Hilfe-Center deutlich mehr. Der Regler ist keine Einmal-Einstellung, sondern das Ergebnis dieser Tests. Und dokumentiere die getesteten Werte: In einem halben Jahr will jemand wissen, warum es 0.4 wurde.
Document Template und Indexierung
Das Document Template legt fest, welcher Text pro Dokument eingebettet wird. Hier entscheidet sich die Relevanz: Titel, Beschreibung und Kategorie gehören hinein, interne IDs und URLs nicht — sie verwässern nur den Bedeutungsvektor. Kurz und dicht schlägt lang und vollständig.
Ein brauchbares Template für einen Shop besteht aus Titel, Kategorie und Beschreibung in einem festen Satzmuster. Mehr braucht es meist nicht. Prüfe aber vorher, ob jedes Dokument das Template sinnvoll füllt: Leere Beschreibungen produzieren leere Bedeutung — und damit zufällig wirkende Treffer.
Danach läuft die Indexierung: Meilisearch schickt jedes Dokument einmal durch den Embedder und speichert den Vektor im Index. Bei Änderungen am Datenbestand wird neu eingebettet — plane diese Pipeline von Anfang an mit, denn ein Katalog, der sich täglich ändert, bettet auch täglich neu ein. Was das kostet, rechnet der nächste Abschnitt vor.
Aus meiner Erfahrung: Rechne für einen sauberen Einbau mit wenigen Tagen, nicht mit Wochen — vorausgesetzt, der Meilisearch-Index selbst steht schon. Der Aufwandstreiber ist nicht die Konfiguration, sondern das Testen gegen echte Suchanfragen.
Was semantische Suche kostet: die ehrliche Rechnung
Jetzt zu der Frage, die in keinem der Definitions-Artikel steht, die bei Google oben ranken: Was kostet das konkret? Die Antwort überrascht die meisten — die KI-Gebühren sind der kleinste Posten.
Alle Zahlen in diesem Abschnitt stammen von den Preisseiten der Anbieter, abgerufen am 04.09.2026, und aus einem durchgerechneten Beispiel: 100.000 Dokumente, 50.000 Suchanfragen pro Monat. Das entspricht einem mittleren Shop oder einem gut gefüllten Hilfe-Center.
Embedding-Gebühren: Cent-Beträge
Rechnen wir ein mittelgroßes Beispiel durch: 100.000 Dokumente à rund 200 Token ergeben 20 Millionen Token. Mit text-embedding-3-small zu 0,02 $ pro Million Token kostet die komplette Erst-Indexierung rund 0,40 $ (developers.openai.com, Abruf 04.09.2026). Kein Tippfehler: vierzig Cent.
Die Suchanfragen sind noch billiger: 50.000 Anfragen à etwa 10 Token sind 0,5 Millionen Token, also rund 0,01 $ pro Monat. Selbst wenn du den Katalog wöchentlich komplett neu einbettest, bleibst du unter 2 $ monatlich. Die Gebühren fallen zwar je Dokument und je Anfrage an — in dieser Größenordnung sind sie trotzdem kein Entscheidungskriterium.
Infrastruktur: Cloud oder Self-Hosting
Meilisearch Cloud startet bei 20 $ pro Monat. Der Preisrechner nennt für 100.000 Dokumente und 50.000 Suchanfragen rund 30 $ monatlich nutzungsbasiert, alternativ 23 $ mit fester Instanz (meilisearch.com/pricing, Abruf 04.09.2026). Ein Aufpreis für hybride Suche steht nicht auf der Preisseite: Die Embedder-Gebühren zahlst du direkt beim KI-Anbieter.
Self-Hosting kostet nur den Server. Zur Lizenz gehört seit 2025 eine Nuance: Der Meilisearch-Kern ist MIT-lizenziert und frei kommerziell nutzbar, nur Enterprise-Module wie Sharding stehen unter der Business Source License und brauchen produktiv einen Vertrag — jeder Stand wird nach vier Jahren MIT (github.com/meilisearch, LICENSE, Abruf 04.09.2026). Für eine einzelne Website-Suche berührt dich das nicht.
Für die Betriebsentscheidung gilt die übliche Logik: Self-Hosting spart die Cloud-Gebühr, kostet aber Updates, Monitoring und Backups in Eigenregie. Bei einem einzelnen Suchindex ist das überschaubar — trotzdem ehrlich einpreisen, statt mit «der Server läuft ja eh» zu kalkulieren.
Die echten Kosten: Engineering und Pflege
Die ehrliche Rechnung endet nicht bei den API-Gebühren. Was ein solches Projekt wirklich kostet, ist Arbeitszeit: das Document Template entwerfen, das semanticRatio gegen echte Suchanfragen testen, die Re-Indexierungs-Pipeline bauen und betreiben, die Relevanz nach dem Launch beobachten.
Aus meiner Projekterfahrung liegen diese Posten um Größenordnungen über den Cent-Beträgen der Embeddings. Wer nur die API-Preise budgetiert, budgetiert das Falsche: Der Dienstleister oder das eigene Team kostet mehr als der komplette KI-Anteil des Projekts.
Zusammengefasst für das Beispiel: rund 20 bis 30 $ Infrastruktur pro Monat, Cent-Beträge für Embeddings, dazu die Arbeitszeit für Einbau und Pflege. Das ist kein Enterprise-Budget — es ist ein Feature-Projekt, das du gegen andere Features abwägen kannst.
Die Grenzen: wann du sie nicht brauchst
Jetzt der Teil, der mich Aufträge kosten kann: Viele Websites brauchen keine semantische Suche. Sie brauchen erst einmal eine funktionierende Suche — und das ist häufig etwas anderes.
Der häufigste Fall in meiner Praxis: Ein gepflegter Katalog mit sauberen Titeln und Beschreibungen, dessen Suche an Tippfehlern und fehlenden Facetten scheitert. Typo-Toleranz und gute Ranking-Regeln lösen dort den Großteil der Beschwerden — ganz ohne Embeddings, ohne KI-Anbieter, ohne laufende Zusatzkosten.
Deshalb meine Reihenfolge: erst messen, dann zahlen. Schau in deine Suchanalyse und beantworte zwei Fragen: Welche Anfragen liefern null Treffer? Und sind das Tippfehler und Schreibvarianten oder echte Bedeutungslücken wie «Geschenk für Grillfans»?
Nur die zweite Kategorie rechtfertigt semantische Suche. Ohne diese Messung kaufst du eine Lösung für ein Problem, das du nicht belegt hast.
Zweite Grenze: Erklärbarkeit. Bei einer Keyword-Suche siehst du jedem Treffer an, warum er da steht. Hinter einem semantischen Treffer steht ein Ähnlichkeitswert aus einem Modell — landet ein unpassendes Ergebnis auf Platz drei, wird das Debugging zäh. Plane dafür Zeit ein, statt auf Magie zu hoffen.
Dritte Grenze: Hersteller-Benchmarks. Zahlen wie «X Prozent bessere Relevanz» stammen fast immer aus Vendor-Material mit unbekanntem Testaufbau. Ich übernehme solche Werte grundsätzlich nicht, und du solltest keine Kaufentscheidung darauf bauen: Miss die Relevanz mit deinen eigenen Suchanfragen, vorher und nachher.
Wie du «vorher und nachher» praktisch misst: Nimm zwanzig echte Anfragen aus deinem Log, davon zehn bekannte Problemfälle, und bewerte die jeweils ersten fünf Treffer vor und nach der Umstellung. Das ist kein wissenschaftliches Verfahren — aber es schlägt jede Bauchentscheidung und jeden Hersteller-Benchmark.
Vierte Grenze: Semantik ersetzt keine Datenpflege. Bestehen deine Produkttexte aus drei Wörtern, hat auch das beste Embedding-Modell nichts, woraus es Bedeutung ziehen könnte. Erst Inhalte, dann Intelligenz — mehr dazu gleich im B2B-Sonderfall.
Kurz: Semantische Suche ist ein präzises Werkzeug für ein präzises Problem. Der Merksatz des ganzen Such-Themas gilt auch hier:
Du brauchst selten Elasticsearch. Du brauchst fast immer eine bessere Suche, als deine Website heute hat.
Sonderfall B2B-Produktdaten
Ein Spezialfall verdient eigene Artikel: B2B-Produktdaten. Wenn deine Kunden nach Anwendungen statt nach Artikelnummern suchen («Dichtung für Trinkwasserleitung» statt einer DIN-Bezeichnung), hängt die Suchqualität weniger an der Technik als an den Produktdaten selbst. Ein Bedeutungsmodell kann nur finden, was in den Daten steht. Das klassische Muster: Der Einkäufer weiß genau, was das Teil leisten soll, aber nicht, wie es bei dir heißt.
Wie du vom Artikelnummern-Denken zur Anwendungs-Suche kommst, steht im Artikel zur semantischen Produktsuche im B2B. Und wenn deine Katalogtexte dafür zu dünn sind, kommt vorher der Schritt, Katalogdaten mit KI anzureichern: erst brauchbare Beschreibungen, dann Embeddings. Die Reihenfolge umzudrehen verschenkt Geld.
Der Unterschied zu diesem Artikel hier: Dort geht es um die Datenperspektive, also Attribute, Anwendungsfälle und Datenpflege. Hier geht es um die generische Technik- und Kostenperspektive. Erst beides zusammen ergibt eine Suche, die B2B-Einkäufer wirklich ans Ziel bringt. Deshalb teilen sich beide Artikel auch bewusst keine Keywords: Sie beantworten verschiedene Fragen.
Nächste Schritte
Wenn du bis hierhin gelesen hast, kennst du meine Empfehlung schon: Fang nicht beim Werkzeug an, fang bei deinen Suchdaten an. Zieh die Null-Treffer-Anfragen der letzten drei Monate aus deiner Suchanalyse, sortiere sie in Tippfehler und Bedeutungslücken und entscheide erst dann über den Stack. Diese Analyse kostet dich einen Nachmittag — und sie sagt dir, ob du ein Typo-Toleranz-Problem oder ein echtes Semantik-Projekt vor dir hast.
Die Kurzfassung der Entscheidung: Postgres-Volltext, wenn eine einfache Suche reicht. Meilisearch mit Typo-Toleranz, wenn Nutzer tippen wie Menschen. Hybride Suche, wenn deine Suchanalyse echte Bedeutungslücken zeigt. pgvector auf Supabase, wenn eine Anwendung Fragen beantworten soll statt Dokumente zu finden.
Wenn du dabei Unterstützung willst: Ich schaue mir deine Suchanalyse mit dir an und sage dir auch dann ehrlich Bescheid, wenn Typo-Toleranz reicht und du dir die Embedding-Pipeline sparen kannst. Buch dir ein unverbindliches Erstgespräch — nach 30 Minuten weißt du, welche Stufe der Such-Hierarchie dein Projekt braucht.
