KI-Audioguide für Museen

Kein einzelnes Modell spricht jede Sprache gut, also tun wir nicht so, als ob. Unser TTS läuft als System mit drei Engines und smarter Auswahl pro Sprache: Chatterbox Turbo übernimmt Englisch mit der geringsten Latenz, Chatterbox Multilingual deckt über 20 europäische Sprachen ab, und Qwen3-TTS übernimmt Chinesisch, Japanisch und Koreanisch. Der Router wählt die richtige Engine automatisch, also klickt ein Kurator einmal auf "Generieren" und das Backend wählt im Hintergrund den besten Weg zur Stimme. Kein Jonglieren mit Modellen, keine Einrichtung pro Sprache auf Seiten des Museums.

Die rohe Ausgabe eines Modells ist nicht veröffentlichungsreif, also haben wir die Pipeline um seine typischen Fehler herum gebaut. Lange Passagen werden vor der Synthese zerlegt, damit die Modelle bei längeren Texten nicht halluzinieren oder abdriften, und jedes Stück durchläuft eine Audio-Nachbearbeitung mit Noise Gate und Stille-Trimming. So klingt die Erzählung bewusst gesprochen und nicht maschinell zusammengestückelt. Dann kommt der Teil, den die meisten TTS-Pipelines auslassen: die Prüfung. Jede Aufnahme läuft durch Whisper zurück in Text, die Transkription wird mit dem Originalskript verglichen, und jede Aufnahme mit Abweichungen wird markiert, damit ein Mensch sie anhört, bevor ein Besucher sie hört. Die Generierung ist automatisch, Korrektheit setzen wir nie einfach voraus.

Das alles ist unser eigener Code auf Serverless-GPU: PyTorch-Modelle, gesteuert von den Job-Queues des Backends, und keine fremde TTS-API, die wir weiterverkaufen. Das Ergebnis ist eine Erzählung in Studioqualität in über 20 Sprachen, ohne Sprecher, ohne Aufnahmekabinen und ohne monatelanges Lokalisierungsprojekt. Ein Museum kann eine komplette mehrsprachige Sammlung in der Zeit füllen, die es früher brauchte, um eine einzige Aufnahmesession zu planen. Und jede Minute Audio, die live geht, ist schon mit ihrem Skript abgeglichen.

Museo hat viele Oberflächen, die alle dieselbe Quelle der Wahrheit brauchen: die Besucher-App, die Kunstwerke scannt, die Ambassador-App, die Inhalte einpflegt, das Self-Service-Admin-Panel und die Pipelines für Erkennung, Beschreibungen und Sprachsynthese auf GPU-Servern. Wir haben das Backend genau deshalb auf Bun und Elysia gebaut, weil es im kritischen Pfad von allen sitzt: schnell genug, um eine Erkennung in ~100 ms nicht auszubremsen, und strikt genug, um ein schnell wachsendes Produkt für viele Kunden sauber zu halten. Drizzle ORM modelliert die Daten auf PostgreSQL 18, und die API ist über Eden Treaty und OpenAPI von Ende zu Ende typsicher. Die Flutter-Clients und das Next.js-Panel nutzen also genau die Verträge, die der Server definiert. Ändert sich ein Feld im Backend, wissen die Clients es schon beim Kompilieren und nicht erst aus einem Bugreport aus der Produktion.

Museo ist eine SaaS-Plattform, also gilt die härteste Regel: Kein Museum sieht jemals die Daten eines anderen. Die Mandantentrennung wird in der Datenschicht erzwungen: Jede Abfrage ist auf ihr Museum begrenzt, also bleiben ein Scan, eine Heatmap in der Statistik oder eine Änderung am Inhalt immer innerhalb der Grenzen des richtigen Museums. Dazu übernimmt das Backend die übergreifenden Aufgaben, die der Rest des Systems nicht neu erfinden sollte: Better Auth verwaltet Konten und Sessions über Google, Apple und Einmalcodes (OTP) mit Bearer-Tokens für die Apps, PostGIS treibt die Geo-Abfragen hinter "Museen in der Nähe" in der Besucher-App an, und S3 speichert jedes Foto und jede Aufnahme, die die Plattform erzeugt. Ein Ort zum Anmelden, einer zum Orten, einer zum Speichern.

Die KI ist der Teil, der nicht synchron laufen kann, und das Backend sorgt dafür, dass man davon nichts merkt. Ein Werk erkennen, eine Beschreibung schreiben, sie übersetzen und auf GPU-Workern eine Erzählung in Studioqualität erzeugen: Das sind langsame, schubweise und fehleranfällige Jobs. Darum schickt das Backend sie durch BullMQ-Queues auf Redis, statt eine Anfrage zu blockieren. Es reiht Arbeit ein, verteilt sie an die Pipelines für Erkennung, Beschreibungen und TTS, verfolgt den Status, wiederholt bei Fehlern und gibt die Ergebnisse zurück, sobald sie fertig sind. Genau deshalb kann ein Kurator einmal auf "Generieren" klicken und weggehen. Dieselbe Queue-Schicht treibt die Versionierung der Inhalte an: Ändert sich ein Prompt und Beschreibungen oder Audio veralten, weiß das Backend, was neu generiert werden muss, und plant es ein. Die Apps und die KI-Services reden nie direkt miteinander. Sie reden mit dem Gehirn, und das Gehirn hält sie synchron.