QuintoAndar
Como Staff AI Design Engineer, lidero tecnicamente iniciativas de AI e Design Engineering: automatizações, EVALs e construção de agents. Abaixo, os projetos em detalhe.
Projetos
LLM as a Judge
Avaliação automatizada de saídas de LLM usando outro modelo como juiz, com rubricas e critérios definidos.
Ver em detalhe → P-02Prompt Reviewer
Metodologia de revisão sistemática de prompts de agentes, cruzando o texto do prompt com conversas reais e dados quantitativos.
Ver em detalhe → P-03Online Eval Matthew
Framework de 3 perguntas para avaliação contínua de qualidade conversacional, rodando via LLM-as-judge em 100% das sessões em produção.
Ver em detalhe →Próximo projeto
Reservado para o próximo case do QuintoAndar.
Em breveLLM as a Judge
01 Contexto
O Matthew é um agente de cobrança com IA do QuintoAndar. Ele conversa via WhatsApp com inquilinos inadimplentes, apresenta propostas de negociação e tenta fechar um acordo, sem intervenção humana imediata. A pergunta de negócio era simples de fazer e difícil de responder: o Matthew está conduzindo bem essas conversas? E quando ele falha, é porque não tinha o que oferecer, ou porque não soube usar o que tinha?
02 O desafio
Responder isso exigia analisar centenas de conversas reais em busca de padrões de comportamento. Manualmente isso não escala, e automatizar sem confiar no critério do avaliador é arriscado. Eu precisava de um classificador consistente o suficiente para ser confiável, mas calibrado o suficiente para não inventar padrões que não existem na conversa.
03 Abordagem
Construí um LLM-as-judge que lê a conversa completa e a classifica segundo 6 critérios independentes: o que aconteceu, como o Matthew se comportou, a qualidade da condução, o turno decisivo, as objeções identificadas e o tom do usuário. A saída é um JSON estruturado com Pydantic, então cada campo vem no formato e domínio de valores certo antes de entrar na análise.
Por dentro, o extrator é um notebook com 12 células, da configuração à extração paralela com múltiplas threads, terminando num relatório agregado. Esta é uma reconstrução do fluxo real de execução:
| Sessões processadas | 278 (181 ACEITE · 97 ABANDONO) |
| Erros de extração | 0 |
| Padrão adaptativo | 57% |
| Padrão sem_objeções | 31% |
| Padrão insistente | 12% |
| Tempo total de execução | ~68s · 8 threads |
Reconstrução ilustrativa do pipeline real. Nomes de célula e métricas finais correspondem à execução em produção.
Esse é o motor por trás de cada sessão. Na prática, cada uma das 278 conversas passa por essa mesma estrutura, e é isso que acontece quando o juiz lê uma conversa específica:
Simulação ilustrativa do fluxo de avaliação. A conversa é fictícia; o schema de campos é o mesmo usado em produção.
Antes de rodar nas 278 sessões, calibrei o juiz contra 21 conversas anotadas manualmente, comparando critério a critério e refinando o prompt até atingir +80% de concordância em todos os critérios. Esse foi o limiar mínimo que defini para validar o uso em escala.
04 O que construí
Uma infraestrutura reutilizável de avaliação, não só uma classificação pontual:
O pipeline de anonimização (Python + spaCy + regex) roda antes de qualquer classificação, de forma determinística. Isso permite cruzar dados sem risco de reidentificação. O judge calibrado processou as 278 sessões com 0% de erro de processamento. O resultado virou base para um segundo entregável: 278 pares contrastivos ACEITE/ABANDONO já estruturados para fine-tuning supervisionado do agente.
05 Resultados
O achado central: a qualidade Baixa é 74% comportamental, não estrutural. Na maioria dos casos o Matthew tinha alternativa para oferecer e simplesmente repetiu a mesma proposta. Esse é o padrão que chamei de insistente.
| Padrão de comportamento | % das sessões | Qualidade Alta |
|---|---|---|
| Adaptativo | 57% | 100% |
| Sem objeções | 31% | 62% |
| Insistente | 12% | 0% |
O padrão insistente concentra 100% das sessões de qualidade Baixa e tem 65% de taxa de abandono, contra 0% no padrão adaptativo. Boa parte da qualidade Baixa é treinável: não é falta de opção do sistema, é o agente não tentar uma opção diferente diante da objeção.
Esse resultado virou recomendação direta de produto: ajuste de regra de negócio para forçar a exploração de alternativas antes de repetir uma proposta, mais o uso dos pares contrastivos gerados para fine-tuning direcionado. Impacto estimado: +8 a 12 pontos percentuais de conversão nas sessões em que o usuário pediu uma alternativa.
06 Valor da entrega
O entregável não terminou no relatório. O judge calibrado entrou em commit no GitHub como um template versionado e replicável, não amarrado ao Matthew. A ideia é poder reaproveitar em qualquer agente conversacional que precise de avaliação de qualidade em escala.
Em vez de uma análise pontual, o projeto deixou um ativo permanente. Qualquer time que precise responder "esse agente está se comportando bem?" pode partir do mesmo schema, do mesmo processo de calibração contra ground truth humano e da mesma estrutura de critérios, adaptando só o domínio da conversa.
Prompt Reviewer
01 Contexto
No QuintoAndar, cada agente de IA tem seu prompt revisado de um jeito diferente, dependendo de quem escreveu e de quanto contexto essa pessoa tinha. Isso funciona, mas não escala: um padrão de erro identificado num agente não necessariamente chega ao prompt do próximo, e a qualidade da revisão varia conforme quem está revisando.
O Prompt Reviewer nasceu para resolver isso: uma ferramenta e uma metodologia para trazer padronização e refinamento aos prompts da empresa como um todo, não a correção pontual de um agente específico.
02 O desafio
Uma IA analisando um prompt sem dado de produção está, em boa parte, adivinhando o que pode dar errado. Isso exige validação humana com contexto de negócio antes de qualquer sugestão ser aplicada. Há também uma assimetria de risco a considerar: em agentes conversacionais, falso positivo e falso negativo não têm o mesmo custo, e cada sugestão de mudança precisa declarar essa diferença em vez de tratar todo erro como equivalente.
03 Abordagem
A metodologia amarra toda sugestão de mudança a uma evidência: um caso real de conversa que mostra o problema acontecendo, ou um dado agregado que mostra a frequência dele. Quando não havia nenhum dos dois, isso fica marcado como hipótese a validar, não como fato. O processo segue 6 etapas: coleta de fontes, leitura cruzada, diagnóstico por bloco, reescrita, validação humana e consolidação. Na ferramenta, o diagnóstico e a reescrita são gerados por um modelo de linguagem; a etapa de validação continua sendo humana.
Batizei a ferramenta de LCARS, o mesmo nome do painel de controle da nave Enterprise em Star Trek. A referência não é por acaso: assim como o LCARS organiza informação densa em blocos de cor e função bem definidos para quem opera a nave, a ferramenta organiza o processo de revisão de prompt em etapas claras, cada uma com sua própria função, sem misturar diagnóstico com reescrita com aprovação.
Esta é uma simulação da ferramenta em funcionamento, usando um exemplo genérico de agente de suporte:
You are a knowledgeable and empathetic Customer Support Agent for a SaaS platform. Your purpose is to help users resolve issues related to their subscription, billing, and account settings efficiently and professionally.
## Task
Assist users with subscription plans, billing inquiries, account settings and cancellation requests.
v1.4 · score 87/100 · temperature 0.3 · atual
v1.3 · score 61/100 · temperature 0.7 · substituída
v1.2 · score 58/100 · temperature 0.7 · substituída
Simulação ilustrativa da ferramenta. O prompt de exemplo é genérico; o fluxo de etapas corresponde à interface real.
04 O que construí
O processo foi validado de ponta a ponta num prompt real em produção, cobrindo múltiplos blocos típicos de um agente conversacional: regras de domínio, regras de decisão, e os fluxos de cada etapa da conversa. Cada achado teve identificação do problema, evidência quando disponível, e reescrita completa do trecho, pronta para aprovação.
Desenhei também o caminho de evolução da metodologia até virar ferramenta, em 4 níveis de maturidade: assistente de revisão manual (custo zero, só processo), pipeline semi-automatizado de diagnóstico com LLM-as-judge, sugestão automática de reescrita com humano no loop, e por fim um loop fechado que mede o impacto de cada mudança antes de propor a próxima.
A melhor versão de uma regra não vem da primeira proposta de IA nenhuma. Vem da iteração entre proposta de IA e questionamento humano com contexto de negócio. Esse é o motivo pelo qual a etapa de validação humana não deveria ser removida nem em versões mais automatizadas da ferramenta.
05 Valor da entrega
O Prompt Reviewer hoje é uma ferramenta em funcionamento, não só uma metodologia documentada. É alimentada por IA de ponta a ponta: o diagnóstico, a reescrita e o score de qualidade são gerados por modelo de linguagem, com versionamento de prompt e histórico de score a cada iteração. Qualquer time do QuintoAndar pode entrar, colar o prompt do seu agente e sair com um diagnóstico estruturado e uma versão otimizada, sem precisar montar esse fluxo do zero.
Online Eval Matthew
01 Contexto
O Matthew é o agente de IA de cobranças do QuintoAndar. Ele conduz negociações com inquilinos inadimplentes via WhatsApp e App, com o objetivo de propor acordos de pagamento de forma autônoma. A qualidade dessas conversas era avaliada por auditoria manual: cerca de 69 conversas por mês, de um universo de ~3.400. Menos de 2% do volume real.
Esse processo não escala e não distingue o tipo de problema: uma conversa em que o Matthew atuou fora do escopo dele recebia o mesmo diagnóstico de uma em que ele tinha tudo para agir e agiu mal. Diagnósticos diferentes exigem donos diferentes, e a auditoria manual não fazia essa distinção.
02 O desafio
Definir um framework simples o bastante para rodar em escala, mas que separasse com precisão três problemas de natureza completamente diferente: falha de roteamento (o Matthew nunca deveria ter entrado naquela conversa), falha de produto (o Matthew agiu certo, mas o sistema não tinha o que o usuário precisava) e falha de comportamento (o Matthew tinha como agir bem e não agiu). Tratar os três como a mesma coisa gera ação errada: nenhuma equipe consegue agir bem em cima de um diagnóstico genérico.
03 Abordagem
Desenhei um framework de 3 perguntas binárias e independentes, respondidas por um juiz de IA sobre a transcrição pré-escalação de cada sessão encerrada:
| Pergunta | O que mede | Roda em |
|---|---|---|
| O cliente foi atendido? | Resposta completa e útil à demanda principal, não se o usuário ficou satisfeito. | 100% das sessões |
| O cliente ficou frustrado? | Insatisfação expressa por escrito, e se o alvo foi o bot ou a situação. | 100% das sessões |
| Quando não funcionou, por quê? | Fora de escopo, sem capacidade do produto, ou falha de comportamento. | Só sessões não atendidas |
A primeira diz se o usuário foi atendido. A segunda diz como ele se sentiu, o que é um eixo separado: dá pra atender bem e mesmo assim deixar frustração pelo caminho. A terceira só entra quando a primeira for não, e aponta pra quem precisa agir: roteamento, produto ou o próprio agente.
O escopo do Matthew precisou ficar explícito no prompt do juiz, porque a pergunta 3 depende disso pra distinguir falha de roteamento de falha de comportamento:
| Dentro do escopo | Fora do escopo |
|---|---|
| Faturas em atraso de locação ativa | Reembolsos de qualquer tipo |
| Negociação e propostas de acordo | Disputas de utilidades (água, luz, gás) |
| Confirmação de pagamentos recentes | Alterações contratuais e rescisão |
| Dúvidas sobre IR / informe de rendimentos | Contestação da legitimidade da dívida |
A avaliação roda dentro da infraestrutura de eval online já existente na plataforma conversacional: um job em lote que executa a cada hora via Databricks e Spark, puxando as sessões encerradas de cada agente configurado. Cada agente roda num host próprio, e cada host segue o mesmo contrato: um runner busca as conversas e executa uma lista de avaliações, e cada avaliação é um par processor + evaluator, o processor extrai o que a avaliação precisa da sessão, o evaluator roda a classificação.
04 O que construí
Reativei o runner do Matthew no job de eval online e construí o par processor + evaluator específico das 3 perguntas: o processor reaproveita a extração já existente de transcrição pré-escalação e logs de tool calls, e o evaluator roda os 3 prompts de LLM-as-judge (Claude Sonnet, temperatura 0) de forma independente por sessão, retornando classificação e uma justificativa de 2 a 4 frases por pergunta.
Esta é uma reconstrução do fluxo real de leitura de uma sessão:
Simulação ilustrativa. As 3 perguntas rodam de forma independente sobre a mesma transcrição pré-escalação.
05 Validação
O eval é calibrado contra anotação humana antes de ir para produção. Na pesquisa conversacional que originou o modelo de perguntas, a calibração chegou a 100% de concordância. Para o Matthew, a meta de entrada é mais conservadora:
| Fase | Amostra | Critério |
|---|---|---|
| Validação inicial | 21 sessões âncora | ≥ 80% de concordância com gabarito humano, por pergunta |
| Expansão de gabarito | 80–100 sessões novas | Representatividade por tipo de conversa · meta de paridade com Wall-E (94%) |
| Recalibração trimestral | 30–50 sessões novas | Detecção de drift de modelo ou mudança no perfil de sessões |
Queda sustentada na taxa de atendimento aciona a leitura da pergunta 3. Frustração com o bot acima de 25% aciona investigação de padrão insistente. Falha de comportamento acima de 40% das sessões não atendidas já justifica iteração de prompt ou regra de negócio. Fora de escopo alto e crescente aponta para o fluxo de roteamento, não para o Matthew.
É esse cruzamento, distribuição agregada mais limiares de ação, que transforma as 3 perguntas num painel de monitoramento. Uma reconstrução ilustrativa de como isso fica com 30 dias de sessões:
Simulação ilustrativa com números fictícios. Os limiares (25% e 40%) são os mesmos definidos no framework de decisão.
06 Valor da entrega
O framework leva a cobertura de qualidade de ~2% das sessões, via amostragem manual, para 100%, rodando dentro da mesma infraestrutura de eval online usada por outros agentes da plataforma. Mais importante que a cobertura: o diagnóstico da pergunta 3 direciona a ação para quem precisa agir, roteamento, produto ou o próprio agente, em vez de devolver um veredito genérico de "deu certo ou não deu".