03 Lançar e detectar

Material do facilitador para 03 Lançar e detectar.

Duração

~15 minutos no total.

• 3 min — diferenciar avaliação operacional de valor para o usuário.
• 4 min — mostrar o preflight e lançar a configuração escolhida com policy-v1.
• 4 min — fazer a pergunta governada no Chat e obter 👎 nessa resposta.
• 4 min — localizar o trace, verificar as duas pontuações e reproduzir com curl.

Preflight no dia anterior

Execute com o vencedor esperado. A alternativa verificada é qwen3.7-flash__P2_fewshot:

cd ClickHouse_Demos/workshops/agent_arena
source .env
export WINNER_CONFIG_ID="${WINNER_CONFIG_ID:-qwen3.7-flash__P2_fewshot}"
.venv/bin/python -m schema.gen_schema_context
.venv/bin/python -m scripts.check_online_eval_scenario \
  --config-id "$WINNER_CONFIG_ID"
.venv/bin/python -m scripts.provision_online_evaluators --operational

O preflight faz uma única repetição limitada quando o primeiro resultado de uma paráfrase é ok/unknown, somente para a mesma paráfrase e configuração. Todas as outras falhas são finais.

Não confie na memória. Confirme no ambiente real:

• stale_count e current_count existem e são diferentes;
• as três classificações são policy-v1;
• a linha final diz que o incidente é reproduzível;
• o evaluator sql-execution-success existe; e
• a regra agent-arena-sql-execution-online está habilitada.

Para Qwen, desative OpenRouter Settings → Privacy → Data Policies → Zero Data Retention → Non-frontier para permitir a rota Alibaba. Faça isso somente após revisar os requisitos de dados. Participantes precisam de chave limitada de runtime, nunca a chave de provisionamento do instrutor.

Roteiro de fala

• Comece com o vencedor real do Módulo 02 e escreva WINNER_CONFIG_ID visivelmente. Núcleo e configuração não mudam; apenas o contexto de política implantado está uma versão atrás.

• Defina o limite: sql-execution-success prova que o ClickHouse aceitou o SQL, não que ele implementa o significado atual da métrica.

• Pergunte no Chat, mostre SQL, resultado e policy_version=policy-v1; clique em 👎 e aguarde feedback sent. Esse trace raiz é o incidente autoritativo.

• Mostre a definição atual lado a lado:

  SELECT uniqExact(customer_id) FROM v_orders
  WHERE order_ts >= now() - INTERVAL 30 DAY
  AND status NOT IN ('cancelled', 'returned')

• Diga explicitamente que o SQL baseado em cadastro é válido sob a policy-v1 fornecida. É falha de lançamento/processo e lacuna do evaluator, não desobediência do modelo.

• No Langfuse, filtre user-thumbs = false, abra o chat_turn mais recente e mostre sql-execution-success=true ao lado de user-thumbs=false. O sinal prioriza investigação; não fornece diagnóstico nem vira verdade por si só.

• Execute depois a reprodução curl obrigatória como diagnóstico sem avaliação. Chame o identificador de CURL_TRACE_ID, verifique só sql-execution-success=true e nunca envie feedback nem o entregue ao Módulo 04.

• Registre ID/URL da raiz e ambas as contagens para o Módulo 04. Mantenha identificadores no projeto e na planilha.

Evidências esperadas do trace

Abra a observação raiz chat_turn, não apenas a filha llm_call:

O código usa policy_version; o adaptador OpenTelemetry sanitiza as chaves para alfanuméricos, portanto o Langfuse exibe policyversion.

O evaluator é assíncrono. Use o verificador antes de tratar ausência como falha:

.venv/bin/python -m scripts.verify_online_scores "$CHAT_TRACE_ID" \
  sql-execution-success=true user-thumbs=false

Falhas comuns

• Provedor bloqueado por ZDR — o Qwen falha antes do SQL quando a exigência non-frontier está ativa e a rota Alibaba é impedida. Desative a restrição para o workshop ou use a alternativa divulgada após revisar a privacidade.
• Dispatcher do evaluator parado — o trace chega, mas sql-execution-success não. Confirme o serviço/dispatcher e a regra agent-arena-sql-execution-online; provisionar regra não processa pontuações sem workers.
• Dependências OpenTelemetry ausentes — nenhum trace aparece embora /ask retorne. Reinstale com .venv/bin/python -m pip install -r requirements.txt; o runtime usa o caminho OpenTelemetry do Langfuse v4.
• Processo antigo do servidor — a resposta indica policy-v2 apesar do comando policy-v1. Pare completamente quem ocupa a porta 8100.
• Porta errada — o Chat usa http://localhost:8100. Se o serving estiver em outra porta, alinhe VITE_SERVING_BASE ou use curl na porta real.
• Feedback duplicado — o ID determinístico é user-thumbs-<trace_id>. Envie uma avaliação por trace; para avaliações concorrentes, crie nova sessão/trace.
• Pontuação pendente — a avaliação é assíncrona. Deixe scripts.verify_online_scores consultar antes de mudar a configuração.
• Contagens de referência iguais — não há contraste nesta amostra. Não invente a falha; repopule ou diagnostique os dados.

Etapas de recuperação

Pare o servidor e inicie um processo limpo com policy-v1:

scripts/arena.sh stop
scripts/arena.sh serve
source .env
.venv/bin/python -m schema.gen_schema_context
AGENT_ARENA_POLICY_VERSION=policy-v1 \
  .venv/bin/uvicorn serving.api:app --port 8100

scripts/arena.sh serve restaura dashboard e interface em segundo plano antes de a API assumir o terminal. Atualize o Chat para nova sessão. Na API bruta, use novo ID de sessão ou omita-o para /ask criar um. Repita preflight e provisionador no segundo terminal; ambos são seguros.

Política de alternativa

Use qwen3.7-flash__P2_fewshot apenas se o vencedor não seguir a política explícita no preflight de três perguntas. Declare a substituição: ela preserva um incidente determinístico, mas o vencedor do leaderboard continua sendo o resultado medido. Não troque silenciosamente nem use a alternativa para ocultar contagens iguais, credenciais, roteamento ou infraestrutura.

Entrega ao Módulo 04

Antes de avançar, confirme na planilha ID/URL do trace raiz autoritativo do Chat, contagens antiga e atual, sql-execution-success=true e Boolean user-thumbs=false. O Módulo 04 começa dessa divergência e acrescenta julgamento humano; não deve começar de um diagnóstico pronto e separado do trace.