Ein Sprachmodell im Produkt: was ich bei FoodX gelernt habe

FoodX löst ein kleines, hartnäckiges Problem: Vier Leute am Tisch, vier Vorstellungen davon, was heute gut wäre. Einer möchte vegetarisch, einer mehr Protein, das Kind hasst Pilze. Statt ein Gericht zu suchen, das zufällig allen passt – davon bleiben schnell nur Nudeln mit Butter übrig –, sucht FoodX ein Gericht, das sich mit wenig Aufwand aufteilen lässt. Ein Grundgericht, vier passende Teller.

Irgendwo in diesem Ablauf steckt ein Sprachmodell. Man kann FoodX in ganzen Sätzen sagen, worauf man Lust hat: „Heute was Mexikanisches, maximal 25 Minuten, die Kinder wollen keine Bohnen." Das Modell versteht das und legt es über das, was FoodX ohnehin über die Familie weiß. So weit die Vorstellung. Was ich beim Bauen gelernt habe, hat weniger mit dem Modell zu tun als mit allem drumherum.

Das Modell ist ein Bauteil, nicht das Produkt

Der häufigste Fehler, den ich bei KI-Projekten sehe – und den ich selbst zuerst gemacht habe –, ist, das Sprachmodell für das Produkt zu halten. Man baut ein Eingabefeld, schickt den Text an ein Modell, zeigt die Antwort an. Fertig ist der „KI-Assistent".

Bei FoodX macht das Modell genau einen Schritt von vielen: Es übersetzt einen Wunsch in Bedingungen. Alles andere ist normaler Code. Welche Gerichte es überhaupt gibt, steht in einem gepflegten Katalog. Ob ein Gericht zu einer Unverträglichkeit passt, rechnet ein deterministischer Abgleich aus – nicht das Modell, weil ich beim Thema Allergene keine Antwort will, die „meistens stimmt". Welches Gericht diese Woche schon einmal auf dem Tisch stand, weiß die Datenbank. Der Wochenplan, die Einkaufsliste mit zusammengezählten Mengen, die Portionsrechnung: alles Code.

Warum das Modell keine Rezepte erfinden darf

Die naheliegende Version wäre gewesen: Der Nutzer beschreibt, was er will, das Modell schreibt ein Rezept. Das funktioniert in der Demo beeindruckend und im Betrieb gar nicht. Drei Gründe.

Qualität. Ein erfundenes Rezept ist jedes Mal anders, manchmal gut, manchmal enthält es einen Schritt, der nicht funktioniert. Ein Katalog, den ich kuratiere, hat eine Qualitätsuntergrenze. Das Modell wählt daraus aus und passt an – es tauscht eine Zutat, es teilt einen Teller ab –, aber es baut nicht von null.

Verlässlichkeit. „Das Kind hasst Pilze" muss zu hundert Prozent greifen, nicht zu 97. Bei einem Katalog kann ich das garantieren, weil die Zutaten strukturiert vorliegen. Bei Freitext aus einem Modell könnte ich nur hoffen.

Vorhersagbarkeit. Jeder Aufruf eines Sprachmodells kostet etwas, und ein Aufruf, der ein ganzes Rezept schreibt, kostet ein Vielfaches von einem, der einen Satz in fünf Bedingungen übersetzt. Ein Katalog macht den teuren Teil selten und den billigen Teil zur Regel. Das entscheidet am Ende darüber, ob ein Produkt mit einem kostenlosen Einstieg überhaupt tragfähig sein kann.

Jede KI-Funktion braucht eine Obergrenze

Das ist die Lektion, die ich am wenigsten erwartet habe. Ein Sprachmodell wird nach Nutzung abgerechnet. Ein Abo ist ein fester Betrag. Dazwischen liegt ein Risiko, das man tragen muss – und das ohne Obergrenze nach oben offen ist.

Nicht, weil jemand böswillig wäre. Sondern weil Neugier billig ist, wenn sie nichts kostet. Jemand probiert aus, was passiert, wenn er zwanzig Wünsche hintereinander eingibt. Jemand anderes lässt eine Seite mit automatischer Aktualisierung offen. Ein Dritter testet, ob der Assistent auch Gedichte schreibt. Jeder einzelne Fall ist harmlos. In Summe zahlt man die Neugier seiner Nutzer.

FoodX hat deshalb für jede Funktion, die ein Modell aufruft, ein Budget – pro Konto, pro Zeitraum, mit klaren Regeln, was passiert, wenn es erreicht ist. Das war keine Nachrüstung, das gehört in den Entwurf. Wer eine KI-Funktion ohne Obergrenze ausrollt, hat keine Kostenstelle, sondern einen offenen Wasserhahn.

Wenn das Modell nicht antwortet, muss das Produkt trotzdem funktionieren

Modelle sind Dienste anderer Leute. Sie haben Wartungsfenster, Ausfälle, Ratenbegrenzungen, und ab und zu ändert sich das Verhalten über Nacht, ohne dass es jemand ankündigt. Wenn das Abendessen davon abhängt, dass ein Server in einem anderen Land gerade Lust hat, ist das Produkt kaputt.

Der Ausweg ist, dass der Weg über das Modell der bessere Weg ist, nicht der einzige. Wenn der Freitext-Wunsch nicht verarbeitet werden kann – Budget erreicht, Modell nicht erreichbar, Antwort unbrauchbar –, bekommt die Familie trotzdem Vorschläge, aus dem Katalog, anhand dessen, was FoodX ohnehin über sie weiß. Weniger genau, aber da. Der Nutzer merkt einen Unterschied in der Qualität, nicht in der Verfügbarkeit.

Nicht jede Frage braucht das große Modell

„Ein Sprachmodell" gibt es nicht. Es gibt Dutzende, mit sehr unterschiedlichen Fähigkeiten und sehr unterschiedlichen Preisen. Die Versuchung ist, überall das beste zu nehmen, weil es am wenigsten Ärger macht.

In FoodX gibt es Aufgaben, die ein kleines Modell zuverlässig erledigt – erkennen, ob ein Wunsch überhaupt ums Essen geht, oder eine Zutat einer Kategorie zuordnen. Und es gibt Aufgaben, bei denen das große Modell den Unterschied macht: einen verschachtelten Satz mit drei Einschränkungen und einer Ausnahme richtig zerlegen. FoodX wählt je nach Aufgabe. Das ist mehr Arbeit im Entwurf und deutlich weniger im Betrieb.

Leute reden mit dem Assistenten über alles Mögliche

Sobald es ein Textfeld gibt, das an ein Sprachmodell geht, versuchen Menschen, ob es auch etwas anderes kann. Das ist keine Bosheit, das ist menschlich. Manche fragen nach dem Wetter. Manche versuchen, dem Assistenten Anweisungen zu geben, die mit Essen nichts zu tun haben. Manche versuchen gezielt herauszubekommen, wie er innen aufgebaut ist.

FoodX hat dafür eigene Tests: dass der Assistent beim Thema bleibt, dass er seine Anweisungen nicht preisgibt, dass eine Eingabe ihn nicht dazu bringt, seine Regeln zu ignorieren. Das gehört zum Produkt wie die Passwortprüfung. Wer das nicht einbaut, betreibt einen kostenlosen Zugang zu einem Sprachmodell mit dem eigenen Firmennamen darüber.

Was ich heute anders machen würde

Das Budget pro Konto hätte vom ersten Tag an dazugehört, nicht erst, als klar war, dass es nötig ist. Alles, was ich oben über Obergrenzen geschrieben habe, habe ich gelernt, indem ich es zunächst nicht hatte.

Für wen das relevant ist

Nichts davon ist FoodX-spezifisch. Die Fragen sind dieselben, ob ein Sprachmodell Rezepte auswählt, Kundenanfragen vorsortiert, Angebote entwirft oder Rechnungen liest: Was darf das Modell entscheiden, was nur vorschlagen? Was passiert, wenn es ausfällt? Wo ist die Obergrenze? Und was macht ein Nutzer damit, der es nicht so meint wie ich?

Wer eine dieser Fragen für den eigenen Betrieb noch nicht beantwortet hat, sollte sie beantworten, bevor das erste Textfeld online geht. Das ist der Teil meiner Arbeit, der nichts mit Programmieren zu tun hat – und der am meisten spart.