Sugar, Revisor e Pepper: o ciclo agêntico que mantém a escala e a consistência do catálogo do iFood

Catálogos vivos exigem sistemas vivos. E, em um catálogo com milhões de itens, a consistência é o fator mais importante.

Em um catálogo com milhões de itens, a classificação de produtos enfrenta desafios que vão além da simples categorização. Descrições inconsistentes, nomes ambíguos e a enorme variedade de itens fazem com que modelos tradicionais tenham dificuldade para interpretar corretamente o que cada item representa dentro da taxonomia do catálogo.

Quando essa interpretação falha, a classificação pode acabar colocando um item no lugar errado da árvore taxonômica. Este é um erro pequeno na estrutura de dados, mas tem impacto direto em busca, recomendação e curadoria.

E aí entra o desafio real: como manter consistência semântica em um catálogo com milhões de itens, cauda longa e descrições ambíguas, sem transformar isso em um trabalho manual infinito?

Nos últimos meses, a resposta para essa pergunta evoluiu muito aqui dentro. O que começou como uma iniciativa para automatizar rotulação de dados virou algo maior: um ecossistema de serviços que classifica e audita em escala, enquanto aprende de forma contínua com as próprias exceções.

Continue lendo para saber mais sobre essa evolução e sobre os três serviços que sustentam o ciclo hoje: Sugar, Revisor e Pepper.

Um breve contexto: do SAL ao próximo estágio

Antes de falarmos sobre os serviços atuais, vale dar um contexto rápido.

O SAL (Smart Automated Labeling) nasceu como uma biblioteca interna para automatizar a geração de rótulos para treino e avaliação de modelos de machine learning. A premissa central era usar múltiplos modelos e combinar suas respostas via métodos de consenso para aumentar a confiabilidade do processo. Isso ajudou a acelerar a rotulação e a elevar a qualidade em casos importantes.

Mas, com o tempo, a escala e o tipo de problema mudaram.

A partir do momento em que a necessidade deixou de ser apenas gerar rótulos e passou a ser melhorar a classificação do catálogo em produção, ficou claro que precisaríamos evoluir a abordagem. O iFood já utilizava classificadores baseados em machine learning tradicional, e o SAL surgiu inicialmente como uma tentativa de ampliar a qualidade dessas classificações por meio de rotulação automatizada.

Apesar de trazer ganhos importantes na geração de dados rotulados e na capacidade semântica, o SAL não escalava bem para os volumes exigidos pelo catálogo.

Em testes internos, o contraste foi bem direto: o que o Sugar faz em cerca de duas horas, o SAL levava de seis a sete horas para fazer em um fluxo equivalente. E, conforme o volume crescia, o tempo simplesmente estourava a janela aceitável dos pipelines de envio de dados. Além disso, havia limites clássicos do SAL para esse uso: taxas relevantes de respostas inválidas ou falta de consenso entre LLMs, além de um custo operacional alto para manter descrições e definições que exigiam esforço constante de construção, correção e validação.

A virada, então, não foi apenas “substituir uma ferramenta por outra”. Essa mudança representou uma evolução mais ampla na forma como tratamos a classificação do catálogo. Expandimos a abordagem anterior, baseada em modelos tradicionais de machine learning e técnicas como TF-IDF, para soluções baseadas em LLMs, capazes de lidar melhor com ambiguidade semântica e com a diversidade de descrições presentes no catálogo.

Ao mesmo tempo, deixamos de tratar rotulação como uma etapa isolada e passamos a operar um ciclo contínuo de qualidade, capaz de classificar, auditar, medir e retroalimentar o sistema.

É aí que o Sugar, o Revisor e o Pepper entram em cena.

O que estamos construindo, afinal?

Se você precisar de uma definição curta, Sugar + Revisor + Pepper formam um sistema inteligente de classificação de catálogo com auditoria e melhoria contínua.

Ou, em termos mais práticos:

O Sugar classifica itens em escala (com estratégia híbrida de modelos);

O Revisor julga a qualidade do que foi classificado, corrige exceções e transforma erros em aprendizado;

O Pepper gera rótulos de validação (ground truth) com confiabilidade e escala, para medir precisão/recall e acelerar a evolução do sistema.

O resultado é um ciclo que funciona como um organismo: executa, verifica, aprende e volta melhor.

Por que isso importa mais do que parece

Classificação e atributos não vivem isolados, eles alimentam diretamente três frentes que todo mundo sente no produto:

Busca: quando o usuário procura algo, a classificação ajuda a entender a intenção e filtrar a oferta certa.

Recomendação: modelos precisam de sinais consistentes para sugerir o que faz sentido naquele contexto.

Curadoria e listas: aquelas listas temáticas e promocionais dependem de taxonomia/atributos para não virar uma “mistura aleatória”.

Se o catálogo não faz sentido, o app não faz sentido. E, por esse e outros motivos, aqui a barra é alta: precisão e recall precisam ser fortes o suficiente para não comprometer a experiência dos usuários. Em outras palavras: não dá para aceitar sistemas e serviços que “às vezes acertam”.

Sugar: o motor de classificação em escala

O Sugar nasceu com uma proposta objetiva: classificar itens do catálogo em volume e com velocidade, mantendo compreensão semântica.

Na prática, isso significa ter throughput suficiente para lidar com volumetria alta. O serviço hoje consegue processar milhares de itens em poucos minutos, permitindo que a classificação acompanhe o ritmo de atualização do catálogo.

O que o Sugar resolve

O Sugar responde a pergunta-base:

“O que é este item e onde ele entra na nossa taxonomia?”

Esse “onde entra” não é trivial. Taxonomia é uma árvore. Classificar um item significa escolher o caminho na árvore, e isso fica especialmente difícil na cauda longa, quando o nome é ambíguo ou o contexto é incompleto.

O desafio: desempenho vs custo

O Sugar, nas primeiras fases, foi construído usando LLMs de fronteira para garantir qualidade semântica. Funciona, é claro, mas escalar isso em milhões de itens pode ficar caro muito rápido.

A saída foi evoluir para uma arquitetura híbrida, em que o sistema decide quando usar um modelo proprietário e quando acionar modelos de fronteira como fallback.

Hoje, o time está em rollout de um modelo menor, treinado com dados do catálogo (a lógica do que internamente chamam de ‘Item Profile’ / derivação do trabalho com modelos proprietários). Em termos práticos, de 50% a 70% das inferências já migra para o modelo proprietário (uma LLM treinada com dados do catálogo), enquanto o restante segue com fallback em modelos de fronteira sempre que necessário.

Essa combinação resolve dois problemas de uma vez: mantém qualidade onde precisa e reduz custo onde dá.

Nosso time estima uma queda de custo entre 60% e 80% comparado a depender exclusivamente de LLMs de fronteira, com o adicional de reduzir custo de manutenção ao substituir múltiplos modelos legados por uma inferência mais unificada.

Revisor: “LLM as a Judge”, com a ajuda de humanos

Ao classificar itens em escala, ter uma governança de qualidade é algo inegociável.

A abordagem clássica é: classifica tudo → tira uma amostra → manda para revisão humana.

Funciona, mas não escala bem. Porque, na prática, isso é adicionar volume sobre um gargalo caro e limitado.

O Revisor, por sua vez, nasceu para atuar como uma camada de auditoria automática, agêntica, antes do humano.

Como funciona o fluxo

O Revisor seleciona uma amostra diária do que o Sugar classificou e a põe dentro de um sistema multiagente que avalia diferentes dimensões: contexto do item, risco de alucinação, regras de negócio e consistência da decisão.

Essas avaliações vão para um agente que age como “juiz” e dá o veredito:

Se concorda com o Sugar, aquilo vira um rótulo confiável para controle de qualidade.

Se discorda, o Revisor tenta reclassificar (usando um agente especialista, em múltiplas tentativas).

Se ainda assim não for possível resolver com confiança, o caso vai para o HITL (human-in-the-loop, ou o humano que será a última camada de validação). Ou seja, a revisão humana é acionada sempre que há uma exceção.

Esse desenho faz um ajuste importante no sistema: o humano deixa de ser o primeiro filtro e passa a ser o último recurso. Com isso, a revisão humana passa a focar apenas nos casos mais complexos, e não em amostras enviadas sem critérios de priorização.

Transformar erro em aprendizado

Para além de julgar, o Revisor também aprende e retroalimenta o ciclo.

Ao identificar uma falha (como um “hambúrguer” classificado como “wrap”, por exemplo), ele gera um insight: uma espécie de regra/observação que orientará o Sugar quando casos similares acontecerem.

Na prática, isso vira uma memória operacional do sistema:

o Revisor detecta o erro;

extrai um insight do que aconteceu;

associa esse insight a itens semelhantes (via similaridade);

e reinjeta orientação no fluxo de classificação.

Isso é o oposto de “corrigir hoje e esquecer amanhã”. A nossa ambição é fazer com que erros não se repitam quando o contexto for equivalente.

Mesmo nos casos em que o Revisor concorda com o Sugar, uma parte pequena (por exemplo, 1%) pode ir para validação humana como controle adicional. Este é um mecanismo de confiança calibrada, que não confia cegamente em automações.

Pepper: medir qualidade sem colapsar o time

Até aqui, mostramos como o sistema é capaz de classificar e auditar dados, mas ainda falta mencionar um ingrediente essencial para qualquer sistema que queira melhorar: a medição confiável.

Para afirmar que uma classe está boa, é preciso fugir do achismo e focar na amostra.

Para validar qualidade com significância estatística, por exemplo, pode ser necessário ter algo como 300–500 rótulos por classe para medir recall e precisão de forma decente. Agora, multiplique isso por centenas de classes.

Se o processo depender da rotulação humana, a conta não fechará nunca.

É aí que o Pepper entra em ação: como um sistema multiagente focado em rótulos de validação, com confiabilidade e escala.

O que o Pepper resolve

O Pepper elimina um gargalo clássico: antes, o cientista de dados precisava selecionar dados com critérios, rodar rotulação, garantir confiabilidade e repetir isso sempre que uma classe evoluísse.

Este é um processo pesado, lento e, a depender da volumetria, inviável.

Com o Pepper, a ideia é que a seleção de dados seja automatizada, com agentes rotuladores recebendo o volume ideal para cada classe. Assim, o output pode alimentar tabelas internas de ground truth e métricas contínuas.

Hoje, o Pepper rotula corretamente cerca de 91% dos casos em comparação aos humanos. E o melhor: com menos de 1% de alucinação.

Em outras palavras, ele viabiliza a validação em escala sem precisar de um exército humano para rotular amostras o tempo todo.

O ciclo completo

Se ainda não está claro, podemos juntar tudo:

Input: entra um lote de itens do catálogo.

Classificação: o Sugar classifica em escala.

Quando possível, usa modelo proprietário (mais barato e rápido).

Quando o caso é novo/complexo, aciona fallback com modelos de fronteira.

Revisor: o Revisor avalia uma amostra diária.

Se concorda, consolida confiança.

Se discorda, tenta reclassificar.

Se não resolve, aciona HITL (humano) para exceções.

Aprendizado: correções e insights voltam para o Sugar como orientações.

Validação: o Pepper gera ground truth para medir recall/precisão e sustentar métricas com escala.

Melhoria contínua: com métricas + insights + dados, o sistema evolui mais rápido, com menos retrabalho.

Assim, fica mais fácil visualizar que não estamos falando de um “modelo melhor”, mas de um processo melhor.

O que mudou na prática

A transição para um ciclo integrado de classificação e melhoria contínua trouxe impactos estruturais para a operação do catálogo. Com isso como ponto de partida, consolidamos uma abordagem orientada a escala, controle de qualidade e eficiência operacional.

Podemos sentir efeitos dessa mudança em diferentes dimensões:

Velocidade e escala

Quando a necessidade virou “classificar o catálogo todo em um curto espaço de tempo”, a queda de muitas horas para poucas horas fez toda a diferença.

A abordagem antiga não se sustentava. O que antes fazíamos em até sete horas, hoje caiu para cerca de duas horas.

Flexibilidade

Nos modelos legados, melhorar um nó podia levar de duas semanas a um mês, dependendo da complexidade.

Com a arquitetura atual, ajustes podem acontecer em dias e, em muitos casos, em poucas horas.

Isso é crítico porque o catálogo muda o tempo todo: itens novos aparecem, descrições variam, tendências explodem (e somem) rápido. Se o sistema não evolui no mesmo ritmo, ele envelhece.

Menos fragmentação

Antes, extrair atributos (como ‘industrializado’, ‘congelado’, ou ‘vegano’, por exemplo) podia depender de múltiplos modelos legados separados e difíceis de manter.

Com a evolução para modelos proprietários e lógica de itemProfile, a visão é concentrar inferências em uma camada mais unificada. Isso torna a manutenção mais sustentável.

Custo sob controle, sem abrir mão de qualidade

LLMs de fronteira são ótimos. E caros. A arquitetura híbrida reduz a dependência desses modelos onde não é necessário e preserva o fallback onde é.

Podemos estimar uma queda de custo na casa de ~60% com o uso crescente do modelo proprietário, além de ganhos indiretos ao reduzir a manutenção de uma coleção de modelos legados.

Qualidade com governança

O Revisor permite que o sistema tenha uma postura mais madura. Ele é capaz de automatizar a triagem e a revisão, envolver humanos quando faz sentido e transformar as exceções em aprendizado.

No fim, a meta não é tornar o sistema “menos humano”. É criar um ecossistema onde o humano seja estratégico e trabalhe menos com rotulação operacional e mais com intervenções em casos complexos.

Para onde vamos

Se o SAL representou um estágio em que o foco era acelerar a rotulação, esta nova etapa mostra outra ambição: transformar a qualificação da oferta em um sistema vivo, semântico e autocorretivo.

Hoje, Sugar, Revisor e Pepper funcionam como uma camada que habilita outras frentes do iFood (especialmente Busca e Recomendação) com sinais mais consistentes e confiáveis.

O próximo passo natural, falando do problema e não necessariamente da solução, é ganhar ainda mais flexibilidade.

Queremos reduzir a dependência de intervenção humana em casos operacionais e evoluir a capacidade do sistema de lidar com classes novas e mudanças na taxonomia de forma mais fluida. E, além disso, tornar o ciclo de aprendizado cada vez mais contínuo.

Porque, no fim, o catálogo é vivo. Então o sistema que dá sentido ao catálogo também precisa ser. Assim, conseguiremos garantir que o usuário sempre encontre exatamente o que ele procura.

Agradecimentos especiais ao Jeferson Santos e Ronald Pereira.