Medir antes de confiar: evals, traces e o agente em produção

QAT (quantization-aware training) (treino ciente de quantização). QAT é como treinar um time de futebol num campo menor e mais apertado antes do jogo, para que ninguém estranhe o espaço reduzido quando a partida de verdade começar.

1. Um modelo de IA guarda o que aprendeu em milhões de números, chamados pesos. Quanto mais casas decimais cada número tem, maior fica o arquivo.
2. Quantização (quantization) arredonda esses números para versões mais curtas. O arquivo encolhe e o modelo roda mais rápido, mas o arredondamento pode piorar as respostas.
3. No QAT, o treino já simula esse arredondamento enquanto o modelo aprende. Ele erra com os números curtos e corrige os pesos para compensar.
4. No fim, o modelo vira um checkpoint (arquivo salvo do modelo) já quantizado que perde pouca qualidade. Quantizar só depois do treino costuma perder mais.
5. Na palestra, os checkpoints QAT do Gemma de 2B ficam com menos de 1 GB. Por isso a demo carregou rápido e respondeu quase na hora dentro do navegador.

Ajuda saber antes: Pesos de um modelo, Quantization, Treinamento de modelo, Checkpoint

Elicitation (pedido de entrada do usuário pelo servidor MCP). Elicitation é como o garçom que volta à mesa no meio do preparo para perguntar o ponto da carne antes de terminar o prato.

1. Às vezes o sistema que atende um pedido percebe que falta uma informação e precisa perguntar ao usuário antes de continuar.
2. No MCP (Model Context Protocol, protocolo de contexto de modelo), o servidor faz o trabalho e o app de IA, como ChatGPT ou Claude, conversa com o usuário.
3. Elicitation (pedido de entrada) é o recurso que deixa o servidor pausar a tarefa e pedir ao app que colete um dado do usuário, como uma confirmação ou um formulário.
4. O app mostra o pedido ao usuário, recebe a resposta e devolve ao servidor, que retoma a tarefa de onde parou.
5. No talk, o palestrante cita o recurso como forma de abrir uma validação externa, por exemplo um checkout num iframe (janela embutida), sem tirar o usuário do agente. Segundo ele, a maioria dos apps grandes ainda não suporta o recurso.

Ajuda saber antes: MCP, App MCP, Servidor e cliente

Cross App Access (XAA) (acesso entre aplicações com identidade do agente via SSO). XAA é como o crachá de visitante que a portaria emite para um estagiário, ligado ao nome do chefe dele e válido só nas salas do projeto, sem que o chefe precise emprestar a própria chave.

1. Na empresa, você entra em vários sistemas como Notion, GitHub e Slack com um único login, o SSO (single sign-on, login único). O agente de IA ainda não tem um acesso próprio desse tipo.
2. Sem XAA, o caminho comum é colocar o token pessoal de alguém dentro do ambiente do agente ou aprovar uma tela de consentimento em cada sistema. Isso espalha credenciais e aumenta o estrago possível de um erro.
3. Com XAA, o sandbox e o MCP gateway declaram a identidade do agente e informam em nome de qual pessoa ele age.
4. O gateway troca essas declarações com o provedor de identidade da empresa, como o Okta, e recebe um ID-JAG, uma concessão de autorização prevista na versão mais recente do MCP.
5. Com o ID-JAG, o agente usa os mesmos servidores OAuth (padrão de autorização entre aplicações) que a empresa já tem. A TI administra tudo em um lugar e nenhuma credencial fica dentro do sandbox.

Ajuda saber antes: SSO, OAuth, MCP gateway, Sandbox

Recall (fração das respostas certas que a busca encontra). Recall é como a lista de chamada da professora: de todos os alunos que deviam estar na sala, ela conta quantos de fato apareceram.

1. Recall (revocação, ou cobertura) mede quanto do que você precisava achar a busca realmente achou.
2. Para medir, você monta perguntas de teste e anota antes qual documento traz a resposta certa de cada uma.
3. A busca do RAG devolve alguns trechos por pergunta. Se o trecho certo está entre eles, conta acerto. Recall é o total de acertos dividido pelo total de perguntas.
4. O número depois do arroba diz quantos trechos entram na conta. No recall@1 (recall no topo 1), só vale acerto se o trecho certo vier em primeiro lugar.
5. Duplicatas e versões velhas empurram o trecho certo para baixo da lista. Por isso a limpeza do acervo pode subir o recall@1, como o palestrante afirma ter visto ao dobrá-lo em testes de RAG com várias etapas (multi-hop).

Ajuda saber antes: RAG, Top-k retrieval, Embeddings, Conjunto de avaliação

Precision e recall (precisão e cobertura de um classificador). Precision e recall são como um fiscal de prova que procura cola, em que a precisão mede quantas das suas acusações eram cola de verdade e a cobertura mede quantas colas da sala ele conseguiu pegar.

1. Imagine um juiz que separa relatórios bons de ruins. Para saber se ele é confiável, você compara as decisões dele com as de uma pessoa que já rotulou os mesmos relatórios.
2. Precision (precisão) olha só para as vezes em que o juiz disse que o relatório era ruim. Ela pergunta quantas dessas acusações estavam certas.
3. Recall (cobertura) olha para todos os relatórios que eram ruins de fato. Ele pergunta quantos desses o juiz conseguiu pegar.
4. As duas medidas puxam para lados opostos. Um juiz rigoroso pega mais erros, mas gera falsos positivos (alarmes falsos). Um juiz cauteloso acerta quando acusa, mas deixa erros passarem.
5. Laurie recomenda priorizar recall na maioria dos casos, porque um alarme falso custa menos do que um erro que passa. Com só 12 exemplos, os números oscilam muito e servem apenas para ver se o juiz está na faixa certa.

Ajuda saber antes: LLM-as-a-judge, Golden dataset, Falso positivo e falso negativo

Signal (agente da Arize que agrupa falhas e propõe correções). O Signal é como um supervisor de loja que revê as gravações das câmeras a cada turno, anota os problemas que se repetem e deixa no quadro uma lista de consertos para o gerente aprovar.

1. Um assistente de IA atende milhares de pessoas por dia, e ninguém consegue reler todas essas conversas. O Signal faz essa leitura no lugar da equipe.
2. Ele é um agente, ou seja, um programa de IA que age sozinho, e roda dentro do Arize AX, a plataforma de observabilidade da Arize. Por padrão, ele acorda a cada seis horas, e esse intervalo pode ser ajustado.
3. Em cada rodada, ele lê os traces (registros de cada passo do agente), procura padrões e agrupa as falhas que se repetem. Na demo, ele achou restrição de idade inventada, resposta a pedido perigoso e obediência a instrução aleatória.
4. Para cada problema, ele oferece caminhos. Pode abrir uma issue (chamado de tarefa) no GitHub, guardar o trace em um dataset (conjunto de exemplos) para rodar evals ou criar um evaluator (avaliador) para aquele erro.
5. Com o repositório conectado, ele lê o código e abre um pull request (proposta de mudança no código) com a correção. O humano só aprova ou rejeita, e isso fecha o ciclo de melhoria sem alguém pedir a análise.

Ajuda saber antes: Trace, Eval, Observabilidade de agentes, Pull request

Agreement gate (trava de CI pela taxa de concordância do juiz). Um agreement gate é como a catraca do estádio que só libera a entrada quando o fiscal confere que o ingresso bate com a lista oficial na maioria das vezes.

1. Antes de liberar uma nova versão do sistema, uma checagem automática decide se ela pode seguir ou se fica parada.
2. A checagem compara as notas dadas por um juiz automático com as notas que uma pessoa já deu para os mesmos casos.
3. O resultado vira uma taxa de concordância (agreement rate), ou seja, a porcentagem de casos em que juiz e humano deram o mesmo veredicto.
4. Essa conta roda no CI (integração contínua, o processo que testa cada mudança no código). Abaixo de 80% o teste fica vermelho e nada vai para produção. Entre 80% e 90% fica verde.
5. Para a trava continuar confiável, fixe a versão exata do modelo juiz. Um apelido como GPT-4o mini pode passar a apontar para outra versão sem aviso e mudar o resultado.

Ajuda saber antes: Eval, LLM-as-a-judge, Conjunto de ouro (golden dataset), Integração contínua (CI)

Cohen's kappa (medida de concordância entre avaliadores). Cohen's kappa é como conferir se dois juízes de uma competição de ginástica concordam de verdade, descontando as vezes em que dariam a mesma nota só no chute.

1. Quando duas pessoas avaliam as mesmas coisas, como provas ou tarefas, queremos saber se elas concordam. O Cohen's kappa (kappa de Cohen) resume essa concordância em um único número.
2. Contar só a porcentagem de acordos engana. Se quase toda tarefa é aprovada, dois avaliadores que aprovam tudo sem olhar concordam muito por pura sorte.
3. Por isso o kappa estima quanto acordo viria do acaso. Ele usa a frequência com que cada avaliador costuma dizer sim ou não e desconta esse valor do acordo que realmente aconteceu.
4. A conta é kappa = (acordo observado menos acordo por acaso) dividido por (1 menos acordo por acaso). O valor 1 indica acordo perfeito, 0 indica acordo igual ao do acaso e valores negativos indicam acordo pior que o acaso.
5. No talk, o verificador teve kappa de 0.58 com os humanos, o mesmo nível medido entre dois anotadores humanos. Na escala mais usada, valores de 0.41 a 0.60 contam como concordância moderada.

Ajuda saber antes: Probabilidade básica, Anotação humana (rótulos de referência), Verifier

Topics e facets (agrupamento de padrões nos traces por facet). Topics e facets é como uma professora que lê todas as redações da turma e separa em pilhas por assunto, pelo humor do aluno e pelo tipo de erro, sem ter decidido as pilhas antes.

1. Um agente em produção gera milhares de conversas, e ninguém consegue ler todas. Topics lê esses registros, agrupa os parecidos e mostra com que frequência cada padrão aparece.
2. Uma facet (faceta, ou ângulo de leitura) define o que observar em cada conversa. As prontas são tarefa (o que o usuário quer), sentimento (como ele se sente) e problemas (onde o agente falhou). Você também pode criar a sua com um prompt próprio.
3. Primeiro, um pré-processador (preprocessor) enxuga o trace, o registro passo a passo da execução, numa conversa curta entre usuário, assistente e chamadas de ferramenta. Depois um modelo resume essa conversa pelo ângulo da facet.
4. Cada resumo vira um embedding (vetor de números que representa o significado). Resumos parecidos ficam próximos, e isso forma um topic map (mapa de tópicos) que rotula e classifica cada trace.
5. Com os rótulos, você filtra o volume e acha falhas que seus evals não testavam, além de pedidos de funcionalidade novos. A Braintrust roda o pipeline em modelo próprio, a US$ 0,06 por milhão de tokens de entrada e US$ 0,40 de saída.

Ajuda saber antes: Trace, Embedding, Eval flywheel, Online scoring

Remote eval (eval exposto a um playground, executado no seu servidor). Remote eval é como um restaurante em que o cliente escolhe os temperos no balcão, o prato é feito na cozinha do dono e volta pronto para a mesa.

1. Um eval (avaliação) roda o agente sobre um conjunto de casos de teste e dá nota às respostas. Normalmente só quem programa consegue rodar e mudar esse teste.
2. O remote eval (avaliação remota) leva esse mesmo eval para um playground (área de testes visual) da Braintrust. Gerentes de produto e especialistas mudam o prompt de sistema ou a descrição de uma ferramenta e clicam em run.
3. No código do eval, o engenheiro declara parâmetros. Eles indicam quais peças do agente a tela pode alterar, como o prompt e o modelo de cada subagente.
4. Ao clicar em run, a Braintrust envia uma requisição POST ao endpoint exposto no seu servidor, local (localhost:8300 com a opção --dev) ou na sua infraestrutura. O código roda lá e os resultados voltam em streaming para o playground.
5. Assim o engenheiro deixa de ser o gargalo para quem quer ajustar prompts, e o código e as ferramentas do agente continuam no seu ambiente.

Ajuda saber antes: Eval, Eval flywheel, Prompt de sistema, Endpoint de API

OpenInference (convenções abertas de rastreamento para IA). OpenInference é como um formulário padrão de ocorrência que todas as filiais de uma empresa preenchem do mesmo jeito, mesmo que cada filial use um sistema próprio no dia a dia.

1. Cada empresa de IA, como OpenAI e Google, registra o que o modelo faz de um jeito diferente. Comparar esses registros dá trabalho, porque os campos têm nomes e formatos distintos.
2. O OpenInference define um vocabulário comum e aberto para esses registros. Ele diz quais campos existem e como cada um se chama, como sessão, entrada de áudio, transcrição, resposta e contagem de tokens (pedaços de texto ou áudio que o modelo cobra).
3. Um instrumentador automático (auto instrumenter) fica ligado ao seu agente e traduz os eventos de websocket (canal de comunicação contínua) de provedores como OpenAI Realtime e Gemini Live para esse vocabulário.
4. O resultado são spans (trechos do trace) compatíveis com OpenTelemetry, o padrão aberto de telemetria. Por isso você pode enviar os dados para a Arize ou para outro back end, como o Grafana.
5. Com um esquema único, você consulta e filtra milhares de chamadas de provedores diferentes da mesma forma. Trocar de modelo deixa de exigir um parser (leitor de formato) novo para cada fornecedor.

Ajuda saber antes: Trace, Span, OpenTelemetry, Websocket

Time to first token (TTFT) (Tempo até o primeiro token). O TTFT é como o tempo entre fazer o pedido no restaurante e o garçom trazer o primeiro prato à mesa.

1. Quando você manda uma pergunta para um chatbot, existe uma espera até a primeira palavra aparecer na tela. Essa espera tem nome, time to first token (tempo até o primeiro token).
2. Nesse intervalo o motor lê o prompt inteiro de uma vez. Essa fase se chama prefill (pré-preenchimento) e termina com o primeiro token pronto.
3. Prompts longos pedem mais conta no prefill e aumentam o TTFT. Reaproveitar um prefixo já calculado no KV cache encurta essa etapa.
4. O TTFT anda junto com a inter-token latency (tempo entre tokens), que mede a velocidade das palavras seguintes. As duas formam o orçamento de latência do deploy.
5. Para um chatbot com pessoas, Frye fala em poucas centenas de milissegundos no máximo. Um agente em segundo plano tolera minutos.

Ajuda saber antes: Token, Prefill e decode, Latência, KV cache

Scheduler (Escalonador de trabalho para a GPU). O scheduler é como o chefe de cozinha que decide quais pedidos vão juntos para o fogão, para que o fogão nunca fique desligado esperando.

1. Um modelo de IA atende muitos pedidos ao mesmo tempo, e alguém precisa decidir a ordem e o que vai junto. Esse papel é do scheduler (escalonador).
2. Ele recebe os pedidos já convertidos em tokens, confere quanta memória cada um vai gastar e quanta está livre, e coloca o excedente em uma fila.
3. Depois monta lotes (batches) de pedidos e os envia para a GPU, que rende mais quando processa vários pedidos em paralelo.
4. No SGLang e no vLLM o scheduler roda em Python, em uma única thread (linha de execução). Ele faz pouca conta, mas toda tarefa da GPU passa por ele.
5. Se o scheduler demora a preparar o próximo lote, a GPU, a peça mais cara, fica parada. Por isso ele vira gargalo e concentra boa parte do trabalho de otimização.

Ajuda saber antes: GPU, Token, Batching, Tokenizer