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.
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.
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 CEmbeddings 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.
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.)
Viele Consumer-Apps werben 2026 mit «KI-Suche». Die meisten meinen damit eines von drei Dingen:
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.
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:
pgvector-Extension; eigenständige Vektor-DBs wie Qdrant, Pinecone und Weaviate nutzen alle HNSW oder nahe Varianten. SavedThat fährt HNSW auf pgvector, weil Vektoren neben den relationalen Metadaten zu halten operativ einfacher ist als zwei Datenbanken zu pflegen.halfvec(768)-Typ in pgvector ist jetzt Default für jedes kostenbewusste Deployment.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.
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 ist die Technik, die seit 2024 leise zum Default in ernsthaften produktiven Suchsystemen geworden 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.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)
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.
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 (9,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.
Drei Gründe:
halfvec und MRL ist die Rechnung doppelt so hoch.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.
Wenn du 2026 ein Suche-in-X-Tool evaluierst, frag:
text-embedding-3-small funktioniert über 100+ Sprachen; ältere oder kleinere Modelle nicht.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.
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.
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.
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.
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.
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).
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.
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, ranked by what they actually do well. SavedThat, Glasp, Otter, Fireflies, Reduct, Trint, plus DIY Whisper.
The best AI video bookmark manager in 2026 depends on what you save. Honest comparison of SavedThat, Mymind, Raindrop, and Glasp — pricing, search, platforms.