Passa al contenuto principale
Tecnologia

Rendere ogni ricerca gratificante: come Ibotta ha trasformato la scoperta delle offerte con Databricks

di Joel Bowen, Jacob Portes e Benjamin Chin

  • Ibotta ha rivoluzionato la sua esperienza di ricerca utilizzando Databricks AI Search, passando da un prototipo da hackathon a un sistema in produzione.
  • La nuova soluzione ha aumentato gli sblocchi delle offerte di quasi il 15%, ha incrementato il coinvolgimento nei bonus e ha ridotto le ricerche senza risultati di oltre il 70%.
  • Un framework di valutazione personalizzato e modelli di embedding ottimizzati hanno consentito un'iterazione rapida, una maggiore rilevanza e un'esperienza più gratificante per milioni di utenti.

In Ibotta, la nostra missione è rendere vantaggioso ogni acquisto (Make Every Purchase Rewarding). Aiutare i nostri utenti (che chiamiamo Saver) a trovare e attivare offerte pertinenti tramite la nostra app direct-to-consumer (D2C), l'estensione del browser e il sito web è una parte fondamentale di questa missione. La nostra piattaforma D2C aiuta milioni di acquirenti a ricevere un cashback sui loro acquisti quotidiani, che si tratti di sbloccare offerte sulla spesa, accumulare premi bonus o pianificare il loro prossimo viaggio. Attraverso l'Ibotta Performance Network (IPN), gestiamo anche programmi di cashback white-label per alcuni dei più grandi nomi della vendita al dettaglio, tra cui Walmart e Dollar General, aiutando oltre 2.600 brand a raggiungere più di 200 milioni di consumatori con offerte digitali in tutti gli ecosistemi dei partner.

Dietro le quinte, i nostri team di Data e Machine Learning gestiscono esperienze fondamentali come il rilevamento delle frodi, i motori di raccomandazione delle offerte e la pertinenza della ricerca per rendere il percorso dei Saver personalizzato e sicuro. Man mano che continuiamo a crescere, abbiamo bisogno di sistemi intelligenti e basati sui dati che supportino ogni interazione in ogni touchpoint.

In D2C e nell'IPN, la ricerca svolge un ruolo cruciale nel coinvolgimento e deve tenere il passo con la scala del nostro business, l'evoluzione dei contenuti delle offerte e le mutevoli aspettative dei Saver.

In questo post vedremo come abbiamo migliorato significativamente la nostra esperienza di ricerca D2C: da un ambizioso progetto di hackathon a una solida funzionalità di produzione di cui ora beneficiano milioni di Saver.

Eravamo convinti che la nostra ricerca potesse tenere meglio il passo con i nostri Saver

Il comportamento di ricerca degli utenti si è evoluto dal passaggio da semplici parole chiave all'integrazione del linguaggio naturale, di errori di ortografia e di frasi colloquiali. I moderni sistemi di ricerca devono colmare il divario tra ciò che gli utenti digitano e ciò che effettivamente intendono, interpretando il contesto e le relazioni per fornire risultati pertinenti anche quando i termini della query non corrispondono esattamente al contenuto.

In Ibotta, il nostro sistema di ricerca interno originale a volte faticava a tenere il passo con le crescenti aspettative dei nostri Saver, e abbiamo intravisto un'opportunità per perfezionarlo.

Le principali aree di opportunità che abbiamo individuato includevano:

  • Miglioramento della pertinenza semantica: concentrarsi sulla comprensione dell'intento dei Saver rispetto alla corrispondenza esatta delle parole chiave per indirizzarli verso le offerte giuste.
  • Comprensione avanzata: interpretare ogni sfumatura e il contesto delle query degli utenti per fornire risultati più completi e realmente pertinenti.
  • Maggiore flessibilità: integrare più rapidamente nuovi tipi di offerte e adattarsi ai mutevoli pattern di ricerca dei Saver per mantenere gratificante l'esperienza di scoperta.
  • Aumento della rilevabilità: volevamo strumenti più robusti per garantire che tipi specifici di offerte o promozioni chiave fossero costantemente visibili in un'ampia gamma di query di ricerca pertinenti.
  • Accelerazione dell'iterazione e dell'ottimizzazione: consentire miglioramenti più rapidi e d'impatto all'esperienza di ricerca attraverso regolazioni in tempo reale e ottimizzazione delle prestazioni.

Eravamo convinti che il sistema potesse tenere meglio il passo con la variazione dei contenuti delle offerte, i comportamenti di ricerca e le crescenti aspettative dei Saver. Abbiamo visto l'opportunità di aumentare il valore sia per i nostri Saver che per i nostri brand partner.

Dall'hackathon alla produzione: reinventare la ricerca con Databricks

Affrontare i limiti del nostro sistema di ricerca legacy ha richiesto un impegno mirato. Questa iniziativa ha preso un forte slancio durante un hackathon interno in cui un team interfunzionale, composto da membri di Data, Engineering, Marketing Analytics e Machine Learning, si è riunito con l'idea di creare un sistema di ricerca alternativo e moderno utilizzando Databricks AI Search, di cui alcuni membri avevano sentito parlare al Databricks Data + AI Summit.

In soli tre giorni, il nostro team ha sviluppato un proof-of-concept funzionante in grado di fornire risultati di ricerca semanticamente pertinenti. Ecco come abbiamo fatto:

  1. Abbiamo raccolto i contenuti delle offerte da più sorgenti nel nostro catalogo Databricks
  2. Abbiamo creato un endpoint e un indice AI Search con l'SDK Python
  3. Abbiamo utilizzato endpoint di embedding pay-per-token con cinque modelli diversi (BGE large, GTE large, GTE small, un modello open-source multilingue e un modello specifico per la lingua spagnola)
  4. Abbiamo collegato tutto al nostro sito web per una demo live

Il progetto dell'hackathon ha ottenuto il primo posto, generando un forte consenso interno e lo slancio necessario per trasformare il prototipo in un sistema di produzione. Nel giro di pochi mesi, e grazie a una stretta collaborazione con gli ingegneri e i ricercatori di Databricks, abbiamo trasformato il nostro prototipo in un solido sistema di ricerca di produzione a tutti gli effetti.

Dal proof of concept alla produzione

Il passaggio dal proof-of-concept dell'hackathon a un sistema pronto per la produzione ha richiesto un'attenta iterazione e test rigorosi. Questa fase è stata fondamentale non solo per l'integrazione tecnica e l'ottimizzazione delle prestazioni, ma anche per valutare se i miglioramenti previsti per il sistema si sarebbero tradotti in cambiamenti positivi nel comportamento e nel coinvolgimento dei Saver. Dato il ruolo essenziale della ricerca e la sua profonda integrazione nei sistemi interni, abbiamo optato per il seguente approccio: abbiamo modificato un servizio interno chiave che richiamava il nostro sistema di ricerca originale, sostituendo tali chiamate con richieste dirette all'endpoint Databricks AI Search, integrando al contempo meccanismi di fallback robusti e fluidi verso il sistema legacy.

La maggior parte del nostro lavoro iniziale si è concentrata sulla comprensione di:

  • Come sfruttare al meglio il prodotto AI Search per il nostro caso d'uso
  • Come selezionare il modello più performante tramite valutazione empirica
  • Come testare i limiti dell'utilizzo pay-per-token
  • Meccanismi di autenticazione
  • Come utilizzare l'endpoint del data plane per evitare il rate limiting
  • Come passare a un endpoint di model serving con throughput assegnato per gestire i nostri requisiti di throughput

Nel primo mese abbiamo eseguito un test con una piccola percentuale dei nostri Saver che non ha ottenuto i risultati di coinvolgimento sperati. Il coinvolgimento è diminuito, in particolare tra i nostri Saver più attivi, come indicato da un calo di clic, sblocchi (quando i Saver mostrano interesse per un'offerta) e attivazioni.

Tuttavia, la soluzione AI Search offriva vantaggi significativi, tra cui:

  • Tempi di risposta più rapidi
  • Un modello mentale più semplice
  • Maggiore flessibilità nel modo in cui indicizzavamo i dati
  • Nuove capacità di regolare le soglie e modificare il testo dell'embedding

Soddisfatti delle prestazioni tecniche di base del sistema, abbiamo visto nella sua maggiore flessibilità il vantaggio chiave necessario per migliorare in modo iterativo la qualità dei risultati di ricerca e superare i deludenti risultati di coinvolgimento.

Creazione di un framework di valutazione

In seguito ai risultati dei nostri test iniziali, affidarsi esclusivamente ai test A/B per le iterazioni di ricerca era chiaramente inefficiente e poco pratico. Il numero di variabili che influenzavano la qualità della ricerca era immenso, inclusi i modelli di embedding, le combinazioni di testo, le impostazioni di ricerca ibrida, le soglie di Approximate Nearest Neighbors (ANN), le opzioni di reranking e molto altro ancora.

Per orientarci in questa complessità e accelerare i nostri progressi, abbiamo deciso di creare un solido framework di valutazione. Questo framework doveva essere personalizzato in modo unico in base alle nostre specifiche esigenze aziendali e in grado di prevedere il coinvolgimento degli utenti nel mondo reale a partire da metriche di prestazioni offline.

Il nostro framework è stato progettato attorno a un ambiente di valutazione sintetico che monitorava oltre 50 metriche online e offline. Offline, abbiamo monitorato le metriche standard di recupero delle informazioni come il Mean Reciprocal Rank (MRR) e la precision@k per misurare la pertinenza. Aspetto cruciale, questo è stato abbinato a segnali di coinvolgimento reali online, come gli sblocchi delle offerte e i click-through rate. Una decisione chiave è stata l'implementazione di un LLM-as-a-judge. Ciò ci ha permesso di etichettare i dati e assegnare punteggi di qualità sia alle coppie query-risultato online sia agli output offline. Questo approccio si è rivelato fondamentale per un'iterazione rapida basata su metriche affidabili e per la raccolta dei dati etichettati necessari per il futuro fine-tuning del modello.

Lungo il percorso, abbiamo sfruttato diverse parti della Databricks Data Intelligence Platform, tra cui:

  • Databricks AI Search: utilizzato per fornire risultati di ricerca ad alta precisione e ricchi dal punto di vista semantico per i test di valutazione.
  • Pattern MLflow e LLM-as-a-judge: Hanno fornito i pattern per valutare gli output dei modelli e implementare il nostro processo di etichettatura dei dati.
  • Endpoint di Model Serving: Distribuzione efficiente dei modelli direttamente dal nostro catalogo.
  • AI Gateway: Per proteggere e gestire il nostro accesso ai modelli di terze parti tramite API.
  • Unity Catalog: Ha garantito l'organizzazione, la gestione e la governance di tutti i dataset utilizzati all'interno del framework di valutazione.

Questo solido framework ha aumentato drasticamente la nostra velocità di iterazione e la nostra sicurezza. Abbiamo condotto oltre 30 iterazioni distinte, testando sistematicamente le principali variazioni delle variabili nella nostra soluzione AI Search, tra cui:

  • Diversi modelli di embedding (fondazionali, open-weights e di terze parti tramite API)
  • Varie combinazioni di testo da fornire in input ai modelli
  • Diverse modalità di query (ANN vs ibrida)
  • Test di diverse colonne per la ricerca testuale ibrida
  • Regolazione delle soglie per la similarità vettoriale
  • Sperimentazione con indici separati per diversi tipi di offerta

Il framework di valutazione ha trasformato il nostro processo di sviluppo, consentendoci di prendere rapidamente decisioni basate sui dati e di convalidare i potenziali miglioramenti con elevata sicurezza prima di esporli agli utenti.

La ricerca del miglior modello pronto all'uso

In seguito al test iniziale su larga scala che ha mostrato risultati di engagement deludenti, abbiamo spostato la nostra attenzione sull'esplorazione delle prestazioni di modelli specifici identificati come promettenti durante la nostra valutazione offline. Abbiamo selezionato due modelli di embedding di terze parti per i test di produzione, a cui abbiamo effettuato l'accesso in modo sicuro tramite AI Gateway. Abbiamo condotto test iterativi a breve termine in produzione (della durata di pochi giorni) con questi modelli.

Soddisfatti dei risultati iniziali, abbiamo proceduto a eseguire un test di produzione più lungo e completo, confrontando il nostro modello di terze parti leader e la sua configurazione ottimizzata con il sistema legacy. Questo test ha dato risultati contrastanti. Sebbene abbiamo osservato miglioramenti generali nelle metriche di engagement e rimosso con successo gli impatti negativi riscontrati in precedenza, questi guadagni sono stati modesti, per lo più incrementi percentuali a una sola cifra. Questi vantaggi incrementali non erano sufficientemente convincenti da giustificare pienamente la sostituzione completa della nostra esperienza di ricerca esistente.

Ancora più preoccupante, tuttavia, è stata l'evidenza emersa dalla nostra analisi granulare: mentre le prestazioni sono migliorate in modo significativo per alcune query di ricerca, altre hanno registrato risultati peggiori rispetto alla nostra soluzione legacy. Questa incoerenza ha presentato un dilemma architetturale significativo. Ci siamo trovati di fronte alla scelta poco attraente di implementare un complesso sistema di suddivisione del traffico per instradare le query in base alle prestazioni previste (un approccio che avrebbe richiesto il mantenimento di due esperienze di ricerca distinte e introdotto un nuovo e complesso livello di gestione del routing basato su regole) o di accettare i limiti.

Questo è stato un momento cruciale. Sebbene avessimo visto abbastanza potenziale per continuare, avevamo bisogno di miglioramenti più significativi per giustificare la sostituzione completa del nostro sistema di ricerca proprietario. Questo ci ha spinto a iniziare il fine-tuning.

Fine-tuning: personalizzazione del comportamento del modello

Sebbene i modelli di embedding di terze parti esplorati in precedenza mostrassero un buon potenziale tecnico e modesti miglioramenti nell'engagement, presentavano anche limitazioni critiche inaccettabili per una soluzione a lungo termine per Ibotta. Tra queste:

  1. Impossibilità di addestrare modelli di embedding di terze parti sul nostro catalogo di offerte proprietario
  2. Difficoltà nel far evolvere i modelli di pari passo con i cambiamenti del business e dei contenuti
  3. Incertezza sulla disponibilità a lungo termine dei modelli di embedding da parte di provider esterni
  4. La necessità di stabilire e gestire nuove relazioni commerciali esterne
  5. Le chiamate di rete a questi provider non erano performanti quanto i modelli self-hosted

La strada da seguire era chiaramente quella di eseguire il fine-tuning di un modello specificamente adattato ai dati di Ibotta e alle esigenze dei nostri Saver. Ciò è stato possibile grazie ai milioni di interazioni di ricerca etichettate che avevamo accumulato da utenti reali tramite il nostro processo LLM-as-a-judge all'interno del nostro framework di valutazione personalizzato. Questi dati di produzione di alta qualità sono diventati la nostra risorsa più preziosa per l'addestramento.

Abbiamo quindi avviato un processo metodico di fine-tuning, sfruttando ampiamente il nostro framework di valutazione offline.

Gli elementi chiave sono stati:

  1. Infrastruttura: Abbiamo utilizzato AI Runtime con A10s in un ambiente serverless e Databricks ML Runtime per una sofisticata ricerca degli iperparametri.
  2. Selezione del modello: Abbiamo selezionato un modello della famiglia BGE rispetto a GTE, che ha dimostrato prestazioni migliori nelle nostre valutazioni offline ed è risultato più efficiente da addestrare.
  3. Ingegneria dei dataset: Abbiamo creato numerosi dataset di addestramento, inclusa la generazione di dati di addestramento sintetici, optando infine per:
    • Un risultato positivo (una corrispondenza verificata come valida da ricerche reali)
    • ~10 esempi negativi per ogni positivo, combinando:
      • 3-4 "hard negative" (etichettati da LLM, con corrispondenze inappropriate verificate da persone)
      • "In-batch negative" (campionamento di risultati da termini di ricerca non correlati)
  4. Ottimizzazione degli iperparametri: Abbiamo analizzato sistematicamente elementi come learning rate, batch size, durata e strategie di campionamento negativo per trovare le configurazioni ottimali.

Dopo numerose iterazioni e valutazioni all'interno del framework, il nostro modello con fine-tuning più performante ha superato la nostra migliore baseline di terze parti del 20% nella valutazione sintetica. Questi risultati offline convincenti ci hanno dato la sicurezza necessaria per accelerare il nostro prossimo test di produzione.

Una ricerca che genera risultati e ricavi

Il rigore tecnico e il processo iterativo hanno dato i loro frutti. Abbiamo progettato una soluzione di ricerca ottimizzata specificamente per il catalogo di offerte unico di Ibotta e per i pattern di comportamento degli utenti, offrendo risultati che hanno superato le nostre aspettative e fornendo la flessibilità necessaria per evolversi insieme al nostro business. Sulla base di questi ottimi risultati, abbiamo accelerato la migrazione a Databricks AI Search come base per il nostro sistema di ricerca in produzione.

Nel nostro test di produzione finale, utilizzando il nostro modello di embedding con fine-tuning, abbiamo osservato i seguenti miglioramenti:

  • 14,8% in più di sblocchi delle offerte nella ricerca.
    Questo dato misura gli utenti che selezionano le offerte dai risultati di ricerca, indicando una migliore qualità e rilevanza dei risultati. Un maggior numero di sblocchi è un indicatore anticipatore dei rimborsi e dei ricavi a valle.
  • Aumento del 6% degli utenti attivi.
    Ciò dimostra che una quota maggiore di utenti trova valore e compie azioni significative all'interno dell'esperienza di ricerca, contribuendo a migliorare la conversione, la fidelizzazione e il lifetime value.
  • Aumento del 15% dell'engagement sui bonus.
    Ciò riflette una migliore visibilità dei contenuti sponsorizzati dai brand ad alto valore, traducendosi direttamente in prestazioni migliori e un ROI superiore per i nostri partner di brand e vendita al dettaglio.
  • Diminuzione del 72,6% delle ricerche con zero risultati.
    La significativa riduzione si traduce in un minor numero di esperienze frustranti e in un importante miglioramento della copertura della ricerca semantica.
  • 60,9% in meno di utenti che effettuano ricerche senza risultati.
    Questo evidenzia l'ampiezza dell'impatto, dimostrando che gran parte della nostra base utenti ora trova costantemente risultati, migliorando l'esperienza complessiva.

Oltre ai vantaggi per gli utenti, il nuovo sistema ha offerto ottime prestazioni. Abbiamo riscontrato una latenza inferiore del 60% per il nostro sistema di ricerca, attribuibile alle prestazioni delle query di AI Search e al minor overhead del modello con fine-tuning.

Sfruttando la flessibilità di questa nuova base, abbiamo anche creato potenti miglioramenti come Query Transformation (che arricchisce le query vaghe) e Multi-Search (che distribuisce i termini generici). La combinazione di un modello di base altamente rilevante, migliori prestazioni del sistema e miglioramenti intelligenti delle query ha portato a un'esperienza di ricerca più intelligente, più veloce e, in definitiva, più gratificante.

Query Transformation

Una sfida dei modelli di embedding è la loro comprensione limitata delle parole chiave di nicchia, come i brand emergenti. Per risolvere questo problema, abbiamo creato un livello di trasformazione delle query che arricchisce dinamicamente i termini di ricerca in tempo reale in base a regole predefinite.

Ad esempio, se un utente cerca un marchio emergente di yogurt che il modello di embedding potrebbe non riconoscere, possiamo trasformare la query per aggiungere "yogurt greco" insieme al nome del marchio prima di inviarla ad AI Search. In questo modo si fornisce al modello di embedding il contesto di prodotto necessario, preservando al contempo il testo originale per la ricerca ibrida.

Questa funzionalità lavora anche in sinergia con il nostro processo di fine-tuning. Le trasformazioni andate a buon fine possono essere utilizzate per generare dati di addestramento; ad esempio, includere il nome del marchio originale come query e i prodotti di yogurt pertinenti come risultati positivi in una futura sessione di addestramento aiuta il modello ad apprendere queste associazioni specifiche.

Multi-Search

Per ricerche ampie e generiche come "neonato", AI Search potrebbe inizialmente restituire un numero limitato di candidati, potenzialmente ulteriormente ridotto dal targeting e dalla gestione del budget. Per affrontare questo problema e aumentare la diversità dei risultati, abbiamo sviluppato una funzionalità di Multi-Search che estende un singolo termine di ricerca in più ricerche correlate.

Invece di cercare semplicemente "neonato", il nostro sistema esegue automaticamente ricerche parallele per termini come "cibo per neonati", "abbigliamento per neonati", "farmaci per neonati", "pannolini per neonati" e così via. Grazie alla bassa latenza di AI Search, possiamo eseguire diverse ricerche in parallelo senza aumentare il tempo di risposta complessivo per l'utente. Ciò fornisce un set di risultati pertinenti molto più ampio e diversificato per ricerche di categorie estese.

Lezioni apprese

In seguito al successo del test di produzione finale e al rollout completo di Databricks AI Search per la nostra base di utenti – che ha portato a risultati positivi in termini di engagement, a una maggiore flessibilità e a potenti strumenti di ricerca come Query Transformation e Multi-Search – questo percorso di progetto ha offerto diverse lezioni preziose:

  1. Inizia con una proof of concept: l'approccio iniziale basato sull'hackathon ci ha permesso di convalidare rapidamente il concetto di base con un investimento iniziale minimo.
  2. Misura ciò che conta per te: il nostro framework di valutazione personalizzato basato su 50 metriche è stato fondamentale; ci ha dato la certezza che i miglioramenti osservati offline si sarebbero tradotti in un impatto sul business, consentendoci di evitare ripetuti test live fino a quando le soluzioni non fossero state davvero promettenti.
  3. Non passare direttamente al fine-tuning: abbiamo capito l'importanza di valutare a fondo i modelli pronti all'uso ed esaurire tali opzioni prima di investire nel maggiore impegno richiesto dal fine-tuning.
  4. Raccogli i dati in anticipo: iniziare a etichettare i dati fin dal nostro secondo esperimento ha garantito la disponibilità di un ricco dataset proprietario quando il fine-tuning si è reso necessario.
  5. La collaborazione accelera i progressi: la stretta collaborazione con gli ingegneri e i ricercatori di Databricks, condividendo approfondimenti su AI Search, modelli di embedding, pattern LLM-as-a-judge e approcci di fine-tuning, ha accelerato notevolmente i nostri progressi.
  6. Riconosci l'impatto cumulativo: ogni singola ottimizzazione, anche se apparentemente minore, ha contribuito in modo significativo alla trasformazione complessiva della nostra esperienza di ricerca.

I prossimi passi

Con il nostro modello di embedding ottimizzato tramite fine-tuning ora attivo su tutti i canali direct-to-consumer (D2C), il nostro prossimo obiettivo è esplorare la scalabilità di questa soluzione su Ibotta Performance Network (IPN). Ciò consentirebbe di migliorare la scoperta delle offerte per altri milioni di acquirenti in tutta la nostra rete di publisher. Mentre continuiamo a raccogliere dati etichettati e a perfezionare i nostri modelli attraverso Databricks, crediamo di essere ben posizionati per far evolvere l'esperienza di ricerca di pari passo con le esigenze dei nostri partner e le aspettative dei loro clienti.

Questo percorso, da un progetto nato da un hackathon a un sistema di produzione, ha dimostrato che reinventare rapidamente l'esperienza di un prodotto core è realizzabile con gli strumenti e il supporto giusti. Databricks è stato fondamentale per aiutarci a muoverci rapidamente, a eseguire il fine-tuning in modo efficace e, in definitiva, a rendere ogni ricerca più gratificante per i nostri Saver.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale

Ricevi gli ultimi articoli nella tua casella di posta

Iscriviti al nostro blog e ricevi gli ultimi articoli direttamente nella tua casella di posta.