Texto escrito em parceria com Valéria Romano, Gerente Sênior de Produto & Design.

Nos últimos meses, Ailo, nosso AI agent para consumidores deixou de ser apenas um pequeno experimento e vem se tornando um produto com propósito.

Se você perdeu nossos posts anteriores onde contamos sobre como foi o processo de criação desse AI agent, recomendamos que acesse esse e esse artigo antes, lá falamos um pouco sobre o processo e bastidores.

Clayton Christensen, em O Dilema da Inovação, mostra como empresas consolidadas muitas vezes se prendem a melhorias incrementais, enquanto as grandes transformações nascem de experimentos que parecem pequenos no início.

Ailo começou assim, quase invisível, e agora mostra sinais de que pode mudar a forma como as pessoas pedem no iFood.

Este artigo é sobre essa virada: os problemas que resolvemos até agora, os primeiros sinais de product-market fit e, principalmente, como os usuários estão recebendo esse produto.

Primeiros sinais de product market fit

Hoje, Ailo está disponível no aplicativo do iFood em 5 cidades, e no WhatsApp, para qualquer pessoa no Brasil.

O fluxo parece simples: o usuário conversa com o agente, que apresenta um carrossel de itens com base no histórico de pedidos e no contexto da interação. Depois, a jornada segue no app do iFood, na experiência que já existe hoje.

Mas por trás dessa simplicidade, os números chamam atenção: usuários Ailo criam 2x mais carrinhos do que na experiência tradicional do app. Além disso, nossas pesquisas mostram que 80% dos usuários consideram Ailo útil em momentos de indecisão.

“O iFood tem muitas opções, como a Netflix, e o assistente me ajudou a encontrar um caminho mais curto.” — comentário do usuário

E é aqui que mora o coração do nosso produto, garantir que essa tarefa que parece simples, mas que é extremamente complexa nos bastidores, seja feita da melhor forma possível para o usuário.

Dados e pessoas: o coração do produto

A parte mais difícil de construir um recomendador não é o modelo em si, mas a qualidade da base de dados. Nada do que mostramos até aqui seria possível sem a base estruturada do iFood e o LCM, que garante que a intenção do usuário esteja sempre alinhada com as opções de oferta em tempo real.

Mas dados sozinhos não bastam. Ailo é uma via de dois sentidos: aprende com cada interação, melhora a partir do feedback dos usuários e se refina continuamente graças ao trabalho conjunto de pessoas, dados e tecnologia. É nessa combinação que a experiência realmente ganha vida.

“Não me interessei por nenhum dos restaurantes sugeridos. Não havia nenhum restaurante que eu conhecia.” — comentário do usuário.

Ainda estamos aprendendo a equilibrar dois momentos importantes: a exploração de novas opções e o conforto de trazer à tona o que o usuário já conhece e gosta, esse tem sido nosso desafio atual e todo feedback é fundamental!

Latência é o calcanhar de todo agente

Se você trabalha com agents, já deve ter enfrentado o problema de latência. Para quem não conhece: latência é o tempo que o sistema demora para responder depois que você faz uma pergunta. É como quando alguém demora demais para responder numa conversa, a fluidez se perde e a impaciência ganha espaço.

No início, nossa latência chegava a 16 segundos ou mais para gerar resultados, o que compromete bastante a experiência principalmente nos momentos em que o usuário está com fome e possivelmente irritado. Com pesquisas e monitoramento constante, conseguimos identificar essa dor e priorizar melhorias até reduzir o tempo para níveis aceitáveis.

Fizemos dois movimentos importantes:

• Ajustamos o modo como Ailo processa cada mensagem. Pedidos simples, como um “oi”, não disparam buscas profundas, garantindo respostas mais rápidas.
• Tornamos a arquitetura mais dinâmica, mostrando micro-interações durante buscas complexas para que o usuário perceba que Ailo está trabalhando em segundo plano.

Esse equilíbrio trouxe mais naturalidade para a conversa e mais confiança no uso.

O canal molda o comportamento

Outro aprendizado importante foi perceber que o canal influencia diretamente o comportamento.

• No app, menos da metade dos usuários faz mais de uma busca. Isso acontece porque o comparativo é sempre com a experiência tradicional do iFood, construída ao longo dos anos.
• No WhatsApp, o diálogo é mais natural e contínuo, aproximando-se de uma conversa real.

Essas diferenças mostram que não existe “o usuário do Ailo”, existem jornadas distintas, moldadas pelo canal e pelo contexto. Agora estamos explorando novas formas de destacar Ailo dentro da experiência no app, respeitando o comportamento esperado e a jornada atual do iFood.

A magia está na praticidade

Cada vez mais percebemos que Ailo está se tornando um alívio para os usuários ao recomendar de acordo com o perfil e acelerar o processo de compra.
As pessoas não querem “AI”. Elas querem o benefício dela — salvar tempo, economizar dinheiro, resolver um problema.

É o que lembra a icônica frase de Theodore Levitt: “As pessoas não compram brocas, elas compram buracos na parede.”

“Se fosse do zero, talvez fosse diferente. Mas como estava adaptado ao meu perfil, foi fantástico.” — comentário do usuário.

A verdadeira mágica está na praticidade e na sensação de que alguém entende suas necessidades no momento certo.

O que vem a seguir?

Estamos apenas no começo. Mas já temos clareza de algumas direções:

Primeiro, expandir gradualmente disponibilizar o Ailo no app iFood, estamos ansiosos para ver pessoas de diferentes regiões conversando com o Ailo dentro do aplicativo. Enquanto isso, seguimos colhendo feedbacks sobre a experiência no WhatsApp e iterando.

Outra discussão é tornar a personalização ainda mais profunda: estamos explorando novos momentos em que o Ailo pode se encaixar no dia a dia das pessoas, sendo cada vez mais proativo, sempre com cuidado, responsabilidade e segurança.

O produto agents ainda está encontrando seu espaço no mercado, e esse futuro muda o tempo todo. Mas nossa visão é clara:

“Ailo vai entender nossas necessidades na hora certa, com um aprendizado tão rápido que parece mágica, mas é o poder da IA!” — Bruna Faim, product designer do Ailo

“O futuro do Ailo é ser um assistente que entende você tão bem quanto um amigo e antecipa seus desejos.” — Renato R. Ribeiro, Software Engineering do Ailo

“Ailo vai se manifestar de forma multimodal, entendendo o contexto para escolher quando e onde ser mais visual, conversacional ou interativo.” — Camila Gargantini, product designer especialista no Ailo

“O Ailo vai ser como um amigo que sabe o que eu quero e faz o pedido por mim.” — Chiara Caratelli, Data Scientist no Ailo

“O Ailo não é só uma nova forma de pedir comida, mas sim um assistente virtual do iFood que me entende como ninguém.” — João Lippi, Software Engineering do Ailo

“O futuro do Ailo é facilitar minha rotina: planejar meu mercado e refeições, com comando de voz, tudo do meu jeito, sem esforço.” Lucas Mattos, GPM do Ailo

Se no início parecia só mais um experimento, hoje já enxergamos Ailo como parte fundamental do futuro do iFood. E esse futuro está sendo construído a cada conversa, a cada escolha e a cada pedido feito com a ajuda do nosso agent.

👉 Convidamos você a conversar com Ailo no WhatsApp, clique aqui e teste agora!

E seguindo a nossa cultura de colaboração e testes, manda pra gente aqui nesse forms se você encontrar algum problema, proposta de melhoria, ou algo que gostou na experiência.

Até a próxima! 👋

Ailo: de experimento a produto com propósito was originally published in iFood Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

O marketing digital vive um paradoxo: nunca tivemos tantos dados e, ao mesmo tempo, nunca foi tão difícil isolar efeitos causais. Modelos de atribuição tradicionais capturam conversões diretas, mas deixam pontos cegos: campanhas de branding, canais offline, efeitos de longo prazo, efeitos de awareness.

A questão fundamental permanece: como estimar com confiança o impacto incremental de cada canal e decidir onde alocar o próximo milhão?

Este é o relato de como construímos o Bobyn, nosso MMM (Marketing Mix Model) proprietário, e a plataforma que busca democratizar a modelagem de mix de marketing no iFood.

O Problema: Uma Visão de Marketing no Escuro

Antes do Bobyn, tínhamos um problema clássico de inferência causal: medir o ganho incremental de cada canal de marketing nas KPIs de negócio, realizar simulações de investimentos e otimizar a alocação de budget (seja para sessões, pedidos ou outros KPIs). Os desafios eram previsíveis, mas não triviais:

• Dados limitados: Séries temporais diárias ou semanais são curtas para modelos complexos. Como estimar efeitos individuais de 10+ canais com ~365 observações por ano?
• Canais não-rastreáveis: OOH (out-of-home) e campanhas de branding não geram clicks ou conversões diretas. Como atribuir valor a eles?
• Confounders externos: Feriados, sazonalidade, ações da concorrência, eventos externos (Black Friday, Copa do Mundo). Como isolar o efeito real dos nossos investimentos?
• Efeitos de mídia não são instantâneos: Como modelar persistência temporal de awareness e conversão?
• Saturação de canais: Retornos marginais decrescentes são esperados, mas onde está o ponto de inflexão para cada canal?

Por que não usar algo pronto?

Testamos ferramentas open-source conhecidas (Robyn, Meridian) e consultamos soluções de mercado. O problema não era capacidade técnica delas, inclusive, elas são excelentes, mas nosso contexto (múltiplas verticais, KPIs variados, necessidade de controle fino) pedia uma solução mais customizada:

• Flexibilidade: Precisávamos adaptar rapidamente o modelo para diferentes verticais (food, groceries, pharma) e KPIs (sessões, pedidos, GMV)
• Interpretabilidade: Stakeholders de negócio precisavam entender não só os resultados, mas por que o modelo sugeria determinada alocação
• Controle total: Queríamos iterar rápido, testar priors diferentes, adicionar features customizadas sem depender de roadmap externo
• Conhecimento interno: Já tínhamos uma equipe de DS capaz de construir e manter um modelo Bayesiano customizado

A escolha ficou clara: construir nosso próprio MMM nos daria controle, transparência e a capacidade de evoluir o modelo junto com o negócio.

A Solução: Nosso Próprio Modelo Bayesiano e uma Plataforma Self-Service

Com um MMM bem calibrado, conseguiríamos responder perguntas que antes dependiam de intuição ou testes A/B difíceis ou até impossíveis de serem realizados, por exemplo:

• Qual o impacto incremental e ROI de cada canal (online e offline)?
• Como realocar budget para maximizar uma métrica específica (sessões, pedidos, GMV)?
• Onde está o ponto de saturação de cada canal?

A solução envolveu duas frentes: construir um modelo que englobasse os desafios da modelagem e torná-lo acessível para toda a empresa.

1. O Cérebro: Nosso Modelo Bayesiano “Bobyn”

Construir nossa própria solução em Python, usando bibliotecas como o PyMC, nos deu controle total. Optamos por modelagem Bayesiana, porque ela nos permitiu ir além dos números frios:

1. Conhecimento de Especialista no Código: Conseguimos traduzir o conhecimento de negócio em premissas matemáticas (as “prioris” do modelo). Com muitos canais e uma base mais enxuta de dados, priors Bayesianos ajudam a regularizar o modelo incorporando conhecimento de domínio, facilitando o aprendizado. Assim, oferecemos “dicas” para o modelo, por exemplo: anúncios de TV têm mais efeito prolongado que canais digitais.
2. Flexibilidade para o Mundo Real: Modelamos efeitos complexos como a saturação (a curva de retornos decrescentes) e o carryover (o impacto residual de uma campanha ao longo do tempo), tornando as previsões muito mais realistas.

• TV tem efeito mais prolongado que search → prior de decay mais suave
• Digital satura mais rápido que OOH → prior de saturação mais agressivo
• Efeitos não podem ser negativos → distribuição LogNormal

É importante notar que nosso objetivo não é enviesar arbitrariamente — é traduzir conhecimento de marketing em matemática.

Estrutura simplificada do modelo:

$$ Y_t = baseline_t + Σ (saturação(adstock(spend_canal_i))) + efeitos_t $$

onde:

• baseline_t = tendência + sazonalidade + eventos
• adstock = carryover temporal (geometric decay)
• saturação = Hill transform (retornos decrescentes)

2. O Corpo: A Plataforma de Democratização

Um modelo brilhante nas mãos de poucos tem impacto limitado. Por isso, criamos uma plataforma interna que permite que qualquer analista de negócio crie seu próprio MMM de forma simples e rápida, adicionando conhecimento operacionais de forma simples.

O que a plataforma faz?

• Democratiza o acesso: Qualquer área pode criar, rodar e interpretar modelos sofisticados facilmente, além de configurar prioris de efeito prolongado e saturação.
• Integra o Bobyn: Nosso modelo exclusivo já está integrado, garantindo a qualidade e a consistência das análises.
• Permite simular e otimizar o futuro: Com a ferramenta de otimização e simulação, os times podem responder a perguntas como “o que acontece se…” e tomar decisões mais inteligentes sobre o orçamento.
• Libera nossos Cientistas de Dados: Com a plataforma cuidando da execução, nosso time de DS pode focar no que faz de melhor: evoluir o modelo e atuar como suporte estratégico.
• GenPlat como apoio em insights: Nossa plataforma de LLM traduz e resume os insights, além de responder dúvidas específicas baseadas nos resultados.

Benefício não-planejado

A plataforma simplifica a criação de modelos, mas não elimina a necessidade de conhecimento técnico — e isso é proposital. Sempre que um novo time se interessa, buscamos fazer um onboarding completo: explicamos a metodologia, de onde vêm os números e como interpretar intervalos de credibilidade.

Esse processo virou parte essencial do produto. Percebemos que a confiança nos resultados não vem só da acurácia do modelo, mas de stakeholders entenderem por que o modelo sugere determinada alocação. A plataforma facilita a experimentação, mas o aprendizado técnico continua sendo necessário — e desejado.

O Impacto: Da Incerteza à Decisão Estratégica

O resultado é uma solução robusta que está se expandindo por toda a empresa, muito além do time de marketing. Tornou-se uma ferramenta estratégica de planejamento.

Um dos grandes apoiadores do projeto foi o time de Branding, que tem buscado ser cada vez mais Data-Driven para tomar decisões de investimento Historicamente, a área tem altos investimentos em mídia offline, logo a grande dor sempre foi: estamos investindo demais ou de menos? Mais ainda, estamos investindo corretamente?

Usando o otimizador e o simulador de cenários da nossa plataforma, o time conseguiu ter respostas para essas dúvidas, o que permitiu gerar e testar novas alocações de orçamento entre os canais, sem comprometer um único real do plano.

O resultado? Em Setembro, o time conseguiu reduzir o investimento em 2% — um número bem expressivo no absoluto — em alguns canais saturados mantendo o volume total de sessões.

O Próximo Capítulo da Mensuração

Construir o Bobyn foi desafiador, mas valeu a pena. Ter controle total sobre o modelo significa que podemos iterar rápido, adicionar features customizadas e, principalmente, explicar para stakeholders exatamente de onde vêm as recomendações.

E este é só o começo. Já estamos explorando os próximas desafios:

Integração com experimentação

Estamos calibrando o MMM com resultados de testes de geolift. A ideia é usar a incrementalidade medida via experimentos para sugerir as distribuições priors, criando um ciclo de validação entre metodologias.

2. Atribuição digital como input

Ao longo desses últimos meses, também aprimoramos nossos modelos de atribuição (MTA), assim, o próximo passo é usar as distribuições dos modelos de MTA para informar as priors dos canais digitais no MMM. Essa abordagem é especialmente útil para canais com baixo volume de dados históricos.

Lições aprendidas:

Build vs buy não é binário: Ferramentas como Robyn (Meta) e Meridian (Google) são excelentes e resolvem bem para muitos casos. Mas nosso contexto — múltiplas verticais (food, groceries, pharma), KPIs variados (sessões, pedidos, GMV, ROI), necessidade de iterar rápido — pedia customização profunda.

• A decisão não foi “criar tudo do zero”. Usamos PyMC-Marketing como base e construímos em cima. O ganho real veio da flexibilidade: quando o time de CRM pediu para incluir push notifications como “canal”, ajustamos o modelo em 2 semanas. Com ferramenta terceirizada, isso seria roadmap de trimestre.
• Atenção: bibliotecas abertas exigem conhecimento sólido de teoria Bayesiana e do código base. Não é “plug and play” — você precisa entender o que está acontecendo sob o capô.

Interpretação > acurácia: Stakeholders confiaram no modelo não somente porque ele tinha métricas boas, mas porque entenderam a lógica por trás. A transparência venceu a complexidade.

É importante investir tanto tempo em visualizações e explicações, quanto em tuning de priors. Os gráficos de contribuição, saturação e simulações interativas geraram mais confiança que um diagnóstico de modelo perfeito.

Self-service tem limite: A plataforma acelerou a adoção, mas o onboarding técnico continua essencial. Não queremos criar modelos mal configurados, porque isso gera decisões ruins.

—

Sobre nós

Prazer, nós somos o time de MediaLab no iFood! Nosso trabalho é construir ferramentas de dados que ajudam os times de mídia, branding e CRM a tomarem decisões melhores: do Bobyn (MMM) a agentes LLM para hiper personalização de notificações.

Se você trabalha com marketing analytics, experimentação ou modelagem Bayesiana e quer trocar ideias, chama a gente no LinkedIn ou comenta aqui embaixo!

→ Quer fazer parte do time de Tecnologia do iFood? Acesse nossas vagas em carreiras.ifood.com.br

Repensando a Mensuração: Como nosso MMM Proprietário aprimorou nossa visão de Mídia was originally published in iFood Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

No iFood, os dados direcionam as tomadas de decisões em todas as instâncias e no momento de definir as promoções de um item, não é diferente.

Você já deve ter se deparado com uma promoção quando abriu o App do Ifood. Esses descontos não são definidos aleatoriamente, eles são pensados para causar o maior engajamento possível e a melhor alocação de recursos, de forma a maximizar a conversão de nossos clientes.

Nesse artigo exploramos o conceito de elasticidade de preço x demanda e sua aplicação para definição de investimentos do iFood em subsídio de promoções.

Para os casos de Mercado, Atacado e Farmácia, desenvolvemos um modelo de elasticidade de subsídios que define o ponto ótimo de desconto de cada produto.

O que é elasticidade de preços e subsídios

Um modelo de elasticidade de preço busca determinar a sensibilidade da demanda de um produto em relação ao seu preço, de forma que é esperado que, quanto menor o preço do produto, maior será sua procura e vice-versa.

Quando falamos de elasticidade de produto em relação aos subsídios ou promoções, esperamos um comportamento inverso: quanto mais subsidiado (dinheiro aplicado à promoção) estiver um produto, maior será sua demanda, já que o preço será reduzido.

O gráfico acima demonstra uma relação teórica de elasticidade de demanda ao preço para um produto elástico. Quando o preço do produto é de 4 unidades monetárias, 60 unidades do produto são demandadas, já quando o preço é de 8 unidades monetárias, somente 20 unidades do produto são demandadas.

Em geral, a elasticidade da demanda em relação ao preço não é constante e nem linear ao longo do tempo e da variação de preço, contudo é possível fazer boas aproximações lineares dessa medida.

Outro ponto a se destacar é que nem todo produto apresentará uma variação de sua demanda conforme os preços se alteram: Esses são os chamados produtos inelásticos.

No iFood adotamos a notação elasticidade do Gross Merchandise Value (GMV) em relação ao subsídio, com uma relação teórica apresentada no gráfico abaixo:

Nesse gráfico notamos que, conforme o subsídio de um produto aumenta, maior é o seu GMV, ou seja, mais desse produto é vendido. Contudo, essa relação não é linear e atinge um platô após um dado valor. Isso ocorre porque, independentemente do subsídio, a demanda pelo produto não aumenta. Isso pode acontecer porque os clientes deixam de identificar uma diferença no valor do produto, porque o mercado já está saturado ou ainda devido a algum outro fator latente.

Métodos comuns para cálculo de elasticidade

Existem muitos métodos conhecidos para cálculo da elasticidade.

Elasticidade entre dois pontos:

Um método muito comum utilizado na econometria é o da elasticidade entre 2 pontos, calculado pela variação percentual da demanda dividido pelas variação percentual do preço:

Esse método apesar de simples e útil apresenta um problema de simetria, pois uma variação de mesmo módulo apresenta elasticidades diferentes se for positiva ou negativa conforme exemplificado abaixo:

Ao calcular a elasticidade do ponto A para o ponto B e do ponto B para o ponto A, obtemos os seguintes valores:

Note que a mesma variação de preço e demanda apresenta elasticidades diferentes a depender da direção em que calculamos essa grandeza.

Elasticidade do ponto médio

Esse método é muito similar a elasticidade entre dois pontos, porém resolve o problema da assimetria ao realizar a divisão de cada medida pelo seu ponto médio:

Nessa equação Q1 e Q2 são as quantidades vendidas pelos preços P1 e P2 respectivamente.

Outros métodos possíveis

Existem diversos outros métodos que podem ser aplicados para se calcular a elasticidade da demanda em relação ao preço do produto:

• Regressão Log-Log (A depender a distribuição da demanda vs preço)
• Métodos de ensemble (Trabalham bem com o problema de multicolinearidade)
• Métodos de Machine Learning (Robustos, porém requerem muitos dados)

Cuidados a serem tomados

Apesar de ser relativamente simples de se medir a elasticidade de um produto, devemos observar algumas premissas para não incorrer em erros de medição e interpretação. Por exemplo, um produto pode apresentar variações sazonais em sua demanda: Um sorvete tende a ser muito mais demandado em dias quentes mesmo que seu preço seja superior ao apresentado em dias frios.

Outro ponto importante é a geografia: Em um país de dimensões continentais como o Brasil, podemos observar preferências por um dado produto em uma região que não se refletem em outra. Essa diferença regional pode nos levar à uma medida pouco significativa da elasticidade geral do produto, quando poderíamos ser mais assertivos ao regionalizar a análise.

O crescimento orgânico de um produto também deve ser levado em consideração. Muitas vezes a variação da demanda do produto não se deve diretamente à variação do preço, mas a popularidade que o produto vem ganhando ou até mesmo pelo aumento orgânico de clientes em nosso APP.

Método adotado pelo iFood

Uma forma de mitigar os problemas relatados na sessão anterior é realizar um teste A/B controlado, em que é possível garantir a medição de demanda e preço sob as mesmas condições sem interferências sazonais, submetendo nossos usuários às mesmas condições. Entretanto, além de ser um processo mais caro e demorado, nem sempre existem condições para a realização de um teste A/B. Neste caso, lançamos mão de técnicas de análises sobre dados históricos

Premissas adotadas para a modelagem

Antes de modelar a elasticidade de subsídios com base em dados históricos, precisamos definir algumas premissas:

1. Os resultados da elasticidade deveriam ser facilmente interpretáveis pelas áreas de negócio, de forma que um score não seria suficiente.
2. O iFood atua com mercados, farmácias, atacadistas, restaurantes, … e vários desses segmentos vendem o mesmo produto, contudo suas demandas e consequentemente sua elasticidade é diferente.
3. Dados históricos podem sofrer alteração de preço e demanda por sazonalidade de produtos, inflação de preços, estratégias de venda de fornecedores e diversos outros fatores não controláveis. Isso posto, deveríamos buscar mitigar a maioria desses problemas em nossa modelagem.

Com base nas premissas apresentadas, nas análises dos dados notou-se que a utilização de um modelo multinível de regressão linear por partes seria adequado para responder às demandas de negócio.

Ao utilizar o coeficiente angular da reta ou o 𝛃 da variável de subsídio como indicativo da elasticidade do produto, obtemos uma interpretabilidade do tipo: Para cada X reais investidos em subsídios, obtemos um retorno de Y reais em GMV.

Para os níveis da regressão utilizamos uma divisão do que chamamos de agressividade (percentual de desconto aplicado sobre os produtos). Na imagem abaixo podemos verificar como isso impacta as predições. A esquerda temos o dado de GMV vs Subsídio investido sem a separação do dado por níveis apresentando uma dispersão e uma heteroscedasticidade muito proeminente. Já na imagem da direita temos o mesmo dado separado em cores por níveis de agressividade de desconto. Isso já reduz muito a dispersão do dado dentro de um mesmo nível, porém em alguns casos ainda mantém a heterocedasticidade quando observamos o GMV apenas em relação.

Para reduzir o efeito de heterocedasticidade além dos efeitos sazonais, adicionamos outras variáveis de controle do GMV à regressão, tais como crescimento orgânico do produto, crescimento orgânico de usuários da plataforma, entre outras.

Para reduzir o efeito inflacionário dos preços ao longo do tempo, utilizamos a propriedade de igualdade da equação linear para regredir a quantidade de unidades do item vendido pelo subsídio para depois retornar a equação para GMV, que era nossa variável de interesse.

quantidade vendida = 𝛽*[matriz de feature]

preço atual do item*quantidade vendida =preço atual do item* 𝛽*[matriz de feature]

Ao multiplicar ambos os lados da igualdade preço do item, ainda é possível manter a interpretabilidade dos 𝛃s da equação, que nesse caso é o fator de interesse para a elasticidade.

Resultados

Para validar os os resultados obtidos por essa modelagem, realizamos testes controlados atribuindo os descontos sugeridos pelo modelo à alguns produtos e avaliando seu comportamento. Esses produtos foram divididos em 2 grupos:

1. Produtos que estavam com promoções muito agressivas, porém o modelo não indicava elasticidade significativa. Para esses itens, removemos a promoção com a expectativa de que não houvesse queda no consumo.
2. Produtos sem promoção ou com pouca agressividade que o modelo indicava como altamente elásticos. Para esses produtos, aplicamos a promoção sugerida pelo modelo com a expectativa de que houvesse aumento no consumo dos produtos na ordem indicada pelo modelo.

Para o grupo 1, em que as promoções foram removidas, notamos uma leve variação dentro da margem de erro esperada, de forma que mesmo sem as promoções, pudemos considerar os produtos como inelásticos, sem variação significativa no consumo dos itens.

Para os produtos do grupo 2 tivemos um significativo aumento do consumo, com cerca de 26% de aumento de GMV e 45% de aumento no número de pedidos. Esse aumento veio acompanhado de um leve aumento no custo da operação, dado que mais subsídios eram destinados à esses produtos, porém esse aumento do custo foi ínfimo frente ao aumento de GMV.

Dessa forma pudemos comprovar que a modelagem escolhida, além de possuir interpretação simplificada, gerou resultados positivos e significativos no consumo dos produtos, permitindo que o iFood direcione melhor seus recursos.

Oportunidades de melhoria

Uma oportunidade de melhoria que deve ser observada é o tratamento de hidden feedback loops: Ao sugerir descontos em itens específicos, direcionamos mais recursos para eles. Isso reforça o comportamento de compra e retroalimenta o modelo de elasticidade, gerando maior confiança nas previsões e aumento na alocação de recursos… Levando à um comportamento de loop em que passamos a operar somente sobre um grupo fechado de itens e perdemos oportunidades em outros.

Elasticidade de subsídios: Como determinar a promoção ideal em mercados was originally published in iFood Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

por Bel Araújo, Diretora de Produto & Design no iFood

Sonhar grande sempre foi parte da nossa essência. Mas no iFood, sonho e entrega caminham juntos. Nosso desafio é transformar ideias em impacto real, equilibrando visão, dados, design e execução. É assim que criamos produtos que resolvem problemas de verdade e experiências que fazem sentido para milhões de pessoas.

O nosso jeito de fazer Produto e Design é o reflexo de uma cultura que acredita que inovação nasce da prática. A gente mira no futuro, mas começa com entregas reais e mensuráveis. Somos curiosos, mas também práticos. Sabemos que excelência não é uma meta distante, é o ponto de partida.

Esses princípios nos inspiram todos os dias e traduzem como criamos, colaboramos e evoluímos. Eles representam uma forma de pensar que une propósito e entrega, estratégia e empatia, resultado e aprendizado contínuo.

Produto com alma de negócio

Fazer produto com alma de negócio é criar soluções que geram resultado e sustentabilidade sem perder de vista o usuário final. Negócio e experiência andam juntos, e um não prospera sem o outro. Por isso, antes de cada entrega, nos perguntamos qual valor real estamos oferecendo para quem usa e para o negócio que sustentamos.

Sonhar grande e começar pequeno é uma das nossas formas de garantir impacto. Validamos hipóteses, aprendemos com dados e ajustamos o caminho sem medo de mudar. Decisões aqui não se baseiam em achismos, mas em fatos. É assim que conseguimos evoluir rápido e com consistência.

Fazer produto também é ir além da tela. Mergulhamos no contexto do usuário, testamos, ouvimos e iteramos. Acompanhamos de perto o impacto das soluções que criamos e ajustamos o percurso sempre que necessário.

E, claro, construímos pontes. Entre áreas, tecnologias e pessoas. Entendemos o ecossistema em que atuamos e conectamos quem precisa estar junto para fazer as coisas acontecerem. Acreditamos que boas ideias ganham força quando ultrapassam fronteiras e são compartilhadas.

Por fim, fazemos produto com alma de negócio porque sabemos que performance e propósito caminham juntos. Sabemos qual ponteiro mover, o que eliminar e onde colocar energia. O foco é gerar impacto real e levar o iFood sempre mais longe.

Design como ponte entre emoção e resultado

No iFood, design é verbo. É ação, empatia e estratégia. Não é sobre interface, é sobre entendimento. Cada projeto começa unindo forma e função, emoção e lógica, para criar experiências que inspiram confiança e refletem quem somos.

Nosso olhar é humano, mas também analítico. Não aceitamos suposições automáticas. Questionamos, investigamos e tomamos decisões com base em dados, conectando o olhar empático do design com métodos quantitativos e qualitativos. Traduzimos números em oportunidades reais.

Design também é sobre vivência. A gente se coloca no lugar das pessoas, entende suas rotinas, emoções e desafios. Buscamos reduzir atritos e projetar soluções que simplifiquem o cotidiano. Por isso, equilibramos descoberta e entrega, acompanhando o resultado após cada implementação. O trabalho não termina no handoff, ele continua com o aprendizado que vem do uso.

Com uma visão sistêmica da experiência, desenhamos jornadas que consideram impacto em todas as áreas. Rompemos silos, integramos times e impulsionamos discussões estratégicas. Design não se constrói sozinho, ele é coletivo.

E mais do que isso: entendemos a língua do negócio. Sabemos quais métricas importam, comunicamos decisões com clareza e traduzimos necessidades de usuários em ações que movem resultados. Design é uma ponte entre pessoas, tecnologia e estratégia.

Um só jeito de criar impacto

O Jeito iFood de fazer Produto e Design é o equilíbrio entre sonho e execução, empatia e dados, propósito e entrega. É a união de mentes criativas e analíticas trabalhando juntas, com autonomia, colaboração e coragem para testar, errar, aprender e acertar mais rápido.

Essa forma de trabalhar é o que nos trouxe até aqui. Recentemente, fomos reconhecidos pela PM3, principal escola de Produto Digital da América Latina, pelo segundo ano consecutivo como uma das empresas mais admiradas em Tecnologia e Produto no Brasil. Esse reconhecimento reforça o que vivemos todos os dias: excelência não é um destino, é um hábito. É resultado de um time que conecta estratégia, design e tecnologia para gerar valor real.

O que fazemos vai muito além de telas, fluxos e jornadas. É sobre entender pessoas, contextos e comportamentos. É sobre transformar ideias em soluções que facilitam a vida, impulsionam negócios e moldam o presente e se tornam referência em construir futuros.

No iFood, essa é a nossa entrega. E ela nunca para no delivery.

→ Quer trabalhar com Produto & Design no iFood? Acesse nossas vagas em carreiras.ifood.com.br

De ideias a impacto: o Jeito iFood de fazer Produto & Design was originally published in iFood Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Texto escrito em parceria com a Isabella Piratininga, Diretora de Tecnologia e Inovação, e Valéria Romano, Gerente Sênior de Produto & Design.

Construindo a partir do desconhecido

Quando Eric Ries escreveu “The Lean Startup”, ele nos ensinou que “o único jeito de vencer, é aprender mais rápido que qualquer outra pessoa”. Nossa jornada construindo o Assistente de IA do iFood é a personificação viva desse princípio. Em um mundo onde até o Vale do Silício ainda tateia no escuro tentando entender como integrar LLMs* ao cotidiano das pessoas, decidimos abraçar a incerteza como nossa maior aliada.

*LLM large language model, é como conversar com alguém que já leu praticamente toda a biblioteca do mundo e consegue improvisar respostas novas a partir desse conhecimento.

O Ciclo Construir-Medir-Aprender em Velocidade Máxima

Nossa história começou antes mesmo do ChatGPT existir, éramos como exploradores em uma mata completamente fechada. Começamos com um bot simples de árvore de decisão no WhatsApp, permitindo pedidos em restaurantes específicos. Era nossa primeira hipótese, nosso primeiro MVP.

Resultado? Pivotamos.

Como Clayton Christensen descreve em “O Dilema da Inovação”, tecnologias verdadeiramente disruptivas começam simples, quase primitivas. Nosso segundo experimento focou em recomendações básicas de restaurantes e pratos. A IA ainda engatinhava e a qualidade não estava onde queríamos.

Hoje, após menos de 3 meses de desenvolvimento intensivo (mesmo), temos um assistente que entende contextos complexos através de um linguagem natural. Você pode mandar um áudio de 5 minutos contando sobre seu dia cansativo, digitar apenas “Oi”, ou descrever detalhadamente suas restrições alimentares, que ele vai te guiar naturalmente até encontrar exatamente o que você precisa, economizando tempo e dinheiro.

E mesmo após as pivotadas, ainda podemos melhorar, e isso é perfeitamente normal. Cada dia é uma nova iteração, um novo aprendizado, uma nova versão melhor que a anterior.

Sobre a importância de falhar: Nossa “Moment of Truth”

🍔O hamburguer das 5 da manhã

Às 5h da manhã, horário de Brasília, nosso time de desenvolvimento estava em plantão acompanhando uma demonstração crucial para investidores internacionais. O plano era elegante em sua simplicidade: mostrar recomendações personalizadas a partir de uma única palavra-chave, usada como busca pelo nosso VP de AI.

A realidade tinha outros planos.

No palco europeu, onde já era quase meio-dia, nosso usuário pediu um hambúrguer. Fazia todo sentido para ele,mas naquele horário no Brasil, só existia uma única hamburgueria aberta no endereço que ele estava buscando, como em um momento anterior a apresentação o apresentador já havia executado uma busca o agente entendeu que ele não havia gostado do único hambúrguer disponível na região e foi tentar executar uma nova pesquisa e aí, por um pequeno erro de classificação de taxonomia em nosso catálogo, o agente apresentou um COOKIE. O agente não achou oferta, ele é não determinístico e isso fez com que a todo custo ele procurasse uma solução e neste momento, não entregamos o melhor — ao vivo e erramos!

Este momento, transmitido ao vivo, foi nosso “Eat Your Own Dog Food” mais valioso.

Como Steve Blank ensina, “saia do prédio”, ou no nosso caso, saia da sua bolha de desenvolvimento. Esse erro público nos forçou a abraçar verdadeiramente nosso mantra interno: “Eat Your Own Dog Food” — use obsessivamente seu próprio produto em todas as situações imagináveis.

A Redenção no Palco

Semanas depois, no maior evento de restaurantes da América Latina, tivemos nossa chance de redenção. Nosso CEO, rejeitando qualquer roteiro, testou o assistente ao vivo com perguntas não ensaiadas:

• “O que você sabe sobre mim?”
• “Me recomende algo para agora”
• “Tem guardanapo?”

A resposta sobre guardanapos nos surpreendeu: “Normalmente os restaurantes que entregam pelo iFood já incluem guardanapos no pedido, mas isso pode variar dependendo do estabelecimento.”

Nunca havíamos treinado especificamente para isso. Foi a validação de que estávamos criando algo genuinamente inteligente, não apenas um sistema de respostas programadas. A inovação disruptiva havia encontrado seu product-market fit inicial.

Do Zero aos Primeiros Usuários: A Importância dos Early Adopters

Geoffrey Moore, em “Crossing the Chasm”, nos ensina sobre a importância dos early adopters. Saímos de zero para para um incremento de 40% na nova experiência vs a busca padrão do app, seguindo religiosamente o princípio de co-criação com usuários reais..

Como garantir que o produto está certo? que ele está fazendo sentido? que as respostas que podem variar individualmente são relevantes?

Foi com essas dúvidas que voltamos ao básico da construção de produto: estar sempre em contato com o usuário.

Criamos grupos no WhatsApp com amigos próximos, pessoas da comunidade iFood (inclusive se você quer participar de grupos como esse, venha ser parte da nossa comunidade se inscreve aqui). Esse grupo nos ajudou a mapear problemas da experiência, avaliar recomendações, encontrar bugs.

O aprendizado crucial? Deveríamos ter feito isso desde o dia zero, mesmo sem produto. Quando finalmente implementamos, os insights coletados reformularam 100% da arquitetura do nosso produto.

Como Ries enfatiza: “Se você não está envergonhado da primeira versão do seu produto, você demorou demais para lançar.”

O que aprendemos até aqui:

1. O contexto é Rei

Não basta recomendar, é preciso entender o momento, o horário, o humor, a história. Um hambúrguer às 5h pode ser jantar para alguém que trabalhou a noite toda ou café da manhã de alguém que chegou da balada :)

Como já defendem Erika Hall e Cathy Pearl, duas das principais referências em design conversacional, projetar agentes não é só “escrever respostas”: é pensar em tom, contexto, recuperação de falhas e expectativas realistas.

2. Velocidade de Iteração Como Vantagem Competitiva

Cada erro vira ajuste em horas, não semanas. Esta é nossa vantagem disruptiva, enquanto grandes corporações demoram meses para aprovar mudanças, nós iteramos diariamente.

3. Confiança Através da Transparência

O usuário precisa sentir que o assistente é um aliado confiável, não uma caixa preta misteriosa. Transparência gera confiança, confiança gera adoção. E mais importante, que o pode de decisão assim como a sua autonomia final, não é substituída pelo agente sem a sua permissão.

4. Tecnologia é Apenas 50% da Equação

A outra metade é a experiência humana: simples, natural, disponível. Como Jobs dizia, “tecnologia sozinha não é suficiente — é tecnologia casada com humanidade, que nos traz resultados que fazem nosso emocional se conectar com o produto.

O Paradoxo da IA: Nunca Está Pronto, Sempre Está Evoluindo

Aqui está nossa maior epifania, alinhada com os princípios do Lean Startup: não existe produto de IA “pronto”. Existe uma relação em constante evolução com quem usa.

Cada conversa é um dado, cada interação é um aprendizado, cada dia o produto é diferente de ontem. É o ultimate continuous deployment — não apenas de código, mas de inteligência.

O Futuro é Colaborativo

Clayton Christensen nos ensinou que inovações disruptivas começam servindo mercados negligenciados ou criando mercados totalmente novos. Nosso assistente não compete com o app tradicional do iFood — ele cria uma nova categoria de interação, uma nova forma de pensar sobre pedir comida.

E esse produto, cadê?

O produto está em constante evolução, mas você pode começar a testar agora a versão no nosso WhatsApp, clique aqui e teste agora!

E seguindo a nossa cultura de colaboração e testes, manda pra gente aqui nesse forms se você encontrar algum problema, proposta de melhoria, ou algo que gostou na experiência.

A Jornada Continua

Como Eric Ries nos lembra: “O sucesso não é entregar um recurso; sucesso é aprender como resolver o problema do cliente.”

Estamos apenas no início. Cada pivô nos aproximou mais da verdadeira necessidade dos usuários. Cada erro público nos tornou mais resilientes. Cada feedback nos tornou mais resilientes em nosso propósito.

A verdadeira disrupção não está na tecnologia em si, mas em como ela se entrelaça naturalmente no cotidiano das pessoas, tornando o complexo simples, o demorado instantâneo, o caro acessível.

E você, o que gostaria de ver nos próximos capítulos dessa jornada?

“The biggest risk is not taking any risk.” — Peter Thiel

E no nosso caso: “O maior risco é não ouvir quem usa.”

IA do iFood: os bastidores da construção do produto was originally published in iFood Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Texto escrito em parceria com a Isabella Piratininga, Diretora de Tecnologia e Inovação, e Valéria Romano, Gerente Sênior de Produto & Design.

“Fazer um pedido no iFood deveria ser como conversar com alguém que realmente entende o que você quer, tornando cada pedido pessoal e descomplicado.”

Foi com esse princípio que começamos a construir nosso agente de IA, uma experiência capaz de entender o contexto do usuário, raciocinar em várias etapas, agir em sistemas internos e entregar o resultado certo, no momento certo, sem você precisar se preocupar com o “como”.

Mas antes de abrirmos os bastidores, vale alinhar alguns conceitos importantes e explicar o que é um agente.

Agente de IA ≠ Chatbot

No nosso time isso é quase regra de convivência: quando alguém solta “bot”, sempre rola uma bronca (amistosa 😅). E há bons motivos:

Chatbots tradicionais são reativos: recebem uma pergunta, buscam em uma árvore de respostas e devolvem algo pronto.

Agentes de IA são proativos: recebem um objetivo, planejam, testam, aprendem e iteram sozinhos até atingir o resultado. É como trocar um FAQ engessado por um estagiário dedicado que:

1. Entende a tarefa
2. Formula um plano
3. Busca os dados certos
4. Age, avalia, ajusta
5. Entrega a melhor solução

Por que isso é relevante agora?

🚀 Explosão de uso — Empresas como Microsoft, Meta e Amazon citam agentes em praticamente toda apresentação estratégica.

📊 Resultados concretos — H&M viu +25 % de conversão; Bank of America ultrapassou 1 bi de interações com “Erica”; fabricantes como Toyota poupam milhares de horas/ano em otimizações de linha.

✅ Mudança de paradigma — De interfaces click-by-click para experiências orientadas a objetivos (Goal-oriented UX).

O elefante na sala: confiança

Agora vem a parte mais interessante (e desafiadora): por que essa revolução ainda não chegou em todo lugar?

A resposta é simples: confiança.

Pense comigo: você delegaria uma decisão financeira importante para um sistema sem nenhuma revisão? Ainda existe (e é natural!) uma hesitação em entregar decisões críticas para agentes autônomos.

Na prática, a maioria das empresas (incluindo a nossa) ainda trabalha com dupla checagem: o agente executa, humanos validam o resultado — que no nosso cenário por ser próprio usuário — e, com o tempo, a confiança cresce. Porque ao invés de passar pelo paradoxo da escolha, o usuário recebe em segundos opções que lhe agradam, por exemplo, um vegetariano não precisa passar por um monte de pratos de carne até achar as opções que se adequam a sua dieta. É como aprender a dirigir com alguém experiente ao lado, até estar pronto para ir sozinho.

Adotar agentes não é só uma decisão tecnológica. É uma jornada de maturidade organizacional que envolve mudança de mentalidade, governança robusta, integração com sistemas legados e cultura de experimentação.

Como a gente faz no iFood (não é magia, é processo)

1. Times cross-funcionais na mesma sala virtual pois estamos remotos
   Design, engenharia, dados e produto sentam juntos quase que diariamente, para discutir experiência e arquitetura usando a mesma linguagem. Essa proximidade encurta ciclos de decisão, evita ruídos e permite que ajustes sejam feitos na hora, enquanto a ideia ainda está quente.
2. Hipóteses claras, métricas objetivas
   Nada de testar “por testar”. Cada sprint começa com uma pergunta simples: o que queremos aprender? Definimos hipóteses específicas, JTBD claros e métricas enxutas para medir se o comportamento do agente está evoluindo.
3. Testes com usuários reais
   Antes de lançar para todo mundo, colocamos o agente nas mãos de grupos-piloto no que enviam feedbacks quase que em tempo real através de grupos de WhatsApp. O retorno chega de forma transparente , com mensagens, áudios, prints — e tudo é registrado no nosso Jira, para ser discutido e priorizado.
4. Aprendizado contínuo
   Cada conversa que não sai como esperado é tratada como um estudo de caso. Investigamos por que falhou: foi o prompt? o fluxo? faltou dado? A partir disso, ajustamos e colocamos novamente para rodar, fechando um ciclo constante de evolução.

E agora?

Este artigo inaugura nossa série sobre como estamos revolucionando a forma como você pede no iFood com agentes de IA. Vamos trazer de tudo um pouco: aprendizados, frameworks, bastidores e evoluções do nosso produto.

E já que essa é uma jornada colaborativa, conta aí nos comentários: o que você gostaria de ver nos próximos capítulos?

👀 ah, um spoiler do que vem pela frente…

AI Agents no iFood: o que são, por que importam e como estamos aprendendo na prática? was originally published in iFood Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

O iFood se destaca como uma organização data-driven, onde os desenvolvimentos de produtos e as tomadas de decisões estratégicas são fundamentadas em dados. Para sustentar esse padrão de excelência, é essencial proporcionar aos engenheiros, analistas e cientistas a autonomia necessária para criar e gerenciar suas próprias soluções, promovendo assim uma cultura de inovação e autogestão analítica.

Com esta liberdade, surgem desafios interessantes como o de lidar com a produção e gestão de dados redundantes. Sem um monitoramento eficaz das tabelas do Data Lake (DL), este problema pode resultar em custos desnecessários de processamento e armazenamento, além de aumentar a complexidade do parque de dados.

Na tentativa de identificar e mitigar estas ineficiências, buscamos na literatura algumas possibilidades e acabamos adotando e adaptando o algoritmo proposto por Raunak Shah et al. no artigo “R2D2: Reducing Redundancy and Duplication in Data Lakes”. O trabalho traz uma abordagem inovadora e principalmente barata, do ponto de vista computacional, a qual constrói e refina grafos relacionais entre datasets para identificar tabelas com dados potencialmente redundantes, destacando oportunidades de ganho e simplificação do ambiente de dados corporativo.

Qual foi o ponto de partida?

O algoritmo original é composto pelo encadeamento de três etapas capazes de entregar, como produto final, um mapa de relações entre pares de tabelas cujos dados são potencialmente duplicados. A cada etapa aplicada, seu resultado serve de insumo para a próxima, a qual refina e entrega um conjunto de pares de tabelas mais assertivo que aquele obtido pela etapa anterior. Resumidamente, as etapas são:

➢ Etapa “Schema Graph Builder (SGB)” — Este componente basicamente compara schemas entre tabelas colunares e determina quais são aqueles coincidentes ou que possuem alguma relação de contenção. Por exemplo, se uma tabela A possui todas as colunas da tabela B, isto pode indicar que A contém potencialmente todos os dados de B, tornando B uma fonte de informações duplicadas (portanto, sem necessidade de existência). E estas relações são representadas em forma de grafo.

O SGB utiliza uma abordagem inteligente de clustering para evitar comparações custosas O(N²) entre todas as tabelas. O algoritmo funciona da seguinte forma:

1. Ordenação: As tabelas são ordenadas por cardinalidade de schema (número de colunas) em ordem decrescente;

2. Formação de clusters: Percorre-se a lista ordenada e, para cada schema:

• Se não está contido em nenhum cluster existente → torna-se um novo centro de cluster;
• Se está contido em algum cluster → é adicionado como membro deste cluster;

3. Construção do grafo: Dentro de cada cluster, são criadas arestas direcionadas entre pares de tabelas onde existe contenção real, sempre apontando da tabela maior para a menor.

Esta estratégia garante que nenhuma relação de contenção seja perdida, enquanto mantém a complexidade computacional em O(N log N) + O(K(N-K)), onde K é o número de clusters formados — muito mais eficiente que a abordagem de comparar todas as tabelas entre si.

➢ Etapa “Min-Max Pruning (MMP)” — Após a criação do grafo, remove-se algumas conexões (filtragem) com base nos valores mínimos e máximos entre colunas comuns do tipo numéricas. O princípio aplicado é que, se um conjunto de dados A está contido em B, para todas as colunas comuns numéricas, então:

1. O valor mínimo na coluna de A deve ser maior ou igual ao valor mínimo na coluna de B.

2. O valor máximo na coluna de A deve ser menor ou igual ao valor máximo na coluna de B.

Se alguma destas condições for violada, o algoritmo MMP remove a conexão entre os conjuntos de dados no grafo, indicando que a contenção não é possível.

➢ Etapa “Content Level Pruning (CLP)” — Nesta fase, o algoritmo ajusta as relações nos grafos (nova filtragem) examinando os dados das tabelas em si, em nível granular de linha.

O CLP utiliza técnicas de amostragem para decidir se as conexões (ou relacionamentos de contenção potenciais entre datasets) devem ser mantidas ou excluídas. Se o conjunto A está totalmente contido em B, esta relação de contenção deve ser válida mesmo para subconjuntos amostrados de A. Ao consultar subconjuntos específicos de A, e verificar sua presença em B, o algoritmo assegura uma inferência precisa de contenção sem precisar varrer tabelas inteiras.

Limitações

Esta abordagem SGB ⇒ MMP ⇒ CLP demonstrou resultados satisfatórios nos estudos de caso realizados no artigo. Contudo, considerando o contexto específico do iFood e a realidade de uma empresa que lida diariamente com Data & IA em larga escala, identificamos algumas adaptações necessárias para melhor atender ao cenário operacional e às características do nosso DL. Importante: sem deixar de lado a premissa original de compor uma solução eficiente e de baixo custo.

Os principais desafios que motivaram estas adaptações incluem:

• Limitações de infraestrutura para metadados estatísticos: A implementação da etapa MMP, quando trabalhando com tabelas em formato puramente Parquet, é trivial e barata pois os arquivos possuem nativamente valores mínimos e máximos dos dados. Não é o caso de tabelas Delta com as quais trabalhamos no iFood. Isto exigiria uma arquitetura de metadados estatísticos robusta, incluindo: (1) pipelines automatizados para apuração de min/max em todas as colunas numéricas; (2) armazenamento e versionamento destes metadados; e (3) tratamento de edge cases como valores nulos e tipos de dados variados. Esta infraestrutura, embora tecnicamente viável, representaria um investimento significativo e violaria a premissa da solução.
• Overhead de processamento: A comparação entre conteúdos das tabelas, conforme proposta pela etapa CLP, sem o cálculo prévio de valores min/max demandaria recursos computacionais excessivos, impactando a performance e também ferindo a premissa.
• Duplicação inerente à Arquitetura Medalhão: Por natureza, a arquitetura em medalhão pode resultar em duplicação de tabelas. Este cenário é esperado quando dados são ingeridos na camada bronze, processados na silver e posteriormente disponibilizados na camada gold para consumo. Na ausência de transformações significativas entre as camadas, a duplicação de dados torna-se uma realidade.

Como fizemos?

Reformulamos o algoritmo original e substituímos as etapas MMP e CLP por duas novas etapas com o mesmo objetivo de filtragem e refinamento incremental do resultado, mas trazendo a realidade das tecnologias do iFood para o jogo e dando nossa assinatura à solução.

Buscamos preservar e/ou aumentar a precisão e relevância dos resultados e eliminando ao máximo falsos positivos. A imagem abaixo ilustra o algoritmo construído, numa abordagem que batizamos de SGB ⇒ DLP ⇒ LTP.

➢ Etapa “Schema Graph Builder (SGB)”

Mantivemos este componente inalterado pois ele oferece a garantia fundamental de 100% de detecção de relações de contenção entre schemas. O SGB continua sendo nossa base sólida para identificar todas as possíveis relações hierárquicas entre tabelas com base nas suas concepções colunares.

➢ Etapa “Data Lake Layer Pruning (DLP)” ✨ NEW ✨

Introduzimos uma filtragem por contexto que permite direcionar o algoritmo para áreas específicas do Data Lake, reservando a potencialidade e assertividade da identificação de informações redundantes a nichos conhecidos e descartando naturalmente redundâncias inerentes a processos internos:

• Filtragem por Domínio: Restringimos a aplicação e análise a domínios de negócio específicos (ex: áreas de Groceries, de Fintech, etc).
• Filtragem por Camada: Focamos em camadas específicas da arquitetura medalhão (ex: bronze, silver, gold).

Benefícios Principais:

• Redução expressiva do escopo e volumetria de dados sob análise, eliminando comparações irrelevantes entre tabelas de contextos completamente não correlacionados.
• Acionamento direto de times de dados e de negócio para validação da solução proposta e também para o endereçamento mais eficaz quando da eliminação/remoção dos dados duplicados identificados.

➢ Etapa “Lineage Track Pruning (LTP)” ✨ NEW ✨

Aproveitamos de um poderoso recurso presente no nosso DL conhecido como Data Lineage e implementamos uma validação por linhagem para eliminar falsos positivos resultantes de coincidências entre schemas:

Como funciona:

• Reconstruímos a linhagem completa de cada tabela (upstreams e downstreams diretos e indiretos), determinando assim toda história dos dados e de suas dependências.
• Mantivemos apenas relações de contenção entre tabelas que possuem conexão real no pipeline de dados (i.e., pertencem a uma mesma storyline).

Impacto Observado:

• Eliminação de falsos positivos: Descobrimos que muitas tabelas tinham schemas similares por pura coincidência, sem qualquer relação real entre seus dados, por vezes resultante de padronizações sistêmicas (por exemplo: tabelas com dados de monitoramento de APIs sempre adotam as mesmas colunas, apesar de se referirem a distintos sistemas).
• Maior precisão: Focamos apenas em relações de contenção que fazem sentido do ponto de vista do fluxo de dados.

Testes e Validações sob Domínio Controlado

Com o protótipo do algoritmo em mãos, chegou o momento de colocá-lo à prova. No lugar de partir direto para uma implementação em ampla escala, adotamos uma abordagem mais estratégica e direcional: selecionamos um Domínio de Negócio específico para servir como nosso laboratório de validação. E o time de Fintech topou a parceria!

Nosso objetivo foi para além de simplesmente medir a taxa de assertividade do algoritmo. Queríamos compreender como os especialistas do domínio perceberam nossa solução e quais insights eles poderiam oferecer para aprimorá-la.

O Resultado que Surpreendeu

Os números falaram por si: de 76 pares de tabelas identificadas como tendo uma potencial relação de duplicidade, 60 delas realmente refletiam informações totalmente redundantes entre si!!! Isto representa aproximadamente 79% de assertividade do algoritmo. Para um primeiro teste, este resultado superou algumas expectativas daquelas mais otimistas.

Destes 60 pares, um total de 30 tabelas puderam ser identificadas como duplicatas e, após sua auditoria detalhada, os especialistas do domínio já puderam tomar ações concretas de limpeza. Os demais pares identificados também envolviam tabelas cujos schemas, linhagens e contextos estavam correlacionados, porém constituíam sub amostragens dos dados umas das outras, por vezes construídas por questões de otimização de processos de leitura de grandes datasets. Apesar de não serem datasets puramente duplicados, abriu-se oportunidade para revisitar e questionar sua real necessidade.

Curiosidade Técnica: desde a construção do grafo primário de relações de duplicidade (etapa SGB) até a filtragem com base no pertencimento à linhagem (etapa LTP), o algoritmo varre todo o Data Lake. Isto envolve mais de 15 mil tabelas com volumetria de algumas centenas de Terabytes!!! Apesar disso, pela natureza hábil da sua construção, este processo leva em torno de 10 minutos numa infraestrutura tímida (alguns poucos workers Spark em instâncias small sized).

O Impulso para a Próxima Fase

Este primeiro resultado teve um efeito transformador na percepção do projeto. A confiança gerada pelos números abriu caminho para duas expansões importantes para torná-lo uma solução robusta e escalável para a companhia:

1. Escalabilidade Horizontal: estender a aplicação para todos os domínios do iFood.
2. Automação Estrutural: automatizar todo o pipeline, desde a detecção das informações redundantes até a visibilidade e o acionamento dos responsáveis.

A Automação e A Robustez

Nossa solução de automação foi estruturada em três fases principais, cada uma com responsabilidades bem definidas:

Fase #1: Detecção e Análise

O coração do sistema reside no algoritmo principal que executa sequencialmente as três etapas essenciais:

• Schema Graph Builder (SGB): constrói o grafo de contenção identificando relações hierárquicas.
• Data Lake Layer Pruning (DLP): filtra por contexto (domínio & camada) para reduzir ruído.
• Lineage Track Pruning (LTP): utiliza a linhagem para aumentar a assertividade e eliminar falsos positivos com base no pertencimento ao mesmo storyline.

Este processo é orquestrado via Airflow, que garante execução periódica, resiliente e confiável do pipeline. O resultado de cada execução é persistido no Data Lake, criando um histórico rastreável de todas as detecções de potenciais duplicidades.

Fase #2: Comunicação Inteligente

Um segundo componente, também orquestrado via Airflow, consome os resultados da análise de redundância e traduz os insights técnicos em sugestões de ações efetivas.

Utilizando um bot personalizado junto ao principal comunicador adotado pela empresa, o sistema notifica diretamente os proprietários e responsáveis pelas tabelas identificadas como potencialmente redundantes, orientando-os com metadados e facilitando como identificá-las, acessá-las e avaliá-las.

Fase #3: Autonomia na Tomada de Decisão

Em vez de simplesmente informar sobre o problema, oferecemos aos responsáveis notificados opções claras de ação num canal direto para acionamento via comunicador (como, por exemplo, a remoção imediata das tabelas, a inclusão das mesmas em listas de exceção — quando a duplicação é intencional ou necessária, a sugestão de alinhamento entre times para otimização/convergência/redução de datasets essenciais, etc).

Oportunidades de Melhoria

Apesar dos resultados positivos, permanecemos continuamente com o foco em tornar a solução ainda mais eficiente e inteligente. Já identificamos áreas específicas para aprimoramento futuro do algoritmo, dentre elas:

Flexibilidade de Schema

O algoritmo atualmente exige correspondência exata de nomenclatura entre colunas, o que pode deixar de fora alguns casos de relações de duplicidade como consequência de erros de digitação, descontinuidade de padrão no ciclo de vida do dado pós-transformação, etc . Em pipelines produtivos, é comum encontrar tabelas da mesma linhagem com colunas idênticas que foram renomeadas para adequação a processos específicos (ex: customer_id vs. client_id). Essas tabelas, apesar de semanticamente equivalentes, não são detectadas pela atual etapa SGB.

Ambiguidade em Relações Simétricas

Quando duas tabelas possuem exatamente as mesmas colunas, o algoritmo cria uma relação bidirecional (A ⊆ B e B ⊆ A, simultaneamente). Essa situação, embora tecnicamente correta, pode gerar confusão na interpretação dos resultados, exigindo uma análise mais detalhada de qual tabela deve ser removida ou mantida. Este aspecto nos desperta a intenção de adotar soluções em DataViz que cumpram melhor este papel e ilustrem relações em grafos de forma mais inteligível.

Validação Semântica por LLM

Após algumas PoCs (Proof of Concept), identificamos o potencial da inclusão de uma nova camada adicional de validação semântica após o filtro por linhagem. Esta etapa incorpora à solução, para além dos schemas, outras fontes extras de metadados e principalmente os códigos-fonte das ETLs por trás das tabelas envolvidas. Sob esta ótica, temos:

• Análise dos notebooks e códigos que compõem as ETLs usando o poder de análise textual oferecido pelos Large Language Models (LLMs).
• Validação se as transformações no pipeline realmente indicam similaridade de propósito.
• Detecção de casos onde tabelas possuem schemas similares e/ou equivalentes, mas finalidades distintas.

Tais melhorias elevam o algoritmo ao patamar de uma solução que combina análise estrutural com compreensão semântica, aumentando significativamente sua precisão a um custo que conserva sua premissa de entregar um caminho inovador e barato para conservação de um Data Lake saudável.

Conclusão

Nossa adaptação do algoritmo R2D2 demonstrou que é possível gerar valor real adaptando pesquisa acadêmica ao contexto corporativo. Com 79% de assertividade numa primeira aplicação piloto detectando potenciais tabelas redundantes, evoluímos de um experimento controlado e deveras manual para uma solução automatizada completa, com aplicação em todo contexto de Dados do iFood. Esta solução entrega hoje a potencialidade de mantermos nosso Data Lake mais saudável, mais eficiente e reduzido de informações redundantes desnecessárias.

Substituímos componentes complexos e de maior custo, existentes na solução original, por equivalentes mais leves e mais inteligentes, baseados em filtragem direcionada ao contexto do negócio e incorporando recurso poderoso de Data Lineage. Esta abordagem reduziu com segurança falsos positivos e se alinharam à nossa realidade tecnológica com mínimo esforço.

As oportunidades de melhoria identificadas — flexibilidade de schemas, tratamento de relações simétricas e validação semântica por LLM — apontam para uma próxima iteração ainda mais precisa e inteligente.

Referências

R2D2: Reducing Redundancy and Duplication in Data Lakes [2023]; Raunak Shah et al.; Proceedings of the ACM on Management of Data, Volume 1, Issue 4 (DOI: https://doi.org/10.1145/3626762 — alternative: arXiv:2312.13427)

Como o iFood conseguiu identificar tabelas duplicadas no Data Lake? was originally published in iFood Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hoje iremos compartilhar com vocês um case muito interessante que desenvolvemos no iFood para fortalecer nossa parceria com os restaurantes que utilizam nossa plataforma. Para começar, vamos falar de um dos desafios mais clássicos e importantes para empresas de todos os setores: a perda de clientes, mais conhecida como churn.

Por que a retenção é tão crucial?

O churn, ou taxa de cancelamento, é uma métrica que indica a porcentagem de clientes que uma empresa perde durante um determinado período. Em qualquer negócio, minimizar o churn é uma prioridade estratégica e o motivo é simples e direto: manter um cliente existente é muito mais barato do que adquirir um novo.

Estudos de mercado e especialistas em gestão, como a Bain & Company, apontam que o custo de aquisição de um novo cliente pode ser de 5 a 25 vezes maior do que o custo de retenção. Clientes fiéis tendem a gastar mais ao longo do tempo e podem se tornar promotores da sua marca, gerando crescimento orgânico. Portanto, uma alta taxa de churn não apenas impacta a receita, mas também aumenta os custos de marketing e vendas, tornando o crescimento sustentável muito mais difícil.

O Contexto do Problema no iFood: Muito Além do Churn Tradicional

No nosso contexto específico, o desafio ganha uma camada extra de complexidade. Não lidamos apenas com o churn do consumidor final, mas sim com o de nossos parceiros de negócio, os restaurantes. E, ao contrário de um churn contratual, onde há uma quebra formal de contrato, nosso principal indicador de risco é a inatividade: o parceiro que para de receber pedidos em nossa plataforma.

O cenário para esses empreendedores já é desafiador por si só. Um dado da Abrasel (Associação Brasileira de Bares e Restaurantes) revela uma realidade dura: cerca de 50% dos restaurantes no Brasil fecham as portas antes mesmo de completarem dois anos de existência.

Em nossa busca contínua pela excelência e pelo sucesso dos nossos parceiros, sempre analisamos nossas estratégias para encontrar novas oportunidades de aprimoramento. Nosso modelo de retenção anterior, alinhado às práticas tradicionais do mercado, evoluiu para uma abordagem mais proativa e inteligente, permitindo otimizar nossos investimentos e gerar um impacto ainda maior.

A Solução: Surge o Albus

Foi nesse contexto que nasceu o Albus, nosso conjunto de ferramentas e modelos de inteligência artificial projetado para revolucionar a forma como lidamos com a retenção de restaurantes. O nome, inspirado no universo mágico, reflete nossa ambição: usar a “magia” dos dados para prever e solucionar problemas complexos.

O Albus é um sistema robusto que nos fornece desde insights semanais e mensais até previsões avançadas de churn e estratégias de uplift. Com ele, nossa abordagem mudou fundamentalmente:

• De Reação para Antecipação: Em vez de esperar um parceiro parar de vender para então agir, agora conseguimos identificar os sinais de risco com antecedência.
• De Ações Genéricas para Estratégias Personalizadas: Os modelos nos ajudam a entender quais parceiros correm o risco de churn e por quê, permitindo a criação de estratégias de retenção e engajamento muito mais eficazes e personalizadas.
• Decisões Orientadas por Dados (Data-Driven): Cada ação é agora informada por uma análise profunda, garantindo que nossos esforços e investimentos sejam direcionados para onde eles podem gerar maior impacto.

Com o Albus, estamos capacitando nossos times a agir de forma mais inteligente e empática, construindo um ecossistema mais saudável e sustentável para todos. O Albus, na verdade, é um ecossistema de soluções que contempla vários módulos:

• Conjunto de Features (Snape): Uma base de dados massiva com centenas de informações e variáveis relacionadas aos nossos parceiros.
• Modelos Preditivos (Firenze): Um conjunto de modelos que nos dá a probabilidade de churn em diferentes janelas de tempo e com base em diferentes gatilhos de pedidos.
• Modelo de Uplift (Flitwick): Um modelo de inferência causal que prevê a sensibilidade de cada parceiro às nossas possíveis ações de retenção, nos ajudando a escolher a melhor abordagem para cada caso.
• Gatilhos de Desengajamento (Hagrid): Técnicas estatísticas para acompanhar o desengajamento dos parceiros de forma proativa, antes que o churn aconteça.
• Interpretabilidade e Ações Direcionadas (Lupin): Usamos a interpretabilidade dos modelos para entender quais fatores mais impactam o risco de cada parceiro, permitindo criar ações focadas em mitigar esses pontos de atrito específicos.

Atualmente, além desses módulos, utilizamos soluções de outros times de dados do iFood que complementam ainda mais as nossas estratégias de retenção, como o Smart Rollout, que terá um publicação dedicada só a ele futuramente.

Nesta postagem, não iremos entrar em detalhes de todos os módulos. Focaremos no Modelo Preditivo e no Modelo de Uplift, compartilhando alguns dos principais aprendizados que tivemos no desenvolvimento dessas duas soluções.

Modelo Preditivo

Vamos agora mergulhar nos detalhes de como o Albus funciona. Começaremos pelo nosso Modelo Preditivo, a primeira linha de defesa que nos ajuda a identificar proativamente os parceiros que precisam da nossa atenção.

Antes de prever, precisamos definir, o que exatamente significa um “parceiro em risco” no nosso contexto? Após diversas análises, estabelecemos dois conceitos fundamentais baseados na inatividade, ou seja, no tempo em que um parceiro passa sem receber pedidos pela nossa plataforma.

• Pré-Churn: Consideramos este o primeiro sinal de alerta. É uma evidência inicial de que um parceiro pode estar caminhando para deixar a plataforma. Para nós, isso se traduz em uma semana sem receber pedidos.
• Churn: Este é o estágio mais crítico, que define um parceiro em processo de desengajamento. Caracterizamos o churn quando um parceiro atinge um mês sem receber pedidos, podendo ser no conceito Month-To-Date (MTD) ou janela móvel.

Agir no estágio de pré-churn é a nossa meta, pois nos dá a melhor janela de oportunidade para reengajar o parceiro e reverter a situação.

Com as definições claras, o objetivo do nosso modelo preditivo é simples e poderoso: identificar a propensão de um parceiro ativo a não realizar nenhum pedido na semana seguinte, entrando, assim, em pré-churn. Para isso, seguimos um fluxo de trabalho estruturado. Toda semana, o processo se reinicia:

1. Coleta de Dados: Partimos do histórico de informações de todos os nossos Parceiros Vigentes. Esses dados incluem centenas de features sobre o comportamento, atributos e transações de cada restaurante.
2. Modelagem Preditiva: Aplicamos nosso modelo de Machine Learning sobre esses dados para gerar um Score de Risco para cada parceiro. Esse score representa a probabilidade de ele entrar em pré-churn.
3. Ações de Retenção: O score gerado orienta nossas Ações de Retenção. Dependendo do nível de risco, as ações podem variar desde contatos proativos da nossa equipe até o oferecimento de incentivos personalizados.

Exemplo de Utilização no Tático

Na prática, como o time de negócios utiliza o score de risco? Nós o traduzimos em faixas de probabilidade que sugerem diferentes níveis de investimento e tipos de ação. Isso permite que os recursos sejam alocados de forma inteligente, focando onde podemos ter o maior impacto.

Nossos Aprendizados na Construção do Modelo Preditivo

Desenvolver um modelo como este é uma jornada cheia de aprendizados. Não existe uma receita de bolo, mas algumas decisões se mostraram cruciais para o sucesso do nosso projeto. Compartilhamos aqui algumas dicas e os caminhos que seguimos:

• Sobre os Modelos: Modelos baseados em árvores de decisão, como XGBoost e LightGBM, foram nosso ponto de partida e se provaram muito eficazes. Também exploramos métodos de Conformal Predictions para entender melhor a incerteza das nossas previsões.
• Sobre a Métrica de Sucesso: A escolha da métrica é vital. Focar apenas em acurácia pode ser enganoso. Nós otimizamos o F-beta score, uma métrica que nos permite dar um peso maior ao recall, que é mais importante para o nosso objetivo de negócio mas sem penalizar muito a importância da precisão. Além disso, focamos bastante na calibração do modelo com a métrica Brier score.
• Sobre as Ações: Um ponto fundamental é que a informação do score, por si só, não é uma bala de prata. Ela precisa ser combinada com as regras de negócio e o conhecimento tático dos times para que as ações de retenção sejam direcionadas e, de fato, eficazes.

Modelo de Uplift

O Modelo Preditivo nos diz quem tem chance de sair, mas ele não responde a uma pergunta ainda mais crucial: devemos investir em uma ação de retenção para este parceiro? E mais, qual é o impacto real da nossa ação? Para responder a isso, usamos uma abordagem de modelagem de uplift. Esse é um tema que, por sua complexidade e relevância, mereceria uma publicação à parte. Mas, vamos tentar resumir aqui a nossa jornada e os principais conceitos.

Diferente de um modelo preditivo (que prevê um acontecimento), um modelo de uplift é prescritivo: ele prevê como cada parceiro provavelmente responderá a uma ação específica. O objetivo é isolar o efeito causal da nossa ação, ou seja, entender se o investimento realmente fez a diferença.

A modelagem de uplift nos ajuda a classificar os parceiros em quatro quadrantes fundamentais, com base em como eles se comportariam com e sem uma ação de retenção (como receber um voucher).

A principal desvantagem? Essa técnica exige uma grande maturidade de dados, pois depende de histórico de testes (grupo de tratamento e controle) bem desenhados para que o modelo possa aprender e nem toda empresa ou área específica possui essa maturidade.

Como estimamos essa sensibilidade?

O problema central é que nunca podemos observar o mesmo restaurante recebendo e não recebendo um voucher no mesmo instante. É aqui que a inferência causal entra em jogo. Utilizamos dois conceitos-chave:

• ATE (Average Treatment Effect): Mede o impacto médio de uma campanha em todos os restaurantes. É útil para uma avaliação geral, para saber se a campanha, como um todo, foi eficaz.

• CATE (Conditional Average Treatment Effect): Estima o impacto esperado do voucher para um restaurante específico, com base em suas características individuais. É com o CATE que conseguimos personalizar as ações e decidir quem, de fato, deve receber o incentivo para otimizar o ROI.

Existem diversas famílias de métodos para estimar essa sensibilidade. Nós exploramos várias, desde Meta-Learners até modelos mais robustos como DoubleML. Existem outros métodos e cada um deles poderia ser uma publicação completa, mas vejamos o exemplo de uma abordagem simples, eficaz e flexível, o T-Learner, um tipo de Meta-Learner. Nele, treinamos dois classificadores separados: um com o dataset de tratamento (quem recebeu a ação) e outro com o de controle (quem não recebeu). A diferença (o lift) entre a probabilidade de conversão prevista por cada modelo nos dá o uplift para cada parceiro.

Como avaliamos um modelo de uplift?

Depois de treinado, como sabemos se o nosso modelo de uplift é realmente bom? Precisamos de uma ferramenta que avalie a capacidade do modelo de separar os Influenciáveis dos outros grupos. É para isso que usamos a Curva de Qini.

Pense nela como um grande teste de eficiência. O objetivo é responder: “Se tivermos orçamento para aplicar nossa ação de retenção em apenas uma fração dos nossos parceiros, o nosso modelo nos ajuda a escolher o melhor grupo possível para maximizar o retorno?”

A construção da curva é um processo engenhoso:

1. Ordenação por Uplift: Primeiro, pegamos todos os parceiros do nosso grupo de teste (tratamento e controle) e usamos o modelo para prever o score de uplift de cada um. Em seguida, ordenamos todos eles, do maior score de uplift para o menor. A “mágica” do modelo está aqui: ele acredita que os primeiros parceiros da lista são os mais propensos a serem “Influenciáveis”.
2. Cálculo do Ganho Acumulado: Percorremos essa lista ordenada, percentil por percentil (do top 1% mais propenso ao uplift até os 100%), e plotamos um gráfico.

• O eixo X representa a porcentagem da população que decidimos contatar, começando pelos de maior score.
• O eixo Y plota o ganho incremental acumulado. Ou seja, para cada ponto no eixo X, calculamos: (o número de conversões no grupo de tratamento) — (o número de conversões no grupo de controle). Esse valor nos diz quantos parceiros “salvamos” a mais do que teríamos salvo se não tivéssemos feito ação nenhuma.

Da Avaliação para a Ação (Inferência)

Com a confiança de que nosso modelo é eficaz, podemos usá-lo na prática para decidir quem receberá a ação. Na hora de usar o resultado (inferência), seguimos dois caminhos:

• Buckets: Faixas de uplift (ex: uplift alto, médio, baixo) para dar mais flexibilidade de análise e de estratégia para o time de negócios.

• Binário: Abordagem direta, onde simplesmente é aplicado a ação se o uplift previsto para o parceiro for maior que zero. É uma regra mais simples e com menos flexibilização.

Exemplo de Utilização no Tático

Com um modelo de uplift validado e um score para cada parceiro em mãos, a pergunta final é: como isso se transforma em ações claras e objetivas para os nossos times de negócio?

A resposta está em simplificar a complexidade. Embora a matriz de uplift tenha quatro quadrantes, na prática, podemos agrupar os parceiros em duas categorias operacionais que direcionam toda a nossa estratégia de investimento: os Influenciáveis e os Não Influenciáveis.

Nossos Aprendizados na Construção do Modelo Uplift

Alguns aprendizados se destacaram e acreditamos que eles podem ser úteis para qualquer time de dados que enfrenta desafios semelhantes.

• A Maturidade de Dados é o Alicerce: A regra é clara: garbage in, garbage out. Nenhum modelo, por mais avançado que seja, sobrevive a dados de baixa qualidade. Investir em uma cultura de testes bem desenhados, em conjunto com os times de produto e negócio, não é um luxo, mas o alicerce indispensável para construir modelos causais robustos.
• A Comunicação dos Resultados é Crucial: Um modelo pode sugerir uma mudança contraintuitiva, como “deixar de investir em 30% dos clientes que antes recebiam incentivos”. Apresentar isso de forma abrupta pode gerar resistência. A nossa dica é: faça uma boa análise de impacto, comece com um piloto, reduzindo o investimento em uma pequena fração da base, e compare os resultados com a estratégia atual. Deixe os números contarem a história e provarem o valor da nova abordagem.
• Comece Simples, Depois Sofistique: O mundo ideal é ter um modelo para cada tipo de ação ou voucher. O mundo real exige priorização. Não é necessário ter o modelo mais complexo do mundo para começar a gerar valor. Generalize, crie uma ação macro e aplique a regra do 80/20. É melhor ter um modelo simples funcionando e gerando impacto do que um modelo perfeito que nunca sai do papel.
• Cuidado com o Viés do Futuro: Se você passar a investir apenas nos “influenciáveis”, com o tempo, seu modelo ficará cego. Ele não terá dados recentes sobre como os outros grupos se comportam, o que é um veneno para os futuros re-treinos. A solução é continuar atuando, de forma controlada, em uma pequena porcentagem dos “não influenciáveis”. Esse pequeno “custo” é o preço para garantir uma base histórica sem viés e a longevidade do seu modelo.

Impacto

No final das contas, o sucesso de um projeto de dados é medido pelo impacto que ele gera para o negócio e para os nossos parceiros. Felizmente, o impacto do Albus, com seus modelos preditivo e de uplift, trouxe resultados extremamente positivos e que validaram nossa abordagem estratégica.

Ao combinar a previsão de risco com a atuação direcionada apenas aos parceiros “influenciáveis” e também com o direcional dos outros modelos dentro e fora do Albus, conseguimos otimizar nossos investimentos e, ao mesmo tempo, construir um ecossistema mais saudável.

Aqui estão nossos principais indicadores de sucesso:

• Redução de 10% no Churn (YoY): Mesmo com a nossa base de parceiros ativos crescendo 8% no período de um ano (Year-over-Year), conseguimos diminuir a taxa de churn em 10%. Isso demonstra que nossas ações se tornaram mais eficientes, sendo capazes de reter mais parceiros mesmo diante de um universo maior e mais desafiador.
• Aumento de 7 p.p. no Ganho Incremental: Ao comparar a nova estratégia (baseada em uplift) com a abordagem anterior, observamos um delta positivo de 7 pontos percentuais no incremento de parceiros retidos.
• CPRi 53% Menor e Economia de R$ 1.2 Milhão/ano: Talvez o resultado mais direto da eficiência do modelo de uplift. O “Custo de Retenção por Parceiro Incremental” (CPRi) foi reduzido em 53%. Ao pararmos de investir em parceiros que não seriam influenciados pela nossa ação (os “não influenciáveis”), conseguimos uma economia direta de R$ 1.2 milhão por ano. É um recurso que pode ser reinvestido em outras frentes estratégicas, gerando ainda mais valor para o ecossistema.

Esses números mostram que, ao usar Inteligência Artificial não apenas para prever, mas para prescrever a melhor ação, saímos de uma estratégia reativa e de alto custo para uma abordagem proativa, eficiente e genuinamente parceira.

Vale lembrar que é uma aplicação para um segmento do universo de parceiros que temos em nossa base de dados, agora imagine aplicando isso para os milhões de usuários do iFood. Essa solução existe e também traz um impacto muito relevante.

Conclusão

Nossa jornada para otimizar a retenção de parceiros, desde a identificação do problema até a implementação de uma solução sofisticada com o Albus, nos ensinou lições valiosas. Vimos que é possível ir além de uma abordagem reativa e de alto custo, utilizando a inteligência artificial não apenas para “prever o futuro”, mas para moldá-lo de forma mais eficiente e empática.

Modelos não são Balas de Prata

Por fim, é fundamental reforçar que os modelos de Machine Learning não são balas de prata. Em uma era onde Agentes de IA autônomos estão na moda e prometem revolucionar operações, é tentador pular para a solução mais tecnológica. No entanto, temas clássicos e profundos como a Inferência Causal continuam sendo super importantes. Saber o “porquê” uma ação funciona, e não apenas prever “o que” vai acontecer, é o que permite a alocação de recursos verdadeiramente eficiente.

A maior eficiência não vem de um algoritmo perfeito, mas da sinergia entre a ciência de dados e o know-how do time de negócios. O score de risco ou o valor de uplift são apenas números, eles se tornam valiosos quando o time de negócios, com sua experiência prática, os utiliza para desenhar a estratégia certa, escolher o canal de comunicação adequado e definir o tom da abordagem para cada parceiro. É essa união que transforma potencial em resultados concretos.

Encerramos este case com a certeza de que a retenção inteligente é um esforço contínuo, baseado em aprendizado, testes e, acima de tudo, colaboração.

Agradecimentos

Data Oferta Lifecycle: Luiz Temponi, Janaína Marchesi, Nayane Gomes, Giovanna Carvalho, Mateus Varelo, Celso Silva, Renato Ernandes, Rodrigo Matias, Gabriel Castro.

Retenção Inteligente: Como o iFood usa AI para apoiar seus parceiros was originally published in iFood Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

“O meu número não bate com esse”.

Um frio na espinha abala a analista de dados. Desconforto, breves silêncios, promessas de que “os números serão conferidos de novo”. Esse cenário de terror corporativo é um medo constante sobre a cabeça dos times de dados em toda reunião que envolve mais de um time discutindo as mesmas métricas.

À medida que as organizações crescem, o compartilhamento de verdades se torna cada vez mais complexo. O boca-a-boca, a conversa de corredor, a “documentação soy yo” se tornam cada vez mais ineficientes para garantir que todos saibam a forma mais apropriada de se levantar os números relevantes para a tomada de decisão, e mecanismos de compartilhamento de conhecimento abrangentes, rápidos e de longo alcance se tornam tão mais relevantes.

Na prática, o que nós vemos entre as equipes de dados de modo geral é a multiplicidade de tabelas sendo geradas sobre os mesmos assuntos, muitas vezes com lógicas de negócio ligeiramente diferentes; próximas o suficiente para que se pense que estamos falando da mesma coisa, distantes o suficiente para surgirem atritos e discussões sobre qual seria o número correto.

O iFood é referência no Brasil por sua aptidão no trabalho com dados, o que possibilitou construir uma base sólida para tomar decisões constantemente orientadas a dados. Essa mentalidade nos trouxe até aqui, em ciclos de alto crescimento ao longo dos últimos anos.

Neste cenário de rápido progresso, a velocidade exigida na tomada de decisões resultou em redundâncias, falta de governança na definição de regras, dados perdidos ou conflitantes, e plataformas subutilizadas, dentre outros problemas. Esses fatores geraram custos desnecessários, impactando diretamente os resultados financeiros da empresa. Destaca-se também a ausência de responsabilidade por indicadores básicos do negócio, levando à multiplicidade de resultados que divergem entre si sobre o mesmo evento, dificultando em se tomar decisões rápidas e assertivas.

Por que Alexandria?

Essa conjuntura crítica já foi enfrentada por várias organizações em fases anteriores no desenvolvimento em gestão de dados, destacando-se grandes empresas como o Airbnb, o Spotify e a Doordash [1], [2], [3]. No passado, a ausência de padronização, eficiência, consistência e escalabilidade nos dados levou essas empresas a desafios significativos que, ao longo do tempo, perderam a confiança na qualidade dos dados e viram sua segurança na tomada de decisões reduzir gradativamente. Como o tempo, superaram essas dificuldades ao desenvolver soluções específicas, como as plataformas Minerva (Airbnb), Metrics Hub (Spotify) e Semantic Layer (Doordash), todas atuando nas especificidades de cada empresa, mas com um objetivo comum: servir como repositório central de métricas.

Foi pensando nos resultados dessas três empresas e nas nossas próprias dores que nasceu o projeto Alexandria. Inspirados na antiga biblioteca de Alexandria do século III a.C. — um imenso local que abrigava o conhecimento materializado em centenas de milhares de rolos de pergaminho, abrangendo áreas da filosofia, ciência, história, drama, dentre outras -, o nosso projeto veio para ser o mais completo repositório de regras de negócios, features e outras funcionalidades do iFood.

Materialmente, o Alexandria é uma biblioteca em python combinado com algumas rotinas automatizadas para que suas funcionalidades possam ser utilizadas também dentro do ambiente SQL do Databricks.

Na prática, ela é uma abstração que busca enfrentar os problemas descritos acima. O grande problema de se acompanhar a solução desse problema é que resta-nos acompanhar contrafactuais: o Alexandria está sendo eficaz quando tabelas não são criadas, quando regras de negócio não são multiplicadas, quando discussões não são levantadas em reunião porque todos estão cientes dos mesmos números. Como não é possível acompanhar os erros e confusões que não aconteceram e os recursos que não foram desperdiçados, parece-nos mais inteligente assumir que, se o time de Dados efetivamente vê valor na ferramenta, então observamos impactos tanto qualitativos quanto quantitativos na rotina do time.

Quantitativamente, medimos o uso: até maio de 2025, contabilizamos mais de 1700 regras registradas na biblioteca e, em média, são cerca de 166 regras novas cadastradas por mês. O gráfico a seguir ilustra a evolução do número de regras na biblioteca desde a sua fundação, em outubro de 2023.

Outra métrica importante é o impacto transversal na organização, que pode ser medido pelo uso da biblioteca nos ETLs em produção. Só em maio de 2025 foram contabilizados quase 240 notebooks usando pelo menos uma regra no Alexandria. ETLs construídos utilizando a biblioteca são aqueles que buscam garantir conformidade transversal das métricas lá calculadas, por isso, são ETLs que estão prevenindo-se contra os problemas que a biblioteca busca sanar.

Qualitativamente, temos casos e histórias que demonstram tanto a capacidade de alinhamento transversal quanto a flexibilidade e eficiência da nossa ferramenta.

Case de Integração entre times: sinergia pela governança e eficiência dos indicadores

Ao longo do desenvolvimento do Alexandria, destacamos um marco fundamental: a integração estratégica entre o Alexandria e o time de Gestão, responsável pela criação dos relatórios de Impacto e Sustentabilidade — área transversal dedicada à centralização dos KPIs de diversas frentes do iFood. Tamanha responsabilidade demanda dados confiáveis, rastreáveis e alinhados, não apenas para o uso interno, mas também para garantir a credibilidade dos relatórios frente a auditorias externas e stakeholders.

Historicamente, a coleta de dados para relatórios de sustentabilidade era um processo fragmentado, dependendo de dezenas de planilhas, múltiplos pontos focais e inúmeras validações manuais. Em um único ciclo, por exemplo, foram utilizados mais de 28 planilhas, totalizando aproximadamente 565 indicadores monitorados por 15 times distintos de várias frentes de negócio — um cenário que tornava a padronização, a confiabilidade e a agilidade tarefas desafiadoras.

A iniciativa de integração nasceu da necessidade do time de Gestão de garantir não só a eficiência, mas principalmente a governança e a transparência no acesso aos dados. O Alexandria, nesse contexto, passou a assumir o papel de repositório central dos indicadores-chave, promovendo rastreabilidade, alinhamento conceitual e atualização contínua das regras. Com a implementação de novas funcionalidades — como o sistema de notificações para alterações de regras e o registro explícito dos responsáveis de cada indicador — aumentamos a segurança e reduzimos os riscos de desalinhamento nos processos de decisão.

Esse processo colaborativo envolveu uma série de ações de ambos os times: mapeamento dos indicadores e áreas envolvidas, priorização dos temas críticos, definição conjunta de critérios para padronização, treinamento dos participantes no uso e cadastro de regras no Alexandria, comunicação contínua com stakeholders, e a elaboração de documentação robusta garantindo histórico e sustentabilidade do projeto. As discussões passaram a ocorrer de maneira transparente dentro do próprio canal da plataforma, promovendo responsabilização e celeridade na resolução de divergências.

Como resultado, apenas no último ciclo, o time de Gestão superou sua meta ao cadastrar 118 indicadores — destes, 75 traduzidos em regras do Alexandria, demonstrando a flexibilidade e escalabilidade do sistema, visto que uma única regra parametrizada pode atender diferentes necessidades de reporte. A otimização do processo foi evidente: enquanto anteriormente a atualização anual dos dados demandava até três meses de trabalho, neste ciclo a mesma tarefa foi concluída em apenas três semanas.

A sinergia entre Alexandria, Gestão e outras áreas envolvidas não apenas otimizou esforços e mitigou riscos, mas pavimentou o caminho para um processo cada vez mais automatizado e integrado. Este case reforça como a colaboração estruturada entre equipes e a evolução contínua de ferramentas e metodologias são essenciais para elevar o padrão de governança de dados do iFood, preparando a empresa para desafios ainda maiores e futuros ciclos de crescimento sustentável.

Case de arquitetura flexível de dados para processos em evolução

Um outro desafio crítico enfrentado pela empresa pode ser resolvido pelo Alexandria: a organização de dados para consumo analítico no processo de onboarding de restaurantes na plataforma. Este processo, dividido em duas etapas fundamentais — Self-Sign In (assinatura do contrato por autoatendimento) e Self-Setup (criação do perfil com todas as informações necessárias para recebimento de pedidos) — representa um fluxo crucial para o crescimento do nosso marketplace.

A análise e monitoramento eficaz deste processo exige a captura precisa de eventos relevantes ao longo de toda a jornada de integração. No entanto, enfrentávamos um desafio significativo: nosso produto evolui rapidamente, o que significa que os eventos relevantes são constantemente criados, descontinuados e reordenados.

A abordagem tradicional seria manter um ETL monolítico responsável por capturar todos os eventos relevantes, exigindo redesenho e modificação a cada alteração no processo. Porém, optamos por uma proposta mais ágil e escalável: construir queries padronizadas para cada evento do processo, compartimentalizando o cálculo de cada evento na biblioteca Alexandria e mantendo um ETL em produção que serve apenas para unir o resultado dessas queries.

Esta arquitetura modular traz uma vantagem significativa: a adição ou remoção de eventos pode ser realizada através de uma simples atualização em uma lista Python contendo os nomes das queries relevantes para o ETL específico. Simultaneamente, a modificação nas regras de captura dos eventos pode ser implementada diretamente na Alexandria, afetando apenas os eventos que precisam ser modificados, garantindo uma estrutura verdadeiramente modularizada e escalável.

Embora a camada analítica criada ainda seja relativamente nova, já observamos impactos significativos. A flexibilidade na alteração e criação de eventos permitiu ao time iterar e reconstruir soluções com muito mais velocidade, adaptando-se rapidamente às necessidades dos times de negócio e de produto. Esta abordagem também tem facilitado o alinhamento de métricas entre equipes diversas, possibilitando a construção ágil de novos eventos requisitados à medida que os stakeholders começam a utilizar a camada analítica disponibilizada.

Como funciona na prática?

O Alexandria é uma biblioteca em Python desenvolvida para solucionar os problemas do nosso ambiente analítico considerando quatro principais pilares:

1. Governança, ao unificar o conceito das regras e ao disseminar o entendimento, acesso e construção de indicadores e resultados de negócio, eliminando divergências;
2. Escalabilidade, ao permitir que a construção dos nossos produtos de dados possam atender às demandas e às constantes evoluções dos times de dados e de negócio e ao facilitar a integração, operacionalização e gerenciamento das regras;
3. Eficiência, ao centralizar e reduzir custos e tempo no cálculo de indicadores transversais;
4. Resiliência, ao garantir a entrega consistente e em prazo adequado das regras, contribuindo para decisões mais ágeis.

O Alexandria oferece três tipos de funcionalidades de regras: filtros, colunas e queries, que iremos explicar na sequência, e também habilita o uso de adaptadores, que são arquivos de metadados específicos para determinadas áreas de data, e não são consideradas regras. Juntos, regras e adaptadores permitem que analistas de dados e de negócio possam realizar consultas dentro do seu ambiente analítico. Todas essas informações estão cadastradas em um repositório do Gitlab chamado Codex, em homenagem ao tipo de livro manuscrito comumente utilizado na antiguidade. Mais recentemente, é possível também obter features que são exclusivamente utilizadas pelo time de Data Science e Machine Learning, mas não entraremos em detalhes neste artigo sobre o funcionamento destes.

No que se refere ao uso das regras — filtros, colunas e queries — a biblioteca está organizada obedecendo à estrutura hierárquica de áreas do iFood separada em domínios, subdomínios e módulos até chegar às regras de negócio. O acesso às regras pode ser feito tanto em Python quanto em SQL. No primeiro caso, usando o recurso de autocomplete do Python, cada etapa da hierarquia é obtida a partir da digitação do “ . “, que lista todas as opções disponíveis naquele nível da navegação. Em SQL o uso é um pouco diferente: cada regra cadastrada ou atualizada no repositório do Codex é convertida em uma função e fica disponível no catálogo da Databricks. No entanto, ainda existem limitações no processo de conversão, o que impede que 100% das regras existentes no Codex estejam disponíveis em SQL.

Para deixar mais claro o funcionamento de filtros, colunas e queries, vamos exemplificar na prática o uso de cada um deles. Iremos demonstrar o seu uso somente em Python, por simplicidade.

Filtros:

São regras utilizadas no Alexandria para filtrar uma tabela fonte. Essa regra é cadastrada num arquivo .yaml, onde são necessários especificar o nome, uma descrição, a regra de negócio em si como uma expressão em SQL, e a tabela fonte compatível com a regra. Confira abaixo a definição do filtro de pedidos concluídos e como utilizá-lo:

Domínio: orde

Subdomínio: ov4

Produto: status

Arquivo: filters.yaml

Regra: order_filters.status_good_orders

Para usar, basta acessar o produto de dados e criar a coluna utilizando a função filter do PySpark:

Quando dizemos que a regra deve ser compatível com a tabela fonte, nos referimos à existência da coluna current_status especificada em rule no data product registrado em compatible_with.

Colunas:

São regras utilizadas no Alexandria para criar uma coluna em uma tabela fonte. Assim como no caso dos filtros, essa regra também é cadastrada em um arquivo .yaml e necessita dos mesmos tipos de informações. Veja no exemplo abaixo como criar uma coluna que faz conversões de data:

Domínio: orde

Subdomínio: ov4

Produto: orders

Arquivo: columns.yaml

Regra: consumption.order_at_local

Para usar, basta ler o data product e criar a coluna usando a função withColumn nativa do PySpark

Queries:

São regras utilizadas no Alexandria para obter uma tabela já tratada. Ao contrário de filtros e colunas, as queries são cadastradas em arquivos com extensão .sql e o próprio nome do arquivo é o nome da regra. Queries são muito versáteis, pois é possível especificar parâmetros de modo que o usuário pode ajustar a tabela no modo que precisa analisar, sem precisar se preocupar com a definição que gerou a tabela. Para cadastrar esse tipo de regra, é necessário especificar metadados como descrição, tabelas usadas, chave primária e parâmetros com seus respectivos tipos, escritos como um cabeçalho em formato de um yaml comentado e na sequência, especificar o código em SQL. A query do exemplo a seguir gera uma tabela agregada com o total de pedidos concluídos por turno em um determinado período de tempo.

Domínio: orde

Subdomínio: ov4

Produto: status

Arquivo: queries/total_concluded_orders_by_shift.sql

Regra: total_concluded_orders_by_shift

Para usar uma query não é necessário especificar a tabela fonte, uma vez que os data products (as sources) já são utilizados no próprio código. Como a regra acima tem parâmetros, basta escolher os valores desejados. Neste caso em particular, é preciso definir as datas de início e fim:

Vale ressaltar que filtros e colunas também podem ser parametrizados como as queries e seu uso é muito similar ao demonstrado neste último exemplo.

Com os exemplos mostrados até aqui, podemos ver que, com poucas linhas de código, o analista de dados e de negócio podem, facilmente, abstrair da sua decisão em definir a regra de negócio. Com isso, o Alexandria garante a padronização do conceito, maior agilidade no processo analítico e a mitigação de erros advindos da multiplicidade de definições por parte da interpretação subjetiva dos analistas. Assim, a regra cadastrada no Alexandria garante que produtos de dados gerados por diferentes times dentro do iFood possuam consistência em seus conceitos e, com isso, possam trazer alinhamento em suas decisões orientadas a dados. Além disso, o Alexandria não materializa nenhuma regra, evitando custos de processamento e armazenamento.

Para que o nosso repositório de conhecimento cresça é essencial a colaboração dos times do iFood, uma vez que cada área é responsável por definir suas próprias regras de negócio. Neste contexto, o Alexandria é considerado um projeto comunitário em constante evolução, alimentado pela participação ativa de seus membros. Para que o repositório esteja em contínuo desenvolvimento, definimos papeis e responsabilidades para o que chamamos de três principais personas:

• os administradores, que garantem a governança das regras e gerenciam a plataforma, prestando suporte a todos os membros da comunidade;
• os codeowners, responsáveis pela definição e sustentação das regras ao longo do tempo, mantendo sempre atualizadas e disponíveis para uso;
• os analistas, que são os consumidores destas regras e que precisam da garantia de que elas estejam corretas e operantes para tomar decisões de negócio com precisão. Sempre que necessário, os analistas contam com a ajuda dos codeowners para solicitar o cadastro e/ou atualização de regras.

Conclusão

Com o Alexandria, o iFood deu um passo decisivo rumo à excelência na gestão e utilização de dados, consolidando as melhores práticas de governança, eficiência, escalabilidade e resiliência. Mais do que uma ferramenta técnica, o projeto simboliza uma mudança de paradigma na forma como trabalhamos com dados, transformando informações em dados acionáveis que orientam decisões estratégicas e impulsionam nossos resultados.

O sucesso do Alexandria será tanto maior quanto for o engajamento da nossa comunidade. A colaboração ativa das personas é e ainda será fundamental para ampliar e fortalecer o repositório de regras, assegurando que ele continue evoluindo juntamente com as necessidades do iFood. Assim, estruturamos uma base sólida para o futuro, criando um ambiente de dados funcional, coeso e preparado para os desafios que estão por vir.

Texto escrito em parceria com Celso Mattheus C. Silva, analista de dados no iFood.

De papiros a queries: Alexandria no centro das regras de negócio do iFood was originally published in iFood Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Com 120 milhões de pedidos mensais e impacto de 0,55% no PIB brasileiro segundo a Fipe, o iFood evoluiu para além do delivery. Nos transformamos em uma plataforma completa de conveniência multicategoria, com crescimento de 50% em novas verticais no último ano. Para sustentar esta operação massiva e preparar o caminho para o futuro, precisamos constantemente evoluir nossos modelos de inteligência artificial e há um elemento fundamental nessa equação: dados rotulados de alta qualidade.

Foi pensando nisso que desenvolvemos o SAL (Smart Automated Labeling), uma biblioteca de rotulação de dados desenvolvida internamente pelo time de tecnologia do iFood. Nas próximas seções, exploraremos como esta tecnologia proprietária está transformando nossa capacidade de inovação, reduzindo drasticamente o tempo de desenvolvimento e aumentando a qualidade das predições dos nossos modelos.

Desafios com rotulações manuais

A abordagem tradicional de rotulação manual apresenta diversos desafios significativos que têm sido objeto de análise em estudos e relatórios da indústria:

• Investimento Considerável: De acordo com projeções da FactMR (2024), o mercado global de soluções e serviços de rotulação de dados poderá alcançar aproximadamente US$92,4 bilhões até 2034. Este crescimento substancial sugere o volume de investimento que organizações de todos os portes estão direcionando para desenvolver datasets de qualidade.
• Tempo e Recursos: O relatório State of Data Science 2022 da Anaconda, com base em mais de 3.400 respondentes, revela que cientistas de dados dedicam cerca de 37,75% de seu tempo em atividades de preparação e limpeza de dados. A pesquisa JetBrains Developer Ecosystem 2023 indica que 46% das equipes gastam mais de 30% de seu tempo gerenciando, limpando ou rotulando dados, destacando o impacto significativo desta etapa no ciclo de desenvolvimento.
• Variabilidade na Qualidade: Um dos desafios frequentemente relatados em projetos de rotulação de dados é a inconsistência na interpretação de diretrizes. Diferentes anotadores podem compreender as mesmas instruções de formas variadas, potencialmente introduzindo inconsistências nos dados de treinamento que podem influenciar o desempenho dos modelos.
• Desafios de Escalabilidade: À medida que os modelos de machine learning evoluem em complexidade, a quantidade de dados rotulados necessários para treinamento também aumenta significativamente. Esta tendência, observada em análises do setor, torna cada vez mais desafiador escalar processos manuais de rotulação para acompanhar as demandas crescentes por dados de treinamento de alta qualidade.

A Evolução das Abordagens de Rotulação

Em resposta a esses desafios, a comunidade de pesquisa e desenvolvimento tem explorado diferentes estratégias para otimizar o processo de rotulação sendo alguma delas:

• Aprendizado Ativo: Esta abordagem busca otimizar o processo de rotulação priorizando as amostras com maior potencial de contribuição para o aprendizado do modelo. Ao identificar e focar nos casos mais informativos, o aprendizado ativo pode reduzir significativamente a quantidade total de dados que necessitam de rotulação manual.
• Rotulação Semi-Supervisionada: Combinando um conjunto limitado de dados rotulados com um volume maior de dados não rotulados, esta técnica permite treinar modelos que podem generalizar além dos exemplos rotulados.
• Supervisão Fraca (Weak Supervision): Esta metodologia utiliza fontes de supervisão alternativas — como regras heurísticas, modelos existentes e bases de conhecimento — para gerar rótulos probabilísticos. A vantagem principal é a possibilidade de criar conjuntos de dados de treinamento sem depender exclusivamente de rotulação manual extensiva.
• Rotulação Assistida por LLMs: O uso de grandes modelos de linguagem para auxiliar na geração de rótulos tem emergido como uma tendência interessante. Contudo, implementações que dependem exclusivamente de um único LLM podem enfrentar limitações de precisão e confiabilidade, especialmente em domínios especializados ou com dados complexos.

Apesar dos avanços significativos nestas abordagens, cada método individualmente ainda apresenta limitações quando aplicado a problemas do mundo real que exigem níveis elevados de precisão e confiabilidade. É neste contexto que soluções híbridas, combinando múltiplas técnicas, mostram-se particularmente promissoras.

O que é o SAL?

O SAL (Smart Automated Labeling) é uma biblioteca para automatizar a anotação de dados para treinamento ou avaliação de modelos de machine learning de forma rápida e confiável. Ele representa uma evolução na trajetória de rotulação de dados no iFood, combinando o poder de múltiplos LLMs através de um sistema de consenso para superar as limitações individuais de cada modelo.

Enquanto a rotulação automatizada com um único LLM pode apresentar variabilidade e imprecisões expressivas, o sistema de consenso do SAL:

• Distribui a mesma tarefa de rotulação para múltiplos modelos
• Analisa as respostas individuais de cada modelo
• Tende a estimar o rótulo verdadeiro com precisão mesmo em meio à anotações ruidosas
• Quantifica o nível de confiança na rotulação final

Nas próximas seções, exploraremos em detalhes como o SAL funciona, seus componentes técnicos, casos de uso e o impacto mensurável já produzido nas aplicações de IA do iFood.

Componentes do SAL

Tarefa de rotulação

A primeira etapa a ser definida ao utilizar o SAL é a especificação da tarefa de rotulação, esta especificação é definida no prompt a ser utilizado como entrada para os rotuladores.

O SAL inicialmente foi desenvolvido para suportar apenas tarefas de classificação. No iFood temos múltiplas tarefas com essas características, como por exemplo:

• Categorização de itens ou merchants
• Detecção de itens proibidos
• Detecção das intenções do usuário na Busca
• Detecção das intenções dos usuários, entregadores e comerciantes nas conversas do chat
• Entre outros

Modelos distintos

O SAL possui acesso a múltiplas LLMs distintas através da GenPlat (Plataforma de IA Generativa do iFood). Além disso, o iFood também possui mais de 150 modelos de IA proprietários em produção e que em alguns casos também podem ser utilizados como rotuladores em situações de melhoria contínua, ou até mesmo auxiliares de uma outra tarefa. Por exemplo, saber a taxonomia de um item pode ajudar a determinar o rótulo de relevância do item para um determinado usuário.

Rotuladores distintos são fundamentais para:

• Redução de Ruído: Múltiplos rotuladores ajudam a minimizar o impacto de erros aleatórios
• Captura de Incerteza: A variação entre rotuladores permite estimar a incerteza dos rótulos
• Robustez a Outliers: Rotuladores discordantes podem ser identificados e tratados adequadamente

Modelos de Consenso

Os modelos de consenso do SAL visam combinar as respostas de múltiplos rotuladores (modelos de IA ou humanos) para obter um rótulo final mais preciso e confiável. Abaixo, estão detalhados alguns métodos comumente utilizados e suportados:

Voto Majoritário

• Tipo de Resposta: Categórica
• Descrição: A classe com o maior número de votos é selecionada como o rótulo final.
• Fórmula:

Onde:

• ℒ é o conjunto de rótulos possíveis
• 𝒲 é o conjunto de rotuladores
• aij é a resposta do rotulador j para a tarefa i
• I é a função indicadora

WAWA (Weighted Average per Worker Agreement)

• Tipo de Resposta: Categórica
• Descrição: Pondera os votos com base no histórico de concordância de cada rotulador. Rotuladores mais confiáveis têm maior peso.
• Fórmula:

Com:

Onde:

• ℒ é o conjunto de rótulos possíveis
• aij é a resposta do rotulador j para a tarefa i
• I é a função indicadora
• Ƭj é o conjunto de tarefas que o rotulador j rotulou
• 𝒲i é o conjunto de rotuladores que rotularam a tarefa i

Dawid-Skene

• Tipo de Resposta: Categórica
• Descrição: Utiliza Expectativa-Maximização (EM) para estimar a probabilidade de cada rotulador atribuir o rótulo correto, considerando a dificuldade da tarefa.

Envolve duas etapas:

1. Expectativa (E): Estima a probabilidade de cada rótulo verdadeiro dado os votos dos rotuladores
2. Maximização (M): Atualiza a probabilidade de cada rotulador esta correto para cada classe e a distribuição dos rótulos verdadeiros.

É um processo iterativo até a convergência.

Bradley-Terry

• Tipo de Resposta: Comparação entre pares
• Descrição: Modela a probabilidade de uma resposta ser preferida sobre outra.
• Fórmula:

Onde:

• P(i ≻ j) é a probabilidade da resposta i ser preferida à resposta j
• 𝜃i >0 é a “habilidade” ou “força” da resposta i

O objetivo é estimar os parâmetros 𝜃 para todas as respostas com base nas comparações observadas.

Noisy Bradley-Terry

• Tipo de Resposta: Comparação entre pares
• Descrição: Adaptação do Bradley-Terry considerando variações na qualidade das respostas. Similar ao Bradley-Terry, mas introduz parâmetros de ruído ou variabilidade na qualidade das respostas.
• Fórmula:

Onde:

• P(i ≻ j) é a probabilidade da resposta i ser preferida à resposta j
• 𝜃i >0 é a “habilidade” ou “força” da resposta i
• 𝜖i é um parâmetro de ruído, representando a probabilidade de uma comparação ser feita aleatoriamente

Observações

• As fórmulas apresentadas são simplificações para dar uma ideia geral do funcionamento de cada método
• A biblioteca crowd-kit implementa esses e outros métodos semelhantes que podem ser utilizados como modelo de consenso
• A escolha do modelo de consenso depende do tipo da resposta desejada, da confiabilidade dos rotuladores e dos requisitos de precisão da aplicação

Caso de uso — Expansão do Modelo de Taxonomia

Desafio

O modelo de taxonomia do iFood é responsável por atribuir categorizações únicas para itens de acordo com uma estrutura de árvore hierárquica. Essas classificações são extremamente importantes porque são metadados valiosos para recomendações, buscas, criação de listas, caracterização dos tipos de oferta por região, estimativa do tempo de preparo, entre outras aplicações essenciais para a operação do iFood.

Diante do cenário de grande expansão do iFood, a quantidade e diversidade de itens ofertados na plataforma têm crescido de maneira expressiva nos últimos anos e isso faz com que o modelo de taxonomia precise de adaptação constante para cobrir a maior quantidade de oferta disponível e também ter cada vez mais granularidade de categorização para cada item disponível na plataforma.

Cada nó da árvore de taxonomia possui uma definição própria que é construída cuidadosamente para que os nós da árvore sigam o princípio MECE (Mutuamente Exclusivo e Coletivamente Exaustivo), ou seja, não podem existir sobreposições entre definições e todos os itens disponíveis como oferta no iFood devem ter nós onde possam ser categorizados.

Inicialmente as rotulações para gerar as bases de dados de treinamento e validação para o modelo de taxonomia eram totalmente realizadas por humanos, com o surgimento das LLMs o número de exemplos foram incrementados em 36% através de rotulações automáticas com apenas uma LLM, mas ainda assim havia grande esforço humano empregado revisando amostras de rotulações para reduzir o impacto da inserção de exemplos rotulados incorretamente nas bases de dados.

Solução

O SAL foi integrado ao pipeline do modelo de taxonomia para realizar as rotulações nos 4 níveis da árvore utilizando 2 LLMs de desempenho similar em benchmarks públicos, sendo uma delas a mesma que foi utilizada para rotular os dados existentes anteriormente.

O uso dessa estratégia nas rotulações do modelo de taxonomia resultou em aumento de 55,7% nos dados de treino e validação, gerando ganho de 66,7% na cobertura de itens com classificação e 43,6% na precisão do modelo de taxonomia.

Inspeção de rotulações com baixa confiabilidade

Além do impacto positivo entregue por rotulações com alta confiabilidade, a inspeção de rotulações com baixa confiabilidade revelou nós ambíguos na árvore de taxonomia, os quais prejudicam a precisão das rotulações e do modelo. A correção desses casos, assim como a obtenção de rotulações altamente confiáveis, contribui para ganhos de qualidade.

Benefícios em geral

Esses são alguns benefícios observados por times que utilizam o SAL:

• Aumento de qualidade das predições dos modelos
• Ganhos de produtividade no desenvolvimento de modelos supervisionados
• Redução de custos com rotulação
• Identificação de ambiguidades que degradam o desempenho dos modelos
• Habilita monitoramento contínuo mais robusto
• Habilita retroalimentação de exemplos para treinamento contínuo utilizando técnicas de aprendizado ativo

Conclusão

O SAL revolucionou a rotulação de dados no iFood, otimizando a qualidade e eficiência dos modelos de IA. A combinação de LLMs e consenso acelera a rotulação e melhora a precisão, resultando em modelos de IA superiores.

Resultados concretos, como o aumento na cobertura de itens classificados e na precisão da taxonomia, comprovam o impacto positivo no iFood. Equipes relatam melhor qualidade das predições, maior produtividade e redução de custos, consolidando o SAL como ferramenta essencial para o futuro da IA na empresa.

O iFood continuará investindo no SAL, explorando novas funcionalidades e expandindo seu uso. Em suma, o SAL fomenta a inovação e o desenvolvimento do iFood, capacitando a empresa a liderar o setor e a proporcionar a melhor experiência aos clientes. O SAL demonstra como a tecnologia estratégica transforma desafios em oportunidades, impulsionando o sucesso do negócio.

Sobre o autor

Agradecimentos

Oferta AI Team: Anna Castro, Antonio Pinto, Danilo Romoaldo, Isabelle Martins, Matheus Ferreira, Murilo Menezes, Nicoli Araujo e Rafael Silva

Referências

• GenPlat: A Plataforma de IA Generativa do iFood
• Ustalov D., Pavlichenko N., Tseitlin B. (2024). Learning from Crowds with Crowd-Kit. Journal of Open Source Software, 9(96), 6227
• Anaconda. (2022). State of Data Science 2022
• JetBrains. (2023). Developer Ecosystem 2023: Data Science
• Fact.MR (2024) Data Labeling Solution and Services Market

SAL: Uma Abordagem Inteligente para Escalar a Rotulação de Dados no iFood was originally published in iFood Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.