# Otimize o auditor de IA com inteligência semântica Este é o segundo guia de uma série de duas partes. Partindo do Avaliador configurado em [**Automatize a validação de tarefas de IA com um quality gate**](https://docs.digibee.com/documentation/resources/pt-br/quickstarts/automate-ai-task-validation-with-a-quality-gate), este guia mostra como usar o **Versionamento** para iterar sobre o prompt do seu auditor e transformá-lo de um avaliador rígido e literal em um **Auditor Semântico** que entende a intenção do negócio, sem perder a capacidade de identificar erros reais. ## **Pré-requisitos** Antes de começar, certifique-se de que você: * Concluiu o guia [**Automatize a validação de tarefas de IA com um quality gate**](https://docs.digibee.com/documentation/resources/pt-br/quickstarts/automate-ai-task-validation-with-a-quality-gate), no qual configurou o Agente Avaliador e executou o Dataset `Avaliação de Precisão de Tarefas`. * Tem o Dataset `Avaliação de Precisão de Tarefas` disponível no seu Agent Component com ambos os Casos de Teste intactos. ## **Cenário** No guia **Automatize a validação de tarefas de IA com um quality gate**, o Agente Avaliador retornou um falso negativo no Caso de Teste **Consistência Semântica**: ele rejeitou um conjunto de tarefas totalmente corretas porque usavam vocabulário técnico (`Eliminar`, `Acrescentar`) em vez dos termos exatos do Protocolo Padrão (`Remover`, `Criar`). O objetivo deste guia é corrigir esse comportamento por meio de iteração de prompt, sem alterar o Dataset ou a Regra de Avaliação. Qualquer diferença nos resultados refletirá apenas a mudança no prompt. {% hint style="info" %} Ambos os guias utilizam o `GPT-4o Mini`. Este modelo foi escolhido porque tende a seguir instruções estruturadas de forma consistente, o que torna os resultados da avaliação mais previsíveis. Os resultados podem variar se você usar um modelo diferente. {% endhint %} ## **Passo a passo** {% stepper %} {% step %} ### Salve a versão de referência Antes de fazer qualquer alteração, salve a configuração atual do Agente como uma versão nomeada. Isso preserva o comportamento original como ponto de referência para comparação. 1. Abra o **Agent Component** (Avaliador). 2. Navegue até o dropdown de versões. Se nenhuma versão tiver sido salva ainda, ele aparecerá como **Rascunho**. 3. Clique em **Criar nova versão**, adicione a tag `auditor-literal` e salve a configuração atual.
Esta é a sua linha de base. Qualquer regressão introduzida pelo novo prompt ficará visível ao comparar os resultados com esta versão. {% endstep %} {% step %} ### Atualize a Mensagem do Sistema Substitua a Mensagem do Sistema atual pelo prompt abaixo. Esta versão muda a lógica de avaliação de correspondência literal de palavras para **mapeamento de intenção funcional**. O auditor agora aceitará tarefas que alcançam o mesmo resultado técnico, mesmo que usem terminologia diferente. {% code overflow="wrap" %} ``` Você é um Analista Sênior de Garantia de Qualidade especializado em avaliação semântica. Seu objetivo é comparar "Tarefas Esperadas" com "Tarefas Geradas pela IA", focando na intenção funcional em vez de correspondência literal de palavras. ### REGRAS DE AVALIAÇÃO: 1. CORRESPONDÊNCIA CONCEITUAL: Você deve identificar tarefas que alcançam o mesmo resultado técnico, mesmo que usem jargão complexo, sinônimos técnicos ou formulações diferentes. - Exemplo: "Achatar arquivos de entrada" corresponde a "Mesclar arquivos CSV". - Exemplo: "Máscara derivada de ISO-8601" corresponde a "Formatação de data". 2. AUSENTE: Uma tarefa é considerada presente apenas se uma ação funcionalmente equivalente puder ser claramente identificada na lista gerada. Cobertura vaga ou parcial não conta como correspondência. 3. EXTRA: Identifique tarefas que adicionam funcionalidades não solicitadas na lista "Esperada". ### LÓGICA DE DECISÃO: - Se todos os requisitos essenciais da lista "Esperada" forem atendidos (mesmo por meio de sinônimos técnicos), defina 'answer' como "Passed". - Se algum requisito essencial estiver funcionalmente ausente, defina 'answer' como "Not Passed". ### FORMATO DE OUTPUT: Retorne um objeto JSON com: - "reasoning": Uma breve explicação de como você mapeou os sinônimos para as tarefas esperadas. - "answer": "Passed" ou "Not Passed". ``` {% endcode %} Após atualizar, salve essa configuração como uma **nova versão** com o nome `auditor-semântico`.
Você agora tem duas configurações comparáveis: * `auditor-literal`: Avaliação baseada em palavras-chave, sem tolerância a sinônimos. * `auditor-semântico`: Avaliação baseada em intenção, aceita equivalentes funcionais. {% endstep %} {% step %} ### Execute novamente o Dataset Vá até a aba **Datasets**, selecione `Avaliação de Precisão de Tarefas` e clique em **Executar**. Como o Dataset, os Casos de Teste e a Regra de Avaliação permanecem inalterados, qualquer diferença de comportamento reflete apenas a modificação no prompt. Quando o Dataset é executado: * Ambos os Casos de Teste são executados sequencialmente contra o Agente atualizado. * Para cada execução, a plataforma extrai o valor em `$.body.answer`. * A Avaliação verifica se ele corresponde a `Passed`. * Cada Casos de Teste é marcado como **Aprovado** ou **Falhou** independentemente.
{% endstep %} {% step %} ### Compare os resultados Após a conclusão da execução, compare os resultados entre as duas versões: | Caso de Teste | auditor-literal | auditor-semântico | O que significa | | -------------------------- | --------------- | ----------------- | ---------------------------------------------------------------------------------------- | | **Consistência Semântica** | ❌ Falhou | ✅ Aprovado | Falso negativo eliminado. Sinônimos válidos agora são aceitos. | | **Omissão Funcional** | ❌ Falhou | ❌ Falhou | Comportamento correto mantido. A tarefa da Tabela Dinâmica ausente ainda é identificada. | O caso **Consistência Semântica** agora passa. Abra o resultado para inspecionar o output: {% code overflow="wrap" %} ```json { "reasoning": "As tarefas geradas pela IA e as esperadas foram analisadas em termos de intenção funcional. A primeira tarefa de mesclar arquivos CSV corresponde à mesclagem em uma aba principal. A segunda tarefa sobre a unicidade de chaves primárias se refere à remoção de registros duplicados, cumprindo a intenção esperada. A terceira tarefa de aplicar uma máscara derivada de ISO-8601 corresponde à conversão de datas, apesar do jargão técnico. A quarta tarefa sobre padronização de precisão decimal se alinha com a formatação da coluna 'Valor Total' como moeda. A última tarefa de adicionar uma planilha de resumo multidimensional corresponde à criação de uma aba secundária com uma Tabela Dinâmica. Todas as tarefas esperadas foram abordadas nas tarefas geradas, embora com terminologia diferente. Portanto, não há tarefas ausentes, e as tarefas extras são consideradas justificadas pela melhoria do resultado.", "answer": "Passed" } ``` {% endcode %} O caso **Omissão Funcional** ainda retorna `Not Passed`. Esse é o comportamento esperado. O prompt atualizado agora é flexível o suficiente para resolver sinônimos, mas ainda rigoroso para detectar uma etapa ausente. O requisito da Tabela Dinâmica não tem equivalente na lista gerada, portanto é corretamente sinalizado como ausente. {% hint style="info" %} Tornar um auditor mais semanticamente flexível introduz um risco: ele pode se tornar tolerante demais e deixar de identificar erros reais. O fato de **Omissão Funcional** ainda falhar é o seu teste de regressão confirmando que isso não aconteceu aqui. {% endhint %} {% endstep %} {% endstepper %} ### **O que isso valida** Este experimento confirma que a iteração de prompt com versionamento controlado produz resultados mensuráveis e comparáveis. Ao manter o Dataset e a Regra de Avaliação inalterados nas duas execuções, você isolou a variável apenas ao prompt. O resultado prova que: * O prompt `auditor-semântico` resolve sinônimos técnicos sem introduzir falsos positivos. * O quality gate permanece rigoroso onde o rigor é necessário. Omissões genuínas ainda são identificadas. * A versão `auditor-literal` é preservada como ponto de reversão caso o novo comportamento introduza regressões em outros cenários. ### **Por que isso importa** Engenharia de prompt é um processo iterativo e experimental. Sem versionamento e um Dataset reutilizável, cada iteração é uma mudança às cegas e você não consegue saber se um novo prompt é melhor ou apenas diferente. Ao combinar Versionamento com Datasets e Avaliações, você pode: * Medir o impacto de cada mudança de prompt em condições de teste idênticas. * Detectar regressões antes que cheguem à produção. * Construir um histórico documentado do comportamento do auditor entre configurações. * Promover apenas as versões que passam em todos os casos de teste. Esta é a base de um pipeline de avaliação de IA confiável e pronto para produção.