
Avaliação de LLM Online vs Offline: De Qual Você Precisa (e Quando)
Avaliação de LLM online vs offline é uma decisão só, não duas, e nossa suíte no promptfoo provou isso na terça passada: um system prompt reescrito, 47 casos de teste, a fidelidade caiu de 0,91 para 0,74 em cerca de 90 segundos de CI. O check offline pegou essa regressão antes do merge; o monitoramento em produção só a encontraria depois, disfarçada de ticket de suporte. Offline ou online, o veredito é o mesmo: duas faixas, trabalhos diferentes.
A avaliação offline de LLM roda seu modelo contra um dataset fixo antes do deploy, provando que uma mudança não quebrou a qualidade medida. A avaliação online pontua o tráfego real de produção depois do lançamento, expondo o que o dataset nunca conteve. A maioria das equipes precisa das duas, em sequência: a offline barra o deploy, a online pega a deriva.
Principais Aprendizados
- A avaliação offline roda contra um dataset fixo antes do deploy; a avaliação online pontua o tráfego real depois do lançamento.
- A maioria das equipes precisa das duas: a offline barra deploys, a online pega o que o dataset deixou passar.
- A offline pega regressões de prompt e quebras de formato; a online pega deriva, latência sob carga e peculiaridades de integração.
- Configure os evals offline como gate de merge no CI; transmita as notas online das traces de produção para o seu conjunto de evals.
Como as Avaliações Online e Offline Realmente Diferem? (9 Dimensões)
Os dois modos diferem em nove eixos, mas o decisivo é a fonte de dados: a avaliação offline pontua um dataset fixo e versionado antes do deploy, enquanto a avaliação online pontua o tráfego real depois do lançamento. Toda outra diferença (custo, latência, risco, governança) decorre dessa divisão.
O centro de aprendizado do Label Studio apresenta a dupla como modos complementares, não rivais, e concordamos. A tabela estende esse enquadramento com métricas específicas de LLM que a versão genérica de ML deles não cobre.
| Dimensão | Offline | Online |
|---|---|---|
| Fonte de dados | Dataset dourado fixo, versionado no git | Traces de produção reais, amostrados |
| Momento | Antes do deploy, em todo PR | Depois do lançamento, contínuo |
| Custo por rodada | Tokens de judge por suíte rodada; custo marginal quase zero | Tokens de judge sobre tráfego amostrado; escala com o volume |
| Restrição de latência | Nenhuma; rode em lote com calma | Orçamentos de sub-segundo em caminhos críticos |
| Risco para usuários | Zero; falhas nunca chegam aos usuários | Real; saídas ruins atingem sessões ao vivo |
| Velocidade de feedback | Minutos por PR | Segundos a minutos em streams |
| Tipos de métrica | Fidelidade, relevância de resposta, conformidade de formato, notas de benchmark | Percentis de latência, taxa de erro, taxa de alucinação, feedback de usuários |
| Reprodutibilidade | Determinística com modelo e dataset fixados | Não determinística; o mix do tráfego muda todo dia |
| Governança e auditoria | Artefatos versionados, comparáveis entre releases | Dashboards e alertas; mais difícil de reproduzir |
Nossa leitura: a coluna offline responde "essa mudança quebrou algo?", e a coluna online responde "a produção está se afastando do que testamos?". A linha de tipos de métrica é onde as duas mais divergem; nosso guia de métricas de avaliação de LLM detalha cada uma.
O Que Cada Modo Pega, e O Que Passa Pelos Dois?
Cada modo é dono de uma classe de falha privada que o outro não vê. A offline pega mudanças que você fez; a online pega mudanças que o mundo fez ao seu redor. As falhas caras, aquelas que sobrevivem às duas redes, precisam de um revisor humano. Esta taxonomia é a nossa síntese do que cada modo reporta, não um padrão publicado.
| Quadrante | Exemplos | Ação |
|---|---|---|
| Só offline | Regressões de prompt, formatos de saída quebrados, quedas de nota em benchmark, fidelidade abaixo do limite | Bloquear o merge no CI |
| Só online | Deriva de distribuição, latência sob carga, peculiaridades de integração, padrões de abuso adversarial | Alertar, amostrar as traces, enviá-las ao conjunto de evals |
| Pego pelos dois | Picos na taxa de alucinação, erosão de consistência factual | Manter os dois; dedupe o esforço, não a cobertura |
| Pego por nenhum | Casos extremos inéditos, julgamentos subjetivos de qualidade, deriva da voz da marca | Fila de revisão humana; casos rotulados alimentam o conjunto offline |
O quadrante "só offline" é onde os gates de CI se pagam: um prompt reescrito que derruba silenciosamente a conformidade de formato de 99% para 91% é invisível no code review e óbvio numa suíte de 47 casos. O quadrante "só online" é mais traiçoeiro. Usuários reais formulam coisas que o seu conjunto dourado nunca formulou, APIs de terceiros expiram em horários que o staging nunca atinge, e alguém vai enviar um prompt de 40.000 caracteres para o seu chatbot só para ver o que acontece. Para esse lado, nosso guia sobre avaliar agentes em produção cobre a pontuação de trajetórias em múltiplas etapas, não apenas saídas únicas.
A linha de baixo é a que as equipes pulam, e a que as queima. As falhas que custam usuários são as que nenhum modo pega sozinho. Elas precisam de um humano no loop.
Como Configurar Evals Offline num Gate de CI? (A Config Que Ninguém Mostra)
Adicione um runner de eval como status check obrigatório em todo pull request que toque em prompt, modelo ou configuração de retrieval. Afirme um limite. Bloqueie o merge abaixo dele. O promptfoo documenta exatamente esse padrão de CI, e é o que rodamos.
O step no GitHub Actions
Uma versão enxuta do gate que rodamos hoje:
name: llm-eval-gate
on:
pull_request:
paths: ["prompts/**", "evals/**", "src/rag/**"]
jobs:
faithfulness-gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- name: Run offline evals, fail the PR on regression
run: npx promptfoo@latest eval --config evals/support-agent.yaml
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} # LLM-as-judgeA configuração YAML declara os casos de teste e as asserções; o eval sai com código diferente de zero quando a suíte fica abaixo do limite, o GitHub marca o check obrigatório como falho, e o botão de merge fica cinza. O filtro de paths importa: uma correção de README não deveria queimar tokens de judge.
O que o gate realmente pega
A versão ao vivo pontua nossa cadeia RAG do agente de suporte contra 47 casos dourados em todo PR que afeta prompts. Uma rodada completa leva cerca de 90 segundos de tempo de CI, e o merge é bloqueado automaticamente se a fidelidade cair abaixo de 0,82. Em três meses, ele pegou duas regressões que de outra forma teriam sido publicadas: uma reescrita de system prompt que empurrou a fidelidade de 0,91 para 0,74, e uma mudança no retriever que dobrou o tamanho do contexto e arrastou a relevância de resposta para baixo do limite. Nenhuma das duas parecia perigosa no review.
Um gate de fidelidade no CI custa 90 segundos por PR. Uma regressão de fidelidade em produção custa um ticket de suporte e um rollback.
Comparamos os runners que você pode plugar nesse padrão (promptfoo, DeepEval e o resto) no nosso roundup de ferramentas de avaliação de LLM.
Quais Ferramentas Rodam Qual Modo? (Matriz Ferramenta-Modo)
Nenhuma ferramenta domina as duas faixas com folga. promptfoo e DeepEval são runners offline-first que podem pontuar dados de produção exportados de forma agendada; Langfuse e LangSmith são depósitos de traces online-first que acoplam pontuadores LLM-as-judge às traces ingeridas. A matriz é a nossa leitura da documentação de cada fornecedor: interpretação, não evangelho.
| Ferramenta | Runner offline | Pontuador online | Ambos nativamente? | O que ela NÃO faz |
|---|---|---|---|---|
| promptfoo | Sim: suítes YAML, nativo de CI, pacotes de red-team | Parcial: as mesmas configs contra logs exportados | Offline-first; o online precisa de um passo de exportação | Ingerir traces ao vivo; atuar como dashboard de monitoramento |
| DeepEval | Sim: testes estilo pytest, 14+ métricas | Sim, via plataforma Confident AI | Sim, com o add-on hospedado | A biblioteca open-source sozinha é só offline |
| Langfuse | Parcial: experimentos de dataset via SDK | Sim: avaliadores judge nas traces ingeridas | Sim: datasets mais pontuadores de traces | Rodar seu gate de merge no CI; isso você conecta sozinho |
| LangSmith | Sim: datasets e experimentos offline | Sim: automações pontuam traces amostradas | Sim | Viver fora da stack LangChain sem atrito |
| OpenAI Evals | Sim: evals YAML estilo registry | Não | Não | Pipelines de traces de produção; modelos fora da OpenAI |
| Arize Phoenix | Sim: experimentos notebook-first | Sim: spans e traces com avaliadores inline | Sim | Setup leve; a observabilidade vem primeiro |
Escolha promptfoo ou DeepEval se a sua primeira necessidade é um gate de merge que barra prompts ruins no CI. Escolha Langfuse ou LangSmith se a sua primeira necessidade é pontuar tráfego ao vivo, e nossa comparação Langfuse vs LangSmith detalha essa escolha. O OpenAI Evals continua sendo o ponto fora da curva: um runner offline estilo registry sem lado de produção.
O promptfoo barra seus PRs. O Langfuse pontua suas traces de produção. Um não substitui o outro.
Como o Loop de Feedback Transforma Falhas Online em Testes Offline?
Amostre traces de produção com nota baixa, rotule-as e faça o commit no conjunto de evals offline. A suíte de regressão então cresce com cada surpresa que a produção joga em você, e o próximo deploy é barrado no conjunto expandido. O enquadramento de flywheel é nosso; é a parte que a maioria das equipes nunca constrói.
O ciclo, como o rodamos:
- Os pontuadores online sinalizam traces abaixo de 0,7 de nota do judge.
- Amostramos de 20 a 30 traces sinalizadas por semana.
- Um humano rotula cada uma: saída esperada mais classe de falha.
- Os casos rotulados entram no conjunto de evals offline como novos exemplos dourados.
- O próximo PR roda contra a suíte expandida, e o loop recomeça.
A amostragem começa na sua camada de observabilidade de LLM, porque as traces são a matéria-prima. Sobre cadência: semanal vence mensal, porque a deriva se acumula. Rotulamos de 10 a 15 casos por semana, e o conjunto fica "grande o suficiente" quando novos rótulos param de mover a taxa de aprovação, em torno de 150 a 250 casos para um agente de suporte estreito. A linha entre os modos continua se borrando: a Deepchecks relata que engenheiros da Union.ai agendam suas avaliações "offline" a cada poucos minutos, efetivamente transformando-as em checks quase em tempo real.
Seu conjunto de evals não é um artefato fixo. Ele cresce toda semana em que a produção surpreende você.
Quando Você Precisa das Duas? (Avaliação de LLM Online vs Offline por Estágio)
Você precisa das duas desde a semana de lançamento em diante, mas o equilíbrio muda por estágio: a offline carrega sozinha o trabalho pré-deploy, a semana de lançamento adiciona pontuação shadow ou canary, o estado estacionário se apoia no monitoramento online com re-rodadas offline periódicas, e um alerta de deriva deveria terminar num teste offline reproduzido mais um conjunto de evals maior.
| Estágio | Offline | Online | Ação |
|---|---|---|---|
| Pré-deploy | Gate de regressão em todo PR | Nenhuma ainda | Bloquear merge abaixo do limite |
| Semana de lançamento | Suíte completa no release candidate | Pontuação shadow ou canary em 5-10% do tráfego | Comparar as notas online com a baseline offline |
| Estado estacionário | Reavaliação periódica num dataset renovado, semanal ou mensal | Pontuação amostrada contínua mais alertas | Vigiar a deriva; redefinir a baseline trimestralmente |
| Deriva detectada | Reproduzir offline as traces que falharam | O alerta que disparou o gatilho | Adicionar traces rotuladas ao conjunto de evals; barrar de novo o próximo deploy |
O pré-deploy é o lugar mais barato para ser rigoroso: um merge bloqueado custa minutos; um release ruim custa confiança. A semana de lançamento é onde as equipes investem pouco, embora a pontuação shadow numa fatia pequena de tráfego custe pouco e revele se o conjunto dourado mentiu. O estado estacionário é onde a complacência se instala, então coloque a reavaliação no calendário.
E o EU AI Act?
As obrigações de alto risco do EU AI Act entram em vigor gradualmente até agosto de 2026, com o cronograma completo de prazos publicado no EUR-Lex, e o padrão de conformidade se encaixa de forma limpa nos dois modos. Evidência offline documentada mostra que o sistema cumpriu as metas de qualidade antes do release; o monitoramento online contínuo mostra que ele continua cumprindo depois. Nossa leitura é que uma trilha de auditoria precisa dos dois artefatos, porque logs offline sozinhos não provam que o sistema permaneceu conforme, e dashboards sozinhos não provam que ele foi lançado conforme. Isso é interpretação, não aconselhamento jurídico; nosso pilar de pipeline de avaliação de LLM mapeia o conjunto completo de requisitos.
A avaliação offline é a sua evidência. A avaliação online é o seu sistema de alerta precoce. Os reguladores querem as duas.
Sobre o autor: Mert Batur é cofundador da Techsy.io, onde a equipe entrega agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Ele escreve sobre a stack de ferramentas de LLM que a equipe da Techsy realmente usa em produção. Conecte-se no LinkedIn.
Perguntas Frequentes
O que é avaliação offline de LLM?
A avaliação offline de LLM roda um modelo ou prompt contra um dataset fixo e versionado antes do deploy. Os checks típicos incluem fidelidade ao contexto recuperado, relevância de resposta, conformidade de formato e notas de benchmark. Como o dataset nunca muda no meio da rodada, os resultados são reproduzíveis e comparáveis, que é exatamente o motivo pelo qual as suítes offline funcionam como gates de merge no CI.
O que é avaliação online de LLM?
A avaliação online de LLM pontua o tráfego real de produção depois do lançamento. Um pontuador LLM-as-judge avalia traces amostradas quanto a alucinação, tom ou correção de tool calls, e as notas fluem para um dashboard. Ela também absorve sinais que os testes offline não veem: latência sob carga, feedback de usuários e como as consultas reais diferem do seu conjunto dourado.
Quando devo usar avaliação de LLM offline vs online?
Use a avaliação offline para barrar deploys: toda mudança de prompt, modelo ou retrieval deveria passar pela suíte antes do merge. Use a avaliação online para monitorar o que foi publicado. A maioria das equipes sequencia as duas em vez de escolher uma: offline primeiro, online a partir da semana de lançamento, com as falhas de produção fluindo de volta para o conjunto offline.
Qual é um exemplo de avaliação de LLM online vs offline?
Exemplo offline: uma suíte promptfoo roda 200 perguntas douradas de suporte em todo pull request e bloqueia o merge se a fidelidade cair abaixo de 0,82. Exemplo online: o Langfuse pontua 10% das traces ao vivo com um check de alucinação LLM-as-judge e alerta quando a média semanal escorrega. Mesma rubrica, fonte de dados diferente.
Como o human-in-the-loop se encaixa na avaliação de LLM?
Humanos fecham a lacuna que nenhum modo cobre: casos extremos inéditos, julgamentos subjetivos de qualidade e deriva da voz da marca. Uma cadência prática é rotular de 10 a 20 traces amostradas de nota baixa por semana e fazer o commit dos casos rotulados no conjunto de evals offline. A fila de revisão é uma entrada do pipeline, não um projeto paralelo.
Como funcionam as avaliações do Langfuse para pontuação online?
O Langfuse ingere traces da sua aplicação, depois anexa avaliadores LLM-as-judge que pontuam cada trace contra uma rubrica: alucinação, relevância, toxicidade ou um prompt customizado. As notas chegam num dashboard indexado por sessões e usuários. As equipes exportam traces com nota baixa persistente para um dataset offline para testes de regressão. Nosso roundup de plataformas de observabilidade compara os depósitos de traces que alimentam esse padrão.
Como adiciono evals offline a um pipeline de CI/CD?
Adicione um runner de eval como status check obrigatório em pull requests que tocam prompts, modelos ou configuração de retrieval. promptfoo e DeepEval rodam headless e saem com código diferente de zero em falha de asserção, o que bloqueia o merge automaticamente. O gate YAML no início deste post é um modelo funcional; comece com 30 a 50 casos.
O EU AI Act exige avaliação offline ou online?
Na prática, as duas. Para sistemas de alto risco, o Act espera evidência documentada de que as metas de qualidade foram cumpridas antes do release, o que significa artefatos offline, mais monitoramento contínuo depois do deploy, o que significa telemetria online. Seus prazos faseados correm até agosto de 2026 conforme o EUR-Lex. Essa é a nossa leitura do padrão de conformidade, não aconselhamento jurídico.
O LLM-as-a-judge pode rodar nos modos offline e online?
Sim, e deveria, porque a rubrica se transfere. No offline, o judge pontua em lote toda saída do conjunto de evals durante o CI. No online, o mesmo prompt de judge pontua traces de produção amostradas quase em tempo real. Manter uma rubrica só nos dois modos é o que torna sua baseline offline comparável ao seu sinal de deriva online.
Quais métricas diferem entre a avaliação offline e a online?
As métricas offline medem a qualidade da saída contra o ground truth: fidelidade, relevância de resposta, conformidade de formato, notas de benchmark. As métricas online adicionam sinais operacionais e comportamentais: latência p95, taxa de erro, taxa de alucinação no tráfego ao vivo, nota de deriva e satisfação do usuário. A lista offline pergunta "está bom?" e a lista online pergunta "continua bom?"
A Versão Curta
- As avaliações offline e online são faixas complementares, não uma escolha excludente: uma barra o que você envia, a outra vigia o que você enviou.
- Comece com o gate de CI esta semana, adicione pontuação de traces online no lançamento e conecte o loop de feedback antes que o seu conjunto de evals envelheça.
- O loop é o sistema. Um dataset dourado estático apodrece; um que cresce se acumula.
Se você quer um segundo par de olhos no seu pipeline de evals, peça uma consulta gratuita.