Criando um pipeline de avaliação contínua
Integre a avaliação por LLM como avaliador ao pipeline de CI/CD para que cada alteração no prompt ou no modelo seja avaliada automaticamente em relação a uma suíte de testes de regressão antes da implantação.
Criando um pipeline de avaliação contínua é uma aula grátis de AI Engineering Academy no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de AI Engineering Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de AI Engineering Academy inclui 4 aulas no total.
Por que a avaliação deve ser contínua
Uma avaliação única no momento da implantação não é suficiente. A qualidade dos LLM se degrada silenciosamente: os provedores de modelos atualizam seus modelos, alterações no comando do sistema são incorporadas, a qualidade da recuperação muda à medida que o acervo de documentos cresce e a distribuição das consultas dos usuários se altera com o tempo. Um processo contínuo de avaliação executa o mesmo conjunto de avaliações a cada alteração e de acordo com uma programação, para que regressões de qualidade sejam detectadas em horas, e não em semanas.
Componentes principais do processo
Um pipeline de avaliação contínua tem cinco componentes: um conjunto de dados de teste (perguntas selecionadas com resultados esperados), um executor do sistema (que chama o pipeline de LLM para cada pergunta de teste), um avaliador (que atribui uma pontuação a cada resposta), um armazenamento de resultados (banco de dados ou armazenamento de séries temporais para métricas históricas) e uma camada de relatórios (painéis e alertas). Cada componente pode ser atualizado de forma independente.
# Pipeline architecture:
#
# test_dataset.json
# |
# v
# system_runner.py --> calls your LLM pipeline
# |
# v
# judge.py --> scores each (question, answer) pair
# |
# v
# results_db --> stores timestamped metric history
# |
# v
# dashboard + alert --> Grafana / Slack notificationEstruturando o Conjunto de Dados de Teste
Armazene o conjunto de testes da sua avaliação como um arquivo JSON ou YAML versionado no seu repositório. Cada entrada contém uma pergunta, a categoria (factual, procedural, fora do escopo) e, opcionalmente, uma resposta de referência. Faça o versionamento do conjunto de testes separadamente do código — adicionar novos casos de teste é uma alteração compatível com versões anteriores, enquanto remover casos pode ocultar regressões. Procure ter de 200 a 500 casos abrangendo todas as categorias relevantes.
# eval/test_set_v3.json
# {
# 'version': '3.0',
# 'created': '2026-06-01',
# 'cases': [
# {
# 'id': 'faq_001',
# 'category': 'factual',
# 'question': 'What is the cancellation policy?',
# 'reference': 'Cancellations must be made 24 hours in advance.',
# 'min_correctness': 4
# },
# ...
# ]
# }Executando o Conjunto de Avaliação
O executor da avaliação chama o sistema de produção (ou uma versão de preparação) para cada caso de teste e registra a resposta e os metadados. Identifique cada execução de avaliação com um ID de execução exclusivo, o SHA do commit que a acionou, o carimbo de data e hora e a versão do conjunto de testes. Isso permite comparar as execuções com precisão e diagnosticar qual alteração no código causou uma regressão.
import asyncio
import uuid
from datetime import datetime
async def run_eval_suite(system, test_set: list, commit_sha: str) -> dict:
run_id = str(uuid.uuid4())
results = []
for case in test_set:
response = await system.answer(case['question'])
score = await judge(case['question'], response, case.get('reference'))
results.append({
'run_id': run_id,
'commit_sha': commit_sha,
'case_id': case['id'],
'category': case['category'],
'response': response,
'score': score.model_dump(),
'evaluated_at': datetime.utcnow().isoformat()
})
return {'run_id': run_id, 'results': results}Armazenando e Consultando Métricas Históricas
Persista o resultado de cada execução de avaliação em um banco de dados. Uma tabela simples eval_results com os campos run_id, commit_sha, case_id e score é suficiente. Consulte as pontuações agregadas por run_id para calcular as métricas de cada execução. Compare a execução atual com a última execução bem-sucedida na ramificação principal para detectar regressões. Um banco de dados de séries temporais como o InfluxDB funciona bem para o monitoramento contínuo.
-- PostgreSQL schema
CREATE TABLE eval_runs (
run_id UUID PRIMARY KEY,
commit_sha TEXT NOT NULL,
test_set_version TEXT NOT NULL,
triggered_by TEXT, -- 'ci', 'scheduled', 'manual'
started_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE TABLE eval_results (
id SERIAL PRIMARY KEY,
run_id UUID REFERENCES eval_runs(run_id),
case_id TEXT NOT NULL,
category TEXT,
correctness INT,
overall INT,
response TEXT
);
CREATE INDEX idx_run_id ON eval_results(run_id);Detectando Regressões Automaticamente
Após cada execução de avaliação, compare as pontuações agregadas com a linha de base (a última execução da ramificação principal aprovada manualmente). Uma regressão é definida como: qualquer dimensão da pontuação que caia mais de 5% abaixo da linha de base ou a pontuação média de qualquer categoria que caia abaixo de um mínimo rígido. As regressões devem bloquear a implantação e alertar a equipe. Melhorias podem ser aprovadas automaticamente.
def detect_regression(current: dict, baseline: dict, threshold_pct: float = 5.0) -> dict:
regressions = []
for metric in ['correctness', 'helpfulness', 'clarity']:
delta_pct = (current[metric] - baseline[metric]) / baseline[metric] * 100
if delta_pct < -threshold_pct:
regressions.append({
'metric': metric,
'baseline': baseline[metric],
'current': current[metric],
'delta_pct': round(delta_pct, 1)
})
return {'has_regression': len(regressions) > 0, 'regressions': regressions}Integrando com CI/CD
Adicione o conjunto de avaliação como uma etapa de CI executada em cada solicitação de pull. O pipeline de CI chama o sistema de preparação, executa o avaliador, armazena os resultados e verifica se há regressões. Se uma regressão for detectada, a etapa de CI falha e bloqueia a mesclagem da PR. Adicione isso como uma verificação de status obrigatória no GitHub ou no GitLab para que ninguém possa ignorá-la. Mantenha o tempo de execução da avaliação abaixo de 10 minutos usando um subconjunto de 50 a 100 casos nas verificações de PR.
# .github/workflows/eval.yml
# name: LLM Quality Evaluation
# on: [pull_request]
# jobs:
# eval:
# runs-on: ubuntu-latest
# steps:
# - uses: actions/checkout@v4
# - name: Run eval suite
# run: python eval/run_suite.py --commit $GITHUB_SHA --mode pr
# env:
# OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
# - name: Check for regressions
# run: python eval/check_regression.py --run-id $EVAL_RUN_IDExecuções Agendadas de Avaliação Completa
Além das verificações de PR, execute diariamente o conjunto completo de avaliação (todos os mais de 300 casos) em relação ao sistema de produção. Isso detecta uma degradação gradual da qualidade que nenhuma alteração isolada causa — por exemplo, se a recuperação do banco de dados vetorial piorar à medida que mais documentos são adicionados ou se o provedor de LLM atualizar seu modelo silenciosamente. As execuções completas diárias fornecem uma série temporal de qualidade que torna as tendências visíveis.
# Separate eval modes:
EVAL_CONFIGS = {
'pr_check': {
'test_cases': 'eval/test_set_core_100.json',
'target': 'staging',
'max_runtime_min': 8
},
'nightly': {
'test_cases': 'eval/test_set_full_350.json',
'target': 'production',
'max_runtime_min': 30
},
'weekly_deep': {
'test_cases': 'eval/test_set_full_350.json',
'target': 'production',
'include_pairwise': True,
'max_runtime_min': 90
}
}Alertando sobre a Degradação da Qualidade
Configure alertas quando as tendências das métricas ultrapassarem os limites de aviso e crítico. Uma queda de 3% na correção média nos últimos 7 dias aciona um aviso. Uma queda de 10% em uma única execução aciona um alerta imediato. Direcione os avisos para um canal da equipe no Slack e os alertas críticos para o PagerDuty. Inclua a análise da regressão, um link para o painel de avaliação e o git blame das alterações recentes em todas as mensagens de alerta.
import httpx
def send_regression_alert(regression_report: dict, webhook_url: str):
regressions = regression_report['regressions']
blocks = [{
'type': 'section',
'text': {'type': 'mrkdwn', 'text': '*LLM Quality Regression Detected*'}
}]
for r in regressions:
blocks.append({
'type': 'section',
'text': {'type': 'mrkdwn',
'text': f'*{r["metric"]}*: {r["baseline"]} -> {r["current"]} ({r["delta_pct"]}%)'}
})
httpx.post(webhook_url, json={'blocks': blocks})Gerenciando a Expansão do Conjunto de Testes
Amplie continuamente o conjunto de testes com base em falhas reais do sistema de produção. Quando um usuário relatar uma resposta inadequada, adicione essa pergunta (anonimizada, se necessário) ao conjunto de testes com uma resposta esperada verificada por uma pessoa. Isso garante que o conjunto de avaliação reflita as necessidades reais dos usuários, em vez de casos hipotéticos. Trate o conjunto de testes como um documento vivo e revise-o trimestralmente para remover casos obsoletos.
def add_to_test_set(question: str, reference_answer: str, category: str,
source: str, test_set_path: str):
import json, uuid
with open(test_set_path, 'r') as f:
test_set = json.load(f)
test_set['cases'].append({
'id': f'user_report_{uuid.uuid4().hex[:8]}',
'category': category,
'question': question,
'reference': reference_answer,
'source': source, # 'user_report', 'regression', 'manual'
'added': '2026-06-21'
})
with open(test_set_path, 'w') as f:
json.dump(test_set, f, indent=2)Visualizando as Tendências de Qualidade ao Longo do Tempo
Crie um painel simples de qualidade que represente suas principais métricas ao longo do tempo: pontuação média de correção, taxa de acertos do cache, latência p95 e custo por consulta. Use uma média móvel semanal para suavizar o ruído causado por tamanhos de amostra pequenos. Um gráfico de tendências torna imediatamente visível a degradação da qualidade — uma queda gradual de 3% ao longo de seis semanas não aparece nos relatórios de execuções individuais, mas fica evidente em um gráfico de séries temporais. O Grafana ou até mesmo um script simples em Python com matplotlib funciona bem para isso.
import matplotlib.pyplot as plt
import pandas as pd
def plot_quality_trend(eval_history: list):
df = pd.DataFrame(eval_history)
df['date'] = pd.to_datetime(df['evaluated_at'])
df = df.sort_values('date')
# 7-day rolling average
df['score_ma7'] = df['mean_correctness'].rolling(window=7).mean()
plt.figure(figsize=(12, 4))
plt.plot(df['date'], df['mean_correctness'], alpha=0.3, label='Daily')
plt.plot(df['date'], df['score_ma7'], label='7-day avg', linewidth=2)
plt.axhline(y=4.0, color='r', linestyle='--', label='Min threshold')
plt.legend()
plt.title('LLM Answer Quality Over Time')
plt.savefig('quality_trend.png')Verificação Rápida
Teste sua compreensão sobre pipelines de avaliação contínua para aplicações de LLM.
Recapitulação da Lição
Nesta lição, você aprendeu que: pipelines de avaliação contínua executam verificações automatizadas de qualidade em cada PR e diariamente para detectar regressões antecipadamente; a detecção de regressões compara as pontuações atuais com uma linha de base e bloqueia a implantação quando a qualidade cai; e a expansão do conjunto de testes a partir de falhas reais mantém o conjunto de avaliação baseado nas necessidades reais dos usuários. Em seguida, classificaremos os modos de falha de agentes e criaremos estratégias de recuperação.
Perguntas Frequentes
A aula “Criando um pipeline de avaliação contínua” é grátis?
Sim — o texto completo de “Criando um pipeline de avaliação contínua” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de AI Engineering Academy, atualize para CoddyKit PRO. O curso de AI Engineering Academy inclui 4 aulas no total.
O que vou aprender em “Criando um pipeline de avaliação contínua”?
Integre a avaliação por LLM como avaliador ao pipeline de CI/CD para que cada alteração no prompt ou no modelo seja avaliada automaticamente em relação a uma suíte de testes de regressão antes da imp… Você pratica AI Engineering Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar AI Engineering Academy?
Nenhuma experiência prévia é necessária. AI Engineering Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.
Quanto tempo leva a aula “Criando um pipeline de avaliação contínua”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de AI Engineering Academy?
Sim. Cada aula de AI Engineering Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- O padrão LLM como juiz
- Avaliação ponto a ponto e em pares
- Calibrando modelos avaliadores em relação a humanos
- Criando um pipeline de avaliação contínua