Como ler a evidência por trás de um lançamento de IA

Você não precisa saber Python, estatística nem como chamar um modelo de linguagem. Comece por um problema conhecido: uma resposta de IA parece convincente, mas ainda é preciso decidir se ela é segura e útil o bastante para ser lançada. Esta introdução apresenta, em linguagem simples, as poucas ideias necessárias para examinar essa decisão.

1 · Defina o fluxo de trabalho antes do juiz

Comece por uma tarefa conhecida: um assistente responde à dúvida de um cliente sobre reembolso. Antes de verificar a resposta, anote o que o assistente pode fazer, qual política deve usar, como reconhecer um resultado útil e quando uma pessoa precisa assumir. Essa descrição curta é o contrato do fluxo de trabalho. Ela evita confundir uma resposta bem escrita com uma tarefa concluída.

2 · Uma chamada LLM e seu registro de execução

Uma chamada LLM é uma função: você envia um prompt (as mensagens de entrada), e o modelo retorna o texto de saída. Essa é a forma mais simples da operação. Um registro de execução é a versão registrada dessa chamada — a entrada, a saída e os dados necessários para investigar problemas e medi-la: quanto tempo levou (latência), quantos tokens usou, quais chamadas de ferramenta aconteceram, qual contexto foi recuperado. Toda avaliação deste curso usa esses registros. Sem registro de execução, não há avaliação.

# a chamada de LLM mais simples e seu registro de execução
out = llm.chat(messages=[{"role": "user", "content": "Summarize the meeting"}])

trace = {
    "input":  "Summarize the meeting",
    "output": out.text,
    "latency_ms": out.latency,
    "tokens":    out.usage,
}
# os juízes do curso leem campos como esses — por isso os registros vêm primeiro

3 · RAG em duas linhas

Imagine que o assistente precise consultar a política atual de reembolso antes de responder. O software recupera primeiro o trecho relevante e o envia junto com a pergunta. Esse padrão recebe o nome de RAG (Retrieval-Augmented Generation). Ele oferece uma fonte ao modelo, mas não garante que ela seja pertinente nem que a resposta a siga. Essa diferença importa no lançamento: uma resposta fluente deve falhar quando cita a política errada ou contradiz o trecho recuperado. Os próximos módulos mostram como verificar esses dois pontos de falha.

4 · Extensão técnica opcional: o Python dos laboratórios

Você pode concluir o percurso central de raciocínio sem Python. Se escolher executar os laboratórios opcionais, o curso usa um subconjunto pequeno e consistente:

• Funções e argumentos — def judge(case, llm): e argumentos nomeados como --threshold 0.7.
• Dataclasses — uma estrutura tipada, por exemplo @dataclass class Verdict: passed; evidence; confidence. Pense nela como um conjunto de campos nomeados.
• Dicionários e listas — o registro é um dicionário; um conjunto de dados é uma lista de dicionários.
• Executando um script — python some_lab.py --input samples/. Cada laboratório funciona offline, sem chave de API.

Se essas linhas forem novas para você, continue pelos exercícios sem código. Volte a esta extensão somente se quiser implementar o método.

5 · Juiz, gate, harness e avaliação — as palavras que o curso usa

Quatro termos recorrem e não são intercambiáveis:

• Um juiz é código que inspeciona uma saída e retorna um veredito + evidência + confiança. (Módulo 0.3.)
• Um gate é uma decisão que bloqueia ou permite um lançamento com base no veredito de um juiz. (Módulo 0.5.)
• Um harness é o conjunto repetível que executa os casos, chama os juízes, aplica os gates e registra as evidências. (Módulo 0.9.)
• Uma avaliação é a prática mais ampla de medir a qualidade de forma sistemática — registros de execução, conjuntos de referência e desvios. (Trilha EVAL.)

Esse é todo o vocabulário. O restante do curso se apoia nessas cinco ideias — contrato de fluxo de trabalho, chamada e registro de execução, RAG, o subconjunto de Python e juiz/gate/avaliação — sem repetir a explicação.