Registro de alterações

oloproof 0.1.0a1 está publicado, então o caminho dourado começa com pip install oloproof em um ambiente limpo e vai direto para oloproof init e oloproof run. As versões são construídas e publicadas a partir de um commit com tag no CI, pela publicação confiável do PyPI, sem nenhum token armazenado.

Uma execução ou comparação que para antes do fim agora registra cada consulta que fez, e o workbench as reproduz: o intervalo válido a qualquer momento se estreitando a cada consulta diante de um limiar que não se move, e a consulta em que cada regra decidiu. Ele desenha apenas intervalos que o motor registrou. Um intervalo de amostra fixa nunca é animado como se estivesse ao vivo, já que observá-lo até que pareça bom anula sua garantia.

⌘K ou Ctrl+K lista todos os destinos que você pode ver, e um id de execução ou digest de comparação colado o abre. g seguido de uma letra navega, j e k percorrem as linhas de uma tabela, e ? lista todos os atalhos. Um caso abre ao lado da sua execução, com sua cadeia de evidências e as pessoas que o rotularam. Toda animação para com movimento reduzido.

O workbench agora atende oloproof.com, e o caminho dourado de ponta a ponta passou no servidor: um revisor rotulou 80 casos sorteados pelo espaço de trabalho, encontrou 7 respostas erradas que o juiz havia aprovado, e o espaço de trabalho decidiu Aprovado com base em sua amostra verificada (91,2%, intervalo de 74,5% a 100,0%), enquanto a execução enviada sozinha tinha evidência insuficiente. O acesso é por convite.

oloproof collect recebe OTLP/HTTP de um SDK padrão do OpenTelemetry, monta spans de GenAI e OpenInference em traces endereçados por conteúdo e mantém o conteúdo deles na sua máquina; um push segue a sua política de saída de dados. oloproof traces promote transforma um trace em um caso de teste com sua procedência e recusa duplicatas.

O seu coletor assina um compromisso com cada trace que selou a cada hora. Em seguida, o espaço de trabalho sorteia uma amostra com sua própria aleatoriedade e confere cada trace sorteado com o compromisso, de modo que uma amostra não pode ser escolhida a dedo retendo traces. oloproof traces evaluate julga a amostra com base nas saídas registradas, o espaço de trabalho a decide sob a avaliação que um Owner fixou, e uma sequência de confiança acompanha cada métrica ao longo das amostras na página Production do projeto.

Um Owner ou Admin abre uma fila e atribui revisores, que rotulam pelo teclado: aprovado ou reprovado, uma nota em uma escala declarada ou uma preferência às cegas entre duas execuções, cada uma registrada por conta. O navegador do revisor busca o conteúdo dos casos no oloproof collect do seu lado com um tíquete assinado de cinco minutos, então o espaço de trabalho nunca o armazena.

Uma execução pode ser assinada por uma chave de runner que um Owner registrou, ou pelo worker gerenciado. Um Owner fixa a avaliação inteira (suíte, avaliadores, métricas e execução de referência) e sua política de gate, e o espaço de trabalho decide cada versão do sistema na primeira execução exatamente dessa avaliação, comparando-a com a execução fixada. Rótulos humanos só contam quando vêm de rotuladores independentes, contados por conta.

Um intervalo PPI corrige um juiz com uma amostra aleatória de rótulos humanos, e sua garantia exige uma amostra que ninguém escolheu. O espaço de trabalho agora sorteia essa amostra depois que a evidência da execução é congelada lá, guarda a semente para si e confere o intervalo corrigido com seu próprio motor. A página da execução informa se o espaço de trabalho verificou um intervalo; uma amostra sorteada na sua própria máquina continua marcada como de boa-fé.

Uma política com early_stopping: true executa os casos em lotes com semente e para uma execução, ou uma candidata e sua referência em sincronia, assim que todas as regras decidem, o que é registrado como DECIDED_EARLY junto com os casos de que não precisou. As taxas interrompidas usam um intervalo de apostas válido a qualquer momento, então olhar após cada lote mantém sua garantia. A taxa de aprovação de um juiz pode passar por um gate sobre um intervalo PPI que combina o juiz com uma amostra aleatória às cegas de rótulos humanos, exibido ao lado dos intervalos só do juiz e só humano.

Quatro notificações, cada uma uma categoria que um membro pode desativar no próprio e-mail: um job gerenciado terminou ou falhou, uma execução ou comparação enviada cujo gate bloqueia um lançamento, o uso em 80% e 100% da cota gratuita, e um membro entrou. Um e-mail de gate cita a decisão armazenada e leva à execução, sem conteúdo de casos. Apenas e-mail: sem Slack, pager ou webhook.

Entre com um endereço de e-mail e uma senha, além de com um provedor, com endereços verificados e redefinições. Uma pessoa pode excluir a própria conta: o usuário e todos os espaços de trabalho dos quais só ela fazia parte são removidos de uma vez, e o worker apaga a evidência desses espaços de trabalho.

Um juiz pode responder a uma pergunta tipada (sim ou não, uma escolha, uma nota segundo níveis) com uma probabilidade para cada resposta, lida das probabilidades de tokens de um modelo local em uma única passagem direta. Sua calibração é medida contra rótulos humanos e registrada na sua entrada no registro, e uma cascata envia a um juiz mais forte apenas os casos em que um juiz barato está em dúvida. Um classificador treinado também pode ser um avaliador, sem chave e sem rede.

Rotule os casos de uma execução a partir de um arquivo ou do terminal, e teste um juiz em rascunho contra esses rótulos antes de adotá-lo. Um juiz informa seu viés ao lado da sua concordância, um juiz cujo viés excede uma margem declarada fica impedido de servir de gate, e uma validação deixa de valer assim que o modelo que ela mediu muda. Sondas sem rótulos verificam se um veredito se move quando nada que importa mudou, e as comparações pareadas são feitas nas duas ordens, de modo que uma resposta preferida só pela sua posição aparece sem que ninguém rotule.

Uma trajetória registra qual agente executou cada passo, e cada passagem de controle. Os avaliadores julgam o roteamento (se a solicitação chegou ao agente que deveria tratá-la), as permissões de ferramentas (se algum agente chamou uma ferramenta que não lhe cabia chamar) e agentes que passam o controle de um lado para o outro em vez de terminar, e os recortes agrupam os casos por rota.

Uma suíte pode medir cada caso várias vezes. As réplicas são agregadas por caso antes de qualquer intervalo, as comparações as pareiam como frações, e a execução informa quantos casos discordaram de si mesmos. Um sistema pode marcar uma falha como transitória para que o runner tente de novo: em um sistema RAG real, isso recuperou 18 de 22 casos ausentes e estreitou o intervalo em 39%.