Erros

A distinção pela qual esta página existe: uma execução que falhou e uma execução que deu erro são coisas diferentes, e apresentar uma como a outra diz a um desenvolvedor que a mudança dele é ruim quando a verdade é que o harness caiu.

Uma falha é um resultado. Um erro não é.

FAIL significa que um gate foi avaliado e a evidência ficou abaixo do limiar. Isso é um resultado de qualidade sobre a mudança.

RUN_ERROR significa que a execução não foi concluída. Nenhum gate foi avaliado e nada sobre a mudança foi medido. Não é um estado de decisão, e PARTIAL e CANCELLED também não são — eles descrevem o que aconteceu com uma execução, não o que foi decidido sobre um sistema.

O que uma execução incompleta informa

Um gate sobre uma execução incompleta sai com 5, não com 1. A evidência está ausente, não ruim, e as duas situações pedem respostas diferentes: um gate que falha pede que você olhe para a sua mudança; um incompleto pede que você olhe para a sua infraestrutura.

Casos que não puderam ser medidos

Um caso que deu erro é limitado, não descartado. Toda métrica registra quatro contagens — total, elegíveis, observados e ausentes — e o intervalo leva em conta os casos que não pôde ver.

Isso importa mais do que parece. Uma métrica que conta um caso não avaliado como zero atribui ao modelo, como falhas de qualidade, as próprias quedas do sistema, e um denominador que encolhe discretamente quando um sistema começa a falhar é a forma como um sistema que falha informa uma pontuação em alta. As duas coisas foram observadas em um assistente real, em que 13,8% das chamadas retornaram HTTP 500.

Falhas transitórias

Um sistema pode declarar que uma falha foi transitória, e uma falha transitória é repetida em vez de registrada como resultado de qualidade. Um timeout do provedor não é evidência sobre um prompt.

A declaração é explícita: um sistema callable levanta TransientError com retryable=True. retryable tem False como padrão, e um TransientError sem ele é registrado no caso como qualquer outra exceção, de modo que o caso fica ausente em vez de ser repetido. Um sistema HTTP e um provedor de juiz não precisam de declaração: um timeout, uma conexão perdida, um 429 ou um 5xx são repetidos para eles. Em ambos os casos, uma chamada é tentada no máximo quatro vezes, com backoff, e um caso que ainda assim falha fica ausente. Progresso e concorrência mostra os dois.

Erros de configuração

O código de saída 2 significa que a invocação ou a configuração estava errada e nada foi executado. Uma recusa por cota é um deles: é um erro de configuração com um motivo nomeado, recusado antes que o primeiro caso seja executado, e nunca é um estado de decisão. Um fato comercial não pode chegar vestido de veredito de qualidade.

Diagnosticando o que de fato falhou

oloproof diagnose RUN_ID --intervention gold-context --criterion answer_correct

A intervenção é aquilo sob a qual ele reexecuta os casos que falharam — gold-context, top-k ou reranker — e o critério diz de qual avaliador as falhas devem ser tomadas. Um diagnóstico informa fatores de falha com contagens, os ids de cenário por trás deles e as suposições que fez. Ele nomeia um fator, não uma causa: o engine não afirma que uma coisa produziu outra, e nenhuma tela que o exibe afirma isso também.

Próximos passos

• Conceitos básicos trata dos estados de decisão e dos denominadores.
• Gate no CI lista todos os códigos de saída.
• Avaliação de RAG percorre um diagnóstico de ponta a ponta.