Die meisten Suchfelder sollen eine Frage beantworten: Was passt zu den von mir eingegebenen Wörtern? Das ist die richtige Frage für einen Bibliothekskatalog. Es ist die falsche Frage für eine Ernährungs-App.
Wenn ein Nutzer die Rezeptseite in Appetec öffnet, sind die eingegebenen Wörter der am wenigsten interessante Teil der Anfrage. Was wirklich zählt, ist unsichtbar: die heute verbleibenden Kalorien, was sie Woche für Woche ohne Nachzudenken gekocht haben, ob sie vegan sind und ob sie ihr Budget bereits zum Abendessen überschritten haben. Eine Suchmaschine, die all das ignoriert, wird gerne passende Rezepte zurückgeben – und ebenso gerne den Grund sabotieren, warum der Nutzer die App geöffnet hat. Dies ist die Architektur hinter einem Muster, das darauf ausgelegt ist, diese Lücke zu schließen: Relevanz, die für diese Person, jetzt, genau richtig ist.
Warum TextĂĽbereinstimmung allein nicht ausreicht
Das Muster greift immer dann, wenn dieselbe Abfrage für verschiedene Nutzer unterschiedliche Ergebnisse liefern soll – wenn „am besten“ vom Kontext abhängt, den der Nutzer nie eingegeben hat, und wenn Ihr eigener Katalog kleiner ist als der, den Ihre Nutzer erwarten. Die personalisierte Rezeptsuche behandelt Relevanz als eine Mischung aus drei Signalen anstatt nur einem:
| Signal | Was es erfasst |
|---|---|
| Text | Was der Nutzer eingegeben hat – oder, im Essens-Scan-Modus, was auf seinem Teller erkannt wurde |
| Zielpassung | Wie gut ein Rezept zu den Kalorien passt, die dem Nutzer fĂĽr diese Mahlzeit heute noch zur VerfĂĽgung stehen |
| Gewohnheit | Wie oft dieser spezifische Nutzer dieses Rezept tatsächlich isst |
Eine naive Engine sieht nur die erste Zeile dieser Tabelle. Dieses Muster fusioniert alle drei zu einer einzigen Rangliste und füllt dann aus einer externen Quelle auf, wann immer der lokale Katalog dünn wird – und erweitert diesen Katalog jedes Mal unbemerkt. Das Ergebnis fühlt sich weniger wie das Abfragen einer Datenbank an und mehr wie ein Freund, der Ihre Küche und Ihre Ernährung bereits kennt.
Wie die Pipeline aufgebaut ist
Das System läuft als Retrieval-Pipeline mit einer Personalisierungsschicht davor und einem sich selbst reparierenden Katalog dahinter.
Zwei Suchmaschinen, ein Vertrag. Elasticsearch ist primär: unscharfe Fehlertoleranz, englisches Stemming („grill“ findet „grilled“), gewichtete Relevanzbewertung. Sollte sie jemals nicht verfügbar sein, fällt dieselbe Abfrage auf eine MongoDB-Suche zurück, die dieselben Filter und Personalisierungsregeln beachtet. Die Suche verschlechtert sich bei Ausfall; sie verschwindet nie.
Die Schicht, die Nutzer spüren, aber nie sehen. Bevor die Ergebnisse zurückgegeben werden, gestalten drei Dinge die Liste neu. Das Kalorienbudget wird aus dem Tagesziel minus dem Protokollierten berechnet, wodurch Rezepte gefördert werden, die in das verbleibende Fenster passen – und wenn der Nutzer sein Ziel überschritten hat, sortiert die Liste unbemerkt nach den kalorienärmsten zuerst, um zur Erholung statt zum Genuss anzuregen. Die Essenshistorie destilliert die Essensprotokolle der letzten 60 Tage zu einer „was Sie tatsächlich essen“-Karte, wodurch Favoriten auf Seite eins nur einen Fingertipp entfernt sind. Ernährungspräferenz – veg, vegan, non-veg, plus zwei Dutzend feinere Tags wie keto, gluten-free und high-protein – filtert und reiht alles darunter neu ein.
Ein Katalog, der sich selbst erweitert. Wenn lokale Ergebnisse knapp werden, greift die Pipeline auf eine externe Quelle, FatSecret, zu und fügt diese Ergebnisse nahtlos in denselben Infinite-Scroll-Feed ein. Anschließend schreibt es diese externen Rezepte zurück in den lokalen Katalog und verwendet ein LLM, um jedes als veg, non-veg oder vegan zu klassifizieren, damit es beim nächsten Mal korrekt personalisierbar ist – derselbe Instinkt hinter einer hybriden Retrieval-Architektur, die wir an anderer Stelle angewendet haben, wo lokale und externe Ergebnisse sich wie ein System anfühlen müssen.
Drei Caches, drei Aufgaben. Kombinierte Ergebnismengen, die nutzerspezifische Gewohnheitskarte und externe API-Antworten haben jeweils eine eigene, unabhängige Lebensdauer, sodass eine personalisierte Abfrage aus mehreren Quellen immer noch ungefähr mit der Geschwindigkeit einer einzelnen, einfachen Abfrage zurückkehrt.
Die nennenswerten Kompromisse
Nichts davon gab es umsonst, und die Ehrlichkeit ĂĽber die Kosten ist ein Teil dessen, was das Muster vertrauenswĂĽrdig statt nur clever macht.
Die Relevanz wurde bewusst un-neutral gestaltet. Ein reines Text-Relevanz-Ranking ist „fair“ auf eine Weise, die hier aktiv nutzlos ist. Ergebnisse sind absichtlich auf Zielpassung und Gewohnheit ausgerichtet, denn ein textlich etwas weniger perfektes Rezept, das zum Budget und Geschmack einer Person passt, ist die bessere Antwort. „Warum landete das auf Platz eins?“ wird zu einer Produktentscheidung, nicht zu einer Suchmaschinen-Standardeinstellung – deshalb sind diese Gewichte im Anwendungscode und nicht in einer nicht verwalteten Konfigurationsdatei hinterlegt.
Der Besitz des gesamten Katalogs war nicht das Ziel – der Besitz des richtigen Teils davon schon. Die betrachteten Extreme waren ein vollständig kuratierter Katalog (hohe Qualität, geringe Breite) oder ein vollständiger Proxy zu einer externen API (unbegrenzte Breite, null Kontrolle, null Personalisierung). Das System teilt den Unterschied: Es beginnt mit eigenen und von Nutzern erstellten Rezepten, füllt bei Bedarf extern auf und integriert das, was aufgefüllt wird – im Laufe der Zeit tendiert es dazu, genau das zu besitzen, wonach Nutzer tatsächlich suchen.
Resilienz wurde der Spitzenleistung vorgezogen. Zwei vollwertige Suchmaschinen sind im Betrieb teurer als eine – dasselbe Resilienz-erste Denken, das den meisten unserer Backend-Entscheidungen zugrunde liegt. Diese Kosten wurden bewusst in Kauf genommen: Die Rezeptsuche ist eine zentrale, täglich genutzte Funktion, bei der eine beeinträchtigte Suche ein geringfügiges Ärgernis ist, aber eine fehlende Suche eine kaputte App bedeutet.
Personalisierung kostet Vorhersehbarkeit. Ergebnisse unterscheiden sich tatsächlich nach Tageszeit, verbrauchten Kalorien und Historie – selbst für denselben Nutzer beim Frühstück im Vergleich zum Abendessen. Das ist beabsichtigt, erhöht aber die Anforderungen an Tests und Support: „Es funktioniert auf meinem Handy“ bedeutet nicht mehr viel, wenn die Korrektheit pro Nutzer, pro Moment definiert ist.
Wann dieses Muster passt – und wann nicht
Es lohnt sich klarzustellen, wo dieses Muster nicht angewendet werden sollte. Es rechtfertigt seine Komplexität, wenn Ergebnisse pro Nutzer basierend auf Kontext, den sie nie eingegeben haben, tatsächlich unterschiedlich sein sollten; wenn der eigene Katalog kleiner ist als das, was Nutzer erwarten, aber extern angereichert werden kann; wenn die Funktion häufig genug genutzt wird, dass ein sanfter Abbau wichtiger ist als minimale Infrastruktur; und wenn „Relevanz“ legitimerweise Signale jenseits von Text umfasst.
Es ist das falsche Werkzeug, wenn die Ergebnisse für jeden Nutzer identisch sind – eine öffentliche Dokumentensuche, eine SKU-Abfrage – wo Personalisierung Kosten ohne Nutzen verursacht. Es ist unnötig, wenn der Katalog klein und stabil genug ist, dass eine einzelne Engine mit einfacher Filterung ausreicht, und es arbeitet gegen Sie, überall dort, wo eine strikte, identische, vollständig erklärbare Rangfolge eine harte Anforderung ist.
Die eigentliche Aufgabe
Die Retrieval-Qualität wird hier als Personalisierungsproblem behandelt, nicht nur als Matching-Problem. Eine Rezeptsuche, die textlich perfekt ist, aber ignoriert, dass der Nutzer vegan ist, bereits sein Budget überschritten hat und den ganzen Monat die gleichen fünf Abendessen gekocht hat, hat technisch funktioniert und praktisch versagt. Die Aufgabe war nie, Rezepte zu finden, die zur Abfrage passen – es geht darum, das Rezept anzuzeigen, das diese Person als Nächstes kochen sollte. Jede Schicht dieser Architektur, von den dualen Suchmaschinen bis zur unbemerkten Neusortierung, wenn jemand sein Budget überschritten hat, existiert, um diese Lücke zu schließen.
Wenn Sie eine ähnliche Build-vs-Blend-Entscheidung für die Suche oder das Retrieval in Ihrem eigenen Produkt abwägen, sprechen wir gerne darüber.
Weitere Blogs
1. Skalierung einer digitalen Gesundheitsplattform mit Microservices
2. Synchronisierung von Apple Health & Health Connect
3. Optimierung des Senderlogos für verschiedene Videoauflösungen
