DDC hakt nach: Wann führt eine semantische Suche nicht zum Ziel?
Gregor Biswanger spricht auf der .NET Developer Conference 2025 über Vektordatenbanken und deren sinnvollen Einsatz. Eng damit verbunden ist die semantische Suche. Im Interview erklärt er, wann klassische Volltextsuche unschlagbar bleibt, welche Rolle Hybrid-Ansätze spielen und warum RAG nicht automatisch semantische Suche bedeutet. Außerdem gibt er Einblicke in Kostenkalkulation, Energieverbrauch und die richtige Wahl von Vektordatenbanken – und verrät, wie Unternehmen typische Fallstricke vermeiden können.
Wo funktioniert eine semantische Suche brillant und wo ist sie Geldverschwendung?
Gregor: Die semantische Suche spielt ihre Stärken aus, wenn Menschen nicht nach einem exakten Begriff suchen, sondern eine inhaltliche Frage stellen. Denk an lange, unstrukturierte Dokumente wie Handbücher, interne Richtlinien, Support-Tickets oder Forschungsberichte. Da reicht es nicht, Zeichenketten zu vergleichen, das System muss den Sinn verstehen.
Das gelingt heute, weil Encoder-Modelle wie BERT seit 2018 einen großen Sprung gemacht haben. Sie wandeln Text in Vektoren um, die den Kontext abbilden, und erkennen dadurch Bedeutungsähnlichkeiten. So findest Du auch Antworten, wenn jemand eine Frage ganz anders formuliert, etwa in einer anderen Sprache oder mit Synonymen. Wobei wichtig ist: Semantische Suche über Sprachen hinweg funktioniert nur mit dafür trainierten Embedding-Modellen. Ohne mehrsprachiges Training fällt die Qualität deutlich ab.
Das Missverständnis: Viele glauben, RAG (Retrieval Augmented Generation) sei automatisch semantische Suche. RAG heißt aber nur, dass Du ein Sprachmodell zur Laufzeit mit externen Informationen anreicherst. Das kann eine Vektordatenbank sein, muss es aber nicht. Oft reicht es, wenn Du aus einer semantischen Suchanfrage mit einer KI gezielt Keywords erzeugst, diese an bestehende Intranet- oder Datenbanksuchen weitergibst und die Ergebnisse dann per RAG einbindest. So nutzt Du vorhandene Systeme, ohne sofort von einem bestimmten Embedding-Modell, einer komplexen Chunking-Strategie oder dem ständigen Re-Indexieren abhängig zu werden. Mehr dazu erkläre ich in meiner Session oder dem Video Mythos entlarvt! RAG ist KEINE semantische Suche.
Semantische Suche sucht nach Bedeutungsgleichheit und nicht nach exakten Treffern. Wenn Du eine Compliance-Vorschrift oder eine Bestellnummer suchst, willst Du keine ähnliche Antwort, sondern exakt die richtige. Die Qualität hängt von vielen Faktoren ab, vom Embedding-Modell über den richtigen Zuschnitt der Texte bis hin zur Konfiguration der Vektordatenbank. Wenn die Ergebnisse schlecht sind, ist es oft aufwendig herauszufinden, woran es liegt.
Am besten funktioniert eine semantische Suche mit Vektordatenbanken, wenn Du externe Wissensquellen vollständig erfassen und sinnvoll chunken, also aufteilen kannst. Für Dokumente mit klarem Ursprung und Kontext ist ein gutes Encoder-Modell essentiell. In allen anderen Fällen ist oft eine Hybrid-Suche aus BM25 und Vektorsuche plus Query Rewriting der bessere Startpunkt. Optimal ist ein dreistufiges Retrieval-Setup: Hybrid Query für hohe Abdeckung, Reranking mit einem Cross Encoder wie dem Azure Semantic Ranker für die beste Reihenfolge und Query Rewriting, um Suchanfragen zu optimieren.
Gibt es eine Faustregel, wann man bei klassischer Volltextsuche bleiben sollte und wann sich der Aufwand für Vektordatenbanken lohnt?
Gregor: Die Grundfrage ist immer, ob der Suchbegriff exakt vorkommen muss oder ob es reicht, wenn der Sinn übereinstimmt. Für exakte Treffer ist die klassische Volltextsuche unschlagbar.
Sobald Fragen nicht nur auf den Wortlaut zielen, sondern auf den Inhalt, spielt Semantik ihre Stärke aus. Beispiel: Jemand sucht nicht nach „Reisekostenrichtlinie 2024“, sondern fragt: „Welche Ausgaben darf ich auf einer Geschäftsreise abrechnen?“. Die passende Stelle im Dokument könnte ganz andere Formulierungen enthalten wie „erstatten“ oder „übernehmen“. Hier findet Semantik zuverlässig, was eine reine Keyword-Suche verpassen würde.
In der Praxis ist ein Hybrid-Retrieval meist am robustesten, ergänzt durch Query Rewriting, um Suchbegriffe zu optimieren. Der anschließende Einsatz eines Rerankers, idealerweise eines Cross Encoders wie dem Azure Semantic Ranker, hat oft einen größeren Einfluss auf die Ergebnisqualität als die Wahl der Vektordatenbank. Bei der Dokumentaufbereitung spielt Chunking eine wichtige Rolle, aber oft entscheidet erst das Reranking über die wirkliche Relevanz. Sinnvoll ist es, Chunks an Satz- oder Absatzgrenzen zu schneiden, Überschriftenkontext beizubehalten und ein hohes k im Retrieval für guten Recall zu wählen, bevor der Reranker greift. Meine getesteten Top-Strategien zeige ich in Scheitert dein RAG? Top 3 Chunking-Strategien im Test!
Der Markt ist voll von Vektordatenbanken. Welche setzt Du wann ein und woran erkennst Du, dass Du die falsche gewählt hast?
Gregor: Technisch speichern alle Vektordatenbanken Vektoren und vergleichen sie mit einem Nearest-Neighbor-Algorithmus, das ist ziemlich primitiv und kann jeder mit wenigen Zeilen Code selbst schreiben. Der Unterschied liegt in Geschwindigkeit, Filtermöglichkeiten, Integrationsfähigkeit und Kostenmodell, bei richtig großen Datenmengen.
Ich entscheide immer aus dem Ökosystem heraus. Nutzt Du schon Elasticsearch oder OpenSearch, bleib dabei und aktiviere deren Vektor-Funktionalität. In MongoDB-Umgebungen ist Atlas Vector Search ideal. Arbeitest Du mit Postgres, ist pgvector eine gute Wahl. Willst Du schnell skalieren und keinen eigenen Betrieb sicherstellen müssen, sind Pinecone, Weaviate Cloud oder Zilliz spannend. Für extrem große Datenmengen sind Milvus, Vespa oder Qdrant geeignet. Qdrant wird in OpenAI-Beispielen und Tutorials gezeigt.
Falsch gewählt hast Du, wenn die Latenz zu hoch ist, Filter nur eingeschränkt funktionieren oder die Kosten mit der Datenmenge explodieren. Besonders kritisch ist der Lock-in bei Embedding-Modellen. Wechselst Du das Modell, musst Du alle Vektoren neu berechnen.
Wie kalkulierst Du die Kosten für ein Projekt mit 100.000 Dokumenten und 1.000 Suchanfragen pro Tag?
Gregor: Ich rechne das bewusst einfach vor. Bei 800 Tokens pro Dokument und etwas Overlap beim Chunking kommst Du auf etwa 250.000 Vektoren. Ein hochwertiges Embedding-Modell kostet aktuell rund 0,00013 Dollar pro 1.000 Tokens, das sind umgerechnet etwa 0,00012 Euro. Für 92 Millionen Tokens zahlst Du also einmalig nicht mal 11 Euro für den Initial-Index.
Die laufenden Kosten sind minimal. 1.000 Anfragen pro Tag mit 50 Tokens im Schnitt ergeben rund 20 Cent pro Monat in Euro für Embeddings. Zum Vergleich: Würdest Du diese 1.000 Anfragen pro Tag mit GPT-5 im Vollmodus verarbeiten, würdest Du bei aktuellen Preisen von 1,25 Dollar pro 1 Million Input-Tokens und 10 Dollar pro 1 Million Output-Tokens schnell im Bereich von 300 bis 500 Euro pro Monat liegen, abhängig vom Kontextfenster und der Länge der Antworten.
Bei Vektordatenbanken solltest Du den Speicher- und Index-Overhead berücksichtigen. HNSW-Indices benötigen je nach Dimensionalität und Parameter zwischen 1 und 20 Prozent zusätzlichen Speicher. Die Infrastrukturkosten hängen davon ab, ob Du einen eigenen Cluster betreibst oder einen Managed-Vector-Service nutzt. Hier bestimmen Speichergröße, SLA und Performanceanforderungen den Preis.
Und wie sieht es mit dem Energieverbrauch aus?
Gregor: Der Energieverbrauch ist geringer als bei der Generierung von Text mit großen Sprachmodellen, aber nicht immer vernachlässigbar. Er hängt stark von Batchgröße, Pipeline-Optimierung und der verwendeten Hardware ab. Eine NVIDIA T4 läuft mit 70 Watt TDP und kann bei optimalem Setup Millionen Embeddings mit wenigen Zehntel Kilowattstunden erzeugen. Ich empfehle, den tatsächlichen Verbrauch mit Tools wie CodeCarbon zu messen und Optimierungen wie Caching, Batch-Verarbeitung und kleinere Modelle für Query Rewriting oder Reranking einzusetzen. So reduzierst Du Kosten und CO₂-Ausstoß spürbar.
Was ist dein Fazit für Unternehmen, die sich mit dem Thema beschäftigen?
Gregor: Entscheidend ist, zuerst das Suchproblem zu verstehen. Geht es um exakte Begriffe, liefert klassische Volltextsuche die besten und überprüfbaren Ergebnisse. Wenn Nutzer konzeptionell fragen, bringt eine Kombination aus BM25 und Vektorsuche, ergänzt durch Query Rewriting, oft den größten Mehrwert. Das anschließende Reranking mit einem starken Cross Encoder wie dem Azure Semantic Ranker sorgt für die beste Ergebnisqualität. Plane den Einsatz von Embeddings so, dass Du das Modell bei Bedarf wechseln kannst, ohne alles neu berechnen zu müssen. Evaluiere dein System regelmäßig mit Metriken wie NDCG@k oder MRR anhand einer Goldliste und führe Online-A/B-Tests durch, um reale Verbesserungen zu messen. Behalte im Hinterkopf, dass Embeddings günstig und energieeffizient sein können, der Aufwand sich aber vor allem dort lohnt, wo Datenmenge und Informationsbedarf klar über das hinausgehen, was eine rein Keyword-basierte Suche leisten kann.
Du willst noch mehr zu dem Thema wissen? Dann komm auf die .NET Developer Conference 2025 vom 24. bis 27. November 2025. Hier erfährst Du alles rund um Microsoft .NET. Gregors Session findet am Dienstag, dem 25. November 2025, um 11.40 Uhr im Track Data & Analytics statt.
Du hast noch kein Ticket? Dann hol Dir gleich eines.
