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 →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.