No mês passado, lancei uma mudança de pipeline da qual eu estava genuinamente orgulhoso. Uma reescrita de prompt. Uma etapa de revisão com contexto completo. Uma rubrica detalhada para detectar repetição e garantir variedade estrutural entre os segmentos.
Fiz o deploy. Observei por seis semanas. Disse a mim mesmo que estava funcionando.
Então construí um framework de avaliação. Executei-o em 40 episódios reais de produção em 7 idiomas. E descobri que a etapa de revisão — aquela que eu havia projetado com tanto cuidado — estava tornando os roteiros mensuravelmente piores.
Não neutro. Pior.
O diálogo por segmento pontuou 3,34 de 5. O outline pontuou 3,01. E o roteiro final, após a revisão? 2,91.
A etapa projetada para melhorar os roteiros estava reduzindo a qualidade em mais de 12%.
Essa mudança — de "acho que está funcionando" para "sei que não está" — começou há algumas semanas. Eu estava assistindo ao curso de IA Agentic do Andrew Ng no DeepLearning.AI, onde ele enfatiza algo que parece óbvio mas não é: avaliações e rastreamentos são a base de qualquer sistema agêntico. Sem eles, você está depurando no escuro. Com eles, você sabe exatamente qual elo da corrente quebrou.
Eu vinha fazendo verificações de qualidade de roteiro ad-hoc há meses — métricas estruturais como proporções de turnos e equilíbrio de locutores, mais um juiz LLM comparando variantes de prompt A/B. Elas detectavam regressões óbvias. Mas não eram abrangentes. Cobriam uma etapa (diálogo), um idioma por vez, e eram projetadas para testes A/B de prompts, não para auditorias de qualidade em todo o pipeline.
O argumento do Andrew sobre rastreamentos me atingiu em cheio. Meu pipeline tem cinco chamadas LLM principais por episódio — pesquisa, outline, diálogo por segmento, intro/encerramento e revisão — mais uma passagem de TTS da ElevenLabs. Eu tinha métricas de qualidade para uma delas. As outras quatro estavam sendo confiadas apenas por instinto.
Então construí um sistema de avaliação de verdade. Completo. Multidimensional. Reexecutável. Aqui está o que ele encontrou, as seis correções que lancei em um dia e o que realmente melhorou.
A Linha de Base: Três Números que Mudaram Tudo
Avaliei 40 episódios concluídos do meu banco de dados de produção — cobrindo todos os 7 idiomas (en, vi, ja, ko, es, zh, fr) e 10 estilos de podcast — contra três rubricas com cinco dimensões cada. Um juiz LLM (GPT-5.6-terra) classificou cada etapa.
| Stage | Score | Worst Dimension |
|---|---|---|
| Dialogue (per-segment) | 3.34 | Factual Grounding: 2.17 |
| Outline (research + structure) | 3.01 | Citation Credibility: 1.28 |
| Final Script (post-review) | 2.91 | Publishability: 1.95 |
Três coisas saltaram aos olhos imediatamente:
1. A passagem de revisão estava degradando os roteiros em 0,43. O diálogo pontuou 3,34. Após a revisão? 2,91. A etapa projetada para melhorar a qualidade estava removendo-a.
2. Todas as URLs de citação eram redirecionamentos opacos. Cada "URL fonte" em cada outline apontava para vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQ.... Funcionam para humanos que clicam, mas parecem completamente fabricadas para revisores automatizados. 344 fatos tinham URLs fonte. Zero tinham resolved_url — um campo que nem existia ainda.
3. Publicabilidade foi a dimensão mais baixa em todo o pipeline (1,95). Podcasters reais, determinou o juiz de avaliação, não publicariam esses roteiros sob o próprio nome. Padrões de IA detectáveis: aberturas de segmento idênticas, transições genéricas, falta de personalidade do apresentador.
A avaliação me deu uma lista ranqueada do que exatamente corrigir. Passei o resto do dia corrigindo.
As Seis Correções (E Seu Impacto Medido)
Correção 1: URLs de Citação — 0% para 100% de Resolução
Antes: 0 de 344 fatos de pesquisa tinham um resolved_url. Cada URL parecia fabricada.
Correção: Um resolvedor de URL de 60 linhas que roda durante a geração do outline, segue o redirecionamento do Vertex AI até a fonte real e armazena ambas as URLs (original para conformidade com os ToS do Google, resolvida para todo o resto).
def resolve_grounding_url(url: str) -> str:
if "grounding-api-redirect" not in url:
return url
response = requests.head(url, allow_redirects=True, timeout=5)
return response.url if response.url != url else url
Depois: 23 de 23 fatos de pesquisa nos novos episódios de hoje têm resolved_url preenchido — URLs reais como simonwillison.net, axios.com, thinkingmachines.ai. 100% de resolução.
Correção 2: Troquei o Modelo de Revisão (Gemini → DeepSeek)
Antes: Gemini 3.5 Flash executava a passagem de revisão. Fazia edições leves e conservadoras: mudava "Exactly!" para "No question about it!" mas quase sempre preservava o texto original. Adicionava enchimento que aplainava o diálogo. A densidade de tags de áudio caía. A razão type-token caía. A contagem de turnos inflava.
Correção: Troquei a passagem de revisão para DeepSeek v4-pro (384K de saída máxima, limitado a 96K). Tornei o provedor configurável:
provider = get_provider("review") # reads REVIEW_PROVIDER env var
response = provider.generate(
prompt=prompt, temperature=0.0,
max_output_tokens=96000,
)
Verificação: Implantado em produção. Um episódio de notícias de tecnologia em vietnamita passou pelo pipeline completo com revisão DeepSeek — 10,3K → 11,6K tokens, concluído em 121 segundos, 0 passagens de aperto necessárias. Um segundo episódio (inglês) processou 7,9K → 17K tokens em 203 segundos. A chave da API DeepSeek reside no Google Cloud Secret Manager, injetada automaticamente no deploy via service.yaml.
Correção 3: Autocrítica do Outline (Melhoria de +0,50)
Antes: Os outlines iam direto do Gemini para o usuário sem nenhuma verificação de qualidade interna. Pontuação média: 3,01.
Correção: Adicionei uma etapa de crítica automatizada. O DeepSeek v4-pro avalia o outline contra uma rubrica de 6 dimensões (as 5 dimensões do outline mais a contagem de segmentos), retorna pontuações + feedback específico e armazena a crítica nos metadados do podcast.
Então executei um experimento controlado: pegue 6 episódios cujos outlines pontuaram abaixo de 3,0, execute a crítica do DeepSeek, alimente o feedback de volta ao Gemini como instruções de regeneração e reclassifique.
Depois: Melhoria geral de +0,50 nos 6 episódios.
| Dimension | Before | After | Delta |
|---|---|---|---|
| Content Boundaries | 3.33 | 4.17 | +0.83 |
| Research Depth | 2.67 | 3.17 | +0.50 |
| Citation Credibility | 1.00 | 1.50 | +0.50 |
| Structural Logic | 3.67 | 4.17 | +0.50 |
| Audience Fit | 2.17 | 2.33 | +0.17 |
O pior episódio foi de 1,80 para 3,20 (+1,40). Apenas 1 de 6 piorou. A crítica agora está habilitada por padrão em produção — todo novo outline recebe essa verificação de qualidade antes que o usuário o veja.
Correção 4: Outlines de Um Segmento Agora Falham Forte
Antes: A avaliação mostrou episódios com um único segmento e zero fatos de pesquisa pontuando tão baixo quanto 2,07. Esses eram casos de falha que o pipeline não estava tratando como falhas.
Correção: Se o gerador de outline produzir menos de 3 segmentos válidos após uma tentativa de recuperação, o podcast é marcado como FAILED. Chega de outlines de um segmento chegando aos usuários. Na próxima tentativa de criação, o crédito do usuário é liberado para tentar novamente.
Correção 5: Regras de Localização para Chinês
Antes: Os episódios em chinês pontuaram 2,88 — o mais baixo entre os 7 idiomas. Artefatos de tradução (expressões idiomáticas em inglês traduzidas literalmente), aberturas de segmento idênticas, nomes de apresentadores padrão em inglês (Alex/Maya) em vez de nomes chineses (明辉/晓雯).
Correção: Escrevi regras de diálogo específicas para chinês: padrões conversacionais nativos (construções 不是...而是...), partículas finais de frase apropriadas (吧/啊/呢), diretrizes anti-tradução (nunca traduza "medical miracle" literalmente), metáforas de futebol chinês para episódios da Copa do Mundo e perfis de apresentadores específicos por localidade com personalidades distintas.
O template de diálogo em chinês passou de reutilizar padrões em inglês para ter seu próprio guia de 80 linhas cobrindo padrões conversacionais, frases para expressar discordância e enquadramento específico para cada estilo de podcast.
Correção 6: Nomes de Apresentadores Padrão para Não-Inglês
Antes: Vários episódios em idiomas não-ingleses tinham apresentadores chamados Alex e Maya. Os perfis de apresentadores específicos por localidade existiam, mas o caminho de fallback no gerador de outline estava hardcoded para os padrões em inglês.
Correção: Rastreei a correção pelo pipeline de resolução de perfis com reconhecimento de localidade. Episódios de produção recentes agora usam 翔太/健一 (ja), Mạnh/Nga (vi), Hugo/Camille (fr), 明辉/晓雯 (zh). Os commits de julho já haviam corrigido a edge function e o fluxo de criação — o fallback restante estava no próprio gerador de outline.
O Framework de Avaliação (Reutilizável)
O framework que encontrou tudo isso tem ~500 linhas de Python, três arquivos de rubrica (5 dimensões cada), um juiz GPT-5.6-terra compartilhado e um orquestrador:
docs/pipeline/evals/
├── run.py # Orchestrator: extract → judge → report
├── judge.py # Shared LLM judge (rate with rubric)
├── rubric_outline.py # Stage 1: 5 dimensions, 1-5 scale
├── rubric_dialogue.py # Stage 2: 5 dimensions, 1-5 scale
├── rubric_final_script.py # Stage 3: 5 dimensions, 1-5 scale
├── dataset_40.json # Extracted production data
├── scores.json # Machine-readable scores
└── report.md # Auto-generated report
Também construí uma camada de experimentos para comparações A/B:
docs/pipeline/evals/experiments/
├── review_ab.py # Compare two review models
├── outline_critique_ab.py # Critique → regenerate → compare
├── shared.py # Score comparator, report generator
└── results/ # Archived by date
Execute python docs/pipeline/evals/run.py --full após qualquer mudança no pipeline e obtenha um relatório em ~8 minutos. Execute experiments/review_ab.py --episodes 10 para comparar modelos. Os resultados são arquivados por data para acompanhamento de tendências — quer saber se a qualidade melhorou este mês vs mês passado? Faça diff das pontuações.
A avaliação completa de 40 episódios custa cerca de $1-2 em chamadas de API. Os experimentos custam menos. Pelo sinal que você recebe de volta — uma lista ranqueada de exatamente quais etapas e dimensões do pipeline precisam de atenção — é a ferramenta de depuração mais barata que já construí.
O Que Ainda Está Quebrado
O experimento A/B de revisão do DeepSeek precisa do prompt de produção completo. O script do experimento usou um prompt simplificado de 15 linhas. A revisão em produção usa um prompt de 80 linhas com regras anti-repetição, cotas de frases características, barreiras editoriais e política de duração. Com o prompt simplificado, o DeepSeek mostrou resultados essencialmente neutros (-0,04). Com o prompt completo em produção, o pipeline está concluindo com sucesso em inglês e vietnamita. Preciso atualizar o experimento para refletir a produção e reexecutar.
A localização para chinês precisa de validação. As regras parecem corretas no papel, os perfis de apresentadores estão escritos, os guias de diálogo estão no lugar. Mas ainda não executei a avaliação em novos episódios em chinês para confirmar que a pontuação subiu de 2,88. Essa é uma prioridade para esta semana.
Preciso reexecutar a avaliação completa de 40 episódios em novos episódios. Todas as seis correções estão implantadas. O próximo passo é extrair 40 episódios gerados após essas mudanças, passá-los pelas mesmas avaliações e comparar com a linha de base histórica. Se a pontuação do roteiro final passar de 2,91 para acima de 3,0, e a credibilidade das citações passar de 1,28 para algo razoável, saberei que as mudanças funcionaram de ponta a ponta.
A Auditoria de Pipeline de Três Perguntas
Após essa experiência, agora audito cada mudança de pipeline com três perguntas:
1. Existe uma barreira de qualidade entre cada etapa? Meu outline ia do Gemini direto para o usuário. Adicionar a etapa de crítica capturou os piores outlines antes que alguém os visse. Cada etapa do pipeline precisa de uma verificação de qualidade — avaliação LLM automatizada contra critérios explícitos.
2. Cada etapa realmente melhora a qualidade quando medida? Executar e assumir que ajuda não é suficiente. Você precisa de pontuações antes/depois literais no mesmo conteúdo. Minha etapa de revisão degradou roteiros por seis semanas antes de eu medir. Meça primeiro, não assuma nada.
3. Consigo identificar qual dimensão quebrou? "Qualidade está ruim" não é acionável. "Credibilidade das citações é 1,28 porque 100% das URLs são redirecionamentos opacos" é. Uma rubrica multidimensional por etapa te diz exatamente onde olhar. Passei horas investigando minha etapa de revisão antes da avaliação. Com a avaliação, passei segundos — os números apontaram diretamente para publicabilidade e o modelo de revisão.
Perguntas Frequentes
Executar avaliações LLM não fica caro?
A avaliação completa de 40 episódios custa cerca de $1-2 em chamadas de API (GPT-5.6-terra, ~420K tokens totais). Os experimentos A/B custam ainda menos. Pelo sinal que você recebe de volta — uma lista ranqueada de exatamente quais etapas do pipeline precisam de atenção — é a ferramenta de depuração mais barata que já construí, e mais barata do que os créditos que os usuários desperdiçariam em episódios quebrados.
Por que 5 dimensões por etapa? Por que não apenas "qualidade geral"?
"Qualidade geral" te diz que algo está errado. Não te diz o quê. Quando vi Credibilidade das Citações em 1,28, soube imediatamente que as URLs estavam quebradas. Quando vi Publicabilidade em 1,95, soube que os sinais de IA eram detectáveis. Cinco dimensões te dão um diagnóstico diferencial. Uma dimensão te dá um termômetro de febre.
Como você mantém o juiz LLM consistente?
Mesmo modelo (GPT-5.6-terra), mesma temperatura (0,0), mesmo esforço de raciocínio (medium), mesmos prompts de rubrica sempre. As pontuações são arquivadas com timestamps para que você possa comparar entre datas. Trocar o juiz muda a linha de base — escolha um e mantenha-o.
O que acontece quando o próprio juiz está errado?
A rubrica inclui justificativas obrigatórias para cada pontuação — o juiz precisa citar evidências específicas do conteúdo. Também fiz uma revisão qualitativa manual de 10 episódios em todos os 7 idiomas para calibrar o juiz. As pontuações do LLM corresponderam de perto ao meu julgamento humano. Para dimensões críticas onde o LLM pode não ser confiável (como "publicabilidade", que requer julgamento cultural), verificações manuais pontuais são essenciais.
Construo o DIALOGUE, uma plataforma de podcasts de IA, sozinho, nas minhas noites e fins de semana. Escrevo sobre o que aprendo pelo caminho.
Se você construiu um sistema de avaliação para seu próprio pipeline LLM, fico curioso: como você mede a qualidade, e o que você descobriu que te surpreendeu?
É isso, pessoal.
Abraços, Chandler