Tornando cada busca recompensadora: como a Ibotta transformou a descoberta de ofertas com o Databricks

Na Ibotta, nossa missão é tornar cada compra recompensadora (Make Every Purchase Rewarding). Ajudar nossos usuários (a quem chamamos de Savers) a encontrar e ativar ofertas relevantes por meio de nosso aplicativo direto ao consumidor (D2C), extensão de navegador e site é uma parte crítica dessa missão. Nossa plataforma D2C ajuda milhões de compradores a receber cashback em suas compras diárias — seja desbloqueando ofertas de supermercado, ganhando recompensas de bônus ou planejando sua próxima viagem. Por meio da Ibotta Performance Network (IPN), também viabilizamos programas de cashback white-label para alguns dos maiores nomes do varejo, incluindo Walmart e Dollar General, ajudando mais de 2.600 marcas a alcançar mais de 200 milhões de consumidores com ofertas digitais em ecossistemas de parceiros.

Nos bastidores, nossas equipes de Dados e Machine Learning impulsionam experiências críticas, como detecção de fraudes, mecanismos de recomendação de ofertas e relevância de busca, para tornar a jornada do Saver personalizada e segura. À medida que continuamos a crescer, precisamos de sistemas inteligentes e orientados a dados que deem suporte a cada interação em todos os pontos de contato.

Em todo o D2C e na IPN, a busca desempenha um papel fundamental no engajamento e precisa acompanhar a escala de nossos negócios, a evolução do conteúdo das ofertas e as mudanças nas expectativas dos Savers.

Neste post, vamos mostrar como aprimoramos significativamente nossa experiência de busca D2C: de um projeto ambicioso de hackathon a um recurso robusto em produção que agora beneficia milhões de Savers.

Acreditávamos que nossa busca poderia acompanhar melhor nossos Savers

O comportamento de busca dos usuários evoluiu de palavras-chave simples para a incorporação de linguagem natural, erros de digitação e frases conversacionais. Os sistemas de busca modernos devem preencher a lacuna entre o que os usuários digitam e o que eles realmente querem dizer, interpretando o contexto e as relações para fornecer resultados relevantes, mesmo quando os termos da consulta não correspondem exatamente ao conteúdo.

Na Ibotta, nosso sistema de busca original desenvolvido internamente às vezes tinha dificuldades para acompanhar as expectativas em constante evolução de nossos Savers, e reconhecemos uma oportunidade de aprimorá-lo.

As principais áreas de oportunidade que identificamos incluíam:

• Melhorar a relevância semântica: Focar na compreensão da intenção do Saver em vez de correspondências exatas de palavras-chave para conectá-los às ofertas certas.
• Aprimorar a compreensão: Interpretar todas as nuances e o contexto das consultas dos usuários para fornecer resultados mais abrangentes e verdadeiramente relevantes.
• Aumentar a flexibilidade: Integrar novos tipos de ofertas mais rapidamente e se adaptar aos padrões de busca em constante mudança dos Savers para manter nossa experiência de descoberta recompensadora.
• Impulsionar a descoberta: Queríamos ferramentas mais robustas para garantir que tipos específicos de ofertas ou promoções importantes estivessem consistentemente visíveis em uma ampla variedade de consultas de busca relevantes.
• Acelerar a iteração e a otimização: Permitir melhorias mais rápidas e impactantes na experiência de busca por meio de ajustes em tempo real e ajuste de desempenho.

Acreditávamos que o sistema poderia acompanhar melhor as mudanças no conteúdo das ofertas, nos comportamentos de busca e nas expectativas em constante evolução dos Savers. Vimos oportunidades de aumentar o valor tanto para nossos Savers quanto para nossos parceiros de marca.

Do hackathon à produção: reimaginando a busca com a Databricks

Superar as limitações do nosso sistema de busca legado exigiu um esforço focado. Essa iniciativa ganhou força significativa durante um hackathon interno no qual uma equipe multifuncional, incluindo membros de Dados, Engenharia, Marketing Analytics e Machine Learning, se reuniu com a ideia de criar um sistema de busca alternativo e moderno usando o Databricks AI Search, sobre o qual alguns membros haviam aprendido no Databricks Data + AI Summit.

Em apenas três dias, nossa equipe desenvolveu uma prova de conceito funcional que entregou resultados de busca semântica relevantes. Veja como fizemos isso:

1. Coletamos conteúdo de ofertas de várias fontes em nosso catálogo do Databricks
2. Criamos um endpoint e um índice de AI Search com o Python SDK
3. Usamos endpoints de embedding pay-per-token com cinco modelos diferentes (BGE large, GTE large, GTE small, um modelo de código aberto multilíngue e um modelo específico para o idioma espanhol)
4. Conectamos tudo ao nosso site para uma demonstração ao vivo

O projeto do hackathon ganhou o primeiro lugar, gerando forte adesão interna e o impulso necessário para fazer a transição do protótipo para um sistema de produção. Ao longo de alguns meses, e em estreita parceria com engenheiros e pesquisadores da Databricks, transformamos nosso protótipo em um sistema de busca em produção robusto e completo.

Da prova de conceito à produção

Levar a prova de conceito do hackathon para um sistema pronto para produção exigiu testes e iterações cuidadosas. Essa fase foi crítica não apenas para a integração técnica e o ajuste de desempenho, mas também para avaliar se as melhorias esperadas no sistema se traduziriam em mudanças positivas no comportamento e no engajamento dos Savers. Dado o papel essencial da busca e sua profunda integração nos sistemas internos, optamos pela seguinte abordagem: modificamos um serviço interno fundamental que chamava nosso sistema de busca original, substituindo essas chamadas por solicitações direcionadas ao endpoint do Databricks AI Search, ao mesmo tempo em que criamos fallbacks robustos e graduais para o sistema legado.

A maior parte do nosso trabalho inicial concentrou-se em entender:

• Como aproveitar melhor o produto AI Search para o nosso caso de uso
• Selecionar o modelo de melhor desempenho com avaliação empírica
• Testar os limites do uso de pay-per-token
• Mecanismos de autenticação
• Usar o endpoint do plano de dados (data plane) para evitar limitação de taxa (rate limiting)
• Mudar para um endpoint de serviço de modelo provisionado para lidar com nossos requisitos de taxa de transferência (throughput)

No primeiro mês, realizamos um teste com uma pequena porcentagem de nossos Savers que não alcançou os resultados de engajamento esperados. O engajamento diminuiu, especialmente entre nossos Savers mais ativos, indicado por uma queda nos cliques, desbloqueios (quando os Savers expressam interesse em uma oferta) e ativações.

No entanto, a solução AI Search ofereceu benefícios significativos, incluindo:

• Tempos de resposta mais rápidos
• Um modelo mental mais simples
• Maior flexibilidade na forma como indexamos os dados
• Novas capacidades para ajustar limites (thresholds) e alterar o texto de embedding

Satisfeitos com o desempenho técnico subjacente do sistema, vimos sua maior flexibilidade como a vantagem fundamental necessária para melhorar iterativamente a qualidade dos resultados de busca e superar os resultados de engajamento decepcionantes.

Criando um framework de avaliação

Após os resultados dos nossos testes iniciais, depender apenas de testes A/B para as iterações de busca era claramente ineficiente e impraticável. O número de variáveis que influenciavam a qualidade da busca era imenso — incluindo modelos de embedding, combinações de texto, configurações de busca híbrida, limites de Vizinhos Mais Próximos Aproximados (ANN), opções de reranking e muito mais.

Para navegar por essa complexidade e acelerar nosso progresso, decidimos estabelecer um framework de avaliação robusto. Esse framework precisava ser adaptado de forma exclusiva às nossas necessidades de negócios específicas e capaz de prever o engajamento do usuário no mundo real a partir de métricas de desempenho offline.

Nosso framework foi projetado em torno de um ambiente de avaliação sintético que rastreava mais de 50 métricas online e offline. Offline, monitoramos métricas padrão de recuperação de informações, como Mean Reciprocal Rank (MRR) e precision@k, para medir a relevância. Fundamentalmente, isso foi combinado com sinais de engajamento online do mundo real, como desbloqueios de ofertas e taxas de cliques (click-through rates). Uma decisão fundamental foi a implementação de um LLM-as-a-judge. Isso nos permitiu rotular dados e atribuir pontuações de qualidade tanto para pares de consulta-resultado online quanto para saídas offline. Essa abordagem provou ser crítica para a iteração rápida com base em métricas confiáveis e para a coleta de dados rotulados necessários para o ajuste fino (fine-tuning) futuro do modelo.

Ao longo do caminho, contamos com várias partes da Databricks Data Intelligence Platform, incluindo:

• Databricks AI Search: Usado para impulsionar resultados de busca de alta precisão e semanticamente ricos para testes de avaliação.
• Padrões do MLflow e LLM como avaliador: Forneceram os padrões para avaliar as saídas do modelo e implementar nosso processo de rotulação de dados.
• Endpoints de Model Serving: Implantação eficiente de modelos diretamente do nosso catálogo.
• AI Gateway: Para proteger e governar nosso acesso a modelos de terceiros via API.
• Unity Catalog: Garantiu a organização, o gerenciamento e a governança de todos os conjuntos de dados usados no framework de avaliação.

Esse framework robusto aumentou drasticamente nossa velocidade de iteração e confiança. Realizamos mais de 30 iterações distintas, testando sistematicamente as principais alterações de variáveis em nossa solução de AI Search, incluindo:

• Diferentes modelos de embedding (fundacionais, de pesos abertos e de terceiros via API)
• Várias combinações de texto para alimentar os modelos
• Diferentes modos de consulta (ANN vs. híbrido)
• Teste de diferentes colunas para busca de texto híbrida
• Ajuste de limiares para similaridade de vetores
• Experimentos com índices separados para diferentes tipos de ofertas

O framework de avaliação transformou nosso processo de desenvolvimento, permitindo-nos tomar decisões baseadas em dados rapidamente e validar possíveis melhorias com alta confiança antes de expô-las aos usuários.

A busca pelo melhor modelo pronto para uso

Após o teste amplo inicial que apresentou resultados de engajamento decepcionantes, mudamos nosso foco para explorar o desempenho de modelos específicos identificados como promissores durante nossa avaliação offline. Selecionamos dois modelos de embedding de terceiros para testes de produção, acessados com segurança por meio do AI Gateway. Realizamos testes iterativos de curto prazo em produção (com duração de alguns dias) com esses modelos.

Satisfeitos com os resultados iniciais, passamos a realizar um teste de produção mais longo e abrangente, comparando nosso principal modelo de terceiros e sua configuração otimizada com o sistema legado. Esse teste apresentou resultados mistos. Embora tenhamos observado melhorias gerais nas métricas de engajamento e eliminado com sucesso os impactos negativos vistos anteriormente, esses ganhos foram modestos — a maioria com aumentos de apenas um dígito percentual. Esses benefícios incrementais não foram convincentes o suficiente para justificar totalmente a substituição completa da nossa experiência de busca existente.

Mais preocupante, no entanto, foi o insight obtido a partir de nossa análise granular: embora o desempenho tenha melhorado significativamente para certas consultas de busca, outras apresentaram resultados piores em comparação com nossa solução legada. Essa inconsistência apresentou um dilema arquitetônico significativo. Enfrentamos a escolha pouco atraente de implementar um sistema complexo de divisão de tráfego para rotear consultas com base no desempenho previsto — uma abordagem que exigiria a manutenção de duas experiências de busca distintas e introduziria uma nova e complexa camada de gerenciamento de roteamento baseado em regras — ou aceitar as limitações.

Esse foi um momento decisivo. Embora tivéssemos visto promessa suficiente para continuar, precisávamos de melhorias mais significativas para justificar a substituição completa do nosso sistema de busca próprio. Isso nos levou a iniciar o ajuste fino.

Ajuste fino: personalizando o comportamento do modelo

Embora os modelos de embedding de terceiros explorados anteriormente tenham mostrado promessa técnica e melhorias modestas no engajamento, eles também apresentaram limitações críticas que eram inaceitáveis para uma solução de longo prazo na Ibotta. Elas incluíam:

1. Inabilidade de treinar modelos de embedding de terceiros em nosso catálogo de ofertas proprietário
2. Dificuldade em evoluir os modelos juntamente com as mudanças de negócios e conteúdo
3. Incerteza quanto à disponibilidade de longo prazo dos modelos de embedding de provedores externos
4. A necessidade de estabelecer e gerenciar novos relacionamentos comerciais externos
5. As chamadas de rede para esses provedores não eram tão eficientes quanto as de modelos auto-hospedados

O caminho claro a seguir era ajustar um modelo especificamente adaptado aos dados da Ibotta e às necessidades dos nossos Savers. Isso foi possível graças aos milhões de interações de busca rotuladas que acumulamos de usuários reais por meio do nosso processo de LLM como avaliador dentro do nosso framework de avaliação personalizado. Esses dados de produção de alta qualidade se tornaram nossa mina de ouro para o treinamento.

Em seguida, embarcamos em um processo metódico de ajuste fino, aproveitando extensivamente nosso framework de avaliação offline.

Os principais elementos foram:

1. Infraestrutura: Usamos o AI Runtime com A10s em um ambiente serverless e o Databricks ML Runtime para varreduras sofisticadas de hiperparâmetros.
2. Seleção do modelo: Selecionamos um modelo da família BGE em vez do GTE, que demonstrou melhor desempenho em nossas avaliações offline e provou ser mais eficiente para treinar.
3. Engenharia de conjuntos de dados: Construímos vários conjuntos de dados de treinamento, incluindo a geração de dados de treinamento sintéticos, definindo finalmente:
   • Um resultado positivo (uma correspondência de qualidade verificada a partir de buscas reais)
   • ~10 exemplos negativos por positivo, combinando:
     • 3 a 4 “hard negatives” (rotulados por LLM, com correspondências inadequadas verificadas por humanos)
     • “In-batch negatives” (amostragem de resultados de termos de busca não relacionados)
4. Otimização de hiperparâmetros: Fizemos varreduras sistemáticas em elementos como taxa de aprendizado, tamanho do lote, duração e estratégias de amostragem negativa para encontrar as configurações ideais.

Após inúmeras iterações e avaliações dentro do framework, nosso modelo ajustado de melhor desempenho superou nossa melhor linha de base (baseline) de terceiros em 20% na avaliação sintética. Esses resultados offline convincentes forneceram a confiança necessária para acelerar nosso próximo teste de produção.

Busca que gera resultados — e receita

O rigor técnico e o processo iterativo valeram a pena. Desenvolvemos uma solução de busca especificamente otimizada para o catálogo de ofertas exclusivo da Ibotta e para os padrões de comportamento dos usuários, entregando resultados que superaram nossas expectativas e ofereceram a flexibilidade necessária para evoluir junto com nossos negócios. Com base nesses resultados sólidos, aceleramos a migração para o Databricks AI Search como base para nosso sistema de busca em produção.

Em nosso teste de produção final, usando nosso próprio modelo de embedding ajustado, observamos as seguintes melhorias:

• 14,8% mais desbloqueios de ofertas na busca.
  Isso mede os usuários que selecionam ofertas nos resultados de busca, indicando melhor qualidade e relevância dos resultados. Mais desbloqueios são um indicador antecedente de resgates e receita subsequentes.
• Aumento de 6% nos usuários engajados.
  Isso mostra uma parcela maior de usuários encontrando valor e realizando ações significativas na experiência de busca, contribuindo para uma melhor conversão, retenção e lifetime value.
• Aumento de 15% no engajamento em bônus.
  Isso reflete uma melhor exibição de conteúdo patrocinado por marcas de alto valor, traduzindo-se diretamente em melhor desempenho e ROI para nossos parceiros de marca e varejo.
• Redução de 72,6% nas buscas com zero resultados.
  A redução significativa significa menos experiências frustrantes e uma grande melhoria na cobertura de busca semântica.
• 60,9% menos usuários encontrando buscas que não retornam resultados.
  Isso destaca a amplitude do impacto, mostrando que uma grande parte da nossa base de usuários agora encontra resultados de forma consistente, melhorando a experiência de modo geral.

Além dos ganhos para os usuários, o novo sistema entregou excelente desempenho. Vimos uma latência 60% menor em nosso sistema de busca, o que se deve ao desempenho de consulta do AI Search e ao menor overhead do modelo ajustado.

Aproveitando a flexibilidade dessa nova base, também criamos melhorias poderosas, como Query Transformation (enriquecimento de consultas vagas) e Multi-Search (desdobramento de termos genéricos). A combinação de um modelo central altamente relevante, melhor desempenho do sistema e aprimoramentos inteligentes de consulta resultou em uma experiência de busca mais inteligente, rápida e, em última análise, mais recompensadora.

Query Transformation

Um desafio dos modelos de embedding é a compreensão limitada de palavras-chave de nicho, como marcas emergentes. Para resolver isso, criamos uma camada de transformação de consulta que enriquece dinamicamente os termos de busca em tempo real com base em regras predefinidas.

Por exemplo, se um usuário pesquisar por uma marca emergente de iogurte que o modelo de embedding pode não reconhecer, podemos transformar a consulta para adicionar "iogurte grego" ao lado do nome da marca antes de enviá-la para o AI Search. Isso fornece ao modelo de embedding o contexto de produto necessário, preservando o texto original para a busca híbrida.

Essa capacidade também funciona em conjunto com nosso processo de fine-tuning. Transformações bem-sucedidas podem ser usadas para gerar dados de treinamento; por exemplo, incluir o nome original da marca como uma consulta e os produtos de iogurte relevantes como resultados positivos em uma futura execução de treinamento ajuda o modelo a aprender essas associações específicas.

Multi-Search

Para buscas amplas e genéricas como "bebê", o AI Search pode inicialmente retornar um número limitado de candidatos, potencialmente filtrados ainda mais por direcionamento e gerenciamento de orçamento. Para resolver isso e aumentar a diversidade de resultados, criamos um recurso de Multi-Search que desdobra um único termo de busca em várias buscas relacionadas.

Em vez de apenas buscar por "bebê", nosso sistema executa automaticamente buscas paralelas para termos como "comida de bebê", "roupas de bebê", "remédio de bebê", "fraldas de bebê" e assim por diante. Devido à baixa latência do AI Search, podemos executar várias buscas em paralelo sem aumentar o tempo de resposta geral para o usuário. Isso fornece um conjunto muito mais amplo e diversificado de resultados relevantes para buscas de categorias abrangentes.

Lições aprendidas

Após o teste final de produção bem-sucedido e a implantação completa do Databricks AI Search para nossa base de usuários – oferecendo resultados positivos de engajamento, maior flexibilidade e ferramentas de busca poderosas como Query Transformation e Multi-Search – a jornada deste projeto rendeu várias lições valiosas:

1. Comece com uma prova de conceito: A abordagem inicial de hackathon nos permitiu validar rapidamente o conceito central com um investimento inicial mínimo.
2. Meça o que importa para você: Nossa estrutura de avaliação personalizada de 50 métricas foi crucial; ela nos deu a confiança de que as melhorias observadas offline se traduziriam em impacto nos negócios, permitindo-nos evitar testes repetidos em produção até que as soluções fossem realmente promissoras.
3. Não pule direto para o fine-tuning: Aprendemos o valor de avaliar minuciosamente os modelos prontos para uso (off-the-shelf) e esgotar essas opções antes de investir no esforço maior exigido para o fine-tuning.
4. Colete dados desde o início: Começar a rotular os dados a partir do nosso segundo experimento garantiu que um conjunto de dados proprietário e rico estivesse pronto quando o fine-tuning se tornou necessário.
5. A colaboração acelera o progresso: A parceria próxima com engenheiros e pesquisadores da Databricks, compartilhando insights sobre AI Search, modelos de embedding, padrões de LLM-as-a-judge e abordagens de fine-tuning, acelerou significativamente nosso progresso.
6. Reconheça o impacto cumulativo: Cada otimização individual, mesmo que parecesse pequena, contribuiu significativamente para a transformação geral de nossa experiência de busca.

Próximos passos

Com nosso modelo de embedding com fine-tuning agora ativo em todos os canais direct-to-consumer (D2C), planejamos a seguir explorar a escala dessa solução para a Ibotta Performance Network (IPN). Isso traria uma descoberta de ofertas aprimorada para mais milhões de compradores em nossa rede de editores. Ao continuarmos a coletar dados rotulados e a refinar nossos modelos por meio da Databricks, acreditamos que estamos bem posicionados para evoluir a experiência de busca juntamente com as necessidades de nossos parceiros e as expectativas de seus clientes.

Essa jornada de um projeto de hackathon para um sistema de produção provou que reimaginar rapidamente uma experiência de produto central é viável com as ferramentas e o suporte certos. A Databricks foi fundamental para nos ajudar a agir rápido, realizar o fine-tuning de forma eficaz e, por fim, tornar cada busca mais recompensadora para nossos Savers.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original