- Textvergleich, Volltextsuche und semantische Suche unterscheiden
- die Funktionsweise eines invertierten Index verstehen
- entscheiden, wann PostgreSQL genügt und wann eine eigene Suchmaschine sinnvoll ist
- hybride Suche als Grundlage für RAG-Anwendungen einordnen
Suchen ist eine der häufigsten Tätigkeiten in Anwendungen: Produkte im Shop, Artikel im Ratgeber, Kunden im CRM, Lektionen in einer Lernplattform. Eine schlechte Suche frustriert Nutzer schnell – sie finden nichts, obwohl das Gesuchte existiert, oder sie finden hundert Treffer, von denen der passende auf Seite drei steht. Mit dem Aufkommen von KI-Anwendungen hat die Suche zudem eine neue Rolle bekommen: Sie liefert Sprachmodellen den Kontext, auf dessen Grundlage sie antworten. Diese Lektion zeigt, wie Suche technisch funktioniert und wie man sie im Systementwurf plant.
1. Drei Arten zu suchen
Der einfachste Ansatz ist ein Textvergleich in der Datenbank, etwa mit LIKE. Er findet nur exakt passende Zeichenketten, ignoriert Wortformen und Synonyme und wird bei großen Tabellen langsam, weil er keinen normalen Index nutzen kann. Die Volltextsuche zerlegt Texte in Wörter, führt sie auf Wortstämme zurück, ignoriert Füllwörter und gewichtet Treffer nach Relevanz. Die semantische Suche schließlich vergleicht Bedeutungen: Sie wandelt Texte in Vektoren um und findet Inhalte, die inhaltlich ähnlich sind, auch wenn andere Wörter verwendet werden. Probieren Sie den Unterschied aus:
- Keine Treffer.
Probieren Sie auch: „akku winter“, „rad pflege“, „rahmen“.
2. Wie Volltextsuche funktioniert
Bevor Texte in den Index kommen, werden sie aufbereitet: in Wörter zerlegt, kleingeschrieben, von Füllwörtern befreit und auf Stämme reduziert, sodass „Fahrräder“ und „Fahrrad“ zusammenfinden. Bei der Suche wird die Anfrage genauso aufbereitet. Die Treffer werden dann nach Relevanz sortiert, klassisch mit Verfahren wie BM25, das berücksichtigt, wie oft ein Wort in einem Dokument vorkommt und wie selten es insgesamt ist. Ein seltenes Wort wie „Rahmengröße“ ist aussagekräftiger als ein häufiges wie „Fahrrad“.
PostgreSQL bietet eine eingebaute Volltextsuche mit Unterstützung für Deutsch, die für viele Anwendungen völlig ausreicht. Ergänzt um die Erweiterung pg_trgm für Tippfehlertoleranz lässt sich damit eine gute Suche bauen, ohne ein zusätzliches System zu betreiben. Eigene Suchmaschinen wie Elasticsearch, OpenSearch, Meilisearch oder Typesense lohnen sich, wenn Anforderungen wie Facetten, Tippfehlertoleranz auf großem Datenbestand, Suche während des Tippens, komplexe Relevanzsteuerung oder sehr große Datenmengen hinzukommen.
| Anforderung | Empfehlung |
|---|---|
| einfache Suche in Titeln und Texten, bis einige Millionen Einträge | PostgreSQL-Volltextsuche |
| Tippfehler, Teilwörter | zusätzlich pg_trgm oder eine Suchmaschine |
| Facetten, Filter, Sortierung, Suche beim Tippen im Shop | Meilisearch, Typesense, OpenSearch |
| Bedeutungssuche, Fragen in natürlicher Sprache | Vektorsuche, etwa pgvector |
| Grundlage für KI-Antworten (RAG) | hybride Suche aus Volltext und Vektor |
3. Semantische Suche und Vektoren
Für die semantische Suche werden Texte mit einem Embedding-Modell in Vektoren umgewandelt, also in lange Zahlenreihen, die die Bedeutung abbilden. Ähnliche Bedeutungen liegen im Vektorraum nah beieinander. Eine Anfrage wie „Batterie hält im Winter nicht lange“ findet dann auch einen Artikel über „Pedelec-Reichweite bei Kälte“, obwohl kein Wort übereinstimmt. Für die Speicherung und Suche gibt es Vektordatenbanken oder Erweiterungen wie pgvector, die PostgreSQL um Vektorspalten und passende Indizes erweitern.
Semantische Suche hat aber auch Schwächen. Sie ist schlecht bei exakten Begriffen wie Artikelnummern, Namen oder Fachbegriffen, die das Modell nicht kennt, und ihre Ergebnisse sind schwerer nachvollziehbar. Deshalb hat sich in der Praxis die hybride Suche durchgesetzt: Volltext- und Vektorsuche laufen parallel, und die Ergebnisse werden kombiniert, etwa mit dem Verfahren Reciprocal Rank Fusion. Oft folgt noch ein sogenannter Reranker, ein Modell, das die besten Treffer genauer bewertet und neu sortiert.
4. Suche im Systementwurf
Im Entwurf ist die Suche fast immer ein abgeleiteter Speicher, wie in der ersten Lektion dieses Moduls beschrieben. Die Quelle der Wahrheit bleibt die Datenbank; der Suchindex ist eine Kopie, die für schnelles Finden optimiert ist. Daraus folgen einige Aufgaben. Der Index muss aktuell gehalten werden, meist über Ereignisse oder das Outbox-Muster, sobald sich Inhalte ändern. Er muss sich jederzeit vollständig neu aufbauen lassen, etwa nach einer Änderung der Aufbereitung. Und er muss Berechtigungen respektieren: Ein Nutzer darf in der Suche nur finden, was er auch öffnen darf. Gerade bei Anwendungen mit mehreren Mandanten oder privaten Inhalten ist das eine häufige Fehlerquelle.
Hinzu kommt die Frage der Qualität. Eine Suche ist nie fertig. Welche Suchen liefern keine Treffer? Welche Treffer werden angeklickt, welche übersprungen? Solche Auswertungen zeigen, wo Synonyme fehlen, Inhalte schlecht aufbereitet sind oder die Gewichtung nicht passt. Für KI-Anwendungen gilt das besonders: Die Qualität der Antworten eines RAG-Systems hängt direkt davon ab, ob die Suche die richtigen Textstellen findet. Das Modul KI-Systeme entwerfen greift dieses Thema wieder auf und zeigt, wie man Retrieval systematisch bewertet.
Mit dieser Lektion endet das Modul Daten speichern. Sie kennen jetzt die wichtigsten Datenbanktypen, Transaktionen, Indizes, Replikation und Sharding, Konsistenzmodelle, Objektspeicher und Suche – das Fundament fast jedes Systementwurfs. Im nächsten Modul geht es darum, wie Systeme mit wachsender Last umgehen: Skalierung, Lastverteilung, Caching, Warteschlangen und der richtige Umgang mit Zeitlimits und Wiederholungen.
Ein Tipp für den Einstieg: Beginnen Sie mit der eingebauten Volltextsuche von PostgreSQL und protokollieren Sie von Anfang an die Suchanfragen, die keine Treffer liefern. Diese Liste ist die wertvollste Quelle für Verbesserungen. Oft zeigt sie fehlende Synonyme, andere Schreibweisen oder Themen, zu denen es schlicht noch keine Inhalte gibt – eine Erkenntnis, die auch für die Redaktion wertvoll ist. Erst wenn die Anforderungen wirklich darüber hinausgehen, lohnt der Umstieg auf eine eigene Suchmaschine oder eine hybride Lösung.
Denken Sie bei der Suche außerdem an die Nutzer, die nicht genau wissen, wonach sie suchen. Vorschläge während des Tippens, Filter nach Kategorien, eine hilfreiche Seite ohne Treffer mit Alternativen und eine gute Sortierung nach Relevanz machen oft mehr aus als die technisch ausgefeilteste Suchmaschine. Die beste Suche ist die, bei der Nutzer schnell finden, was sie brauchen – egal, welche Technik dahintersteckt.
Messen Sie deshalb nicht nur die technische Geschwindigkeit der Suche, sondern auch, wie oft Nutzer nach einer Suche tatsächlich etwas anklicken und finden. Diese Kennzahl zeigt am ehrlichsten, ob Ihre Suche ihren Zweck erfüllt, und sie hilft, Verbesserungen an Aufbereitung, Gewichtung und Inhalten gezielt zu priorisieren. Eine kleine, regelmäßig gepflegte Liste mit den häufigsten Suchanfragen und ihren besten Treffern ist dafür ein hervorragender Ausgangspunkt, auch für automatisierte Tests der Suchqualität nach jeder Änderung an Index, Synonymen oder Gewichtung, bevor Nutzer die Auswirkungen bemerken.
- [1]PostgreSQL Global Development Group (2026): Documentation – Full Text Search; pg_trgm.
- [2]Manning, C. D.; Raghavan, P.; Schütze, H. (2008): Introduction to Information Retrieval. Cambridge: Cambridge University Press.
- [3]Robertson, S.; Zaragoza, H. (2009): The Probabilistic Relevance Framework: BM25 and Beyond. Foundations and Trends in Information Retrieval 3(4), 333–389.
- [4]Cormack, G. V.; Clarke, C. L. A.; Büttcher, S. (2009): Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods. Proceedings of ACM SIGIR, 758–759.
- [5]pgvector (2026): Open-source vector similarity search for Postgres. github.com/pgvector/pgvector.
Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.