ai-machine-learning

Avaliação de LLM Online vs Offline: De Qual Você Precisa (e Quando)

Escrito por Mert Batur
Aug 1, 2026
13 min de leitura
Avaliação de LLM Online vs Offline: De Qual Você Precisa (e Quando)

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ãoOfflineOnline
Fonte de dadosDataset dourado fixo, versionado no gitTraces de produção reais, amostrados
MomentoAntes do deploy, em todo PRDepois do lançamento, contínuo
Custo por rodadaTokens de judge por suíte rodada; custo marginal quase zeroTokens de judge sobre tráfego amostrado; escala com o volume
Restrição de latênciaNenhuma; rode em lote com calmaOrçamentos de sub-segundo em caminhos críticos
Risco para usuáriosZero; falhas nunca chegam aos usuáriosReal; saídas ruins atingem sessões ao vivo
Velocidade de feedbackMinutos por PRSegundos a minutos em streams
Tipos de métricaFidelidade, relevância de resposta, conformidade de formato, notas de benchmarkPercentis de latência, taxa de erro, taxa de alucinação, feedback de usuários
ReprodutibilidadeDeterminística com modelo e dataset fixadosNão determinística; o mix do tráfego muda todo dia
Governança e auditoriaArtefatos versionados, comparáveis entre releasesDashboards 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.

QuadranteExemplosAção
Só offlineRegressões de prompt, formatos de saída quebrados, quedas de nota em benchmark, fidelidade abaixo do limiteBloquear o merge no CI
Só onlineDeriva de distribuição, latência sob carga, peculiaridades de integração, padrões de abuso adversarialAlertar, amostrar as traces, enviá-las ao conjunto de evals
Pego pelos doisPicos na taxa de alucinação, erosão de consistência factualManter os dois; dedupe o esforço, não a cobertura
Pego por nenhumCasos extremos inéditos, julgamentos subjetivos de qualidade, deriva da voz da marcaFila 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:

yaml
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-judge

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

FerramentaRunner offlinePontuador onlineAmbos nativamente?O que ela NÃO faz
promptfooSim: suítes YAML, nativo de CI, pacotes de red-teamParcial: as mesmas configs contra logs exportadosOffline-first; o online precisa de um passo de exportaçãoIngerir traces ao vivo; atuar como dashboard de monitoramento
DeepEvalSim: testes estilo pytest, 14+ métricasSim, via plataforma Confident AISim, com o add-on hospedadoA biblioteca open-source sozinha é só offline
LangfuseParcial: experimentos de dataset via SDKSim: avaliadores judge nas traces ingeridasSim: datasets mais pontuadores de tracesRodar seu gate de merge no CI; isso você conecta sozinho
LangSmithSim: datasets e experimentos offlineSim: automações pontuam traces amostradasSimViver fora da stack LangChain sem atrito
OpenAI EvalsSim: evals YAML estilo registryNãoNãoPipelines de traces de produção; modelos fora da OpenAI
Arize PhoenixSim: experimentos notebook-firstSim: spans e traces com avaliadores inlineSimSetup 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:

  1. Os pontuadores online sinalizam traces abaixo de 0,7 de nota do judge.
  2. Amostramos de 20 a 30 traces sinalizadas por semana.
  3. Um humano rotula cada uma: saída esperada mais classe de falha.
  4. Os casos rotulados entram no conjunto de evals offline como novos exemplos dourados.
  5. 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ágioOfflineOnlineAção
Pré-deployGate de regressão em todo PRNenhuma aindaBloquear merge abaixo do limite
Semana de lançamentoSuíte completa no release candidatePontuação shadow ou canary em 5-10% do tráfegoComparar as notas online com a baseline offline
Estado estacionárioReavaliação periódica num dataset renovado, semanal ou mensalPontuação amostrada contínua mais alertasVigiar a deriva; redefinir a baseline trimestralmente
Deriva detectadaReproduzir offline as traces que falharamO alerta que disparou o gatilhoAdicionar 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.

Etiquetas

avaliação de llm online vs offlineavaliação de llmllm-as-a-judgegate de eval no cimonitoramento de llm em produção

Partilhar este artigo

Inicia o Teu Projeto

Pronto para criar algo extraordinário?

Vamos transformar a sua visão em realidade. A nossa equipa está pronta para o ajudar a criar software que faz a diferença.