Direkt zum Hauptinhalt
Technologie

Jede Suche lohnend machen: Wie Ibotta die Angebotsentdeckung mit Databricks transformiert hat

von Joel Bowen, Jacob Portes und Benjamin Chin

  • Ibotta hat sein Sucherlebnis mithilfe von Databricks AI Search grundlegend überarbeitet und ist von einem Hackathon-Prototyp zu einem produktiven System übergegangen.
  • Die neue Lösung verbesserte die Freischaltung von Angeboten um fast 15 %, steigerte das Bonus-Engagement und reduzierte Suchen ohne Ergebnisse um über 70 %.
  • Ein benutzerdefiniertes Evaluierungs-Framework und feinabgestimmte Embedding-Modelle ermöglichten schnelle Iterationen, eine höhere Relevanz und ein lohnenderes Erlebnis für Millionen von Nutzern.

Unsere Mission bei Ibotta ist es, jeden Einkauf lohnend zu machen („Make Every Purchase Rewarding“). Ein entscheidender Teil dieser Mission ist es, unseren Nutzern (die wir „Savers“ nennen) dabei zu helfen, relevante Angebote über unsere Direct-to-Consumer (D2C)-App, Browser-Erweiterung und Website zu finden und zu aktivieren. Unsere D2C-Plattform hilft Millionen von Käufern, bei ihren täglichen Einkäufen Cashback zu verdienen – sei es beim Freischalten von Lebensmittelangeboten, beim Sammeln von Bonusprämien oder bei der Planung ihrer nächsten Reise. Über das Ibotta Performance Network (IPN) betreiben wir auch White-Label-Cashback-Programme für einige der größten Namen im Einzelhandel, darunter Walmart und Dollar General. So helfen wir über 2.600 Marken, mehr als 200 Millionen Verbraucher mit digitalen Angeboten über Partner-Ökosysteme hinweg zu erreichen.

Hinter den Kulissen unterstützen unsere Daten- und Machine-Learning-Teams wichtige Funktionen wie Betrugserkennung, Empfehlungssysteme für Angebote und Suchrelevanz, um die Customer Journey für unsere Savers personalisiert und sicher zu gestalten. Da wir weiter wachsen, benötigen wir datengesteuerte, intelligente Systeme, die jede Interaktion an jedem Touchpoint unterstützen.

Sowohl im D2C-Bereich als auch im IPN spielt die Suche eine entscheidende Rolle für das Engagement. Sie muss mit unserem geschäftlichen Wachstum, den sich ständig weiterentwickelnden Angeboten und den veränderten Erwartungen der Savers Schritt halten.

In diesem Beitrag zeigen wir Ihnen, wie wir unsere D2C-Suche erheblich verbessert haben: von einem ehrgeizigen Hackathon-Projekt zu einer robusten Produktionsfunktion, von der heute Millionen von Savers profitieren.

Wir waren überzeugt, dass unsere Suche besser mit unseren Savers Schritt halten könnte

Das Suchverhalten der Nutzer hat sich von einfachen Keywords hin zur Verwendung von natürlicher Sprache, Tippfehlern und umgangssprachlichen Formulierungen entwickelt. Moderne Suchsysteme müssen die Lücke zwischen dem, was Nutzer eingeben, und dem, was sie eigentlich meinen, schließen. Sie müssen Kontext und Beziehungen interpretieren, um relevante Ergebnisse zu liefern, selbst wenn die Suchbegriffe nicht exakt mit dem Inhalt übereinstimmen.

Bei Ibotta hatte unser ursprüngliches, selbst entwickeltes Suchsystem manchmal Mühe, mit den steigenden Erwartungen unserer Savers Schritt zu halten. Wir erkannten darin eine Chance für Verbesserungen.

Die wichtigsten Optimierungspotenziale, die wir sahen, waren:

  • Verbesserung der semantischen Relevanz: Fokus auf das Verständnis der Absicht der Savers anstelle von exakten Keyword-Treffern, um sie mit den passenden Angeboten zusammenzubringen.
  • Besseres Verständnis: Interpretation aller Nuancen und des Kontexts von Nutzeranfragen, um umfassendere und wirklich relevante Ergebnisse zu liefern.
  • Höhere Flexibilität: Schnellere Integration neuer Angebotstypen und Anpassung an veränderte Suchmuster der Savers, damit das Entdecken von Angeboten weiterhin attraktiv bleibt.
  • Steigerung der Auffindbarkeit: Wir wollten robustere Tools, um sicherzustellen, dass bestimmte Angebotstypen oder wichtige Werbeaktionen bei einer Vielzahl relevanter Suchanfragen konsistent sichtbar sind.
  • Schnellere Iteration und Optimierung: Ermöglichung schnellerer, wirkungsvoller Verbesserungen des Sucherlebnisses durch Echtzeitanpassungen und Performance-Tuning.

Wir waren überzeugt, dass das System besser mit sich ändernden Angeboten, dem Suchverhalten und den steigenden Erwartungen der Savers Schritt halten könnte. Wir sahen darin die Möglichkeit, den Mehrwert sowohl für unsere Savers als auch für unsere Markenpartner zu steigern.

Vom Hackathon in die Produktion: Die Suche mit Databricks neu denken

Die Behebung der Einschränkungen unseres Altsystems erforderte gezielte Anstrengungen. Diese Initiative nahm während eines internen Hackathons Fahrt auf. Ein funktionsübergreifendes Team aus den Bereichen Data, Engineering, Marketing Analytics und Machine Learning kam zusammen, um ein modernes, alternatives Suchsystem mit Databricks AI Search zu entwickeln. Einige Teammitglieder hatten auf dem Databricks Data + AI Summit davon erfahren.

In nur drei Tagen entwickelte unser Team einen funktionierenden Proof-of-Concept, der semantisch relevante Suchergebnisse lieferte. Und so sind wir vorgegangen:

  1. Sammeln von Angeboten aus verschiedenen Quellen in unserem Databricks-Katalog
  2. Erstellen eines AI Search-Endpunkts und -Index mit dem Python SDK
  3. Nutzung von Pay-per-Token-Embedding-Endpunkten mit fünf verschiedenen Modellen (BGE Large, GTE Large, GTE Small, einem mehrsprachigen Open-Source-Modell und einem speziellen Modell für Spanisch)
  4. Anbindung des gesamten Systems an unsere Website für eine Live-Demo

Das Hackathon-Projekt belegte den ersten Platz und stieß intern auf große Begeisterung, was uns den nötigen Schwung gab, um den Prototyp in ein Produktionssystem zu überführen. Im Laufe weniger Monate und in enger Zusammenarbeit mit Ingenieuren und Forschern von Databricks haben wir unseren Prototyp in ein robustes, vollwertiges Produktionssuchsystem verwandelt.

Vom Proof-of-Concept in die Produktion

Die Überführung des Hackathon-Proof-of-Concepts in ein produktionsreifes System erforderte sorgfältige Iterationen und Tests. Diese Phase war nicht nur für die technische Integration und das Performance-Tuning entscheidend, sondern auch für die Frage, ob sich die erwarteten Systemverbesserungen in einem positiven Verhalten und Engagement der Savers niederschlagen würden. Da die Suche eine so zentrale Rolle spielt und tief in unsere internen Systeme integriert ist, haben wir uns für folgenden Ansatz entschieden: Wir haben einen wichtigen internen Dienst modifiziert, der unser ursprüngliches Suchsystem aufrief, und diese Aufrufe durch Anfragen an den Databricks AI Search-Endpunkt ersetzt. Gleichzeitig haben wir robuste, nahtlose Fallbacks auf das Altsystem implementiert.

Der Großteil unserer anfänglichen Arbeit konzentrierte sich auf folgende Fragen:

Im ersten Monat führten wir einen Test mit einem kleinen Prozentsatz unserer Savers durch, der jedoch nicht die erhofften Engagement-Ergebnisse lieferte. Das Engagement ging zurück, insbesondere bei unseren aktivsten Savers, was sich in einem Rückgang der Klicks, Unlocks (wenn Savers Interesse an einem Angebot zeigen) und Aktivierungen äußerte.

Dennoch bot die AI Search-Lösung erhebliche Vorteile, darunter:

  • Schnellere Antwortzeiten
  • Ein einfacheres mentales Modell
  • Größere Flexibilität bei der Indexierung von Daten
  • Neue Möglichkeiten zur Anpassung von Schwellenwerten und zur Änderung von Embedding-Texten

Erfreut über die grundlegende technische Leistung des Systems sahen wir in seiner größeren Flexibilität den entscheidenden Vorteil, um die Qualität der Suchergebnisse iterativ zu verbessern und die enttäuschenden Engagement-Ergebnisse zu überwinden.

Aufbau eines Evaluierungs-Frameworks

Nach unseren ersten Testergebnissen war es offensichtlich ineffizient und unpraktisch, sich bei Suchiterationen ausschließlich auf A/B-Tests zu verlassen. Die Anzahl der Variablen, die die Suchqualität beeinflussen, war immens – darunter Embedding-Modelle, Textkombinationen, Einstellungen für die Hybridsuche, Schwellenwerte für Approximate Nearest Neighbors (ANN), Reranking-Optionen und viele mehr.

Um diese Komplexität zu bewältigen und unseren Fortschritt zu beschleunigen, haben wir uns für den Aufbau eines robusten Evaluierungs-Frameworks entschieden. Dieses Framework musste speziell auf unsere geschäftlichen Anforderungen zugeschnitten und in der Lage sein, das tatsächliche Nutzer-Engagement anhand von Offline-Performance-Metriken vorherzusagen.

Unser Framework basierte auf einer synthetischen Evaluierungsumgebung, die über 50 Online- und Offline-Metriken erfasste. Offline überwachten wir Standardmetriken des Information Retrieval wie Mean Reciprocal Rank (MRR) und Precision@k, um die Relevanz zu messen. Entscheidend war die Verknüpfung mit realen Online-Engagement-Signalen wie Offer Unlocks und Klickraten. Eine Schlüsselentscheidung war die Implementierung eines LLM-as-a-Judge-Ansatzes. Dies ermöglichte es uns, Daten zu labeln und Qualitäts-Scores sowohl für Online-Suchanfrage-Ergebnis-Paare als auch für Offline-Ergebnisse zu vergeben. Dieser Ansatz erwies sich als entscheidend für schnelle Iterationen auf der Grundlage zuverlässiger Metriken und für die Erfassung der gelabelten Daten, die für ein zukünftiges Fine-Tuning des Modells erforderlich sind.

Dabei haben wir verschiedene Komponenten der Databricks Data Intelligence Platform genutzt, darunter:

  • Databricks AI Search: Wird verwendet, um hochpräzise, semantisch reichhaltige Suchergebnisse für Evaluierungstests bereitzustellen.
  • MLflow-Patterns und LLM-as-a-judge: Lieferten die Muster zur Evaluierung von Modellausgaben und zur Implementierung unseres Daten-Labeling-Prozesses.
  • Model-Serving-Endpunkte: Effiziente Bereitstellung von Modellen direkt aus unserem Katalog.
  • AI Gateway: Zur Absicherung und Steuerung unseres Zugriffs auf Drittanbieter-Modelle via API.
  • Unity Catalog: Sicherte die Organisation, Verwaltung und Governance aller im Evaluierungs-Framework verwendeten Datensätze.

Dieses robuste Framework erhöhte unsere Iterationsgeschwindigkeit und unser Vertrauen in die Ergebnisse drastisch. Wir haben über 30 verschiedene Iterationen durchgeführt und dabei systematisch wichtige Variablenänderungen in unserer AI Search-Lösung getestet, darunter:

  • Verschiedene Embedding-Modelle (Foundational, Open-Weights und Drittanbieter via API)
  • Verschiedene Textkombinationen zur Einspeisung in die Modelle
  • Verschiedene Abfragemodi (ANN vs. Hybrid)
  • Testen verschiedener Spalten für die hybride Textsuche
  • Anpassen von Schwellenwerten für die Vektorähnlichkeit
  • Experimentieren mit separaten Indizes für verschiedene Angebotstypen

Das Evaluierungs-Framework hat unseren Entwicklungsprozess grundlegend verändert. Es ermöglichte uns, schnell datengestützte Entscheidungen zu treffen und potenzielle Verbesserungen mit hoher Sicherheit zu validieren, bevor wir sie für die Nutzer freigeben.

Die Suche nach dem besten Standardmodell

Nach dem ersten breiten Test, der enttäuschende Engagement-Ergebnisse lieferte, verlagerten wir unseren Fokus auf die Untersuchung der Leistung bestimmter Modelle, die sich in unserer Offline-Evaluierung als vielversprechend erwiesen hatten. Wir wählten zwei Embedding-Modelle von Drittanbietern für Produktionstests aus, auf die wir sicher über das AI Gateway zugriffen. Mit diesen Modellen führten wir kurzfristige, iterative Tests in der Produktion durch (die einige Tage dauerten).

Erfreut über die ersten Ergebnisse führten wir einen längeren, umfassenderen Produktionstest durch, bei dem wir unser führendes Drittanbieter-Modell und dessen optimierte Konfiguration mit dem Altsystem verglichen. Dieser Test lieferte gemischte Ergebnisse. Obwohl wir insgesamt Verbesserungen bei den Engagement-Metriken feststellten und die zuvor beobachteten negativen Auswirkungen erfolgreich beseitigen konnten, waren diese Zuwächse bescheiden – meist im einstelligen Prozentbereich. Diese schrittweisen Vorteile waren nicht überzeugend genug, um einen vollständigen Austausch unserer bestehenden Suchfunktion zu rechtfertigen.

Beunruhigender war jedoch die Erkenntnis aus unserer detaillierten Analyse: Während sich die Leistung bei bestimmten Suchanfragen deutlich verbesserte, schnitten andere im Vergleich zu unserer Altlösung schlechter ab. Diese Inkonsistenz stellte uns vor ein erhebliches architektonisches Dilemma. Wir standen vor der unattraktiven Wahl, entweder ein komplexes Traffic-Splitting-System zu implementieren, um Anfragen basierend auf der vorhergesagten Leistung weiterzuleiten – ein Ansatz, der die Pflege zweier unterschiedlicher Suchfunktionen erfordern und eine neue, komplexe Ebene des regelbasierten Routing-Managements einführen würde –, oder die Einschränkungen zu akzeptieren.

Dies war ein entscheidender Wendepunkt. Obwohl wir genügend Potenzial sahen, um weiterzumachen, benötigten wir deutlichere Verbesserungen, um den vollständigen Ersatz unseres selbst entwickelten Suchsystems zu rechtfertigen. Dies veranlasste uns, mit dem Fine-Tuning zu beginnen.

Fine-Tuning: Anpassung des Modellverhaltens

Obwohl die zuvor untersuchten Embedding-Modelle von Drittanbietern technisch vielversprechend waren und leichte Verbesserungen beim Engagement zeigten, wiesen sie auch kritische Einschränkungen auf, die für eine langfristige Lösung bei Ibotta inakzeptabel waren. Dazu gehörten:

  1. Die Unfähigkeit, Embedding-Modelle von Drittanbietern auf unserem proprietären Angebotskatalog zu trainieren
  2. Schwierigkeiten bei der Weiterentwicklung von Modellen parallel zu geschäftlichen und inhaltlichen Veränderungen
  3. Unsicherheit hinsichtlich der langfristigen Verfügbarkeit von Embedding-Modellen externer Anbieter
  4. Die Notwendigkeit, neue externe Geschäftsbeziehungen aufzubauen und zu verwalten
  5. Netzwerkaufrufe an diese Anbieter waren nicht so performant wie selbst gehostete Modelle

Der klare Weg nach vorn bestand darin, ein Modell per Fine-Tuning speziell auf die Daten von Ibotta und die Bedürfnisse unserer Sparer abzustimmen. Dies wurde dank der Millionen von gelabelten Suchinteraktionen ermöglicht, die wir von echten Nutzern über unseren LLM-as-a-judge-Prozess innerhalb unseres benutzerdefinierten Evaluierungs-Frameworks gesammelt hatten. Diese hochwertigen Produktionsdaten wurden zu unserem Trainings-Gold.

Anschließend begannen wir mit einem methodischen Fine-Tuning-Prozess, bei dem wir unser Offline-Evaluierungs-Framework intensiv nutzten.

Die wichtigsten Elemente waren:

  1. Infrastruktur: Wir haben AI Runtime mit A10s in einer serverlosen Umgebung und Databricks ML Runtime für anspruchsvolles Hyperparameter-Sweeping verwendet.
  2. Modellauswahl: Wir haben uns für ein Modell aus der BGE-Familie anstelle von GTE entschieden, da dieses in unseren Offline-Evaluierungen eine bessere Leistung zeigte und sich als effizienter im Training erwies.
  3. Dataset-Engineering: Wir haben zahlreiche Trainingsdatensätze erstellt, einschließlich der Generierung synthetischer Trainingsdaten, und uns letztendlich für Folgendes entschieden:
    • Ein positives Ergebnis (eine verifizierte gute Übereinstimmung aus echten Suchen)
    • ~10 Negativbeispiele pro Positivbeispiel, kombiniert aus:
      • 3–4 „Hard Negatives“ (von LLM gelabelt, von Menschen verifizierte unpassende Übereinstimmungen)
      • „In-Batch Negatives“ (Stichproben von Ergebnissen aus nicht zusammenhängenden Suchbegriffen)
  4. Hyperparameter-Optimierung: Wir haben systematisch Parameter wie Lernrate, Batch-Größe, Dauer und negative Sampling-Strategien untersucht (Sweeping), um optimale Konfigurationen zu finden.

Nach zahlreichen Iterationen und Evaluierungen innerhalb des Frameworks übertraf unser leistungsstärkstes, per Fine-Tuning optimiertes Modell unsere beste Drittanbieter-Baseline in der synthetischen Evaluierung um 20 %. Diese überzeugenden Offline-Ergebnisse gaben uns das nötige Vertrauen, um unseren nächsten Produktionstest zu beschleunigen.

Suche, die Ergebnisse liefert – und Umsatz generiert

Die technische Gründlichkeit und der iterative Prozess haben sich ausgezahlt. Wir haben eine Suchlösung entwickelt, die speziell auf den einzigartigen Angebotskatalog und die Verhaltensmuster der Nutzer von Ibotta optimiert ist. Sie lieferte Ergebnisse, die unsere Erwartungen übertrafen, und bot die nötige Flexibilität, um sich parallel zu unserem Geschäft weiterzuentwickeln. Aufgrund dieser starken Ergebnisse haben wir die Migration auf Databricks AI Search als Grundlage für unser Produktionssuchsystem beschleunigt.

In unserem finalen Produktionstest mit unserem eigenen, per Fine-Tuning optimierten Embedding-Modell konnten wir die folgenden Verbesserungen feststellen:

  • 14,8 % mehr Angebotsfreischaltungen in der Suche.
    Dies misst, wie viele Nutzer Angebote aus den Suchergebnissen auswählen, was auf eine verbesserte Ergebnisqualität und Relevanz hindeutet. Mehr Freischaltungen sind ein Frühindikator für nachgelagerte Einlösungen und Umsätze.
  • 6 % Steigerung bei den aktiven Nutzern.
    Dies zeigt, dass ein größerer Anteil der Nutzer einen Mehrwert findet und sinnvolle Aktionen innerhalb der Suchfunktion durchführt, was zu einer besseren Conversion, Retention und einem höheren Lifetime Value beiträgt.
  • 15 % Steigerung des Engagements bei Boni.
    Dies spiegelt die verbesserte Darstellung von hochwertigen, markengesponserten Inhalten wider, was sich direkt in einer besseren Performance und einem höheren ROI für unsere Marken- und Einzelhandelspartner niederschlägt.
  • 72,6 % weniger Suchen ohne Ergebnisse.
    Diese erhebliche Reduzierung bedeutet weniger frustrierende Erlebnisse und eine deutliche Verbesserung der semantischen Suchabdeckung.
  • 60,9 % weniger Nutzer, bei denen Suchen keine Ergebnisse liefern.
    Dies verdeutlicht die enorme Tragweite: Ein Großteil unserer Nutzerbasis findet nun konsistent Ergebnisse, was das Gesamterlebnis auf breiter Front verbessert.

Abgesehen von den Vorteilen für die Nutzer überzeugte das neue System auch durch seine Performance. Wir konnten eine um 60 % geringere Latenz unseres Suchsystems verzeichnen, was auf die Abfrageleistung von AI Search und den geringeren Overhead des per Fine-Tuning optimierten Modells zurückzuführen ist.

Durch die Nutzung der Flexibilität dieser neuen Basis haben wir auch leistungsstarke Erweiterungen wie Query Transformation (Anreicherung vager Suchanfragen) und Multi-Search (Auffächern generischer Begriffe) entwickelt. Die Kombination aus einem hochrelevanten Kernmodell, verbesserter Systemleistung und intelligenten Sucherweiterungen hat zu einer Suchfunktion geführt, die smarter, schneller und letztendlich lohnender ist.

Query Transformation

Eine Herausforderung bei Embedding-Modellen ist ihr begrenztes Verständnis von Nischen-Keywords, wie beispielsweise aufstrebenden Marken. Um dieses Problem zu lösen, haben wir einen Query-Transformation-Layer entwickelt, der Suchbegriffe während der Ausführung (in-flight) basierend auf vordefinierten Regeln dynamisch anreichert.

Wenn ein Nutzer beispielsweise nach einer neuen Joghurtmarke sucht, die das Embedding-Modell möglicherweise nicht erkennt, können wir die Suchanfrage so transformieren, dass neben dem Markennamen auch „griechischer Joghurt“ hinzugefügt wird, bevor sie an AI Search gesendet wird. Dies liefert dem Embedding-Modell den notwendigen Produktkontext, während der Originaltext für die Hybridsuche erhalten bleibt.

Diese Funktion arbeitet auch Hand in Hand mit unserem Fine-Tuning-Prozess. Erfolgreiche Transformationen können zur Generierung von Trainingsdaten verwendet werden. Wenn beispielsweise der ursprüngliche Markenname als Suchanfrage und die relevanten Joghurtprodukte als positive Ergebnisse in einem zukünftigen Trainingslauf einbezogen werden, hilft dies dem Modell, diese spezifischen Assoziationen zu erlernen.

Multi-Search

Bei breit gefächerten, generischen Suchanfragen wie „Baby“ liefert AI Search anfangs möglicherweise nur eine begrenzte Anzahl von Kandidaten, die durch Targeting und Budgetverwaltung eventuell noch weiter eingeschränkt werden. Um dem entgegenzuwirken und die Vielfalt der Ergebnisse zu erhöhen, haben wir eine Multi-Search-Funktion entwickelt, die einen einzelnen Suchbegriff in mehrere verwandte Suchanfragen aufteilt.

Anstatt nur nach „Baby“ zu suchen, führt unser System automatisch parallele Suchen nach Begriffen wie „Babynahrung“, „Babykleidung“, „Babymedizin“, „Babywindeln“ usw. aus. Aufgrund der geringen Latenz von AI Search können wir mehrere Suchen parallel ausführen, ohne die Antwortzeit für den Nutzer insgesamt zu verlängern. Dies liefert eine weitaus breitere und vielfältigere Auswahl an relevanten Ergebnissen für breit gefächerte Kategoriesuchen.

Erkenntnisse

Nach dem erfolgreichen finalen Produktionstest und dem vollständigen Rollout von Databricks AI Search für unsere Nutzerbasis – was zu positivem Engagement, erhöhter Flexibilität und leistungsstarken Suchwerkzeugen wie Query-Transformation und Multi-Search führte – hat dieses Projekt mehrere wertvolle Erkenntnisse geliefert:

  1. Mit einem Proof of Concept starten: Der anfängliche Hackathon-Ansatz ermöglichte es uns, das Kernkonzept mit minimalem Vorabaufwand schnell zu validieren.
  2. Messen, was wichtig ist: Unser maßgeschneidertes Evaluierungs-Framework mit 50 Metriken war entscheidend. Es gab uns die Gewissheit, dass sich offline beobachtete Verbesserungen in geschäftlichen Erfolg ummünzen lassen, sodass wir wiederholte Live-Tests vermeiden konnten, bis die Lösungen wirklich vielversprechend waren.
  3. Nicht direkt mit dem Fine-Tuning beginnen: Wir haben gelernt, wie wichtig es ist, Standardmodelle gründlich zu evaluieren und diese Optionen auszuschöpfen, bevor man in den größeren Aufwand investiert, der für ein Fine-Tuning erforderlich ist.
  4. Daten frühzeitig sammeln: Da wir bereits ab unserem zweiten Experiment mit dem Labeln von Daten begonnen haben, stand ein umfassender, proprietärer Datensatz bereit, als das Fine-Tuning notwendig wurde.
  5. Zusammenarbeit beschleunigt den Fortschritt: Die enge Partnerschaft mit Databricks-Ingenieuren und -Forschern sowie der Austausch von Erkenntnissen über AI Search, Embedding-Modelle, LLM-as-a-Judge-Muster und Fine-Tuning-Ansätze haben unseren Fortschritt erheblich beschleunigt.
  6. Kumulative Wirkung erkennen: Jede einzelne Optimierung, selbst wenn sie noch so gering erschien, hat erheblich zur Gesamttransformation unseres Sucherlebnisses beigetragen.

Wie es weitergeht

Da unser feinabgestimmtes Embedding-Modell nun auf allen Direct-to-Consumer-Kanälen (D2C) live ist, planen wir als Nächstes, die Skalierung dieser Lösung auf das Ibotta Performance Network (IPN) zu prüfen. Dies würde Millionen weiteren Käufern in unserem Publisher-Netzwerk eine verbesserte Angebotssuche ermöglichen. Da wir weiterhin gelabelte Daten sammeln und unsere Modelle über Databricks verfeinern, sehen wir uns gut aufgestellt, um das Sucherlebnis parallel zu den Bedürfnissen unserer Partner und den Erwartungen ihrer Kunden weiterzuentwickeln.

Dieser Weg von einem Hackathon-Projekt zu einem Produktivsystem hat bewiesen, dass die schnelle Neugestaltung eines Kernprodukterlebnisses mit den richtigen Tools und der passenden Unterstützung machbar ist. Databricks hat entscheidend dazu beigetragen, dass wir schnell agieren, effektiv Fine-Tuning betreiben und letztendlich jede Suche für unsere Savers lohnender gestalten konnten.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag

Erhalten Sie die neuesten Beiträge in Ihrem Posteingang

Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.