> ## Documentation Index > Fetch the complete documentation index at: https://docs.tela.com/llms.txt > Use this file to discover all available pages before exploring further. # Regras de validação e métricas > Respostas Esperadas e Erradas, regras de validação de IA por atributo, como cada execução é validada automaticamente e como a Pontuação de Precisão é calculada Revisar à mão cada atributo de cada Caso de Teste funciona na primeira execução. Não funciona na décima versão. As validações são a forma de um Caso de Teste lembrar os seus vereditos: os exemplos que você marcou e as regras que escreveu são aplicados a cada nova execução, então a maioria dos atributos chega já revisada e você só olha o que é novo. As métricas no topo da experiência **Testar** resumem esses vereditos em números que você compara entre versões. Os dois ficam no Caso de Teste, por atributo. A regra *O total deve ser um número sem símbolo de moeda* em `total_amount` da nota com duas moedas vale para toda execução daquele Caso de Teste, em toda versão, e para nada mais. ## Onde as validações ficam Abra um Caso de Teste, passe o mouse sobre um atributo e clique em **Validações**. O selo no botão conta os exemplos e as regras daquele atributo. O popover tem duas abas: * **Regras**: as regras em linguagem natural deste atributo, numeradas. Digite uma regra na caixa (*Adicionar regra...*) e clique em **Adicionar** ou pressione Enter. Passe o mouse sobre uma regra para excluí-la. * **Exemplos**: as **Respostas Esperadas** e **Respostas Erradas**. Escolha **Resposta certa** ou **Resposta errada** no seletor, digite o valor (*Adicionar exemplo...*) e **Adicionar**. Polegar para cima e para baixo no resultado também adicionam exemplos aqui. ![Popover Validações do atributo total\_amount, aba Regras, com duas regras e a segunda em vermelho como reprovada](https://mintcdn.com/meistrari/M2w7BduKZAFA1Sbx/images/pt/test-cases/validations-popover.png?fit=max\&auto=format\&n=M2w7BduKZAFA1Sbx\&q=85\&s=5065b392a28c443e795fe0fd6ca5b68a) Listas e tabelas têm **Regras** só no nível do atributo inteiro; os itens delas são comparados individualmente com os exemplos do pai. > [!NOTE] > > Regras e exemplos pertencem a um Caso de Teste. Não existe conjunto de regras do Canvas inteiro: uma regra que você quer em toda nota fiscal precisa ser adicionada a cada Caso de Teste, e um Caso de Teste novo começa sem nenhuma. ## Respostas Esperadas e Erradas Uma **Resposta Esperada** é um valor certo para este atributo neste Caso de Teste; uma **Resposta Errada** é um valor que foi produzido uma vez e está errado. Elas vêm de três lugares: * os seus polegares para cima (Esperada) e para baixo (Errada) em um resultado; * uma tarefa da Workstation transformada em Caso de Teste: valores não tocados viram Esperadas, valores editados viram Errada (o original) e Esperada (a correção); * a aba **Exemplos**, onde você as digita. Um atributo pode ter várias Respostas Esperadas. Em `category` da nota limpa, `Office supplies` e `office-supplies` podem ambas estar certas. A comparação ignora maiúsculas e minúsculas e, em listas, a ordem, então `["USD", "EUR"]` coincide com `["eur", "usd"]`. ## Como uma execução é validada Quando uma execução termina, o Tela valida cada atributo do Formato de Saída antes de você ver: **1. Correspondência exata com os exemplos** Um valor igual a uma Resposta Esperada é **Bom** (*Corresponde exatamente a uma boa resposta*). Um valor igual a uma Resposta Errada é **Ruim** (*Corresponde exatamente a uma resposta errada*). **2. Sem correspondência, com exemplos, sem regras** Quando o atributo tem Respostas Esperadas, o valor não coincide com nenhuma e não há regras, o valor é **Ruim** (*Não corresponde às respostas esperadas*). `due_date` = `2024-01-05` quando a única Resposta Esperada é `2024-05-01` reprova aqui. **3. Regras** Caso contrário, quando o atributo tem regras, um juiz de IA recebe o atributo, o valor e todas as regras de uma vez e devolve **Bom** ou **Ruim** com um raciocínio e uma confiança. Abaixo de 50% de confiança o veredito é inconclusivo e o atributo fica pendente para você. **4. Nada se aplica** Um valor vazio sem exemplos é sinalizado como *Atributo está vazio*. Qualquer outro valor sem exemplos e sem regras fica para você revisar. Vereditos automáticos mostram a marca **AUTO-REVISADO** no atributo. **Ver validações** abre o detalhe: **Correspondência Exata** com a **Resposta correspondente**, ou **Regra IA** com o raciocínio do juiz, a **Confiança** e as **Regras que falharam**, que também aparecem em vermelho na aba **Regras**. Um veredito para o mesmo valor e as mesmas regras é reaproveitado de um cache (**Resultado de validação em cache**) em vez de chamar o juiz de novo; editar, adicionar ou remover uma regra invalida o cache. Você pode sobrescrever qualquer veredito automático com o seu polegar. A sua marcação vence e é guardada como exemplo, então a próxima execução a segue. > [!TIP] > > Escreva regras como você explicaria a um colega, uma condição por regra: *Deve ser uma data no formato ISO (YYYY-MM-DD)*, *Deve ser o valor depois dos impostos*, *Deve ser um de: Office supplies, Services, Travel*. Uma regra que lista várias condições reprova como um todo e informa menos. ### Escolhendo entre exemplos e regras | Use | Quando | | - | - | | Respostas Esperadas | O valor certo é fixo para esta entrada: um nome de fornecedor, uma data, uma categoria | | Respostas Erradas | Um erro específico volta sempre e você quer que ele seja sinalizado no momento em que reaparecer | | Regras | Vários valores são aceitáveis, ou o atributo é texto livre ou lista: *deve estar em inglês*, *deve mencionar o número da nota*, *não deve incluir itens com quantidade zero* | Para o caso *Não é nota fiscal*, o `total_amount` certo é vazio. Marque o valor vazio como **Bom** para que um resultado vazio seja uma Resposta Esperada, e adicione a regra *Deve ser vazio, este documento não é nota fiscal* para pegar um total inventado com uma explicação. ## Métricas O card de resumo mostra as métricas da versão que você está vendo, calculadas a partir da última execução de cada Caso de Teste naquela versão. Filtros na tabela (categorias, usuário, data, status) restringem as métricas às linhas que correspondem. ![Card de resumo com Pontuação de Precisão, cobertura Confiável, Revisados 5 de 6 e Atributos 92%](https://mintcdn.com/meistrari/M2w7BduKZAFA1Sbx/images/pt/test-cases/summary-card.png?fit=max\&auto=format\&n=M2w7BduKZAFA1Sbx\&q=85\&s=8e0273cbbdf35a2b08def0810fe4e15c) | Métrica | O que mede | | - | - | | **Pontuação de Precisão** | Entre os Casos de Teste em que pelo menos um atributo tem veredito: os atributos marcados como **Bom**, divididos por todos os atributos desses Casos de Teste. Mostrada como porcentagem com um rótulo: **Sem dados**, **Precário** (até 49), **Regular** (50 a 64), **Bom** (65 a 79), **Muito bom** (80 a 89), **Excelente** (90 ou mais) | | **Revisados** | Quantos Casos de Teste estão **Concluído**, do total: *5 de 6* | | **Atributos** | A parcela de atributos, em todas as execuções, que tem veredito (Bom ou Ruim). É a sua cobertura: **Sem cobertura**, **Baixa cobertura** (abaixo de 40%), **Média cobertura** (abaixo de 75%), **Confiável** (75% ou mais) | Leia as três juntas. Uma **Pontuação de Precisão** de 100% com **Baixa cobertura** quer dizer que você revisou poucos atributos e eles estavam certos; diz pouco sobre o resto. O título do card muda conforme a combinação das duas, de *Comece a revisar* a *Continue revisando* até *Parabéns, seu sistema está ótimo!*, e o arco em volta da pontuação fica cinza até a cobertura chegar a 40%. Por Caso de Teste, a coluna **Pontuação** mostra a parcela de atributos marcados como Bom na última execução, e passar o mouse sobre o nome mostra as contagens de atributos positivos, negativos e pendentes. Um Caso de Teste cuja execução é mais antiga que a versão que você está vendo não mostra pontuação. > [!NOTE] > > Atributos pendentes reduzem a **Pontuação de Precisão** de um Caso de Teste parcialmente revisado: quatro atributos, dois Bom e dois pendentes, dão 50%. Termine a revisão, ou use **Marcar como revisado**, antes de ler o número como medida de qualidade. ### Em Agentes Casos de teste de Agente mostram a mesma **Pontuação de Precisão**, **Revisados** e **Atributos**. Os vereditos vêm dos seus polegares e do avaliador, que julga o resultado inteiro contra as **Regras** do caso de teste e o prompt global de **Configurar avaliador**, e **Critérios** agrupa atributos para calcular precisões separadas. Veja [Rodando todos](https://docs.tela.com/pt/agent/testing.md#rodando-todos). ### Em Workflows Os atributos contados são os dos Formatos de Saída das etapas de IA do Workflow, agrupados por etapa. Etapas sem Formato de Saída não acrescentam nada às métricas. Veja [Nos Casos de Teste](https://docs.tela.com/pt/workflow/outputs-and-results.md#nos-casos-de-teste). ## Pela API Cada Caso de Teste devolvido por [`GET /test-case`](https://docs.tela.com/api-reference/test-case/get) carrega seus `answers` (um objeto por atributo, com arrays `good` e `bad`) e, com `includeGenerations=true`, suas execuções com `attributeFeedback` e `validations`. Regras são adicionadas com `POST /test-case/{id}/validation-rules/{attributeKey}` e um corpo `{ "description": "..." }`, e removidas com `DELETE /test-case/{id}/validation-rules/{attributeKey}/{ruleId}`. ```sh cURL theme={null} curl -X POST https://api.tela.com/test-case/2a3b4c5d-6e7f-4a8b-9c0d-1e2f3a4b5c6d/validation-rules/total_amount \ -H 'Content-Type: application/json' \ -H "Authorization: Bearer $TELA_API_KEY" \ -d '{ "description": "Must be a number without currency symbol" }' ``` > [!NOTE] > > Os endpoints de validation-rules e os de feedback de generation ainda não fazem parte da referência de API publicada. O formato deles vem da aplicação e pode mudar. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.