Typesense im Einsatz: Suche, die weiß, was sie durchsucht
KI-generiert, menschlich reviewt
Die Suche ist auf vielen Websites die schwächste Stelle. Das liegt selten an der Suchtechnik und fast immer daran, was ihr vorgesetzt wird: Die eingebaute Suche eines Redaktionssystems kennt meist nur eine Sorte Inhalt — „Seite” — und sortiert danach, wie oft ein Wort darin vorkommt. Wer auf einem Kunstmagazin nach einem Galerienamen sucht, bekommt dann drei Artikel, in denen die Galerie erwähnt wird, aber nicht die Galerie selbst.
Wir setzen für Volltextsuche seit einiger Zeit auf Typesense — eine quelloffene Suchmaschine, die man selbst betreibt. Dieser Artikel beschreibt, was sie in drei sehr unterschiedlichen Projekten tut, warum die eigentliche Arbeit im Datenmodell steckt und wie derselbe Index eine Website dazu bringt, Fragen zu beantworten statt nur Links zu liefern.
1. Was Typesense ist — kurz
Typesense ist ein eigener kleiner Dienst neben der Website. Er hält eine Kopie der Inhalte im Arbeitsspeicher und beantwortet Suchanfragen in wenigen Millisekunden, auch bei Tippfehlern. Anders als die bekannten Suchdienste aus der Cloud läuft er auf der eigenen Infrastruktur: Die Inhalte verlassen das Haus nicht, und es gibt keine nutzungsabhängige Rechnung.
Der Index ist dabei kein Datenbestand, den man pflegen muss. Er wird aus der Website neu erzeugt und ist damit wegwerfbar — kein Backup, keine Migration, im Zweifel ein Neuaufbau.
2. openDesk: Suche, wo das CMS keine hat
Für das Zentrum für Digitale Souveränität haben wir die Website zu openDesk gebaut — bewusst schlank, auf einem dateibasierten CMS ohne Laufzeit-Datenbank. Das ist gut für Betrieb und Sicherheit und schlecht für die Suche: Ohne Datenbank gibt es nichts, worüber sich suchen ließe.
Typesense schließt genau diese Lücke: Der Suchindex liegt als eigener Dienst neben der Website, nicht in einer Datenbank hinter dem CMS. Die Suche auf opendesk.eu filtert nach Inhaltsart — Blog, FAQ, Produktseiten — und trennt sauber zwischen deutscher und englischer Fassung. Ein zweisprachiger Auftritt braucht das: Eine Suche, die englische Treffer in eine deutsche Ergebnisliste mischt, wirkt nicht mehrsprachig, sondern kaputt.
Der Aufwand ist hier klein, weil der Inhaltsbestand klein ist. Interessant wird es eine Größenordnung darüber.
3. Monopol: wenn Inhalt nicht gleich Inhalt ist
Für den Res Publica Verlag betreiben wir die Plattformen von Cicero und Monopol. Ein Kunstmagazin ist kein Stapel Artikel. Auf Monopol stehen neben rund 26.000 redaktionellen Beiträgen auch mehrere tausend Ausstellungen und Termine, mehrere hundert Orte — Galerien, Museen, Kunstvereine — und Künstlerprofile.
Diese Dinge haben nichts miteinander gemein außer der Sprache, in der sie geschrieben sind:
| Inhaltsart | Was sie ausmacht |
|---|---|
| Artikel | Autor, Rubrik, Datum, Bezahlschranke ja/nein |
| Ausstellung | Veranstaltungsort, Stadt, Laufzeit |
| Ort | Stadt und Art der Institution (Galerie, Museum, Kunstverein) |
| Künstlerprofil | Name, verknüpfte Beiträge |
Eine klassische Volltextsuche wirft all das weg. Sie kennt pro Treffer einen Titel und einen Textauszug — und muss eine Ausstellung, die morgen endet, genauso darstellen wie einen Kommentar von 2019.
In der Suche auf monopol-magazin.de behält jede Inhaltsart ihre eigenen Felder. Die Ergebnisse stehen nach Art gruppiert nebeneinander, jede Gruppe mit eigener Trefferzahl. Eine Ausstellung zeigt Ort, Stadt und Datum, ein Ort zeigt Stadt und Institutionsart, ein Artikel zeigt Autor und Rubrik — und ob er hinter der Bezahlschranke liegt, steht als eigenes Feld im Index und damit vor dem Klick in der Liste.
Das ist der eigentliche Punkt an strukturierten Daten in der Suche: Nicht die Suchmaschine wird besser, sondern das, was sie zurückgeben kann. Die Arbeit steckt nicht in der Installation, sondern in der Entscheidung, welche Felder je Inhaltsart in den Index gehören und welche davon filterbar sein müssen. Diese Entscheidung ist redaktionell, nicht technisch — und sie fällt am besten, bevor jemand ein Schema schreibt.
4. kontrollfeld.de: derselbe Index beantwortet Fragen
Auf dieser Website gehen wir einen Schritt weiter. Die Wortmarke im Seitenkopf ist ein Eingabefeld: Man stellt eine Frage und bekommt eine Antwort in Prosa, mit Verweisen auf die Stellen, aus denen sie stammt. Dahinter steht dasselbe Verfahren — Retrieval-Augmented Generation (RAG), also Suchen und anschließendes Formulieren.
flowchart LR
A[Frage des Besuchers] --> B[Typesense sucht Passagen]
B -->|Quellen stehen sofort fest| C[Belege werden angezeigt]
B -->|gefundene Passagen| D[Sprachmodell formuliert]
D --> E[Antwort mit Belegen]
Drei Dinge daran sind entscheidend, und alle drei haben mit dem Index zu tun, nicht mit dem Modell:
Der Index ist nach Abschnitten geschnitten, nicht nach Seiten. Eine Seite als Ganzes im Index ist für eine Antwort unbrauchbar: Sie kommt entweder komplett oder gar nicht, und ein Beleg verweist bestenfalls auf den Seitenanfang. Zerlegt in Abschnitte mit eigener Überschrift zeigt der Beleg auf die Passage, die die Aussage trägt.
Die Quellen stehen vor der Antwort fest. Nach der Suche ist bekannt, worauf sich die Antwort stützen wird — lange bevor das Modell den ersten Satz geschrieben hat. Also zeigen wir die Belege sofort. Scheitert die Formulierung, bleiben sie stehen; der Besucher hat trotzdem etwas in der Hand.
Das Modell sieht nur, was die Suche gefunden hat. Das ist die unbequeme Seite. Bei uns lieferte die Frage „Wem gehört Kontrollfeld?” lange die Antwort, dazu stehe nichts in den Inhalten — obwohl es auf der Website steht. Der Fehler lag nicht beim Modell: Das Impressum war nicht im Korpus, also hat das Modell korrekt über das geurteilt, was es sah. Wer RAG betreibt, debuggt zuerst das Retrieval und erst danach den Prompt.
Typesense sucht dabei nach Wörtern, nicht nach Bedeutung. Wer „Fahrzeug” eingibt, findet „Auto” nicht. Für einen überschaubaren Inhaltsbestand ist das verschmerzbar und die Antwort auf Lücken heißt besseres Retrieval, nicht sofort Vektorsuche. Ab welcher Größe sich ein Vektor-Store lohnt und welcher, haben wir an anderer Stelle verglichen. Und wer Inhalte nicht nur lesbar, sondern für KI-Assistenten aufrufbar machen will, braucht davor eine Kontrollschicht statt einer offenen Suchroute — einen eigenen MCP-Server.
5. Was es kostet
Typesense ist ein zusätzlicher Dienst, der laufen, überwacht und aktualisiert werden muss, und der Index liegt im Arbeitsspeicher — das ist der Preis für die Antwortzeiten. Dafür entfällt die nutzungsabhängige Abrechnung, und die Inhalte bleiben auf der eigenen Infrastruktur.
Die ehrliche Voraussetzung ist die andere: Suche lohnt den Aufwand dort, wo es etwas zu unterscheiden gibt. Bei fünfzig Seiten reicht eine gute Navigation. Bei 30.000 Dokumenten in vier Inhaltsarten ist die Suche das eigentliche Inhaltsverzeichnis.
Fazit
- Die Suche ist so gut wie das Datenmodell darunter. Die Arbeit steckt darin, je Inhaltsart die richtigen Felder zu bestimmen — nicht im Aufsetzen der Suchmaschine.
- Strukturierte Daten statt flacher Liste: Wenn Ausstellung, Ort und Artikel ihre eigenen Felder behalten, kann die Ergebnisliste zeigen, was den Treffer ausmacht, und danach filtern.
- Self-hosted ist hier unaufwendig: ein Dienst, ein aus der Website reproduzierbarer Index, keine Backup-Pflicht, keine nutzungsabhängige Rechnung.
- RAG steht und fällt mit dem Retrieval. Abschnittsweise indexieren, Belege vor der Antwort zeigen, und bei falschen Antworten zuerst prüfen, was das Modell überhaupt zu sehen bekam.