Agentes de AI focados em avaliação: como a Zepto escala o suporte ao cliente no Databricks e MLflow

O esforço da Zepto por um suporte ao cliente confiável e em tempo real

A Zepto é uma das plataformas de quick-commerce que mais cresce na Índia, com mais de milhares de produtos, presença em mais de 60 cidades e janelas de entrega medidas em minutos. Em um negócio onde a velocidade é o produto, o suporte ao cliente precisa ser igualmente rápido.

Para atender a essa expectativa, a Zepto opera seu suporte ao cliente em um sistema de AI multiagente que processa mais de cem mil chamados por dia. No início, a equipe conseguia criar e implantar agentes rapidamente. A questão mais difícil era como manter esses agentes confiáveis à medida que o volume crescia, as categorias se expandiam e o comportamento do cliente continuava mudando. A Zepto fez uma parceria com a Databricks para responder a essa pergunta, não implantando mais agentes, mas tornando a avaliação a principal forma de criar, testar e operar agentes.

Este blog detalha essa jornada: a arquitetura do sistema, o framework de avaliação no Databricks e MLflow, as histórias de produção onde ele provou seu valor, e os resultados e lições que surgiram disso.

Por que "apenas implantar o agente" falha em escala

Em um negócio de alta velocidade, "apenas implantar o agente" funciona até que falhe em escala. Com mais de 100.000 chamados de agentes de AI por dia, até mesmo uma taxa de erro de 1% gera milhares de resultados ruins e perda real de receita todos os dias.

A pressão chegava em ondas desiguais. Eventos climáticos, o Diwali e o início do verão causavam picos acentuados no volume de chamados. A expansão de mantimentos para vestuário, eletrônicos e beleza introduziu novas jornadas de reembolso, troca e devolução. Enquanto isso, uma base de clientes mais diversa e multilíngue trouxe uma gama mais ampla de solicitações de suporte — e novos modos de falha surgiam a cada poucas semanas.

O problema mais profundo é a lacuna de garantia (assurance gap). Sistemas de agentes operam como fluxos de trabalho de várias etapas — classificando a intenção, recuperando conhecimento, analisando entradas, raciocinando sobre decisões, chamando ferramentas transacionais e gerando respostas —, de modo que as falhas podem surgir em qualquer ponto do caminho, não apenas na resposta final.

Essa lacuna de garantia se traduzia em problemas concretos:

• As falhas eram invisíveis até que os clientes reclamassem
• As correções eram lentas
• A resposta final ocultava erros internos
• Faltava uma maneira estruturada de equilibrar custo, desempenho e qualidade para o agente
• O design do agente não capturava todas as perspectivas críticas das partes interessadas
• A confiabilidade era difícil de garantir diante da rápida evolução dos agentes

O objetivo ficou claro: desenvolver um framework de avaliação no Databricks e MLflow para que ele funcione como a infraestrutura de AI central sobre a qual os agentes são criados e operados.

Por que um framework de avaliação e seus resultados

Um framework de avaliação robusto afeta diretamente cinco eixos de prontidão para produção:

• Confiabilidade: garantias em nível de sistema de que os agentes se comportam corretamente em todas as etapas, e não apenas que “pareçam corretos”
• Velocidade: iteração mais rápida e segura em prompts, políticas e modelos, pois as alterações são testadas contra regressão automaticamente
• Controle de Custo vs. Qualidade vs. Desempenho: capacidade de escolher modelos ideais, estratégias de prompt ou estratégias de roteamento híbrido para atingir o ponto ideal de restrições, com o respaldo de dados de avaliação concretos
• Governança: rastreamentos auditáveis, baselines de avaliação versionadas e limites bem definidos para implantação e rollback. Mudando as decisões de intuição (“esta versão parece melhor”) para evidências (“esta versão supera a baseline nas métricas acordadas”)
• Colaboração das partes interessadas: capturar os critérios de sucesso e confiabilidade sob a perspectiva das partes interessadas, tornando as compensações (trade-offs) explícitas e mensuráveis para todos

Com o Databricks + MLflow como base de avaliação e uma arquitetura de agentes focada primeiro em avaliação, a Zepto alcançou

Custo e eficiência

• Mais de 80% dos chamados totalmente gerenciados por agentes de AI com supervisão humana
• Redução de 65% no custo de suporte ou nos chamados de suporte
• Período de retorno (payback) de menos de um mês

Qualidade e reputação

• Melhoria de 20% na satisfação do cliente (CSAT)
• Melhoria de 8% na precisão

Desempenho e operações

• Ciclos de desenvolvimento 3 vezes mais rápidos
• Tempo de resolução 4 vezes mais rápido

Construindo o framework: um loop duplo para confiança e controle

No cerne dessa abordagem está o modelo de loop duplo: um loop de desenvolvimento e um loop de produção, conectados por um portal de qualidade (quality gate). Esta seção descreve como esses loops funcionam juntos.

• Loop de desenvolvimento: onde você projeta, realiza iterações e avalia versões de agentes para criar com confiança antes de implantar
• Loop de produção: onde você monitora o comportamento em tempo real e detecta falhas para operar agentes com confiança
• Loop de feedback: onde as falhas de produção retornam ao desenvolvimento para enriquecer a próxima iteração
• Portal de qualidade (quality gate): controlando a transição entre os loops, ele decide quais versões têm permissão para ir para a produção e quais devem voltar para o desenvolvimento para melhores iterações

Juntos, esses dois loops garantem que os agentes sejam criados e operados com controle. Qualquer falha é capturada automaticamente, enviada de volta e corrigida. Como resultado, os agentes são criados com confiança, executados com controle e aprimorados continuamente para lidar melhor com as falhas de produção ao longo do tempo. O loop duplo está no cerne do nosso framework.

Fase 0: Habilitar o rastreamento (tracing): agentes transparentes por design

Cada invocação de agente emite um rastreamento (trace) de execução detalhado que captura prompts, conclusões, documentos recuperados, chamadas de ferramentas, latências e caminhos de decisão, de modo que todo o fluxo de trabalho seja observável em um nível granular, em vez de apenas uma entrada e uma saída final.

Habilitamos isso com uma abordagem híbrida usando o MLflow. Uma única linha, mlflow.<library>.autolog(), ativa o rastreamento automático, e o decorador @mlflow.trace adiciona spans personalizados onde quer que precisemos de mais detalhes. Os rastreamentos são emitidos em tempo real como spans do OpenTelemetry com IDs exclusivos para que permaneçam combináveis, e a integração do MLflow com o Unity Catalog centraliza o registro em tabelas Delta.

Fase 1: Definir as dimensões de avaliação: pilares e portões

Com o rastreamento habilitado, o próximo passo é capturar, sob a perspectiva de cada parte interessada, “O que o sucesso deste agente significa para você?”. Formalizamos isso como pilares de avaliação, cada um com portões (gates) específicos.

Isso transforma um debate entre várias partes interessadas em um contrato compartilhado e mensurável. Os agentes são avaliados de acordo com as dimensões que realmente importam para cada parte interessada. Os pilares típicos incluem experiência do cliente, eficiência operacional, risco e conformidade e impacto financeiro; cada pilar tem limites numéricos claros que devem ser atingidos antes da implantação.

Fase 2: O conjunto de dados de referência (golden dataset): a base da confiabilidade

O conjunto de dados de referência (golden dataset) é a única fonte de verdade para avaliar o comportamento do agente no loop de desenvolvimento. Ele deve:

• Cobrir casos normais, limites (edge cases) e de falha que o agente deve tratar
• Incluir expectativas de diferentes partes interessadas capturadas como exemplos
• Ser ricamente anotado com metadados (tipo de cenário, linha de negócios, nível de risco, etc.)

Todas as partes interessadas colaboram para moldar o dataset. Por exemplo, a equipe de segurança contribui com exemplos de padrões adversários, como injeção de prompt, ataques de identidade e tentativas de exfiltração de dados. Isso garante que a confiabilidade seja medida em relação a todos os cenários do mundo real, bem como ao uso comum.

Os datasets são ativos vivos, e sua qualidade se acumula com o tempo. A diferença de acurácia entre o desenvolvimento e a produção é, por si só, um sinal de qualidade do dataset. A Zepto investiu continuamente em datasets de avaliação do MLflow ao longo de seis meses, passando de 500 exemplos e uma diferença de acurácia de 8 pontos entre dev e prod, para 2.000 exemplos e uma diferença de 2 pontos, e depois para 5.247 exemplos e uma diferença de 0,4 ponto. Cada hora gasta na qualidade do dataset economiza cerca de dez horas de depuração em produção, de modo que o dataset de referência se torna um multiplicador de 10x: cada falha em produção adiciona rastros de falha ao dataset de referência e torna o sistema mais robusto para todas as versões futuras.

Fase 3: Automatizar a engenharia de prompt: autogeração e otimização automática

Em vez de escrever prompts manualmente, transformamos a engenharia de prompt em um processo automatizado e orientado por dados. O design de prompts é a fase crítica em que os engenheiros passam a maior parte do tempo, e a qualidade dos prompts tem um impacto desproporcional na qualidade e no desempenho dos resultados dos agentes.

Usando a otimização de prompt do MLflow, registramos um prompt inicial, geramos e otimizamos variantes em relação aos mesmos avaliadores que controlam a implantação, executamos avaliações A/B automaticamente e implantamos o melhor resultado. O otimizador analisa com um modelo robusto e avalia os candidatos em produção com um modelo mais barato, para que a própria busca continue ciente dos custos em produção. Isso reduziu a experimentação manual de prompts, melhorou a acurácia e garantiu que as melhorias nos prompts fossem sempre medidas em relação ao dataset de referência antes de chegarem à produção.

Fase 4: Definir avaliadores e configurar o júri de AI

Com os rastros (traces) fluindo no ciclo de produção, precisamos pontuá-los de acordo com as dimensões que importam para a qualidade do agente (dimensões de avaliação). Pense nisso como um júri de AI, onde cada avaliador joga com seus pontos fortes. O MLflow oferece três opções para criar avaliadores.

• Juízes integrados (built-in) - avaliadores prontos para uso
• Juízes personalizados - crie juízes personalizados para atender a necessidades exclusivas
• Avaliadores baseados em código - para métricas determinísticas, como latência de ferramentas ou número de chamadas de ferramentas

Usamos avaliadores baseados em LLM apenas onde o julgamento humano é necessário e contamos com regras simples onde a lógica determinística é suficiente. Calibramos os juízes em relação a rótulos humanos para alcançar de 80% a 90% de concordância e usamos vários juízes para decisões de alto risco.

Fase 5: Configurar a opcionalidade de modelos

A opcionalidade de modelos é um componente crítico que permite ao framework alternar entre vários modelos proprietários e de código aberto simplesmente alterando os nomes dos modelos no Databricks. Isso significa que o ciclo de desenvolvimento pode buscar continuamente uma combinação melhor para encontrar o equilíbrio ideal entre custo, desempenho e qualidade.

Fase 6: Criar regressão automática

Automatizamos a avaliação de regressão para criar um ciclo de desenvolvimento repetível, configurável e escalável. Qualquer alteração aciona a regressão automática e, quando a confiabilidade é garantida, a implantação automática.

Juntando as peças, uma mudança típica segue este caminho:

1. Alguém altera a lógica, o prompt ou o modelo do agente.
2. O fluxo de trabalho de avaliação é acionado automaticamente com três entradas: a nova versão do agente, o dataset de referência e a linha de base (baseline) de produção atual.
3. O sistema executa avaliações e gera métricas em todos os avaliadores e pilares.
4. O portal de qualidade (quality gate) verifica:
   • A nova versão atende a todos os critérios (custo, qualidade, desempenho, etc.)?
   • Ela tem um desempenho pelo menos tão bom quanto, ou melhor que, a linha de base de produção?
5. Se sim, a nova versão é promovida para a produção; se não, ela é rejeitada e o agente existente continua atendendo ao tráfego.

Fase 7: Criar o ciclo de produção - Configurar uma rede de segurança em tempo real

Avaliar 100% do tráfego é caro, mas uma amostragem uniforme simples de 10% perde a maioria dos casos extremos. Implementamos uma amostragem estratificada na qual as taxas de amostragem de avaliação dependem de clientes de alto valor, novos recursos ou fluxos alterados recentemente, sentimento negativo ou alto risco de escalonamento, e interações baseadas em imagens ou propensas a fraudes. Isso resulta em uma amostra de avaliação real de 18% a 20% (~14.400 rastros por dia) a um custo gerenciável, capturando de 45% a 60% dos casos extremos e detectando problemas em 4 a 6 minutos.

A lógica financeira é convincente: em comparação com uma abordagem de amostragem uniforme, a metodologia estratificada alcançou uma redução de 86% no custo de revisão por problema identificado, ao mesmo tempo em que proporcionou uma melhoria de 9x na detecção de casos extremos, tornando o processo de garantia de qualidade significativamente mais eficiente e escalável.

Os resultados da avaliação são gravados em tabelas Delta e exibidos por meio de painéis (dashboards) e regras de alerta no Databricks. Alertas críticos (verificados a cada 5 minutos) monitoram quedas na acurácia da intenção, violações de fundamentação (groundedness), alto risco de escalonamento e violações de latência P95. Alertas de prioridade alta/média acompanham a degradação da empatia, picos de custo, taxas de falha de ferramentas, tendências de CSAT, taxa de detecção de fraudes e latência multimodal. Isso permite operações semelhantes a SRE para agentes de AI: detecção rápida, triagem e mitigação.

A pilha de agentes de arquitetura combinável

Um bom framework de avaliação funciona muito melhor quando a arquitetura do agente é projetada para ser observável e decomponível desde o início. A pilha de suporte da Zepto foi desenvolvida em torno dessa ideia.

Uma consulta do cliente, em formato de chat ou imagem, passa primeiro por um orquestrador e roteador de agentes. O roteador pode transferir o atendimento para um humano a qualquer momento. Abaixo dele, o sistema se divide em dois tipos de agentes.

Agentes verticais são especialistas, cada um responsável por uma única família de intenções bem definida:

• WIMO: para rastreamento de pedidos e dúvidas sobre ETA
• Missing: para pedidos não entregues ou parciais
• Expiry: para produtos embalados vencidos
• Returns: para status e processamento de reembolso
• Quality: para produtos murchos ou estragados
• Unable to Pay: para falhas de carteira digital, cupons promocionais e pagamento
• Geral, como alternativa (fallback)

Agentes horizontais atuam como camadas de supervisão que abrangem diversos casos de uso:

• Image Deduplication: detecta imagens reutilizadas em diferentes reclamações
• Item Matching and Image Manipulation Detection: verificam se as imagens enviadas correspondem aos itens do catálogo e se não foram editadas

Essa separação traz um duplo benefício. As métricas podem ser calculadas por agente vertical, como o F1 de intenção do WIMO ou a precisão de OCR de expiração, e os agentes horizontais podem ser avaliados em questões transversais, como precisão de fraude, reutilização de imagens e detecção de manipulação. Cada parte pode ser medida de forma isolada e combinada.

O framework em ação

Quando você lança um agente de IA em produção pela primeira vez, a sensação é a de enviar um estagiário brilhante, mas imprevisível, para representar sua empresa. Você dá instruções e espera pelo melhor, mas até que ele esteja sob pressão, você está essencialmente voando às cegas.

Logo no início, percebemos que o monitoramento de software tradicional é totalmente inútil para a IA. Um agente pode ter um uptime de servidor perfeito e zero erros enquanto repete exatamente a mesma resposta errada para um cliente frustrado. Para os engenheiros, o painel está verde. Para o cliente, é um desastre.

Sabíamos que não podíamos escalar nossa IA baseados apenas em esperança. Precisávamos de um framework de avaliação que não apenas rastreasse se a IA estava falando, mas que realmente entendesse o que ela estava dizendo e onde estava falhando. As histórias a seguir mostram os momentos em que esse framework provou seu valor, mostrando que um bom sistema de avaliação viabiliza recursos de produtos totalmente novos.

História 1: O ETA que nunca mudava

Um problema em produção deixou os entregadores presos no trânsito enquanto o agente continuava respondendo "chegando em 10 min" em um loop, porque estava lendo dados em cache. O cliente perguntava onde estava o pedido, recebia a mesma resposta, perguntava de novo e recebia a mesma resposta novamente.

O contador de tokens (que monitora o uso de tokens) e os pontuadores de alerta detectaram a repetição e o alto risco de escalonamento em 5 minutos, identificando traces de entregadores parados com ETAs inalterados. Isso acionou uma mudança de regra. Se um entregador permanecer parado por mais de 10 minutos, o agente agora fornece uma atualização real e oferece proativamente o cancelamento com reembolso total, em vez de repetir uma promessa desatualizada.

Um insight, obtido pela avaliação online, transformou-se em uma linha inteira de recursos: cancelamento por atraso, uma proposta proativa de cancelamento durante a escassez de entregadores, cancelamento automático se nenhum entregador for atribuído dentro de uma janela de tempo definida e cancelamento sem perguntas para clientes de alto valor.

História 2: Detectando a regressão de cancelamento antes dos clientes

Quando a Zepto adicionou o tratamento de cancelamento ao agente WIMO, o modelo começou a confundir três intenções muito diferentes: "onde está meu pedido", "quero cancelar" e "meu pedido foi cancelado".

A avaliação do MLflow na fase de desenvolvimento detectou isso imediatamente. A precisão geral da intenção caiu de cerca de 92,1% para 87,4%, com um F1 baixo nas novas intenções WIMO_CANCEL e WIMO_CANCEL_STATUS. Como a regressão apareceu no golden dataset, nenhum cliente chegou a vê-la. A otimização de prompts e as atualizações do conjunto de dados restauraram a precisão geral para cerca de 94,2%, melhor do que a linha de base original, com um F1 de chamada de ferramenta (tool-calling) quase perfeito nas APIs de cancelamento. O recurso entrou em produção com zero rollbacks.

História 3: Calibrando agentes multimodais com base no julgamento humano

A qualidade dos produtos frescos é genuinamente difícil de pontuar, e os humanos nem sempre concordam. A mesma imagem de cogumelos pode receber nota 2 de 5 de um avaliador e nota 3 de 5 de outro. Medimos essa divergência com o Kappa de Cohen e a tratamos como nosso teto de confiabilidade, já que nenhum modelo pode ser mais consistente do que os humanos com quem ele aprende.

Também descobrimos que a IA jogava de forma segura. Por conta própria, ela acumulava pontuações em 3 para evitar decisões difíceis, enquanto as pontuações humanas atingiam o pico em 4 e 5. Portanto, não apenas minimizamos o erro em relação à média. Nós replicamos o formato da distribuição de pontuação humana. A avaliação online também revelou casos para os quais o sistema não foi projetado, como leite coalhado que é colocado na prateleira como produto embalado, mas precisa ser avaliado como produto fresco, e reclamações de sabor ou cheiro que uma foto simplesmente não pode mostrar, as quais foram direcionadas para um fluxo separado.

Essa linha de base calibrada nos permite decidir quais modelos usar por tipo de produto, como iterar prompts com base no julgamento humano e como ajustar a política de reembolso por segmento de cliente com base no desempenho real do agente.

História 4: Fechando as brechas de abuso

As tentativas de abuso de reembolso usavam imagens de catálogo, fotos editadas e imagens reutilizadas em diferentes solicitações. O pipeline de avaliação multimodal passava as imagens por verificações de pré-processamento para desfoque, brilho e resolução, validava-as com OCR e, em seguida, usava um júri de três modelos de visão com regras de consenso para decidir entre a aprovação automática e a revisão humana. Camadas adicionais incluíam detecção de desfoque, detecção de captura de tela, detecção de duplicatas, correspondência de imagem versus SKU, verificações de imagem versus motivo declarado e validação de comprovante de entrega.

O que aprendemos operando isso em escala

Operar esse framework em escala nos ensinou alguns princípios que se aplicam além do quick commerce.

• Nunca otimize uma única métrica. Certa vez, buscamos a precisão da intenção isoladamente e vimos o CSAT cair. Otimizar apenas a intenção aumentou a precisão da intenção em 5 pontos, mas elevou a latência em 133% e custou 0,4 pontos de CSAT. Uma pontuação composta e multi-objetivo ganhou 3 pontos de intenção com apenas 17% a mais de latência e adicionou 0,2 pontos de CSAT. Múltiplas perspectivas, juízes de LLM, verificações baseadas em regras, rótulos humanos e métricas de produção criam a verdade juntos. Essa redundância é uma garantia, não um desperdício.
• Os golden datasets são a base. Invista cedo para alcançar milhares de exemplos diversos e de alta qualidade. Monitore a diferença entre a precisão de desenvolvimento e de produção e ajuste até que convirjam. A diferença entre desenvolvimento e produção (dev-prod gap) é um sinal de qualidade do conjunto de dados, não um mistério.
• Os juízes de LLM precisam de calibração. Trate os juízes como modelos com sua própria avaliação. Meça a concordância deles com os humanos, use ensembles para casos de alto risco e recalibre à medida que os modelos base mudam.
• A estratégia de amostragem importa mais do que a taxa de amostragem. A amostragem uniforme simples é barata, mas cega. A amostragem estratificada focada em fluxos de alto risco oferece uma detecção de problemas muito superior por dólar investido.
• Automatize o ciclo de feedback desde o primeiro dia. Detectar, rotular, retreinar, implantar e monitorar devem ser processos automatizados, com cada falha enriquecendo automaticamente a próxima rodada de treinamento. Para nós, isso economizou cerca de 155 horas por mês, o equivalente a dois engenheiros em tempo-integral redirecionados para o desenvolvimento de recursos.
• Trate a avaliação como uma interface de produto. Painéis e métricas são usados pelas equipes de suporte, produto, fraude e operações. Eles precisam ser interpretáveis e acionáveis, não apenas tecnicamente corretos.

Recomendações para criadores de agentes

Para organizações que constroem sistemas de agentes no Databricks, a experiência da Zepto sugere o seguinte roteiro:

• Comece pelos traces, não apenas pelos modelos: imponha um esquema de trace compartilhado e registre tudo no Delta
• Torne as avaliações do MLflow uma etapa obrigatória no CI/CD: sem implantação sem superar a linha de base nas métricas acordadas
• Construa golden datasets como um ativo, com KPIs próprios (tamanho, diferença entre desenvolvimento e produção, cobertura de casos extremos)
• Use LLM-as-judge para o que os humanos julgam hoje (qualidade, empatia, fundamentação), mas calibre e limite aos segmentos corretos
• Implemente amostragem estratificada e alertas em tempo real o quanto antes; adaptar a visibilidade operacional mais tarde é caro
• Projete agentes para serem verticais (especializados) e horizontais (supervisão), para que você possa avaliá-los de forma isolada e combinada

Conclusão

Na transição de demonstrações experimentais para infraestrutura de missão crítica, a principal limitação mudou da capacidade bruta do modelo para a garantia do sistema. A jornada da Zepto demonstra que, ao estabelecer a avaliação como a primitiva de desenvolvimento fundamental, as organizações podem escalar agentes de forma confiável para gerenciar dezenas de milhares de interações diárias complexas em entradas multimodais, respaldadas por garantias rigorosas de qualidade, custo e mitigação de riscos.

O Databricks e o MLflow servem como a base essencial para essa evolução, fornecendo infraestrutura de dados centrada em traces no Unity Catalog e Delta, juntamente com avaliação escalável, otimização automatizada de prompts e integração de CI/CD simplificada. Essa pilha combinável, combinada com a opcionalidade de modelos, capacita as equipes a ajustar o equilíbrio entre desempenho e custos para cada tarefa específica.

No fim das contas, a vantagem competitiva está na decisão estratégica de tratar a avaliação não como uma verificação final, mas como infraestrutura central de AI. O modelo para operar agentes em escala de produção não é mais um mistério; a Zepto e o Databricks trouxeram a resposta. O desafio agora é a velocidade de adoção. No cenário de AI em rápida evolução, os líderes não serão aqueles que esperam pela certeza absoluta, mas sim aqueles que desenvolvem com foco em confiabilidade desde o primeiro dia.

Para desenvolvedores que criam agentes que precisam conquistar confiança em ambientes de produção, esses mesmos blocos de construção fundamentais estão prontos no Databricks e no MLflow 3. As organizações que definirão a próxima fronteira serão aquelas que iniciarem sua jornada focada primeiro em avaliação hoje mesmo.

Crie agentes no Databricks
Comece a usar a avaliação e o monitoramento do MLflow

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