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.
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:
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.
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:
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.
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:
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:
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.
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:
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:
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.
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.
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:
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:
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.
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:
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.
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.
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.
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:
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
Iscriviti al nostro blog e ricevi gli ultimi articoli direttamente nella tua casella di posta.