Hamel Husain & Eugene Yan — Da demo ao produto: por que avaliação é o trabalho

"Building solid evals should be the starting point for any LLM-based system or product." — Eugene Yan, Patterns for Building LLM-based Systems & Products

O essencial em 30 segundos

Há uma distância enorme entre uma demo que impressiona numa reunião e um sistema de IA em que você confia para tocar parte do seu negócio. Hamel Husain e Eugene Yan passaram a carreira na trincheira dessa distância. Os dois dizem, com palavras diferentes, a mesma coisa incômoda: o que separa quem entrega "lixo quente apressado" de quem constrói produto de verdade não é o modelo, não é o framework, não é o prompt esperto — é a disciplina de medir. Avaliação sistemática (evals), guardrails, ciclos rápidos de iteração ancorados em dados reais. Husain é o consultor que repete sem cansar "seu produto de IA precisa de evals". Yan é o cientista aplicado que codificou os padrões de produção de LLM num material que virou referência. Para um operador que está prestes a colocar agentes de IA na frente de processos reais, os dois oferecem a única coisa que importa: um método para confiar — ou não confiar — no que a máquina está fazendo.

Quem são

Hamel Husain é engenheiro de machine learning com mais de vinte anos de estrada. Começou em 2003 construindo modelos de risco de crédito num banco, passou por consultoria, e em meados da década de 2010 entrou no circuito de startups de ML que importam: DataRobot, onde conviveu com grandmasters de Kaggle; depois Airbnb como cientista de dados, onde liderou o roadmap de infraestrutura de ML da empresa; e então GitHub (2017–2022), onde liderou o lançamento do CodeSearchNet — projeto de busca semântica em código que é reconhecidamente um precursor do GitHub Copilot. É contribuidor central do ecossistema fast.ai (nbdev, fastpages, fastcore). Em 2023 fundou a Parlance Labs, consultoria e laboratório focado em LLMs, com especialidade declarada em fine-tuning, sistemas de avaliação, LLM-Ops e engenharia de software. Seu blog, hamel.dev, e seu ensaio "Your AI Product Needs Evals" se tornaram leitura obrigatória de quem leva LLM a sério em produção.

Eugene Yan é cientista aplicado que liderou times de ML/IA na Amazon, Alibaba, Lazada e numa startup de healthtech Série A — currículo construído em sistemas de recomendação e busca operando em escala real. (Em 2024–2025 ele passou a integrar a Anthropic como Member of Technical Staff, mas o corpo de trabalho que o tornou referência foi escrito do ponto de vista de quem operava ML em produção dentro de uma big tech.) No seu site, eugeneyan.com, mantém um arquivo enorme — centenas de posts e talks — sobre ML na indústria. Seus dois marcos para o tema deste post são o ensaio "Patterns for Building LLM-based Systems & Products" e a co-autoria de "What We Learned from a Year of Building with LLMs" (a série e o material O'Reilly escrito junto com Husain e outros praticantes). É o tipo de autor que escreve do ponto de vista de quem teve que manter o sistema de pé às 3 da manhã.

A dupla não é casual. Husain e Yan colaboraram diretamente no material "A Year of Building with LLMs" e dividem o mesmo público — engenheiros e operadores que querem parar de torcer e começar a medir.

A grande contribuição

A contribuição conjunta dos dois pode ser resumida numa inversão de prioridade. A cultura dominante em IA aplicada é centrada em ferramenta: qual modelo, qual framework de orquestração, qual vector database, qual técnica de prompting da semana. Husain e Yan viraram a mesa. A pergunta certa não é "qual ferramenta", é "como você sabe que está funcionando, e como você descobre rápido quando para de funcionar".

Husain formula isso com uma observação que vem de campo, não de teoria: depois de ajudar dezenas de empresas a construir produtos de IA, ele notou que os times que têm sucesso "mal falam de ferramentas" — eles obcecam com medição e iteração. E que os produtos que fracassam quase sempre compartilham uma causa-raiz: a ausência de um sistema robusto de avaliação. Sem evals, você não consegue iterar com confiança; e como ele diz, "assim como na engenharia de software, o sucesso com IA depende de quão rápido você consegue iterar".

Yan dá a isso uma forma quase metodológica. Ele propõe pensar em Eval Driven Development (EDD) — análogo a test-driven development, mas para sistemas de LLM. A avaliação não é uma etapa de QA no fim; é o ponto de partida. "Construir evals sólidas deveria ser o ponto de partida de qualquer sistema ou produto baseado em LLM." E ele é cirúrgico sobre por que isso é existencial: "Sem evals, estaríamos voando às cegas, ou teríamos que inspecionar visualmente as saídas do LLM a cada mudança."

Juntos, eles transformaram "avaliação" de uma tarefa chata e adiável na coisa central da engenharia de IA. Esse é o legado prático: deram aos operadores um vocabulário e um método para tratar IA como engenharia, não como mágica.

As ideias-chave

1. Evals em níveis: do barato e frequente ao caro e raro

Husain organiza avaliação numa hierarquia de três níveis que resolve o problema prático de "por onde começo".

• Nível 1 — Unit tests (asserções): testes baratos e rápidos que rodam o tempo todo. Você escreve asserções concretas sobre a saída — formato esperado, presença ou ausência de certos campos, comprimento, ausência de PII, sintaxe JSON válida. São o equivalente a um teste de unidade de software, e devem rodar em cada mudança.
• Nível 2 — Avaliação humana e por modelo (LLM-as-judge): mais caro. Aqui você usa um modelo para julgar a saída de outro (com cuidado, porque LLM-judge tem vieses conhecidos) e periodicamente revisa exemplos com olhos humanos.
• Nível 3 — A/B testing: o mais caro, reservado para produtos maduros, onde você mede impacto real em usuários reais.

A sacada é que a maioria dos times pula direto para a fantasia do Nível 3 (ou para nenhum nível) quando o Nível 1 — asserções triviais que pegam 80% dos regressões — está ali, esperando, e custa quase nada. Exemplo concreto: para um agente que classifica uma solicitação de colaborador em "férias / reembolso / atestado / outro", o eval Nível 1 não precisa de IA nenhuma: é uma lista de 40 casos rotulados à mão e uma asserção de que a classificação bate. Isso roda em segundos, em cada deploy, e te diz no ato se a última mudança de prompt quebrou alguma coisa.

2. "Olhe para os seus dados" — sem atalho

A frase de Husain que mais incomoda é também a mais importante: "Você nunca pode parar de olhar para os dados — não existe almoço grátis." E o corolário operacional: "Remova TODO atrito de olhar para os dados."

Isso parece óbvio e quase nunca é feito. A maioria dos times constrói o sistema, mede uma métrica agregada (acurácia 87%!) e nunca lê as transcrições reais. Husain inverte: construa, antes de qualquer coisa, a ferramenta que te deixa ler os outputs reais sem fricção — uma planilha, um pequeno dashboard, um notebook. Porque a métrica agregada esconde os modos de falha que importam, e você só descobre lendo. Exemplo concreto: num sistema de RAG, a "acurácia" pode estar alta enquanto 100% dos erros se concentram num único tipo de pergunta que vale 40% da receita. Você só vê isso lendo as falhas, uma a uma, até os padrões emergirem.

3. Guardrails: validar a saída antes que ela cause dano

Yan trata guardrails como infraestrutura, não como enfeite. "Guardrails validam a saída dos LLMs, garantindo que ela não apenas soe bem, mas seja sintaticamente correta, factual e livre de conteúdo nocivo." Eles existem em três camadas: guardrails de input (limitar o tipo de entrada a que o modelo responde — primeira defesa contra entradas adversariais), guardrails de estrutura (a saída é JSON válido? tem os campos obrigatórios?) e guardrails semânticos/de factualidade (o resumo de fato representa a fonte? a resposta é relevante à pergunta?). O ponto de Yan: "Eles ajudam a garantir que as saídas do modelo sejam confiáveis e consistentes o bastante para usar em produção." Guardrail não é luxo de empresa grande; é o que te deixa dormir.

4. O abismo entre demo e produto

Yan tem uma frase que devia estar pendurada em toda sala onde se decide investir em IA: "Existe uma grande classe de problemas que são fáceis de imaginar e de construir demos, mas extremamente difíceis de transformar em produto." Esse abismo é onde a maioria dos projetos de IA morre — não na prova de conceito, que sempre funciona na primeira reunião, mas no longo caminho de torná-la confiável diante de inputs reais, casos de borda, usuários hostis e o modelo mudando por baixo dos panos. Evals e guardrails são, literalmente, a ponte sobre esse abismo.

5. Fine-tuning vs. RAG: para que serve cada coisa

Husain corta um mal-entendido comum com uma distinção limpa: "Fine-tuning é melhor para aprender sintaxe, estilo e regras, enquanto técnicas como RAG fornecem ao modelo contexto ou fatos atualizados." Ou seja: se o problema é "o modelo não conhece os fatos do meu domínio / dados de ontem", isso é RAG. Se o problema é "o modelo não fala do jeito certo, não segue o formato, não obedece às regras do meu domínio", isso pode ser fine-tuning. Confundir os dois é como tomar antibiótico para dor de cabeça. E Yan reforça por que dados são o que importa de verdade: "Dados — corpus de pré-treino, demonstrações feitas por especialistas, preferências humanas para reward modeling — são um dos poucos fossos defensáveis para produtos de LLM."

Em suas palavras

"Like software engineering, success with AI hinges on how fast you can iterate." — Hamel Husain, Your AI Product Needs Evals

"You can never stop looking at data—no free lunch exists. Remove ALL friction from looking at data." — Hamel Husain, Your AI Product Needs Evals

"How important evals are to the team is a major differentiator between folks rushing out hot garbage and those seriously building products in the space." — Eugene Yan, Patterns for Building LLM-based Systems & Products

"Without evals, we would be flying blind, or would have to visually inspect LLM outputs with each change. Think of it as Eval Driven Development (EDD)." — Eugene Yan

"There is a large class of problems that are easy to imagine and build demos for, but extremely hard to make products out of." — Eugene Yan

Limites e críticas

Nenhuma metodologia é grátis, e é honesto nomear o custo.

Evals dão trabalho, e trabalho que não some. Construir e manter um conjunto de avaliação é esforço contínuo: rotular casos, atualizar quando o produto muda, curar exemplos. Para um time pequeno isso compete com a entrega de features. A resposta de Husain — comece pelo Nível 1, que é barato — atenua, mas não elimina. Há um julgamento de quando o investimento se paga, e a tentação de pular evals é real exatamente quando você está com pressa, que é o pior momento.

LLM-as-judge tem vieses. Usar um modelo para julgar outro é prático e escala, mas modelos-juízes têm vieses conhecidos (preferem respostas mais longas, preferem o próprio estilo, são sensíveis à ordem). Yan é o primeiro a alertar sobre isso e a dizer que LLM-judge precisa ele mesmo ser validado contra rótulos humanos. Quem trata o juiz automático como verdade absoluta repete o erro de confiar na métrica agregada.

Generalização limitada de evals. Um eval mede o que você pensou em medir. Modos de falha que você não imaginou passam despercebidos — daí a insistência de Husain em continuar olhando os dados manualmente, além dos evals automáticos. Eval não substitui leitura; complementa.

Risco de cargo cult. Há gente que cita "precisa de evals" como senha de pertencimento e constrói suítes elaboradas que não medem nada que importa para o negócio. O método só vale se os casos de teste refletirem o que de fato dá errado e custa dinheiro. Isso exige conhecimento de domínio, não só de engenharia.

Como aplicar no seu dia a dia

A regra que se tira da dupla é dura e simples: não coloque um agente de IA na frente de um processo real antes de ter uma suíte de evals confiável. Confiança em IA não se decreta; se mede.

Agentes que atendem solicitações — o caso mais óbvio. Os agentes que classificam, respondem e roteiam solicitações de usuários são exatamente o tipo de sistema que parece pronto na demo e quebra em produção. Antes de confiar neles, siga o playbook:

1. Nível 1 desde o dia zero. Para cada agente, um conjunto de 30–50 casos reais rotulados à mão (extraídos de tickets antigos), com asserções concretas: classificação correta, saída em JSON válido, campos obrigatórios presentes, zero vazamento de dado de outro usuário. Isso roda em cada deploy. Se uma mudança de prompt quebra um caso, você sabe antes do cliente.
2. Remova o atrito de olhar dados. Um painel interno simples onde você (e o time de suporte) lê transcrições reais dos agentes toda semana. Não métrica agregada — transcrições. É ali que os modos de falha aparecem.
3. Guardrails em três camadas. Input (o agente só responde a categorias de solicitação previstas); estrutura (toda saída validada contra schema antes de seguir para o sistema downstream — isso conversa direto com structured outputs); semântica (um checador confirma que a resposta é relevante à pergunta, e qualquer coisa abaixo do limiar vai para humano).
4. EDD para novos agentes. Cada novo agente nasce com seus evals escritos antes do prompt final. Defina "como vou saber que isso funciona" antes de "como faço isso funcionar".

Onde o uso de IA é mais pontual. Em usos mais pontuais — previsão de demanda, classificação de chamados, análise de dados operacionais — o princípio de Yan continua valendo: a demo de "IA prevê a demanda da unidade" é fácil; o produto confiável exige medir erro real contra dados reais ao longo de meses, com guardrails que impeçam uma previsão absurda de virar decisão de compra. Antes de qualquer modelo entrar num fluxo de decisão de capital, ele passa por backtest e por um guardrail de sanidade.

A síntese operacional: trate IA como qualquer outro sistema crítico do negócio. Você não bota um software financeiro em produção sem testes; não vai botar um agente decidindo coisas sem evals.

Para ir além

Comece por: o ensaio de Husain "Your AI Product Needs Evals" (hamel.dev/blog/posts/evals) — é a porta de entrada, com a hierarquia de três níveis explicada de forma acionável. Leia com um caso seu em mente e tente escrever cinco asserções de Nível 1 enquanto lê.

Depois: "Patterns for Building LLM-based Systems & Products", de Eugene Yan (eugeneyan.com/writing/llm-patterns) — o mapa completo dos sete padrões de produção (evals, RAG, fine-tuning, caching, guardrails, defensive UX, feedback). E o material conjunto "What We Learned from a Year of Building with LLMs", escrito por Husain, Yan e outros praticantes — lições de quem operou, não de quem teorizou.

Avançado: "Task-Specific LLM Evals that Do & Don't Work" (eugeneyan.com/writing/evals) e "A Field Guide to Rapidly Improving AI Products" (hamel.dev) — ambos descem ao detalhe de como construir evals que de fato discriminam qualidade, e como evitar os evals que dão falsa sensação de segurança.

Conexões no vault

• IA e Tecnologia — área-mãe deste estudo
• Templates — usar como base para montar a eval suite dos agentes do Gestão de Colabs (template de casos rotulados + asserções de Nível 1)
• jason-liu-riley-goodside — structured outputs (Jason Liu / Instructor) é a camada que faz os guardrails de estrutura de Yan funcionarem na prática; e a engenharia de prompt rigorosa de Goodside é o que você está, no fim, avaliando
• swyx — co-conduziu com Husain a conversa "Why Your AI Product Needs Evals"; ponte para o ecossistema de AI Engineering
• andrej-karpathy — visão de mais alto nível sobre o que os modelos conseguem e não conseguem fazer