0Pricing
AI Engineering Academy · Aula

Avaliação, implantação e retrospectiva

Execute o conjunto completo de avaliação, incluindo métricas de recuperação, pontuações de qualidade do LLM como avaliador e testes de carga, implante em um provedor de nuvem e escreva uma retrospectiva documentando as lições aprendidas.

Avaliação, implantação e retrospectiva é 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.

A etapa final: avaliação antes do lançamento

Um sistema não está pronto para ser lançado até ser avaliado de ponta a ponta em condições do mundo real. A fase final de avaliação combina todas as técnicas aprendidas neste percurso: métricas de recuperação para verificar se o fluxo de RAG encontra os trechos corretos, pontuações de avaliação por LLM como juiz para verificar a qualidade das respostas, testes de carga para verificar os SLAs de latência e varredura de segurança para verificar o reforço. Tudo deve ser aprovado antes do início da implantação.

Execução do conjunto completo de avaliação

Execute a suíte completa de avaliação no seu ambiente de homologação, usando uma amostra representativa de consultas semelhantes às de produção. Registre todas as métricas: taxa de acerto, MRR e NDCG para recuperação; fidelidade e relevância da resposta para geração; custo por consulta; latência p50/p95/p99. Compare cada métrica com os critérios de sucesso definidos na fase de arquitetura. Não faça o lançamento até que todos os requisitos mínimos rigorosos sejam atendidos.

async def final_evaluation(system_url: str, test_set_path: str) -> dict:
    test_cases = load_test_set(test_set_path)
    results = []
    for case in test_cases:
        start = time.perf_counter()
        response = await query_system(system_url, case['question'])
        latency_ms = (time.perf_counter() - start) * 1000
        judge_score = await judge(case['question'], response['answer'], case.get('reference'))
        hit = any(case['relevant_doc'] in s for s in response.get('sources', []))
        results.append({'latency_ms': latency_ms, 'score': judge_score, 'hit': hit, 'cost': response.get('cost_usd', 0)})
    return compute_final_metrics(results)

Teste de carga do sistema de produção

Execute um teste de carga que simule o tráfego realista de produção antes de entrar em operação. Use uma ferramenta como Locust ou k6 para aumentar gradualmente até a concorrência máxima esperada (por exemplo, 50 usuários simultâneos) e medir como a latência muda sob carga. Verifique se os mecanismos de proteção não são acionados sob carga normal, se o limitador de taxa retorna respostas 429 corretas durante tráfego em rajadas e se a taxa de acerto do cache semântico permanece acima da meta. Corrija todas as regressões antes de prosseguir.

# Locust load test (locustfile.py)
from locust import HttpUser, task, between
import random

QUESTIONS = [
    'What is the return policy?',
    'How do I cancel my subscription?',
    'Where are you located?',
]

class AIUser(HttpUser):
    wait_time = between(1, 3)  # realistic think time

    @task
    def query(self):
        self.client.post(
            '/query',
            json={'question': random.choice(QUESTIONS), 'tenant_id': 'load_test'},
            headers={'Authorization': 'Bearer test_token'}
        )

# Run: locust -f locustfile.py --headless -u 50 -r 5 --run-time 5m

Implantação em produção

Faça a implantação usando uma implantação azul-verde: inicie a nova versão (verde) ao lado da versão existente (azul), execute testes básicos contra a versão verde e, em seguida, transfira gradualmente o tráfego da azul para a verde. Comece com 5% do tráfego na versão verde, monitore as taxas de erro e a latência por 10 minutos e então transfira 25%, depois 50% e, por fim, 100%. Isso permite reverter instantaneamente para a versão azul se algo der errado, sem qualquer indisponibilidade.

# Deployment steps (pseudocode for AWS ECS or K8s):
# 1. Build and push new Docker image
#    docker build -t qa-assistant:v2.0 . && docker push ...
#
# 2. Deploy green (new) version alongside blue (current)
#    kubectl apply -f deploy/green.yaml
#
# 3. Run smoke tests against green
#    pytest tests/smoke/ --base-url https://green.internal
#
# 4. Canary traffic shift (ALB weighted routing)
#    5%  -> green (monitor 10min)
#    25% -> green (monitor 10min)
#    50% -> green (monitor 10min)
#    100% -> green
#
# 5. Decommission blue after 24h stability

Monitoramento pós-implantação

Após a implantação, acompanhe ativamente as principais métricas durante as primeiras 2 horas. Monitore: taxa de erros (meta <1%), latência p95 (meta <8s), taxa de acerto do cache (meta >20%) e custo por consulta (meta <$0.05). Configure um canal de guerra no Slack com todos os engenheiros de plantão para a primeira implantação. Qualquer métrica que ultrapasse um limite de aviso inicia uma investigação; um limite crítico aciona uma reversão imediata para a versão azul.

# Post-deploy monitoring dashboard queries:
# (Assuming Grafana + Prometheus)

# Error rate (last 5 min):
# rate(http_requests_total{status=~'5..'}[5m]) / rate(http_requests_total[5m])

# p95 latency (last 5 min):
# histogram_quantile(0.95, rate(query_duration_seconds_bucket[5m]))

# Cache hit rate:
# rate(cache_hits_total[5m]) / rate(queries_total[5m])

# Average cost per query:
# rate(llm_cost_usd_total[5m]) / rate(queries_total[5m])

Redação da retrospectiva da arquitetura

Depois que o sistema estiver em operação por uma semana, escreva um documento de retrospectiva que registre o que funcionou, o que não funcionou e o que você faria de forma diferente. Uma boa retrospectiva é honesta sobre as falhas e específica quanto aos aprendizados. Leitores futuros — incluindo você mesmo daqui a seis meses — se beneficiarão de compreender o raciocínio por trás das decisões tomadas sob pressão de tempo e dos obstáculos inesperados encontrados.

# RETROSPECTIVE.md structure:
#
# ## What Worked Well
# - Hybrid retrieval improved hit rate from 71% to 89%
# - Semantic cache reduced average cost by 31%
# - LangSmith tracing saved 2 days of debugging
#
# ## What Did Not Work
# - Semantic chunking was 4x slower than recursive chunking
#   with only 3% hit rate improvement -- not worth it
# - Cohere reranker had 400ms latency -- too slow for p95 target
#   Switched to BGE-reranker-v2 running locally
#
# ## What We'd Do Differently
# - Start with pgvector, not Pinecone (migration cost 3 days)
# - Add semantic cache BEFORE building the agent, not after

Documentação dos manuais operacionais

Escreva manuais operacionais para cada alerta que possa ser acionado em produção. Um manual operacional é um guia passo a passo para diagnosticar e resolver um alerta específico. Ele deve responder: o que este alerta significa, qual é a causa provável, como faço o diagnóstico e como corrijo o problema. Os manuais reduzem o tempo médio até a resolução (MTTR) de horas para minutos, eliminando a necessidade de elaborar as etapas do diagnóstico durante um incidente estressante.

# runbooks/latency.md
# ## Alert: p95 Latency > 8000ms
#
# ### Likely Causes
# 1. OpenAI API degraded (check status.openai.com)
# 2. Cohere reranker slow (check Cohere status page)
# 3. pgvector query slow (check DB CPU in CloudWatch)
# 4. Redis cache full (check Redis memory usage)
#
# ### Diagnosis
# curl https://api.openai.com/v1/models -H 'Authorization: Bearer $KEY'
# Check LangSmith traces for which step is slow
# SELECT mean(duration) FROM traces GROUP BY step
#
# ### Fixes
# - If OpenAI slow: circuit breaker should auto-failover to Claude
# - If Cohere slow: disable reranking temporarily (env SKIP_RERANK=1)
# - If DB slow: increase pgvector ef_search from 40 to 20

Medição do impacto nos negócios

Após um mês em produção, meça o impacto nos negócios do sistema além das métricas técnicas. Para um assistente de perguntas e respostas: quanto diminuiu o volume de chamados de suporte? Qual é o índice de satisfação dos usuários nas consultas respondidas pela IA? Quantas consultas o sistema processou que antes exigiam o atendimento de agentes humanos? Essas métricas de negócio justificam o investimento e orientam a priorização futura entre melhorias de qualidade e novos recursos.

# Business impact metrics (month 1):
# Technical:
# - 12,847 queries served, 11,439 (89%) answered without human
# - Avg query cost: $0.031 (within $0.05 budget)
# - System uptime: 99.94%
#
# Business:
# - Support tickets: 1,840/month -> 1,203/month (-35%)
# - Avg resolution time: 4.2h -> 23 seconds for AI-answered
# - User CSAT on AI answers: 4.1/5.0
# - Cost per resolved query: $12 (human) -> $0.031 (AI)
# - ROI: 157% in month 1 at current volumes

Planejamento da próxima iteração

Um sistema colocado em produção nunca está realmente concluído — ele é uma base para a melhoria contínua. Use seus dados de avaliação, o feedback dos usuários e os aprendizados das retrospectivas para planejar a próxima iteração. Priorize as melhorias que têm o maior impacto nas métricas mais importantes: se a taxa de acerto da recuperação for o fator limitante, invista em uma segmentação em trechos melhor ou em um modelo diferente de vetorização; se a satisfação dos usuários estiver baixa apesar de uma boa recuperação, invista na qualidade dos prompts.

# Next iteration priorities (based on first month data):
NEXT_SPRINT = [
    # High impact / high confidence
    {
        'feature': 'Sentence-window retrieval',
        'expected_impact': 'Hit rate 89% -> 93%',
        'effort': 'medium',
        'evidence': '11% of failures due to answer split across chunks'
    },
    # High impact / medium confidence
    {
        'feature': 'Query decomposition for multi-hop questions',
        'expected_impact': 'Multi-hop correctness 61% -> 78%',
        'effort': 'high',
        'evidence': '23% of failures are multi-hop questions'
    },
    # Low effort quick win
    {
        'feature': 'Extend cache TTL from 1h to 24h',
        'expected_impact': 'Cache hit rate 31% -> 38%',
        'effort': 'trivial',
        'evidence': 'Same questions asked daily by different users'
    }
]

Compartilhamento de conhecimento e documentação

Escreva uma documentação para as principais decisões de implementação não óbvias do sistema. Isso inclui: por que o tamanho específico dos trechos foi escolhido (e o que os experimentos demonstraram), como o limiar de similaridade do cache semântico foi calibrado, quais padrões de injeção o filtro detecta atualmente e quais não detecta, e como adicionar novas ferramentas ao agente. Uma boa documentação interna reduz o tempo de integração de novos colaboradores e evita que decisões sejam revertidas acidentalmente por alguém que desconhece sua justificativa.

# INTERNALS.md — key non-obvious decisions:
#
# ## Chunk Size: 800 tokens with 100 token overlap
# We tested 400, 600, 800, 1200 tokens.
# 800 tokens maximizes hit rate (89%) while keeping context
# small enough for 5 chunks to fit comfortably in 4096 token prompt.
# Larger chunks improved recall but degraded precision.
#
# ## Cache Similarity Threshold: 0.92
# Tested 0.85, 0.90, 0.92, 0.95.
# 0.92 gives 31% hit rate with <2% incorrect cache hits.
# 0.85 gives 41% hit rate but 8% incorrect hits (too aggressive).
#
# ## Reranker Top-N: 3 (from initial 10)
# More than 3 chunks causes context stuffing without quality gain.

O que você construiu

Reflita sobre o sistema completo que você construiu ao longo deste projeto final: um fluxo híbrido de RAG que combina recuperação densa e esparsa com reclassificação, um agente com transmissão contínua com chamada de funções e proteções de segurança, um cache semântico que reduz os custos em 30%, disjuntores que fornecem comutação automática, uma avaliação com LLM como juiz executada continuamente na integração e entrega contínuas, e defesas contra injeção de prompts que protegem contra entradas adversárias. Isso é engenharia de IA para produção.

# System capabilities summary:
SYSTEM_CAPABILITIES = {
    'retrieval': 'Hybrid BM25+dense with Cohere reranking, 89% hit rate',
    'generation': 'GPT-4o with Claude fallback, circuit breaker, streaming',
    'caching': 'Semantic cache (Redis+embeddings), 31% cache hit rate',
    'security': 'Injection filter (2-stage) + output scanning + tenant isolation',
    'observability': 'LangSmith traces + Prometheus metrics + PagerDuty alerts',
    'evaluation': 'Automated LLM-as-judge in CI, daily full suite, LangSmith evals',
    'reliability': '99.94% uptime, circuit breakers, graceful degradation ladder',
    'cost': '$0.031/query average, model routing saves 67% vs GPT-4o only',
}

Verificação rápida

Teste sua compreensão sobre a implantação e a avaliação de sistemas de IA em produção.

Recapitulação da lição

Nesta lição, você aprendeu que: a avaliação final combina métricas de recuperação, pontuações de LLM como juiz, testes de carga e varredura de segurança antes do início de qualquer implantação; a implantação azul-verde com transferência gradual de tráfego permite uma reversão imediata sem tempo de inatividade; e as retrospectivas e os manuais operacionais registram o conhecimento institucional, reduzindo o tempo de resolução de incidentes futuros. Parabéns por concluir a trilha de Engenharia de IA: LLM, RAG e agentes!

Perguntas Frequentes

A aula “Avaliação, implantação e retrospectiva” é grátis?

Sim — o texto completo de “Avaliação, implantação e retrospectiva” é 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 “Avaliação, implantação e retrospectiva”?

Execute o conjunto completo de avaliação, incluindo métricas de recuperação, pontuações de qualidade do LLM como avaliador e testes de carga, implante em um provedor de nuvem e escreva uma retrospect… 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 “Avaliação, implantação e retrospectiva”?

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

  1. Projetando a arquitetura de produção
  2. Implementando recursos essenciais de RAG e agentes
  3. Reforço: segurança, armazenamento em cache e confiabilidade
  4. Avaliação, implantação e retrospectiva
← Voltar para AI Engineering Academy