Wie semantische Suche funktioniert (und warum Keyword-Suche scheitert)
Wie semantische Suche 2026 funktioniert — Embeddings, Vektoren und hybrides Retrieval einfach erklärt. Warum Keyword-Suche deine Lesezeichen verfehlt und was es behebt.
Tipp «wie viel kostet es Kunden zu gewinnen» in eine gespeicherte-Lesezeichen-Suche und schau zu, wie nichts matcht. Das Video, das du suchst, ist genau da in deiner Bibliothek — du hast es gespeichert. Der Sprecher hat sechzehnmal «CAC» gesagt. Deine Suche hat «customer acquisition cost» gesagt. Die Wörter überschneiden sich nicht. Der Match scheitert.
Dieser Failure Mode hat einen Namen: das Vocabulary-Mismatch-Problem. Genau deshalb verliert Keyword-Suche immer wieder, und genau deshalb ist semantische Suche jetzt der Default in jedem ernsthaften Tool, das irgendetwas Text-Förmiges durchsucht. Unten: wie semantische Suche 2026 wirklich funktioniert — in einfachem Deutsch, kein Mathe-Studium nötig — und warum die meisten Consumer-Apps, die «KI-Suche» ausliefern, es immer noch falsch machen.
Das Vocabulary-Mismatch-Problem in 60 Sekunden
Alte Suchsysteme matchten wörtliche Strings. Du tippst customer acquisition cost, das System fand Dokumente mit genau diesen Wörtern. Dokumente, die «CAC» oder «die Kosten neue Käufer zu gewinnen» oder «was wir pro Signup zahlen» sagten, blieben unsichtbar.
In der Information-Retrieval-Forschung wird das seit vierzig Jahren gemessen. Typischer Vocabulary Mismatch liegt bei etwa 70–80%: Menschen benutzen die meiste Zeit andere Wörter für dasselbe Konzept. Wenn deine Suche nur wörtliche Strings matcht, verfehlst du vier von fünf relevanten Dokumenten. Das ist eine höfliche Art zu sagen «Keyword-Suche ist seit 1985 kaputt».
Zwei Dinge haben es gefixt. Das erste sind Embeddings: eine Methode, Bedeutung als Zahlen zu repräsentieren, sodass zwei Phrasen mit derselben Bedeutung «nah» beieinander landen, auch wenn sie kein Wort teilen. Das zweite sind Vektor-Datenbanken: Speicher und Indizes, die die nächsten Vektoren schnell finden können, selbst wenn der Korpus Millionen von Dokumenten umfasst.
Zusammen machen sie «semantische Suche» überhaupt erst möglich.
Was ein Embedding ist, einfach erklärt
Nimm einen Satz. Schick ihn durch ein neuronales Netz. Das Netz gibt eine Liste von Zahlen zurück — typischerweise 384, 768 oder 1.536. Diese Liste ist das Embedding des Satzes.
Der Trick: das Netz ist so trainiert, dass Sätze mit ähnlicher Bedeutung ähnliche Listen produzieren. Beispiel:
"Was sind Akquisekosten"→ Embedding A"Wie viel zahlen wir um einen neuen Kunden zu gewinnen"→ Embedding B"Wie geht es den Möwen heute"→ Embedding C
Embeddings A und B sind nah beieinander in dem 1.536-dimensionalen Raum, in dem sie leben. C ist weit weg. Nähe wird per Cosine Similarity gemessen — wie ausgerichtet die beiden Vektoren in diesem hochdimensionalen Raum sind. Werte nahe 1,0 bedeuten fast identische Bedeutung; Werte nahe 0 bedeuten unverwandt.
Stell es dir vor, als plottest du jede Phrase als Punkt in einer 1.536-dimensionalen Galaxie, in der Richtung Bedeutung kodiert. Die tatsächlichen Koordinaten sind für sich genommen sinnlos — was zählt, ist welche anderen Phrasen wo in der Nähe landen.
Das Modell, das das macht
Mehrere Modelle sind 2026 konkurrenzfähig. OpenAIs text-embedding-3-small liefert nativ 1.536 Dimensionen und unterstützt Matryoshka-Repräsentation (du kannst auf 768 oder 256 Dimensionen kürzen, um Speicher zu sparen, ohne neu zu trainieren). Coheres embed-v3 ist bei mehrsprachigem Content konkurrenzfähig. Open-Source-Alternativen wie bge-large und nomic-embed-text liegen wenige Genauigkeitspunkte darunter und laufen auf einem Mac.
Für mehrsprachige Workloads — wie gespeicherte Videos in 30 Sprachen mit Queries in jeder davon — ist text-embedding-3-small aktuell die beste Balance aus Genauigkeit, Kosten und Dimensionen. Bei SavedThat nutzen wir die 768-dim-Matryoshka-Kürzung: halber Speicher, ~99% der Suchqualität. (Mehr zur Matryoshka-Repräsentation.)
Warum «einfach KI nehmen» nicht dasselbe wie semantische Suche ist
Viele Consumer-Apps werben 2026 mit «KI-Suche». Die meisten meinen damit eines von drei Dingen:
- Echte semantische Suche — Embeddings + Vektor-Retrieval, wie oben beschrieben.
- LLM-on-top von Keyword-Suche — das System läuft eine Keyword-Suche, holt Ergebnisse und bittet ein LLM, sie umzuformulieren oder zusammenzufassen. Das Retrieval bleibt keyword-kaputt; das LLM übermalt nur die Fehler.
- Reines LLM-Q&A — du stellst eine Frage, das LLM antwortet aus seinem allgemeinen Training, deine gespeicherten Inhalte werden überhaupt nicht konsultiert.
Nur das erste löst Vocabulary Mismatch auf deinen Daten. Die anderen zwei sind produktisiert, aber nicht nützlich, um zu finden, was du gespeichert hast.
Eine schnelle Diagnose: wenn du nach dem Konzept suchen kannst und das Dokument nicht findest, es aber findest, wenn du nach einem seiner spezifischen Wörter suchst, macht das Tool #2 oder #3 verpackt als «KI-Suche». Findest du das Dokument per Paraphrase, ist es #1.
Vektor-Datenbanken: Embeddings schnell speichern und finden
Embeddings allein helfen nicht, wenn du jeden Query gegen Millionen Vektoren einzeln vergleichen musst. Die volle Durchsuchung eines 50.000-Dokument-Indexes dauert naiv Hunderte Millisekunden — viel zu langsam für interaktive Nutzung.
Der Fix ist Approximate Nearest Neighbour (ANN) Indexing. Spezialisierte Datenstrukturen — HNSW (Hierarchical Navigable Small World), IVF, ScaNN — speichern Vektoren so, dass die nächsten Treffer in unter 10 Millisekunden gefunden werden, selbst bei Bibliotheken mit zehn Millionen Vektoren.
Der aktuelle Stand der Technik (Mai 2026) für produktive semantische Suche:
- HNSW-Indexierung ist am häufigsten deployt. Postgres hat es via
pgvector-Extension; eigenständige Vektor-DBs wie Qdrant, Pinecone und Weaviate nutzen alle HNSW oder nahe Varianten. SavedThat fährt HNSW aufpgvector, weil Vektoren neben den relationalen Metadaten zu halten operativ einfacher ist als zwei Datenbanken zu pflegen. - Half-Precision-Speicher. Mit 16-Bit-Floats pro Dimension statt 32-Bit nehmen Vektoren halben Plattenplatz. Qualitätsverlust für Retrieval ist vernachlässigbar. Der
halfvec(768)-Typ inpgvectorist jetzt Default für jedes kostenbewusste Deployment. - MRL- (Matryoshka-) Kürzung. Einmal trainierte 1.536-dim-Embeddings werden beim Speichern auf 768 oder 256 Dimensionen pro Use Case gekürzt. Such erst einen schnellen 256-dim-Index ab, re-rank die Top 100 dann gegen die 768- oder 1.536-dim-Version.
In SavedThat-Größenordnung (aktuell ~120 gespeicherte Videos × ~50 Chunks pro Video = 6.000 Vektoren) passt der Index in den RAM, und Lookups sind unter einer Millisekunde.
Der Haken: semantische Suche allein liegt bei exakten Phrasen falsch
Jetzt die Pointe, die die meisten Tutorials auslassen: semantische Suche verliert bei exakten Phrasen gegen Keyword-Suche.
Wenn du nach "text-embedding-3-small" suchst (ein exakter Produktname), liefert Keyword-Suche das Dokument, das genau diesen String erwähnt, auf Rang 1. Semantische Suche kann ein Dokument höher ranken, das über «OpenAI-Embeddings im Allgemeinen» spricht, weil es der durchschnittlichen Bedeutung des Querys semantisch näher ist, obwohl der wörtliche String fehlt.
Das ist real. Öffentliche Benchmarks zeigen konsistent: reine Semantik unterperformt Keyword bei Queries mit hoher Spezifität: Produktnamen, Funktionssignaturen, exakte Zitate, Daten, Markennamen. Die Sache, die Semantik fixen sollte (Vocabulary Mismatch), existiert für solche Queries nicht — der Nutzer hat den wörtlichen String getippt, den er wollte.
Der Fix ist, beide laufen zu lassen und die Ergebnisse zu mergen.
Hybrides Retrieval mit Reciprocal Rank Fusion
Hybrides Retrieval ist die Technik, die seit 2024 leise zum Default in ernsthaften produktiven Suchsystemen geworden ist:
- Lauf eine semantische Suche (Vektor-Ähnlichkeit). Hol die Top-K-Ergebnisse nach Cosine sortiert.
- Lauf eine Volltextsuche (Keyword, tsvector, BM25, was auch immer). Hol die Top-K-Ergebnisse nach Relevanz-Score sortiert.
- Merge beide Listen mit Reciprocal Rank Fusion (RRF): der RRF-Score jedes Dokuments ist
1 / (rang + 60), summiert über die beiden Methoden. Dokumente, die in beiden gut auftauchen, bekommen einen spürbaren Boost; Dokumente, die nur in einer auftauchen, tragen trotzdem bei. - Sortier nach kombiniertem RRF-Score.
Die Konstante 60 ist eine Magic Number, die in zahllosen Benchmarks geprüft wurde und über die meisten Korpora hinweg funktioniert. Du kannst sie tunen; meistens musst du nicht.
Das Ergebnis: paraphrasierte Queries finden weiterhin Konzept-Matches (über die semantische Seite), und Exakte-Phrase-Queries ranken den wörtlichen Match weiterhin auf #1 (über die Keyword-Seite). Der Blindspot jeder Methode wird von der anderen abgedeckt.
Das ist, was SavedThat als Default-Suche ausliefert. Die search_chunks RPC in unserem Postgres läuft beide Queries parallel, berechnet RRF-Scores und liefert gerankte Treffer in ~80ms für unsere aktuelle Korpus-Größe. (Microsoft zu hybrider Suche)
Wo das noch fancy wird: Re-Ranking
Für High-Stakes-Use-Cases — Legal Discovery, medizinische Literatur, Enterprise-Suche über Millionen Dokumente — ist Hybrid RRF meist die vorletzte Schicht. Die letzte Schicht ist Re-Ranking mit einem Cross-Encoder-Modell.
Ein Cross-Encoder ist ein kleineres, langsameres Modell, das den vollen Query und das volle Kandidaten-Dokument nimmt und einen engen Relevanz-Score berechnet, indem es über beide gemeinsam Attention zieht. Du kannst es nicht auf einer Million Dokumente laufen lassen (zu langsam); du lässt es auf den Top 50–200 Ergebnissen vom hybriden Retrieval laufen, um sie präzise umzusortieren.
Cohere liefert rerank-v3 dafür. Open-Source-Alternativen: bge-reranker-large, jina-reranker-v2. Für Consumer-Scale-Workloads wie SavedThat rechtfertigt der marginale Gewinn die 100ms Latenz nicht. Für Enterprise-Legal-Discovery-Suche ist Cross-Encoder-Re-Ranking jetzt Standard.
Wir bauen es ein, wenn unser Korpus oder unser Use Case es verlangt. Nicht früher.
Das Kosten-Bild
Die ganze Pipeline ist grob:
| Schritt | Kosten |
|---|---|
| 1.000 Chunks embedden (~50 Videos) | ~0,02 $ in OpenAI-Credits |
| 1 Mio. Chunks in pgvector speichern | ~25 $/Monat auf einer kleinen Postgres-Instanz |
| HNSW-Index-Build für 1 Mio. Chunks | ~30 Sekunden, einmalig pro größerer Datenänderung |
| Eine Suchanfrage (embed + HNSW-Lookup + FTS + RRF) | ~0,0001 $ + 80ms |
Bei SavedThats Pricing deckt ein Pro-Abo (6,99 $/Monat) Tausende von Suchen und mehrere Hundert neue Saves. Die Ökonomie ist für Consumer-Scale fein; was nicht funktioniert, ist, das mit einem Free-Forever-Unbegrenzt-Plan zu finanzieren, weil die OpenAI-Rechnung linear mit Content wächst, während Revenue bei null gedeckelt ist.
Warum die meisten «Second Brain»-Tools das nicht ausliefern
Drei Gründe:
- Engineering-Komplexität. Hybrides Retrieval mit RRF erfordert zwei parallele Retrieval-Systeme und einen Merge. Die meisten Teams liefern eines. Das eine ist meist Keyword, weil es älter ist und der Stack ausgereift ist.
- Speicher-Kosten. Embeddings mit 1.536 Dimensionen × 4 Bytes/Dim = ~6 KB pro Chunk. Eine Bibliothek mit 100.000 Chunks ist 600 MB Vektor-Speicher zusätzlich zum Original-Text. Ohne
halfvecund MRL ist die Rechnung doppelt so hoch. - Trägheit. Die meisten existierenden Notiz-Tools wurden ausgeliefert, bevor Satz-Embeddings Commodity waren. Semantische Suche in Evernote oder Pocket nachzurüsten hätte ein Vektor-Datenbank-Projekt verlangt, das die Organisation nie priorisiert hat.
Die Tools, die semantische Suche von Tag eins ausliefern — Mem, Reflect, Glasps Premium-Tier, SavedThat — sind meist Post-2022-Builds, weil das damals war, als die Embedding-Kosten unter die Schwelle fielen, an der Consumer-Scale nachhaltig bepreist werden konnte.
Was das praktisch bedeutet
Wenn du 2026 ein Suche-in-X-Tool evaluierst, frag:
- Embeddet es? Wenn das Architektur-Diagramm keinen Vektor-Store enthält, ist die Antwort nein.
- Läuft es hybrides Retrieval? Reine Semantik ist bei vielen echten Queries schlechter als hybrid. Tools, die «Vektor-Suche», aber keine Volltextsuche ausliefern, machen es halb richtig.
- Unterstützt es mehrsprachig? Das ist eine Funktion des Embedding-Modells, nicht der Such-Infrastruktur.
text-embedding-3-smallfunktioniert über 100+ Sprachen; ältere oder kleinere Modelle nicht. - Zeigt es die Mathematik überhaupt? Tools, die ihr Retrieval erklären, machen es meist gut. Tools, die «KI-gestützte Suche ✨» sagen, ohne zu spezifizieren, machen meist Punkt 2 oder 3 von oben (LLM-on-top von Keyword oder reines Q&A).
Für Videos speichern und später finden: SavedThat liefert alle vier (Architektur-Übersicht hier). Glasp liefert nur Keyword (Free-Tarif) und Semantik (bezahlt). Mem liefert nur Semantik ohne Hybrid. Notions «KI-Suche» ist Punkt 2 — LLM auf Keyword.
So sieht die Landschaft im Mai 2026 aus.
Keep reading
Search inside saved videos: the complete 2026 guide
Search inside saved videos by what was actually said — across YouTube, Instagram, and TikTok. How transcript search works in 2026, and four tools that do it.
The 7 best video transcript search tools in 2026
The 7 best video transcript search tools in 2026, ranked by what they actually do well. SavedThat, Glasp, Otter, Fireflies, Reduct, Trint, plus DIY Whisper.
Best AI video bookmark manager in 2026: 4 tools compared
The best AI video bookmark manager in 2026 depends on what you save. Honest comparison of SavedThat, Mymind, Raindrop, and Glasp — pricing, search, platforms.
Frequently asked questions (2026)
Was ist der Unterschied zwischen einem Embedding und einem Vektor?
Funktional keiner — in der Praxis werden die Begriffe austauschbar verwendet. Streng genommen ist ein Embedding die *Repräsentation*, die ein Modell produziert, und ein Vektor ist einfach eine Liste von Zahlen. Jedes Embedding ist ein Vektor; nicht jeder Vektor ist ein Embedding (eine Spalte von Pixelintensitäten ist ein Vektor, aber kein Embedding). Die meisten Papers und Engineering-Docs nutzen «Vektor» als Speicher-Begriff und «Embedding» als konzeptionellen Begriff.
Funktioniert semantische Suche in jeder Sprache?
Hängt vom Embedding-Modell ab. OpenAIs text-embedding-3-small wurde auf 100+ Sprachen trainiert und produziert Vektoren, die über sie hinweg grob ausgerichtet sind — ein russischer Query und ein englisches Dokument zum selben Konzept landen in ähnlichen Regionen des Vektor-Raums. Kleinere Open-Source-Modelle degradieren oft signifikant bei nicht-englischen Inhalten. Wenn Mehrsprachigkeit Pflicht ist, prüfe ob die Model Card Cross-Lingual Alignment explizit erwähnt.
Wie unterscheidet sich hybride Suche davon, zwei Suchen zu laufen und beide anzuzeigen?
Zwei Suchen zu laufen und die Ergebnisse zu konkatenieren gibt dir nur doppelt so viele Ergebnisse. Hybride Suche merged sie per Score (RRF oder gewichtete Fusion), sodass das finale Ranking die Übereinstimmung beider Methoden widerspiegelt. Ein Dokument auf Rang 1 in Keyword und Rang 1 in Semantik landet insgesamt auf Rang 1; ein Dokument auf Rang 1 in Keyword und Rang 50 in Semantik fällt in die Mitte. Ohne Merge weißt du nicht, welchen Ergebnissen zu trauen ist.
Warum verliert reine semantische Suche bei exakten Phrasen gegen Keyword?
Embeddings kodieren semantische Bedeutung, nicht wörtliche Strings. Ein Query wie 'text-embedding-3-small' hat seine Bedeutung mehr in 'OpenAI-Embeddings-Familienmitglied' als in der wörtlichen Token-Sequenz. Der Vektor für den Query ist ähnlich zu Vektoren von Dokumenten, die OpenAI-Embeddings breit diskutieren, was höher ranken kann als das spezifische Dokument, das den exakten Produktnamen erwähnt. Keyword-Suche hat null Ambiguität auf exakten Strings — sie erscheinen oder nicht. Hybrid deckt beide Modi ab.
Ist RAG dasselbe wie semantische Suche?
Verwandt, aber nicht dasselbe. Semantische Suche ist der Retrieval-Schritt — finde Dokumente nahe an einem Query im Vektor-Raum. RAG (Retrieval-Augmented Generation) ist ein System, das semantische Suche nutzt, um Dokumente zu holen, und sie dann an ein generatives LLM gibt, das eine Antwort mit den Dokumenten als Kontext schreibt. RAG enthält semantische Suche als eine Komponente; du kannst semantische Suche ohne RAG haben (wenn du nur die Dokumente finden willst, nicht obendrauf Text generieren).
Brauche ich eine GPU, um semantische Suche zu fahren?
Für Inferenz — Suchen gegen einen bestehenden Index — nein. CPU reicht für Retrieval in Consumer-Größenordnung. Für den Index-Bau — das Embedding-Modell auf deinem Content laufen zu lassen — ist eine GPU schnell, aber nicht nötig. OpenAIs API macht das Embedding in ihrem Rechenzentrum und gibt dir den Vektor zum Speichern zurück; das Einzige auf deiner Seite ist die Vektor-Datenbank und das Query-Embedding (ein kurzer API-Call pro Query). Kosten sind Cents pro Tausend Suchen.