O que é validação de modelos?

Em vez de apenas perguntar "O modelo produz uma resposta?", a validação de modelos pergunta se o design, as premissas, os dados, a implementação, as saídas, as limitações e o comportamento do modelo ao longo do tempo são confiáveis o bastante para as decisões que as pessoas vão tomar com base nele.

Esse processo permite que as empresas reduzam o risco de modelo (o risco de um modelo produzir resultados imprecisos, enviesados, instáveis, inseguros ou mal utilizados) ao avaliar, de forma proativa, até que ponto o modelo cumpre suas funções.

Em uma validação simples, os desenvolvedores de modelos podem se limitar a avaliar, durante o desenvolvimento, o modelo candidato em um conjunto de validação (o conjunto de exemplos que engenheiros de ML e cientistas de dados usam para verificar se um modelo está aprendendo bem).

No âmbito do gerenciamento de riscos de modelos, porém, a validação é muito mais abrangente. Em geral, a validação de modelos nas empresas é uma avaliação independente de todo o ciclo de vida do modelo. O modelo de ML é revisado por pessoas que não o criaram, e a revisão abrange o modo como ele foi construído, colocado em produção, usado, monitorado, alterado e, por fim, desativado.

Um processo de validação bem-sucedido confirma cinco pontos.

1. O modelo de ML tem uma finalidade clara, além de população, escopo e contexto de decisão definidos.
2. A abordagem conceitual do modelo (o método que mapeia entradas saídas, a lógica e as premissas subjacentes) faz sentido para essa finalidade.
3. Os dados que o modelo usa e sua implementação são precisos e controlados.
4. O modelo tem desempenho adequado em dados relevantes, inclusive em dados que não viu durante o desenvolvimento.
5. A organização compreende as limitações do modelo e toma providências se o desempenho piorar.

O rigor do processo de validação costuma ser proporcional à finalidade do modelo. Uma ferramenta interna de previsão de baixo impacto não precisa ser examinada com tanta profundidade quanto um modelo que aprova financiamentos imobiliários ou detecta transações bancárias fraudulentas.

Vale destacar que a validação de modelos não é uma aprovação concedida uma única vez. Mesmo que tenham bom desempenho no início, os modelos podem sofrer desvio e se degradar depois de entrarem em produção; por isso, a validação contínua de modelos de ML costuma estar incorporada às práticas de governança de inteligência artificial (IA) das empresas.

De acordo com o NIST AI Risk Management Framework, os pilares da confiança em modelos incluem validade e confiabilidade; segurança; proteção e resiliência; responsabilização e transparência; explicabilidade e interpretabilidade; aprimoramento da privacidade; e equidade e gestão de vieses.

A validação de modelos de aprendizado de máquina ajuda a estabelecer e manter a confiança no modelo (o grau em que se pode esperar, com fundamento, que um modelo se comporte de forma adequada). As empresas tomam decisões com base nas saídas dos modelos de ML, por isso a confiança no modelo não é apenas uma questão de reputação. Ela é a base do uso seguro, eficaz e escalável da IA. Na verdade, os objetivos de confiança no modelo costumam orientar as práticas de validação de modelos.

Além disso, um modelo não pode ser considerado confiável só porque seu desenvolvedor o chama de "IA responsável". Os modelos precisam ser capazes de executar suas tarefas com consistência, proteger pessoas e dados, resistir ao uso indevido e ser compreendidos e governados. Esse nível de confiança precisa ser conquistado por meio de controles demonstráveis e da coleta contínua de evidências durante a validação de modelos de IA.

Uma forma amplamente adotada de entender os pilares da confiança em modelos é o AI Risk Management Framework do Instituto Nacional de Padrões e Tecnologia dos EUA (NIST). Ele identifica sete características interdependentes da IA confiável.

Um modelo confiável precisa ser válido para a sua tarefa e manter a confiabilidade ao longo do tempo, em todas as condições previstas. A validade verifica se o modelo realmente mede, prevê, classifica ou gera aquilo a que se propõe.

A confiabilidade verifica se o modelo tem desempenho consistente e estável diante de entradas comparáveis, inclusive as que vêm de diferentes usuários, ambientes, fontes de dados e períodos.

O pilar da segurança trata da possibilidade de o modelo causar danos a pessoas, bens, organizações ou à sociedade, mesmo quando, do ponto de vista técnico, ele funciona conforme projetado.

Um modelo pode ser preciso e, ao mesmo tempo, inseguro. Por exemplo, um chatbot de atendimento ao cliente pode recuperar corretamente as informações da conta, mas, se puder ser manipulado para expor dados sensíveis, ainda assim não é seguro implementá-lo. A segurança exige que as equipes identifiquem os danos previsíveis antes da implementação e os tratem de forma proativa no design do sistema.

A proteção resguarda o modelo, seus dados, suas interfaces e a aplicação em que ele está inserido contra acesso ou manipulação maliciosos. Nos sistemas de IA modernos, a superfície de ataque vai muito além dos pesos do modelo. Ela abrange também os dados de treinamento, as fontes de recuperação, os prompts, as interfaces de programação de aplicações (APIs), os plug-ins, as identidades de usuário, a infraestrutura de implementação, os logs e as cadeias de suprimentos de modelos. Os controles de proteção precisam ser capazes de gerenciar toda a superfície de ataque.

A resiliência diz respeito à capacidade do modelo de continuar funcionando com segurança, recuperar-se adequadamente ou falhar de forma controlada se algo der errado. Isso significa validar se os modelos conseguem lidar tanto com interrupções não maliciosas quanto com ciberataques. Em um contexto de alto impacto, falhar com segurança costuma ser mais importante do que simplesmente continuar disponível.

A responsabilização significa que pessoas designadas respondem pela concepção, pela implementação, pelos resultados e pela correção do modelo. Sem responsabilização, uma empresa pode alegar que "a IA decidiu" quando algo dá errado.

A transparência significa que todas as informações relevantes sobre o sistema, suas saídas, suas limitações e sua governança estão disponíveis para as pessoas que precisam delas. A transparência não exige que as empresas revelem código-fonte proprietário nem detalhes sensíveis de proteção. Trata-se de divulgar informações precisas e úteis em quantidade suficiente para que os stakeholders compreendam o sistema como um todo.

A explicabilidade e a interpretabilidade ajudam as pessoas a entender como um modelo funciona e o que suas saídas significam no contexto de uma decisão real. Em termos simples, a explicabilidade pergunta: "Que fatores ou processos levaram a esta saída?" e a interpretabilidade pergunta: "O que esta saída significa e como uma pessoa deve usá-la?"

Esse pilar é mais importante quando as decisões têm grande impacto, são contestadas, regulamentadas ou difíceis de reverter (por exemplo, na modelagem de risco de crédito).

Privacidade e proteção estão intimamente ligadas, mas são conceitos distintos. A proteção impede que terceiros não autorizados acessem os dados, enquanto a privacidade ajuda a garantir que eles sejam coletados, usados, armazenados e compartilhados de forma adequada.

Os modelos podem gerar riscos para a privacidade mesmo quando não foram projetados explicitamente para processar dados pessoais. Os conjuntos de treinamento dos modelos podem conter informações sensíveis, e os logs, reter dados de usuários que deveriam ficar armazenados apenas temporariamente. As práticas de validação de modelos ajudam as empresas a garantir que as ferramentas de IA estejam protegidas e, ao mesmo tempo, em conformidade com as regras de privacidade.

A equidade exige que uma organização identifique, meça, reduza e monitore vieses prejudiciais. Isso não significa que todas as pessoas devam sempre receber a mesma saída. O que se exige é que as diferenças de tratamento ou de resultado sejam justificadas, lícitas e pertinentes à tarefa, e que não decorram de vieses evitáveis ou prejudiciais.

A validação de modelos costuma combinar várias verificações e técnicas.

A solidez conceitual avalia a lógica e a concepção subjacentes ao modelo. Ela analisa se a metodologia, as entradas, as premissas, os julgamentos qualitativos e as escolhas de design são adequados às decisões que o modelo deve embasar.As verificações de solidez incluem:

• Avaliação da metodologia do modelo para entender como ele transforma dados em saídas.

• Exame das funcionalidades e das entradas para confirmar que cada funcionalidade importante é relevante, disponível e lícita.

• Questionamento das premissas para fins de documentação e monitoramento.

• Identificação de limitações e fatores ausentes para descobrir o que o modelo não sabe e entender os contextos em que ele se torna menos confiável.

• Análise da interpretabilidade e da adequação do uso para determinar por que um modelo produz suas saídas e onde ele pode falhar.

A validação de dados ajuda as equipes a determinar se os dados usados para criar, ajustar, testar e executar um modelo são confiáveis.Essa validação inclui:

• Avaliação da qualidade dos dados. As verificações de qualidade dos dados buscam garantir que os registros de dados sejam precisos, completos, relevantes, representativos, corretamente rotulados, obtidos de forma lícita, protegidos e separados.

• Estabelecimento da procedência e da linhagem. As revisões de validação devem permitir rastrear cada conjunto de dados e cada atributo até uma fonte identificável.

• Confirmação da relevância para a tarefa. Confirmar a relevância significa verificar se cada elemento de dados usado reflete informações de fato relacionadas à finalidade do modelo.

• Verificação dos rótulos e da verdade fundamental. A validação de rótulos garante que eles representem o resultado-alvo de forma precisa e adequada, com uma definição consistente. Ela também identifica o padrão de referência: a melhor base disponível para determinar o que é verdade.

A análise de resultados tem duas finalidades principais. Em primeiro lugar, ela determina se as saídas do modelo correspondem às condições reais que ele se propõe a prever. Em segundo lugar, ela questiona se o uso dessas saídas de fato ajuda a empresa a atingir o objetivo pretendido sem gerar danos, custos ou riscos inaceitáveis.Na análise de resultados, as equipes podem precisar:

• Comparar previsões com resultados. A análise de resultados aguarda, coleta ou estabelece a "verdade fundamental" do modelo e a compara com as saídas que ele gera.

• Usar backtesting. O backtesting aplica um modelo a casos passados usando apenas as informações que estariam disponíveis naquele momento histórico e, depois, compara as previsões do modelo com o que de fato aconteceu.

• Examinar o recall e os erros de previsão. Modelos problemáticos podem gerar falsos positivos e falsos negativos. As análises de resultados medem os dois tipos de erro, avaliam suas consequências e determinam se eles ultrapassam o limite de risco da organização.

• Verificar a calibração. A calibração avalia se as probabilidades que um modelo informa correspondem às frequências observadas. Se um modelo atribuir 70% de probabilidade de fraude a 1.000 transações, cerca de 700 delas devem, no fim, se confirmar como fraude. Se só 250 se confirmarem, ou se forem 850, o modelo estima o risco de forma incorreta.

• Avaliar o impacto nos negócios e nas operações. A análise de resultados examina se o modelo contribui para o objetivo real que motivou sua implementação.

Validar a robustez e a sensibilidade de um modelo ajuda a garantir que ele continue se comportando de forma confiável quando as condições forem imperfeitas, anormais ou deliberadamente hostis.

A sensibilidade, por si só, não é ruim. Algumas entradas devem mesmo ter forte influência sobre a saída de um modelo. Uma mudança recente em uma conta privilegiada, por exemplo, altera, com razão, a pontuação de risco de cibersegurança da conta. O problema é a sensibilidade injustificada, em que mudanças pequenas, irrelevantes ou rotineiras têm um efeito desproporcional sobre o comportamento do modelo.

As equipes podem pôr o modelo à prova com:

• Entradas ruidosas e incompletas. As verificações de robustez simulam condições como dados ausentes e entradas incorretas para ver como a má qualidade dos dados afeta o desempenho e as respostas do modelo. Isso ajuda a evitar o underfitting (quando o modelo não aprende o suficiente com os dados de treinamento e, por isso, não consegue reconhecer padrões) e o overfitting (quando o modelo memoriza demais os dados de treinamento, inclusive o ruído).

• Alterações nas condições. Os modelos de aprendizado de máquina precisam saber lidar com mudanças de distribuição (novas políticas, interrupções do serviço, desvio de conceito), situações em que os dados de produção já não se parecem com os dados de desenvolvimento. Os revisores podem usar períodos posteriores, novos ambientes e casos fora da distribuição criados deliberadamente para verificar se o desempenho do modelo cai abaixo dos níveis aceitáveis.

• Casos extremos e incerteza. Os casos extremos costumam expor as premissas ocultas de um modelo. Ao verificar como o modelo responde a esses cenários, as equipes conseguem ver se ele reconhece a incerteza e recorre a um mecanismo de contingência adequado.

• Entradas adversariais. A validação de entradas adversariais avalia se alguém consegue manipular intencionalmente o modelo para que ele gere uma saída incorreta, insegura, não autorizada ou enganosa.

• Desvio do modelo. As equipes podem usar a simulação de desvio para criar deliberadamente cenários em que os dados de produção, o comportamento dos usuários ou a relação entre entradas e resultados mudaram e, em seguida, verificar se o modelo se degrada de forma controlada e se os controles reagem como deveriam.

O benchmarking e os testes de desafio avaliam se um modelo traz ganho real, comparando-o com alternativas críveis. As organizações adotam essas práticas para saber se o desempenho de um modelo é significativamente superior ao de um método mais simples, de um modelo anterior, de um processo executado por pessoas ou de um modelo desafiante desenvolvido de forma independente (um modelo criado ou selecionado especificamente para validar o comportamento do modelo candidato).

• Os benchmarks (como modelos de produção anteriores ou desafiantes) são pontos de referência usados para aferir modelos de ML. O modelo principal não precisa superar todas as alternativas em todas as métricas de desempenho. As equipes só precisam entender os prós e contras envolvidos para poder justificar os modelos que escolhem.

• Os testes de desafio são uma prática mais ampla, que consiste em tentar demonstrar que um modelo não é adequado ao uso pretendido. Além de avaliar as situações em que se espera que o modelo funcione bem, os testes de desafio examinam os cenários de falha mais prováveis.

As verificações de segurança, proteção e privacidade avaliam os diversos riscos que um modelo pode gerar, mas muitas fragilidades estão nas integrações em torno de um modelo de ML, e não no modelo em si.

Um modelo pode ter, por exemplo, uma política interna rigorosa contra a divulgação de informações confidenciais, mas, ainda assim, uma aplicação pode expor documentos privados se o sistema de recuperação que ela usa não respeitar as permissões dos documentos. Da mesma forma, um modelo pode ser resistente a um jailbreak básico, mas um agente criado a partir dele ainda pode executar uma ação insegura porque uma página da web recuperada continha uma injeção de prompt indireta.

Por isso, uma validação eficaz exige que as equipes avaliem o modelo e todo o ecossistema ao seu redor.

A documentação e a reprodutibilidade transformam a validação em um conjunto de evidências auditável, em vez de uma afirmação informal de que um modelo "funciona".

A documentação acompanha todo o ciclo de vida de um modelo de ML, desde a justificativa inicial de negócio, passando pelo desenvolvimento, pela validação, pela implementação, pelo monitoramento e pelas alterações relevantes, até chegar, por fim, à desativação. Ela envolve registrar a linhagem do modelo e manter um controle de versão claro, o que permite aos revisores entender como o modelo muda ao longo do tempo.

A reprodutibilidade ajuda a garantir que um revisor independente e qualificado possa usar os materiais documentados para repetir o processo de desenvolvimento ou de validação do modelo e obter aproximadamente os mesmos resultados.

A validação, o teste e o monitoramento de modelos são práticas correlatas de garantia de qualidade, mas respondem a perguntas diferentes em momentos distintos do ciclo de vida de um modelo de aprendizado de máquina:

• A validação pergunta: "O modelo é adequado, confiável e projetado de forma apropriada para o uso pretendido?"

• O teste pergunta: "O modelo finalizado atende aos critérios de aceitação técnicos, de negócios, de segurança e operacionais definidos previamente?"

• O monitoramento pergunta: "O modelo implementado continua tendo bom desempenho com dados reais, em condições reais?"

O teste de modelos ocorre ao longo de todo o processo de desenvolvimento, mas a avaliação formal no conjunto de teste costuma acontecer depois que as equipes já fecharam as principais decisões de design e de ajuste. Em geral, quem conduz o teste é alguém que não participou das decisões de desenvolvimento do modelo. No caso das técnicas de train_test_split, o teste também recorre a um conjunto de dados de teste separado, que não foi usado no treinamento, no ajuste de hiperparâmetros, na escolha do limiar nem na seleção de modelos, para obter uma estimativa confiável e sem viés do desempenho do modelo finalizado em dados de fato inéditos.

As empresas podem escolher entre diversas abordagens de avaliação de modelos.

Os conjuntos de holdout, por exemplo, mantêm uma parte dos dados fora do treinamento e do desenvolvimento do modelo e depois usam esses dados reservados para avaliar como o modelo final se sai em casos que ele nunca viu. As equipes podem usar a validação cruzada k-fold, em que o modelo é treinado e testado k vezes, em partes diferentes dos dados, e depois se calcula a média dos resultados. Ou, para uma forma mais rigorosa de validação cruzada k-fold, uma equipe pode recorrer à validação cruzada leave-one-out (LOOCV), em que o modelo é testado em cada um dos pontos de dados simultaneamente. Seja qual for o método, o teste de modelos procura prever a qualidade de um modelo de ML no mundo real antes da implementação.

Enquanto o teste se concentra em avaliar a qualidade, o monitoramento de modelos busca garantir que um modelo treinado e o ecossistema ao seu redor se comportem como esperado após a implementação. O monitoramento, que pode ser realizado de forma contínua ou em intervalos predeterminados, observa as entradas, as saídas e o comportamento operacional de um modelo em produção para que as equipes de gerenciamento de riscos possam detectar mudanças antes que elas se tornem regressões propriamente ditas ou, pior, falhas.

O monitoramento oferece às empresas um sistema de alerta precoce para comportamentos problemáticos do modelo, mas não substitui a validação. A validação de modelos é um processo iterativo de avaliação que normalmente ocorre enquanto as equipes de desenvolvimento constroem o modelo, mas também pode ser conduzida como um processo independente, antes da aprovação e, periodicamente, depois dela.

Embora a validação, o teste e o monitoramento sejam processos distintos, as empresas geralmente precisam dos três para otimizar o desempenho e a confiabilidade dos modelos de ML ao longo de toda a sua vida útil.

A IA generativa (IA gen) e os agentes de IA exigem as mesmas práticas fundamentais de validação que os demais sistemas de ML. No entanto, essas ferramentas podem trazer riscos que a validação de modelos preditivos não consegue cobrir por completo. Os sistemas de IA generativa produzem saídas abertas, e os agentes podem usá-las para planejar e executar ações em sistemas interconectados.

No ML convencional, a saída de um modelo muitas vezes pode ser avaliada por comparação direta com um rótulo de verdade fundamental. Se um modelo de detecção de fraudes prevê "fraude" em uma transação e uma investigação posterior confirma a fraude, a previsão estava correta. Se um modelo de previsão de demanda estima 1.150 unidades e a demanda real é de 1.600, as equipes podem usar o erro quadrático médio (métrica de regressão que avalia o quanto as previsões do modelo se aproximam dos valores reais) para medir a discrepância com precisão.

Em geral, as saídas da IA generativa não admitem uma só redação correta e podem não ter uma "resposta certa" única e completa. Algumas tarefas delimitadas (extração estruturada, seleção de ferramentas) ainda podem ser avaliadas por comparação com saídas esperadas explícitas. Mas, de modo geral, o comportamento de um modelo depende muito do contexto em tempo de execução, que pode mudar de uma interação para outra. A IA generativa também pode alucinar, apresentando com convicção informações falsas ou incorretas em resposta a um prompt.

Por isso, a validação da IA generativa exige que as equipes usem um conjunto de avaliação que contenha prompts realistas, material de origem aprovado, elementos da resposta esperada e rubricas de pontuação. As rubricas permitem que o modelo gere várias respostas aceitáveis e, ao mesmo tempo, exigem que cada resposta contenha determinados fatos, evite afirmações sem fundamento e declare a incerteza quando houver.

Os agentes de IA podem elaborar planos, conceder acesso, modificar registros, enviar mensagens e iniciar fluxos de trabalho totalmente inéditos (com novos agentes). Assim, os agentes de IA precisam de todas as verificações de saída que se aplicam à IA generativa, mas também obrigam os desenvolvedores a validar as decisões e ações decorrentes dessas saídas. Qualquer alteração relevante (por exemplo, uma mudança no modelo de base do agente ou a conexão a um novo repositório de recuperação) deve acionar uma revalidação.