Hacer que cada búsqueda sea gratificante: cómo Ibotta transformó el descubrimiento de ofertas con Databricks

En Ibotta, nuestra misión es hacer que cada compra sea gratificante. Ayudar a nuestros usuarios (a quienes llamamos Savers) a encontrar y activar ofertas relevantes a través de nuestra aplicación directa al consumidor (D2C), extensión de navegador y sitio web es una parte fundamental de esta misión. Nuestra plataforma D2C ayuda a millones de compradores a obtener reembolsos (cashback) en sus compras diarias, ya sea desbloqueando ofertas de supermercado, obteniendo recompensas adicionales o planificando su próximo viaje. A través de la Ibotta Performance Network (IPN), también impulsamos programas de reembolso de marca blanca para algunos de los nombres más importantes del sector minorista, incluidos Walmart y Dollar General, ayudando a más de 2600 marcas a llegar a más de 200 millones de consumidores con ofertas digitales en todos los ecosistemas de socios.

Detrás de escena, nuestros equipos de Datos y Machine Learning impulsan experiencias fundamentales como la detección de fraudes, los motores de recomendación de ofertas y la relevancia de las búsquedas para que el recorrido de los Savers sea personalizado y seguro. A medida que seguimos creciendo, necesitamos sistemas inteligentes y basados en datos que respalden cada interacción en cada punto de contacto.

En D2C y la IPN, la búsqueda juega un papel fundamental en la interacción y debe mantener el ritmo de nuestra escala comercial, el contenido de ofertas en constante evolución y las cambiantes expectativas de los Savers.

En esta publicación, explicaremos cómo mejoramos significativamente nuestra experiencia de búsqueda D2C: desde un ambicioso proyecto de hackatón hasta una sólida función de producción que ahora beneficia a millones de Savers.

Creíamos que nuestra búsqueda podía seguir mejor el ritmo de nuestros Savers

El comportamiento de búsqueda de los usuarios ha evolucionado de palabras clave simples a la incorporación de lenguaje natural, errores ortográficos y frases conversacionales. Los sistemas de búsqueda modernos deben cerrar la brecha entre lo que los usuarios escriben y lo que realmente quieren decir, interpretando el contexto y las relaciones para ofrecer resultados relevantes incluso cuando los términos de la consulta no coinciden exactamente con el contenido.

En Ibotta, nuestro sistema de búsqueda interno original a veces tenía dificultades para mantener el ritmo de las cambiantes expectativas de nuestros Savers, y reconocimos una oportunidad para mejorarlo.

Las áreas clave de oportunidad que identificamos incluyeron:

• Mejorar la relevancia semántica: Centrarse en comprender la intención del Saver en lugar de las coincidencias exactas de palabras clave para conectarlo con las ofertas adecuadas.
• Mejorar la comprensión: Interpretar todos los matices y el contexto de las consultas de los usuarios para proporcionar resultados más completos y verdaderamente relevantes.
• Aumentar la flexibilidad: Integrar más rápidamente nuevos tipos de ofertas y adaptarse a los patrones de búsqueda cambiantes de los Savers para mantener una experiencia de descubrimiento gratificante.
• Impulsar la capacidad de descubrimiento: Queríamos herramientas más sólidas para garantizar que tipos específicos de ofertas o promociones clave fueran visibles de manera constante en una amplia gama de consultas de búsqueda relevantes.
• Acelerar la iteración y la optimización: Permitir mejoras más rápidas e impactantes en la experiencia de búsqueda mediante ajustes en tiempo real y optimización del rendimiento.

Creíamos que el sistema podía seguir mejor el ritmo del contenido cambiante de las ofertas, los comportamientos de búsqueda y las cambiantes expectativas de los Savers. Vimos oportunidades para aumentar el valor tanto para nuestros Savers como para nuestros socios de marca.

De hackatón a producción: rediseñando la búsqueda con Databricks

Abordar las limitaciones de nuestro sistema de búsqueda heredado requirió un esfuerzo enfocado. Esta iniciativa cobró un gran impulso durante un hackatón interno en el que un equipo multifuncional, que incluía miembros de Datos, Ingeniería, Análisis de Marketing y Machine Learning, se unió con la idea de crear un sistema de búsqueda alternativo y moderno utilizando Databricks AI Search, sobre el cual algunos miembros habían aprendido en el Databricks Data + AI Summit.

En solo tres días, nuestro equipo desarrolló una prueba de concepto funcional que ofreció resultados de búsqueda semánticamente relevantes. Así es como lo hicimos:

1. Recopilamos contenido de ofertas de múltiples fuentes en nuestro catálogo de Databricks
2. Creamos un punto de conexión e índice de AI Search con el SDK de Python
3. Utilizamos puntos de conexión de embeddings de pago por token con cinco modelos diferentes (BGE large, GTE large, GTE small, un modelo de código abierto multilingüe y un modelo específico para el idioma español)
4. Conectamos todo a nuestro sitio web para una demostración en vivo

El proyecto del hackatón ganó el primer lugar, lo que generó un fuerte respaldo interno y el impulso para la transición del prototipo a un sistema de producción. En el transcurso de unos meses, y en estrecha colaboración con ingenieros e investigadores de Databricks, transformamos nuestro prototipo en un sistema de búsqueda de producción completo y robusto.

De la prueba de concepto a la producción

Llevar la prueba de concepto del hackatón a un sistema listo para producción requirió una iteración y pruebas cuidadosas. Esta fase fue fundamental no solo para la integración técnica y la optimización del rendimiento, sino también para evaluar si las mejoras previstas en el sistema se traducirían en cambios positivos en el comportamiento y la interacción de los Savers. Dado el papel esencial de la búsqueda y su profunda integración en los sistemas internos, optamos por el siguiente enfoque: modificamos un servicio interno clave que llamaba a nuestro sistema de búsqueda original, reemplazando esas llamadas con solicitudes dirigidas al punto de conexión de Databricks AI Search, al tiempo que incorporamos alternativas de respaldo (fallbacks) sólidas y graduales al sistema heredado.

La mayor parte de nuestro trabajo inicial se centró en comprender:

• Cómo aprovechar al máximo el producto AI Search para nuestro caso de uso
• Seleccionar el modelo de mejor rendimiento mediante una evaluación empírica
• Probar los límites del uso de pago por token
• Mecanismos de autenticación
• Utilizar el punto de conexión del plano de datos para evitar la limitación de velocidad (rate limiting)
• Pasar a un punto de conexión de servicio de modelos aprovisionado para gestionar nuestros requisitos de rendimiento (throughput)

En el primer mes, realizamos una prueba con un pequeño porcentaje de nuestros Savers que no logró los resultados de interacción que esperábamos. La interacción disminuyó, especialmente entre nuestros Savers más activos, lo que se reflejó en una caída en los clics, los desbloqueos (cuando los Savers muestran interés en una oferta) y las activaciones.

Sin embargo, la solución de AI Search ofreció beneficios significativos, entre ellos:

• Tiempos de respuesta más rápidos
• Un modelo mental más sencillo
• Mayor flexibilidad en la forma en que indexamos los datos
• Nuevas capacidades para ajustar umbrales y cambiar el texto de los embeddings

Satisfechos con el rendimiento técnico subyacente del sistema, vimos su mayor flexibilidad como la ventaja clave necesaria para mejorar de forma iterativa la calidad de los resultados de búsqueda y superar los decepcionantes resultados de interacción.

Creación de un marco de evaluación

Tras los resultados de nuestras pruebas iniciales, confiar únicamente en las pruebas A/B para las iteraciones de búsqueda era claramente ineficiente y poco práctico. La cantidad de variables que influyen en la calidad de la búsqueda era inmensa, incluidos los modelos de embeddings, las combinaciones de texto, la configuración de búsqueda híbrida, los umbrales de vecinos más cercanos aproximados (ANN), las opciones de reranking y muchas más.

Para navegar por esta complejidad y acelerar nuestro progreso, decidimos establecer un marco de evaluación sólido. Este marco debía adaptarse de manera única a nuestras necesidades comerciales específicas y ser capaz de predecir la interacción de los usuarios en el mundo real a partir de métricas de rendimiento fuera de línea (offline).

Nuestro marco se diseñó en torno a un entorno de evaluación sintético que realizaba un seguimiento de más de 50 métricas con conexión (online) y fuera de línea (offline). Fuera de línea, monitoreamos métricas estándar de recuperación de información como el rango recíproco medio (MRR) y precisión@k para medir la relevancia. Fundamentalmente, esto se combinó con señales de interacción en línea del mundo real, como los desbloqueos de ofertas y las tasas de clics. Una decisión clave fue implementar un LLM como juez (LLM-as-a-judge). Esto nos permitió etiquetar datos y asignar puntuaciones de calidad tanto a los pares de consulta-resultado en línea como a los resultados fuera de línea. Este enfoque demostró ser fundamental para una iteración rápida basada en métricas confiables y para recopilar los datos etiquetados necesarios para el futuro ajuste fino (fine-tuning) del modelo.

En el camino, nos apoyamos en múltiples partes de Databricks Data Intelligence Platform, que incluyen:

• Databricks AI Search: Utilizado para impulsar resultados de búsqueda de alta precisión y semánticamente enriquecidos para pruebas de evaluación.
• Patrones de MLflow y LLM como juez: Proporcionaron los patrones para evaluar los resultados del modelo e implementar nuestro proceso de etiquetado de datos.
• Endpoints de Model Serving: Despliegue eficiente de modelos directamente desde nuestro catálogo.
• AI Gateway: Para proteger y gobernar nuestro acceso a modelos de terceros a través de API.
• Unity Catalog: Garantizó la organización, gestión y gobernanza de todos los conjuntos de datos utilizados dentro del marco de evaluación.

Este marco robusto aumentó drásticamente nuestra velocidad de iteración y confianza. Realizamos más de 30 iteraciones distintas, probando sistemáticamente cambios importantes en las variables de nuestra solución de AI Search, que incluyen:

• Diferentes modelos de embedding (fundacionales, de pesos abiertos y de terceros a través de API)
• Varias combinaciones de texto para alimentar los modelos
• Diferentes modos de consulta (ANN frente a híbrido)
• Prueba de diferentes columnas para la búsqueda de texto híbrida
• Ajuste de umbrales para la similitud de vectores
• Experimentación con índices separados para diferentes tipos de ofertas

El marco de evaluación transformó nuestro proceso de desarrollo, lo que nos permitió tomar decisiones basadas en datos rápidamente y validar posibles mejoras con gran confianza antes de exponerlas a los usuarios.

La búsqueda del mejor modelo listo para usar

Tras la prueba inicial general que mostró resultados de interacción decepcionantes, cambiamos nuestro enfoque hacia la exploración del rendimiento de modelos específicos identificados como prometedores durante nuestra evaluación offline. Seleccionamos dos modelos de embedding de terceros para pruebas de producción, a los que accedimos de forma segura a través de AI Gateway. Realizamos pruebas iterativas a corto plazo en producción (que duraron unos pocos días) con estos modelos.

Satisfechos con los resultados iniciales, procedimos a realizar una prueba de producción más larga y exhaustiva, comparando nuestro modelo de terceros líder y su configuración optimizada con el sistema heredado. Esta prueba arrojó resultados mixtos. Aunque observamos mejoras generales en las métricas de interacción y eliminamos con éxito los impactos negativos observados anteriormente, estas ganancias fueron modestas, principalmente aumentos de un solo dígito porcentual. Estos beneficios incrementales no fueron lo suficientemente convincentes como para justificar plenamente un reemplazo completo de nuestra experiencia de búsqueda existente.

Sin embargo, lo más preocupante fue la información obtenida de nuestro análisis detallado: mientras que el rendimiento mejoró significativamente para ciertas consultas de búsqueda, otras mostraron peores resultados en comparación con nuestra solución heredada. Esta inconsistencia planteó un dilema arquitectónico importante. Nos enfrentamos a la poco atractiva opción de implementar un sistema complejo de división de tráfico para enrutar las consultas en función del rendimiento previsto (un enfoque que requeriría mantener dos experiencias de búsqueda distintas e introduciría una nueva y compleja capa de gestión de enrutamiento basada en reglas) o aceptar las limitaciones.

Este fue un momento crítico. Aunque habíamos visto suficientes promesas como para continuar, necesitábamos mejoras más significativas para justificar el reemplazo completo de nuestro sistema de búsqueda de desarrollo propio. Esto nos llevó a comenzar el ajuste fino.

Ajuste fino: personalización del comportamiento del modelo

Aunque los modelos de embedding de terceros explorados anteriormente mostraron promesa técnica y mejoras modestas en la interacción, también presentaron limitaciones críticas que eran inaceptables para una solución a largo plazo en Ibotta. Estas incluían:

1. Incapacidad para entrenar modelos de embedding de terceros en nuestro catálogo de ofertas propietario
2. Dificultad para hacer evolucionar los modelos junto con los cambios comerciales y de contenido
3. Incertidumbre respecto a la disponibilidad a largo plazo de los modelos de embedding por parte de proveedores externos
4. La necesidad de establecer y gestionar nuevas relaciones comerciales externas
5. Las llamadas de red a estos proveedores no eran tan eficientes como los modelos autohospedados

El camino claro a seguir era ajustar un modelo específicamente adaptado a los datos de Ibotta y a las necesidades de nuestros Savers. Esto fue posible gracias a los millones de interacciones de búsqueda etiquetadas que habíamos acumulado de usuarios reales a través de nuestro proceso de LLM como juez dentro de nuestro marco de evaluación personalizado. Estos datos de producción de alta calidad se convirtieron en nuestro oro para el entrenamiento.

Luego nos embarcamos en un proceso metódico de ajuste fino, aprovechando ampliamente nuestro marco de evaluación offline.

Los elementos clave fueron:

1. Infraestructura: Utilizamos AI Runtime con A10s en un entorno serverless, y Databricks ML Runtime para un barrido sofisticado de hiperparámetros.
2. Selección del modelo: Seleccionamos un modelo de la familia BGE en lugar de GTE, que demostró un rendimiento más sólido en nuestras evaluaciones offline y resultó más eficiente de entrenar.
3. Ingeniería de conjuntos de datos: Construimos numerosos conjuntos de datos de entrenamiento, incluida la generación de datos de entrenamiento sintéticos, decidiéndonos finalmente por:
   • Un resultado positivo (una coincidencia buena verificada de búsquedas reales)
   • ~10 ejemplos negativos por cada positivo, combinando:
     • 3-4 «negativos difíciles» (etiquetados por LLM, coincidencias inapropiadas verificadas por humanos)
     • «Negativos en lote» (muestreo de resultados de términos de búsqueda no relacionados)
4. Optimización de hiperparámetros: Realizamos barridos sistemáticos de aspectos como la tasa de aprendizaje, el tamaño de lote, la duración y las estrategias de muestreo negativo para encontrar configuraciones óptimas.

Después de numerosas iteraciones y evaluaciones dentro del marco, nuestro modelo ajustado de mejor rendimiento superó nuestra mejor línea base de terceros en un 20% en la evaluación sintética. Estos convincentes resultados offline proporcionaron la confianza necesaria para acelerar nuestra próxima prueba de producción.

Búsqueda que impulsa resultados e ingresos

El rigor técnico y el proceso iterativo dieron sus frutos. Diseñamos una solución de búsqueda específicamente optimizada para el catálogo de ofertas único de Ibotta y los patrones de comportamiento de los usuarios, ofreciendo resultados que superaron nuestras expectativas y brindando la flexibilidad necesaria para evolucionar junto con nuestro negocio. Basándonos en estos sólidos resultados, aceleramos la migración a Databricks AI Search como base para nuestro sistema de búsqueda en producción.

En nuestra prueba de producción final, utilizando nuestro propio modelo de embedding ajustado, observamos las siguientes mejoras:

• Un 14.8% más de desbloqueos de ofertas en la búsqueda.
  Esto mide a los usuarios que seleccionan ofertas de los resultados de búsqueda, lo que indica una mejor calidad y relevancia de los resultados. Más desbloqueos son un indicador principal de los canjes e ingresos posteriores.
• Aumento del 6% en usuarios activos.
  Esto muestra una mayor proporción de usuarios que encuentran valor y realizan acciones significativas dentro de la experiencia de búsqueda, lo que contribuye a mejorar la conversión, la retención y el valor de vida del cliente.
• Aumento del 15% en la interacción con los bonos.
  Esto refleja una mejor visualización de contenido de alto valor patrocinado por marcas, lo que se traduce directamente en un mejor rendimiento y ROI para nuestros socios de marca y minoristas.
• Disminución del 72.6% en búsquedas con cero resultados.
  Esta reducción significativa significa menos experiencias frustrantes y una mejora importante en la cobertura de la búsqueda semántica.
• Un 60.9% menos de usuarios que se encuentran con búsquedas que no devuelven resultados.
  Esto destaca la amplitud del impacto, mostrando que una gran parte de nuestra base de usuarios ahora encuentra resultados de manera constante, mejorando la experiencia en general.

Más allá de las ganancias de cara al usuario, el nuevo sistema cumplió con el rendimiento. Observamos una latencia un 60% menor en nuestro sistema de búsqueda, atribuible al rendimiento de las consultas de AI Search y a la menor sobrecarga del modelo ajustado.

Aprovechando la flexibilidad de esta nueva base, también creamos mejoras potentes como Query Transformation (enriquecimiento de consultas vagas) y Multi-Search (desglose de términos genéricos). La combinación de un modelo central altamente relevante, un mejor rendimiento del sistema y mejoras inteligentes en las consultas ha dado como resultado una experiencia de búsqueda que es más inteligente, más rápida y, en última instancia, más gratificante.

Query Transformation

Un desafío de los modelos de embedding es su comprensión limitada de palabras clave de nicho, como las marcas emergentes. Para solucionar esto, creamos una capa de transformación de consultas que enriquece dinámicamente los términos de búsqueda sobre la marcha en función de reglas predefinidas.

Por ejemplo, si un usuario busca una marca emergente de yogur que el modelo de embedding podría no reconocer, podemos transformar la consulta para añadir "Greek yogurt" junto al nombre de la marca antes de enviarla a AI Search. Esto proporciona al modelo de embedding el contexto de producto necesario, al tiempo que conserva el texto original para la búsqueda híbrida.

Esta capacidad también funciona de la mano con nuestro proceso de ajuste fino. Las transformaciones exitosas se pueden utilizar para generar datos de entrenamiento; por ejemplo, incluir el nombre original de la marca como consulta y los productos de yogur relevantes como resultados positivos en una futura ejecución de entrenamiento ayuda al modelo a aprender estas asociaciones específicas.

Multi-Search

Para búsquedas amplias y genéricas como "bebé", AI Search podría devolver inicialmente un número limitado de candidatos, potencialmente filtrados aún más por la segmentación y la gestión del presupuesto. Para abordar esto y aumentar la diversidad de los resultados, creamos una capacidad de Multi-Search que despliega un único término de búsqueda en múltiples búsquedas relacionadas.

En lugar de buscar solo "bebé", nuestro sistema ejecuta automáticamente búsquedas en paralelo para términos como "comida para bebés", "ropa para bebés", "medicamentos para bebés", "pañales para bebés", etc. Debido a la baja latencia de AI Search, podemos ejecutar varias búsquedas en paralelo sin aumentar el tiempo de respuesta general para el usuario. Esto proporciona un conjunto mucho más amplio y diverso de resultados relevantes para búsquedas de categorías de gran alcance.

Lecciones aprendidas

Tras el éxito de la prueba final de producción y el despliegue completo de Databricks AI Search para nuestra base de usuarios (lo que generó resultados de interacción positivos, una mayor flexibilidad y potentes herramientas de búsqueda como Query Transformation y Multi-Search), este recorrido del proyecto dejó varias lecciones valiosas:

1. Comenzar con una prueba de concepto: El enfoque inicial de hackatón nos permitió validar rápidamente el concepto principal con una inversión inicial mínima.
2. Medir lo que realmente importa: Nuestro marco de evaluación personalizado de 50 métricas fue crucial; nos dio la confianza de que las mejoras observadas fuera de línea se traducirían en un impacto comercial, lo que nos permitió evitar pruebas repetidas en vivo hasta que las soluciones fueran realmente prometedoras.
3. No saltar directamente al ajuste fino: Aprendimos el valor de evaluar a fondo los modelos listos para usar y agotar esas opciones antes de invertir en el mayor esfuerzo que requiere el ajuste fino.
4. Recopilar datos desde el principio: Comenzar a etiquetar datos desde nuestro segundo experimento garantizó que un conjunto de datos propio y enriquecido estuviera listo cuando el ajuste fino fuera necesario.
5. La colaboración acelera el progreso: La estrecha colaboración con los ingenieros e investigadores de Databricks, compartiendo conocimientos sobre AI Search, modelos de embedding, patrones de LLM como juez y enfoques de ajuste fino, aceleró significativamente nuestro progreso.
6. Reconocer el impacto acumulativo: Cada optimización individual, incluso las que parecían menores, contribuyó significativamente a la transformación general de nuestra experiencia de búsqueda.

Próximos pasos

Con nuestro modelo de embedding ajustado ya activo en todos los canales directos al consumidor (D2C), nuestro siguiente plan es explorar la escala de esta solución a la red Ibotta Performance Network (IPN). Esto llevaría un descubrimiento de ofertas mejorado a millones de compradores más en toda nuestra red de editores. A medida que continuamos recopilando datos etiquetados y refinando nuestros modelos a través de Databricks, creemos que estamos bien posicionados para evolucionar la experiencia de búsqueda junto con las necesidades de nuestros socios y las expectativas de sus clientes.

Este viaje desde un proyecto de hackatón hasta un sistema de producción demostró que reimaginar rápidamente una experiencia de producto principal es alcanzable con las herramientas y el soporte adecuados. Databricks fue fundamental para ayudarnos a avanzar rápido, realizar el ajuste fino de manera efectiva y, en última instancia, hacer que cada búsqueda sea más gratificante para nuestros Savers.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original