Guias
O que funciona hoje
O que você pode avaliar com o Oloproof hoje, como chegar lá (SDK Python, oloproof.yaml e a CLI, ou o navegador) e o que não está construído. Esta página se baseia na auditoria de capacidades de 8 de outubro de 2026, uma revisão interna que verificou cada linha contra o código e os seus testes, e não contra planos.
Como ler esta página
"SDK" significa o pacote Python (import oloproof). "YAML" significa um projeto que você executa com oloproof run a partir do oloproof.yaml. Não são a mesma superfície: alguns avaliadores existem em apenas uma delas, e esta página diz qual. "Navegador" significa o workbench hospedado, que mostra o que você envia com oloproof push; ele não executa avaliações que você não definiu em código ou em YAML.
O Oloproof chama o seu sistema; ele não o hospeda, não o isola e não o reinicia. A sua aplicação é dona do próprio estado, das sessões e dos efeitos colaterais das ferramentas durante uma execução.
Por tipo de sistema
| Seu sistema | O que funciona | Onde | Não construído |
|---|---|---|---|
| Classificador ou saída estruturada | Correspondência exata, contém, regex, JSON schema, juiz de rubrica, juiz de probabilidade, classificador de modelo; taxas de aprovação com intervalos | SDK e YAML; model_classifier, probability_judge e cascade apenas no YAML | n/a |
| Geração de texto, resumos, extração | As mesmas verificações sobre texto livre, juízes de rubrica, concordância do juiz com rótulos humanos, preferência pareada | SDK e YAML; a preferência é o comando oloproof prefer | BLEU, ROUGE ou similaridade por embeddings (escreva uma com @evaluator) |
| RAG que você executa como caixa-preta | Hit rate, recall, MRR, nDCG, validade de citações, juízes de fundamentação e de suporte das citações, a partir de artefatos de recuperação que o seu sistema registra ou retorna | SDK e YAML | Diagnóstico: diagnose precisa de um sistema em estágios |
| RAG construído em estágios | Tudo acima, cache por estágio e oloproof diagnose com contexto de referência, mudanças de top-k ou de reranker ao lado de um controle | SDK @rag_system, YAML system.rag, CLI diagnose | Intervenções além dessas três |
| Agente que usa ferramentas | Limites de passos, ferramentas obrigatórias e proibidas, ordem das ferramentas, loops, restrições, a partir de uma trajetória registrada | SDK e YAML | Uma verificação de qualidade da trajetória julgada por LLM |
| Sistema multiagente | Roteamento, permissões de ferramentas por agente, limites de handoff | SDK e YAML | n/a |
| Replay de agente | Reexecutar um caso a partir de um checkpoint para rotular um passo como necessário ou não | Apenas SDK (replay_case), para um sistema que suporta checkpoints | Um comando de CLI |
| Modelo classificador binário | Acurácia, precisão, recall, Brier, log loss, ranqueamento (AUC) | SDK e YAML predictive: | n/a |
| Modelo multiclasse | Um bloco por classe (uma contra as demais) | SDK e YAML | Médias macro ou micro |
| Modelo de regressão | Erro absoluto dentro de um target_range declarado | SDK e YAML | Erro quadrático, R quadrado, erro sem limites |
| Conversa de múltiplos turnos | Se cada turno roteirizado foi respondido, e um juiz de rubrica sobre a conversa inteira | Apenas SDK (ConversationCompleted, ConversationJudge) | Tipos YAML, pontuações por turno, um simulador de usuário, replay de conversa |
| Imagens, áudio, vídeo | Nada nativo: um caso pode levar uma URL ou um arquivo codificado através do seu sistema, e @evaluator pode verificar a saída | n/a | Os juízes veem apenas texto JSON; sem artefatos de mídia nem renderização |
Uma alternativa para múltiplos turnos: faça de cada turno um caso e dê aos turnos de uma mesma conversa o mesmo group_id, para que a análise os trate como um cluster (Clusters). Cada turno é então uma chamada separada, não um diálogo registrado.
Conectando o seu sistema
- Callable Python: @system no SDK ou system.callable: module:function no YAML. Ele recebe o input do caso e retorna um dicionário. Funções síncronas e assíncronas funcionam.
- HTTP: system.http com url, method, output_path, artifacts e timeout_s. A entrada do caso é enviada como corpo JSON e a resposta é lida como JSON. Cabeçalhos e autenticação ainda não podem ser configurados; coloque um endpoint que precise de chave atrás de um callable que a adicione.
- Avaliadores personalizados: @evaluator no SDK. O oloproof.yaml ainda não pode nomear um.
Fluxos de trabalho
| Fluxo | O que funciona | Não construído |
|---|---|---|
| Comparar duas versões | Superioridade pareada, não inferioridade e equivalência; segmentos com controle de multiplicidade | n/a |
| CI | Códigos de saída do oloproof gate a partir do block_on da sua política, aprovação, registros assinados; um resumo de pull request (--summary markdown) | n/a |
| Revisão humana | Rótulos de um arquivo ou do terminal; uma fila de revisão no navegador com revisores designados em um workspace hospedado | Uma fila de revisão no navegador em um projeto local |
| Workbench no navegador | Execuções, casos, comparações, diagnósticos, avaliadores, revisão e tráfego, após oloproof push | Importação de datasets, criação de juízes, agendamentos, alertas e postmortems (mostrados como planejados) |
| Navegador local | n/a | Nenhum comando da CLI serve o workbench localmente; ele é hospedado |
O que foi testado, e como
Cada família acima tem testes automatizados, executados sobre fixtures e provedores simulados. Execuções contra sistemas reais com modelos reais estão registradas para RAG, um único agente e uma conversa de múltiplos turnos; nenhuma ainda para modelos preditivos ou sistemas multiagente. Os métodos estatísticos que decidem lançamentos são, cada um, admitidos por sua própria auditoria; uma métrica sem intervalo admitido não decide uma regra sobre um intervalo, e uma regra que precisaria de um retorna MANUAL_REVIEW ou INSUFFICIENT_EVIDENCE com o seu motivo.