A UiPath adicionou, em pré-visualização, um controlo LLM-as-Judge à sua plataforma de agentes. As equipas podem escrever uma regra em linguagem natural e pedir a um modelo que avalie pedidos, respostas ou chamadas a modelos feitas durante a execução do agente. Há uma consequência imediata: cada verificação gera uma chamada real a um modelo e consome unidades para além do consumo normal do agente.
Isto significa que a regra escrita é apenas uma parte do controlo. O modelo usado como avaliador, o limiar de decisão, os exemplos, o momento em que a verificação é feita e a sua utilização durante os testes influenciam o resultado e devem ser tratados como configuração operacional.
O modelo avaliador passa a fazer parte do caminho de controlo
Nas notas de versão de setembro, a UiPath descreve a funcionalidade como um controlo integrado capaz de comparar entradas e saídas do agente com instruções definidas em linguagem natural. No SDK de Python, o mesmo mecanismo surge como LLMAsJudgeValidator e pode ser aplicado antes da execução, depois dela ou nas duas fases.
A configuração inclui o modelo avaliador, uma instrução até 4 000 caracteres, um limiar entre 0 e 6 e até dois exemplos positivos e dois negativos. A documentação indica que os valores mais baixos são mais exigentes e que o valor predefinido é 2. O modelo escolhido também tem de ser permitido pela política de governação da organização através do LLM Gateway.
O resultado deixa, por isso, de depender apenas de uma regra determinística. A mesma instrução pode ser aplicada de forma diferente quando muda o modelo, o limiar ou o conjunto de exemplos.
Uma auditoria precisa de mais do que o texto da regra
Guardar apenas a instrução em linguagem natural não chega para reconstruir uma decisão. Uma configuração auditável deve incluir, pelo menos, o modelo avaliador e a sua identidade de disponibilização, o limiar, os exemplos, a fase em que o controlo é executado e a ação tomada.
A consequência para a governação é prática. Dois ambientes podem mostrar exatamente a mesma regra e ainda assim tomar decisões diferentes se utilizarem modelos ou limiares distintos. Alterar o modelo avaliador deve, portanto, seguir a mesma disciplina aplicada a uma mudança de política: controlo de versões, aprovação, testes de regressão e rastreabilidade.
A UiPath avisa ainda que a disponibilização está a ser feita gradualmente e pode não abranger todos os ambientes. O estatuto de pré-visualização impede que a implementação atual seja tratada como um contrato de produção já estabilizado.
O custo depende de onde e quantas vezes a verificação é feita
As notas de versão dizem explicitamente que cada verificação LLM-as-Judge provoca uma chamada real a um modelo e acrescenta consumo. A documentação de licenciamento dos agentes programados confirma que as chamadas a modelos são contabilizadas em Agent Units ou Platform Units, consoante o plano.
Isto torna a colocação do controlo uma decisão de engenharia. Verificar apenas uma operação de maior risco depois de executada tem um perfil de custo diferente de verificar todas as interações antes e depois de cada chamada ao modelo. Várias regras em várias fases podem multiplicar o número de inferências sem qualquer alteração na lógica principal do agente.
A questão não é apenas saber se um modelo avaliador permite formular regras mais flexíveis do que um mecanismo determinístico. É necessário decidir quais as decisões que justificam uma avaliação probabilística e onde o custo e a latência adicionais são aceitáveis.
Testar o agente não é o mesmo que testar o sistema já protegido
O SDK disponibiliza a opção enabled_for_evals e apresenta-a como ativa por predefinição. Isso é útil para testar a solução tal como será usada, mas altera aquilo que a métrica representa.
Se o avaliador estiver a bloquear ou a registar comportamentos durante um teste, o resultado mede o conjunto formado pelo agente e pelo controlo. Não mede apenas o comportamento base do agente. Uma avaliação de prontidão para produção pode precisar exatamente desta visão, mas ela não substitui uma referência sem a camada de controlo.
A análise da Aipolix é que, quando a distinção for relevante, devem existir dois resultados: uma linha de base sem o avaliador e uma avaliação do sistema governado com a configuração exata que será utilizada em produção. Sem essa separação, uma melhoria aparente na segurança ou no cumprimento das regras pode ser atribuída ao agente quando foi, na realidade, introduzida pelo mecanismo de controlo.
A pré-visualização limita as conclusões sobre eficácia
A UiPath disponibilizou um mecanismo concreto e documentou a sua configuração e o respetivo consumo. As fontes, porém, não demonstram que um modelo avaliador consiga aplicar qualquer regra com fiabilidade constante em todos os domínios ou perante entradas adversariais.
Para uma equipa que queira experimentar a funcionalidade, a consequência operacional já é suficientemente clara: o avaliador deve ser tratado como um componente do caminho de controlo que precisa de versão, medição e orçamento. A identidade do modelo e a configuração devem ser guardadas juntamente com a regra, as falhas desta camada devem ser testadas separadamente das falhas do agente e as chamadas adicionais devem entrar no orçamento de inferência.