O que conta como evidência quando a máquina é probabilística?
Probabilidade não é um veredicto
Quando uma máquina devolve 0.87, a primeira pergunta costuma ser demasiado pequena. As pessoas perguntam se 0.87 é alto. Alto em comparação com quê, para que resultado, sobre que casos e para que decisão? Um número impresso ao lado de um resultado parece uma propriedade desse resultado. Muitas vezes não é. É uma tentativa de descrever uma relação entre um modelo, uma população definida de casos e um resultado observado ao longo do tempo. Essa relação pode ser útil. Pode orientar uma fila de revisão, definir um limiar ou dizer a um operador quando um resultado merece uma segunda análise. Mas não transforma uma previsão individual num facto com um decimal anexado.
Este é o ponto incómodo no centro dos sistemas probabilísticos. Os seus resultados são muitas vezes mais informativos do que uma etiqueta simples, porque podem expressar graus de apoio ou de incerteza. Também são mais fáceis de sobreinterpretar. Uma pontuação pode ser tratada como uma declaração de testemunha, uma conclusão jurídica, um diagnóstico ou uma autorização. Não é nenhuma dessas coisas por defeito. A evidência começa quando a organização consegue dizer o que o número representa, como foi verificado, onde essa verificação se aplica e que ação o número pode alterar.
Essa distinção é importante muito antes de um sistema encontrar um regulador. Uma equipa pode estar a decidir se um documento sugerido precisa de verificação humana. Um comprador pode estar a comparar dois fornecedores que anunciam medidas de confiança. Um operador pode estar a definir uma regra de escalada. Um organismo público pode estar a perguntar se uma lista ordenada é suficientemente boa para influenciar para onde vai a atenção primeiro. Em todos os casos, uma execução bem-sucedida é evidência de uma coisa: que essa execução produziu um resultado. Ainda não é evidência de que o sistema merece a autoridade que lhe é atribuída.
A resposta sensata não é proibir probabilidades em trabalho de consequências. É dar-lhes uma descrição de funções adequada. Uma probabilidade pode apoiar uma decisão quando está ligada a um evento definido, a uma população relevante, a um método de observação, a um limite de incerteza e a uma regra para o que acontece quando a evidência é fraca. Isto é mais lento do que admirar um único número e muito mais rápido do que descobrir mais tarde que ninguém consegue explicar o que o número devia fazer.
A evidência tem de nomear a sua pergunta
As provas nunca estão simplesmente presentes. São provas a favor de uma proposição. Um resultado de teste pode apoiar a proposição de que um componente produz um determinado resultado para uma determinada entrada sob uma determinada configuração. Pode apoiar a proposição de que um modelo classifica bem os exemplos num conjunto de dados reservado. Pode apoiar a proposição de que uma estimativa de probabilidade corresponde razoavelmente de perto às frequências observadas num conjunto de avaliação definido. Essas proposições são diferentes. A disciplina começa por escrever a proposição antes de escolher a métrica.
Considere a afirmação aparentemente simples de que um sistema é exato. Exato em quê? Uma exatidão de classificação pode descrever com que frequência a classe com a pontuação mais alta correspondeu a um rótulo. Não diz se a probabilidade declarada estava bem calibrada. Uma métrica de classificação pode descrever a ordem, não a qualidade da escala de pontuação. Um erro médio baixo pode coexistir com um padrão de erro prejudicial num subgrupo ou num limiar que desencadeia uma ação. A métrica não está errada. O salto da métrica para a conclusão operacional é onde o problema geralmente começa.
O trabalho da OCDE sobre instrumentos de avaliação é útil precisamente porque abandona a fantasia de que uma única pontuação pode carregar toda a explicação. O seu quadro distingue facetas, incluindo cobertura, finalidade, realismo, fiabilidade, reprodutibilidade, objetividade e parcialidade. Não são ornamentos burocráticos em torno de um padrão de referência. Descrevem se o resultado tem a relação correta com a pergunta que está a ser feita. Uma comparação de investigação, uma avaliação de conformidade e uma decisão operacional de lançamento podem todas usar testes. Não pedem a mesma coisa a esses testes.
Comece, então, com uma frase com a qual se possa discordar. Por exemplo: este sistema pode encaminhar casos para revisão humana quando a sua estimativa de probabilidade documentada para um resultado definido excede um limiar especificado, desde que a entrada corresponda ao âmbito validado e o revisor mantenha a autoridade para rejeitar a sugestão. Essa é uma proposição operacional discutível. Nomeia a ação, a condição e o limite. Não finge que uma pontuação escolheu independentemente o seu papel no mundo.
A frase contrária é familiar porque é conveniente: o modelo está 87 por cento confiante. Mesmo quando um modelo emite verdadeiramente uma probabilidade, a frase omite o evento, a evidência de calibração, a população, o período e a decisão. Converte uma relação num traço de personalidade. As máquinas não precisam de ser descritas como tímidas ou certas. Precisam de ser descritas como sistemas cujos resultados têm significados definidos e limites definidos.
Confiança não é o mesmo que correção
Um sistema pode estar confiante e errado. Também pode estar correto enquanto expressa baixa confiança. Esses dois factos não surpreendem uma vez que os termos sejam mantidos separados. A correção pergunta se um resultado correspondeu à referência escolhida para um caso. A confiança é uma declaração anexada a um resultado, muitas vezes derivada de uma pontuação do modelo ou de uma transformação dela. A calibração faz uma pergunta adicional em muitos casos: quando o sistema atribui probabilidades semelhantes, os resultados ocorrem aproximadamente à taxa declarada? São perguntas relacionadas, mas uma boa resposta não fornece as outras.
Imagine um conjunto de casos para os quais um classificador reporta uma probabilidade de 0,80 para um evento definido. Se, ao longo de um conjunto adequadamente descrito e suficientemente grande de casos comparáveis, o evento ocorrer cerca de oito vezes em dez, a estimativa pode ser considerada bem calibrada para essa população e condição. Isso não significa que o próximo caso de 0,80 tenha um destino de oitenta por cento. Significa que a pontuação mostrou uma relação com os resultados observados ao longo da coleção declarada. A expressão ao longo da coleção declarada faz a maior parte do trabalho intelectual.
A calibração também não é um crachá universal. Uma pontuação pode estar bem calibrada num conjunto de dados histórico e mal calibrada depois de mudarem a fonte de entrada, a população de utilizadores, o fluxo de trabalho, o processo de rotulagem ou as condições de implantação. Pode estar bem calibrada no geral e comportar-se de forma diferente numa parte da população que interessa ao serviço. Pode parecer boa num agrupamento amplo e, ao mesmo tempo, ocultar uma diferença acentuada perto do limiar de decisão. Um gráfico de calibração não é um diploma emoldurado por cima do sistema de produção. É uma observação datada com um âmbito.
A literatura sobre calibração de modelos torna a separação concreta. Guo e colegas estudaram a calibração da confiança em redes neuronais modernas e mostraram que a exatidão, por si só, não resolve se as estimativas de confiança representam probabilidades de correção observadas. O trabalho deles também avalia métodos de calibração por pós-processamento. A lição operacional importante é mais restrita do que uma receita: não se deve presumir que uma pontuação de modelo tem um significado probabilístico adequado apenas porque é fornecida num intervalo conveniente entre zero e um.
Uma organização cuidadosa regista, por isso, três coisas diferentes. Regista o desempenho na tarefa, para poder perguntar se os resultados cumprem a tarefa definida. Regista a calibração ou outra propriedade explícita de incerteza, para poder perguntar o que a pontuação significa na prática. E regista a consequência de agir num determinado limiar, para poder perguntar se a regra de decisão é adequada. Combinar as três num único indicador verde pode simplificar um painel de controlo. Não simplifica o mundo.
A calibração tem um denominador
Toda a afirmação sobre calibração tem um denominador. O denominador não é apenas o número de registos num ficheiro. É o conjunto de casos elegíveis para serem contados, a forma como foram agrupados, a definição do resultado, o período de tempo, as exclusões e o processo que produziu os rótulos de referência. Retire essas condições e um diagrama de fiabilidade torna-se numa curva agradável sem jurisdição sobre uma decisão.
Suponha que uma avaliação agrupa previsões por confiança declarada. A taxa observada em cada grupo depende dos casos admitidos no grupo e da definição do resultado. Foram excluídos os casos ambíguos? As abstenções foram tratadas como erros, recusas seguras ou outra coisa? O rótulo representava um evento imediato, uma revisão posterior ou um recurso final? Foram mantidos os duplicados? A avaliação incluiu apenas registos que passaram por uma etapa de validação a montante? Cada resposta pode ser razoável. Cada resposta altera o significado da afirmação de calibração resultante.
É por isso que um modelo pode ter um resultado de calibração global respeitável e, ainda assim, ser inadequado para uma utilização específica. O resultado global pode agrupar idiomas, comprimentos de entrada, regiões, tipos de dispositivo, percursos do cliente ou modos de funcionamento que não partilham a mesma estrutura de erros. Um valor agregado pode ser um resumo honesto e, mesmo assim, ser prova insuficiente para uma decisão local. A resposta certa não é exigir um modelo separado para cada pessoa. É testar os pressupostos de agrupamento que a própria decisão torna relevantes.
O quadro de avaliação da OCDE chama a isto cobertura. O quadro pergunta se um instrumento de avaliação cobre uma distribuição enviesada ou representativa daquilo que se propõe medir e distingue o desempenho na tarefa de uma afirmação mais ampla de capacidade. Essas distinções são úteis para a evidência probabilística. Uma pontuação pode ser evidência sobre o desempenho numa distribuição de tarefas. Não deve tornar-se silenciosamente em evidência sobre uma capacidade, uma população afetada ou um contexto futuro que a avaliação não cobriu.
O denominador também tem um lado social. Quando uma organização decide quais os casos suficientemente simples para automatizar e quais têm de esperar por uma pessoa, as definições determinam quem fica com a incerteza restante. Uma pontuação agregada pode ocultar o facto de um grupo mais pequeno ter menos exemplos, rótulos menos estáveis ou um contexto operacional diferente. Isso não é motivo para prometer estatísticas iguais onde a evidência é escassa. É motivo para comunicar a evidência escassa com clareza e para criar uma regra de decisão cautelosa em torno dela.
Uma execução bem-sucedida é um espécime, não uma conclusão
Os sistemas probabilísticos convidam a uma forma particular de excesso de confiança porque são tão fáceis de demonstrar. Introduza uma entrada, receba um resultado impressionante, repita com uma entrada próxima, receba outro. A demonstração pode mostrar que o sistema consegue realizar a tarefa. Pode até mostrar algo que vale a pena investigar. Não pode mostrar a distribuição dos resultados, a estabilidade da pontuação, a resposta a casos-limite, a qualidade dos rótulos de referência ou o efeito de uma condição de implementação alterada. Um espécime pode iniciar uma investigação. Não pode concluí-la.
O mesmo se aplica a uma única execução de referência. Um resultado pode ter sido recolhido corretamente, num sistema bem descrito, com uma métrica legítima. Se foi executado uma vez, é evidência do valor observado uma vez nessas condições. Não é automaticamente evidência de uma propriedade estável do sistema. A repetição ajuda a expor a variação. Não elimina a necessidade de perguntar se o teste representa a utilização pretendida. A reprodutibilidade e a validade resolvem problemas diferentes, e ambas merecem um lugar no registo.
O quadro da OCDE torna essa separação explícita. A fiabilidade diz respeito a saber se uma avaliação apresenta repetições, duração de episódios ou instâncias suficientes para dar baixa variação quando aplicada novamente. A reprodutibilidade diz respeito a saber se o mesmo teste pode ser gerado novamente, incluindo se os componentes estocásticos alteram as interações. Um teste pode ser exatamente reprodutível e ainda assim responder a uma pergunta pouco útil. Pode ser realista e difícil de reproduzir exatamente porque o ambiente mudou. Nenhuma das condições é um defeito por si só. O registo deve indicar qual das condições se verifica e o que permite ao leitor inferir.
Há aqui um hábito operacional modesto mas valioso: guarde a execução bem-sucedida, mas não a faça carregar mais do que pode. Preserve a entrada, a configuração, a versão, a semente quando aplicável, as dependências, o resultado e a decisão de avaliação. Depois, coloque-a ao lado de medições repetidas, contracxemplos, abstenções e condições alteradas. Um resultado que permanece útil depois de ter enfrentado os seus vizinhos incómodos é mais valioso do que um resultado que teve de ser protegido deles.
Para sistemas generativos, uma resposta bem-sucedida é evidência particularmente fraca de repetibilidade, a menos que o contrato de interação seja registado. As definições de amostragem, os prompts, o material recuperado, a disponibilidade de ferramentas, a versão do modelo, a política de segurança e o fluxo de trabalho envolvente podem todos moldar o resultado. Reproduzir uma sequência de palavras sem o estado relevante pode reproduzir a aparência de um teste, mas perder a condição que o tornou significativo. No trabalho de evidência, semelhança não é reprodução.
Repetibilidade não é sinónimo de confiança
Uma reprodução determinística pode ser excelente evidência para uma proposição restrita: dados os mesmos dados de entrada, configuração e condições de implementação registados, o sistema produziu o mesmo resultado. Isso torna as investigações, os testes de regressão e as comparações de versões mais fáceis de gerir. Não estabelece que o resultado estava correto, que a entrada era adequada, que o sistema deveria ter sido usado para a decisão, ou que o resultado se generalizará para além do seu limite registado. A repetibilidade é uma propriedade da experiência. A confiança é um juízo sobre um arranjo mais amplo.
O comportamento estocástico altera o registo em vez de desculpar a sua ausência. Se um resultado variar, a avaliação deve registar quais partes variam, com que frequência, dentro de que intervalo e de que forma essa variação afeta a decisão. Um sistema que propõe formulações alternativas pode tolerar um intervalo mais amplo do que um sistema que classifica casos para atenção. Um sistema que aconselha um ser humano pode exigir provas diferentes daquelas exigidas a um sistema que disponibiliza uma ação irreversível. A probabilidade não é, por si só, uma categoria operacional. É a consequência que determina quanta incerteza um processo pode suportar com segurança.
Há um erro fácil de cometer em ambos os lados. Uma equipa exige um resultado fixo de uma ferramenta cujo propósito declarado inclui a exploração e, depois, confunde o determinismo resultante com qualidade. Outra equipa aceita resultados variáveis de um sistema de apoio à decisão e, quando a variabilidade se torna difícil de avaliar, chama-lhe criatividade. Nenhuma das posições é séria. A questão é se a variação é esperada, limitada, observável e compatível com a autoridade atribuída ao sistema.
A regulamentação europeia não reduz esta questão a uma pontuação universal. Para os sistemas de IA de alto risco, o artigo 15.º do Regulamento IA exige um nível adequado de exatidão, robustez e cibersegurança, bem como um desempenho coerente nesses aspetos ao longo de todo o ciclo de vida. O mesmo artigo determina ainda que os níveis de exatidão e as métricas de exatidão relevantes sejam indicados nas instruções de utilização e incentiva a utilização de parâmetros de referência e métodos de medição para os aspetos técnicos da avaliação do desempenho. A disposição não afirma que um único teste repetido resolve a questão. Exige que o desempenho seja especificado e mantido em contexto.
Esta é a postura sensata para qualquer avaliação séria. Um teste repetível é uma peça da cadeia de provas. Precisa de um responsável, de um limite de versão, de um gatilho de alteração e de uma ligação à decisão operacional que suporta. Sem estes elementos, a reprodutibilidade pode tornar-se outra palavra atraente que viaja mais longe do que a experiência.
A incerteza precisa de um percurso operacional
O propósito prático da incerteza não é fazer com que um painel de controlo pareça sofisticado. É alterar o que o sistema está autorizado a fazer. Se uma pontuação não tiver qualquer efeito no encaminhamento, na revisão, na explicação, na monitorização ou na interrupção, pode ser uma curiosidade técnica em vez de um sinal operacional. Se alterar uma ação, a organização precisa de declarar o percurso da pontuação até à autoridade.
Um limiar é um desses percursos, mas não é uma linha mágica. Definir um limiar implica selecionar um compromisso entre tipos de erro, carga de trabalho, atraso e dano potencial. Um limiar pode ser adequado para priorizar uma fila de revisão de baixa consequência e inadequado para negar a uma pessoa o acesso a um serviço. O mesmo limiar numérico pode significar coisas diferentes quando a taxa de base, o custo do erro, a reparação disponível e a qualidade da revisão a jusante mudam. Não existe um número prudente universal à espera num manual de um fornecedor.
Por esse motivo, uma regra de decisão deve descrever mais do que um ponto de corte. Deve identificar o resultado que está a ser estimado, as provas que suportam a pontuação, os casos fora do âmbito, as circunstâncias que obrigam à abstenção, a autoridade humana que permanece, o registo que será mantido e as condições para rever a regra. Um limiar sem estes acompanhamentos é uma decisão disfarçada de configuração.
Uma hipótese útil ilustra o ponto sem inventar um incidente público. Considere um serviço que utiliza uma pontuação de modelo para ordenar os pedidos recebidos para um revisor especializado. As provas podem suportar uma afirmação limitada: a pontuação pode ajudar a ordenar pedidos comparáveis dentro de uma categoria de admissão declarada, enquanto toda a priorização final permanece com o revisor. As mesmas provas não suportam a rejeição automática de pedidos com pontuação baixa, porque essa é uma ação diferente, com consequências diferentes e necessidades de prova diferentes. O resultado não mudou. A sua autoridade mudou.
Abster-se merece a mesma seriedade. Um sistema que consegue dizer que as suas provas são insuficientes pode criar mais trabalho a curto prazo e reduzir erros não observados a longo prazo. Mas a abstenção só é útil quando tem um destino responsável. Se os casos incertos desaparecem numa fila sem dono, o sistema limitou-se a converter incerteza em atraso. Um bom percurso identifica quem recebe o caso, o que pode ver, como o corrige e como essa correção informa avaliações posteriores.
Afirmações causais exigem mais do que um gráfico de antes e depois
As estimativas de probabilidade são frequentemente usadas para apoiar afirmações sobre o que acontecerá se uma organização agir. Essa é uma tarefa probatória diferente de prever o que aconteceu em dados históricos. Um modelo pode estimar que um caso se assemelha a outros casos com um determinado resultado. Isso não demonstra que alterar o caso, mudar uma política ou seguir uma recomendação fará com que o resultado mude. A previsão e a intervenção não devem ser fundidas apenas porque o gráfico parece arrumado.
As figuras de antes e depois são particularmente tentadoras. Uma equipa introduz uma ferramenta, um resultado muda e a ferramenta recebe o crédito ou a culpa. Muitas outras coisas podem ter mudado: a população que entra no serviço, a documentação, o pessoal, as políticas, as condições sazonais, os filtros a montante ou a própria medição. A observação pode merecer atenção. Não é uma conclusão causal até que a comparação, as explicações alternativas e a incerteza remanescente tenham sido abordadas.
Isto é importante para a governação da IA porque um sistema pode ser operacionalmente influente muito antes de ser formalmente decisivo. Uma classificação pode alterar qual registo uma pessoa abre primeiro. Um indicador de confiança pode levar um revisor a aceitar um resultado. Uma ação recomendada pode tornar-se rotina porque a fila está ocupada. O percurso causal inclui interpretação humana, design da interface, incentivos, pressão de tempo e o percurso de correção disponível. Avaliar apenas o modelo não conta toda a história.
Quando uma afirmação causal é importante, o plano de evidências deve indicar que comparação tornaria a afirmação mais credível e o que ainda não conseguiria excluir. Isso pode envolver um teste controlado, uma implementação faseada, uma revisão independente, um desenho observacional cuidadosamente construído ou a decisão de renunciar totalmente a uma afirmação causal. A questão não é exigir perfeição académica em cada mudança operacional. É fazer corresponder a confiança da afirmação às provas efetivamente disponíveis.
Há um certo senso comum holandês nisto, embora se generalize bem: se apenas mediu que o vento mudou, não anuncie que redesenhou o clima. Uma previsão pode ser valiosa sem se tornar uma história sobre causalidade. A honestidade não é uma retirada. É o que torna o resultado utilizável por alguém que tem de decidir o que fazer a seguir.
A exatidão pode ocultar uma má regra de decisão
A exatidão é frequentemente útil e frequentemente insuficiente. Um sistema pode alcançar uma exatidão elevada quando um resultado é comum, oferecendo pouca ajuda nos casos que mais importam. Pode ter uma média forte e um desempenho fraco perto do limiar de ação. Pode fazer previsões corretas sem oferecer estimativas de probabilidade que apoiem limiares sensatos. Pode parecer bem-sucedido porque o rótulo de referência é fácil de prever, mesmo que o próprio rótulo seja um proxy fraco para a decisão que o serviço precisa de tomar.
Nada disto significa que a exatidão não tenha valor. Significa que o leitor deve perguntar o que ela mede e o que fica de fora do enquadramento. O Regulamento IA reconhece esta necessidade de contexto nos requisitos para as instruções de utilização: a documentação dos sistemas de alto risco deve incluir as características e limitações de desempenho, a finalidade prevista, as métricas de exatidão relevantes utilizadas para testar e validar o sistema e as circunstâncias conhecidas ou razoavelmente previsíveis que possam afetar o desempenho esperado. Um valor de exatidão torna-se mais útil quando as condições que o rodeiam permanecem associadas.
Uma boa revisão operacional pergunta, por isso, pelos padrões de erro, e não apenas pelos totais. Que tipos de casos foram classificados incorretamente? Quais ficaram por decidir? Que casos foram excluídos ou enviados para revisão? O que acontece a um falso positivo, a um falso negativo, a uma resposta atrasada ou a uma abstenção injustificada? Quem consegue detetar o resultado, contestá-lo e corrigir o registo? Estas perguntas devolvem a avaliação ao serviço, em vez de a deixarem com o modelo.
Pode também ser útil distinguir a evidência de um componente da evidência de um fluxo de trabalho. Um teste de componente pode estabelecer propriedades de um modelo sob entradas definidas. Uma avaliação de fluxo de trabalho pode estabelecer como o modelo, a interface, os dados, as pessoas e a política interagem. Um componente pode ter uma forte calibração de pontuação enquanto o fluxo de trabalho produz enviesamento de automação porque a interface esconde a incerteza. Um fluxo de trabalho pode ter um excelente processo de revisão enquanto depende de um componente cujos dados de origem já não correspondem ao âmbito declarado. Os testes têm de se encontrar em algum ponto.
A evidência resultante não é necessariamente um relatório grandioso. Pode ser um registo conciso e com versões se a decisão for restrita. O que importa é que outra pessoa consiga inspecionar a proposição, a população, o método, o resultado, o limite e a decisão. O tamanho do ficheiro não determina a qualidade do raciocínio. Um registo curto pode ser rigoroso. Uma apresentação extensa pode ser, na sua maioria, ar.
A mudança transforma a evidência de ontem numa pergunta
Todos os resultados de avaliação têm uma data, mesmo quando a data está oculta. Os modelos mudam. As instruções mudam. As fontes de dados mudam. Um formulário a montante ganha um campo. Um fornecedor altera uma política. Uma equipa move um serviço para outro ambiente. Um novo grupo começa a utilizar o sistema. Uma métrica é calculada após um processo de revisão alterado. Cada mudança pode alterar a proposição que a evidência anterior sustentava.
A resposta certa não é voltar a executar todos os testes após cada alteração. É definir quais as mudanças que são relevantes para quais afirmações. Uma alteração de cor pode não afetar a calibração de probabilidade. Um novo canal de entrada pode afetar. Uma política de rótulos revista pode alterar a definição de resultado. Uma nova versão do modelo pode mudar tanto o desempenho como a interpretação das suas pontuações. Uma alteração na autoridade atribuída ao sistema pode invalidar uma regra de decisão mesmo que o modelo permaneça exatamente igual, byte a byte. O plano de testes deve tornar estas relações visíveis antes de um lançamento ser conveniente.
O artigo 9.º do Regulamento IA descreve um processo contínuo e iterativo de gestão do risco para sistemas de alto risco ao longo do seu ciclo de vida. O processo inclui identificar e analisar os riscos conhecidos e razoavelmente previsíveis, estimar e avaliar os riscos quando o sistema é utilizado para o fim a que se destina e em condições de utilização incorreta razoavelmente previsível, e adotar medidas de gestão do risco. O ponto para a avaliação é direto: a evidência não é uma cerimónia única no lançamento. Pertence a um sistema operativo de revisão, mudança e resposta.
Monitorizar não significa recolher todos os sinais disponíveis e esperar que um padrão se revele por si só. Significa decidir qual observação reabriria um pedido. Uma verificação de calibração pode ser agendada por período, volume ou alteração na combinação de entradas. Um limiar pode ser revisto quando a pressão na fila altera a qualidade da supervisão humana. Uma alteração na fonte pode suspender uma utilização até que o teste relevante seja repetido. Um plano de monitorização sério indica o que é observado, por quem, em relação a que referência, e que ação se segue.
Isto é mais exigente do que uma ficha de modelo arquivada no dia da aquisição, mas também é mais útil. Um documento estático pode preservar o que foi afirmado. Um registo de evidência vivo pode mostrar se a afirmação ainda tem lugar. Para um sistema probabilístico, essa diferença é a diferença entre saber que a pontuação existiu e saber se ela ainda significa o que o serviço pensa que significa.
Os registos permitem que um leitor posterior discorde de forma fundamentada
A evidência precisa de memória. Um revisor posterior não pode avaliar uma afirmação a partir de um ecrã de uma pontuação e de uma recordação da reunião. Precisa do objeto com versão: a pergunta, as condições de entrada, o método de teste ou observação, o resultado, as exclusões, a incerteza, a decisão e o responsável. Pode também precisar de saber o que não foi capturado. Um registo que torna visíveis os seus pontos cegos é mais útil do que um registo de aparência perfeita que deixa o estado do sistema à adivinhação.
Para os sistemas de IA de alto risco, o Regulamento IA exige o registo automático de eventos ao longo do ciclo de vida do sistema, com capacidades de registo adequadas à finalidade pretendida e úteis para identificar riscos, apoiar a monitorização pós-comercialização e monitorizar o funcionamento. Exige também que a documentação técnica seja elaborada antes de o sistema ser colocado no mercado e mantida atualizada. Estes requisitos não são apenas um convite para manter mais registos. São um convite para tornar os registos inteligíveis em relação a um sistema, uma finalidade e uma decisão.
A rastreabilidade é especialmente importante quando a probabilidade é interpretada por uma pessoa. Se um revisor vê uma pontuação, o registo de evidência deve permitir reconstruir a que a pontuação estava associada, como foi apresentada, que dados ou fontes estavam no âmbito, o que o revisor decidiu e se ocorreu uma correção posterior. Sem essa cadeia, uma equipa pode descobrir que um resultado estava errado, mas não se o problema estava na entrada, no modelo, na interface, na regra de decisão ou no processo humano em torno dele.
Na Dweve, o AION é um exemplo pequeno e relevante do princípio mais amplo, não uma afirmação de que a evidência pode ser reduzida a criptografia. A sua descrição pública diz que um produtor pode emitir um certificado tipado juntamente com um resultado e que o AION verifica o certificado de forma independente em relação às premissas originais. Esse tipo de registo verificável pode reforçar uma proposição restrita sobre se um resultado decorre de premissas registadas. Não prova que as premissas eram adequadas, que a tarefa era justa ou que a utilização era apropriada. A evidência precisa tanto de verificação como de juízo.
Essa limitação vale a pena manter porque evita um erro categórico comum. Um rasto perfeitamente preservado pode mostrar o que aconteceu. Não pode tornar boa uma pergunta mal formulada. Uma decisão reproduzível pode continuar a ser uma decisão que nunca deveria ter sido automatizada. O registo deve ajudar um leitor posterior a fazer ambas as perguntas, não responder prematuramente à segunda.
A confiança pode ser honesta sem ser útil
Uma probabilidade bem calibrada pode continuar a ser pouco útil. Pode ser demasiado ampla para separar os casos que precisam de tratamentos diferentes. Pode chegar tarde demais para afetar a decisão. Pode estar ligada a um resultado que não é acionável. Pode ser tão incerta que todos os casos exigem a mesma revisão. Não são falhas de honestidade. São limites de utilidade, e devem ser admitidos cedo em vez de serem descobertos depois de um fluxo de trabalho ter sido construído em torno da pontuação.
Inversamente, um sistema útil não precisa de fingir que tem certeza. Um sinal modesto pode melhorar a forma como o trabalho é organizado se tiver um propósito estreito e um percurso de revisão claro. Pode ajudar um operador a ver quais os casos que merecem uma nova verificação da fonte. Pode selecionar um pequeno conjunto para garantia de qualidade. Pode revelar um conflito entre registos. Nesses usos, o requisito de evidência diz respeito a saber se o sinal melhora o processo de decisão específico sem introduzir erros novos ou dependências inaceitáveis. O sinal não precisa de se tornar um oráculo para merecer um lugar.
É por isso que o propósito pretendido deve controlar a avaliação. Os Princípios de IA da OCDE exigem informação significativa sobre as capacidades e limitações dos sistemas, e rastreabilidade em relação a conjuntos de dados, processos e decisões, para que os resultados possam ser analisados e as perguntas respondidas. Os princípios exigem também agência humana e supervisão adequadas. A implicação prática não é que todas as interfaces precisem de mostrar uma probabilidade. É que a evidência e a explicação de um sistema devem adequar-se à pessoa e à decisão afetadas por ele.
Não há prémio por expor um valor de incerteza que o utilizador não consegue interpretar ou usar. Um número sem um percurso de decisão pode criar o teatro da transparência. Dá às pessoas algo para apontar e nenhuma forma de o contestar. É melhor mostrar o limite relevante em linguagem simples, como esta sugestão está fora da categoria validada, ou este resultado exige revisão porque a evidência disponível está incompleta. A apresentação adequada segue o controlo operacional, e não o contrário.
Pela mesma razão, uma pontuação de confiança não deve ser tratada como uma medida de valor moral, credibilidade ou direito. É uma declaração técnica com um contrato de evidência limitado. Pode ajudar um processo. Não deve tornar-se numa classificação social vaga porque a sua forma numérica a faz parecer decisiva.
A organização é dona da inferência
Os fornecedores podem disponibilizar modelos, documentação, pontuações e resultados de testes. Não podem deter silenciosamente o significado de uma decisão tomada ao serviço de outra pessoa. A organização que liga um resultado probabilístico a uma ação tem de decidir em que proposição se baseia, qual a população relevante, qual o limiar aceitável, quem analisa as exceções, que registos são conservados e quando expira a validade das provas. Os contratos podem atribuir tarefas. Não eliminam a necessidade de juízo.
Isto torna-se visível nos processos de aquisição. Um comprador deve pedir a um potencial fornecedor não apenas uma métrica de destaque, mas também a pergunta de avaliação, a população, os rótulos, as exclusões, as versões, a variação, o método de calibração se for feita uma alegação de probabilidade, os limites conhecidos e a política de alterações. A questão não é exigir divulgações que o fornecedor não possa legalmente prestar. É estabelecer se o comprador consegue compreender o limite da alegação suficientemente bem para a utilizar com responsabilidade num contexto operacional europeu.
A resposta pode, por vezes, ser que as provas não são adequadas para o uso pretendido. Isso não é um processo de aquisição falhado. É o processo de aquisição a cumprir a sua função real antes de a organização se tornar dependente de uma pontuação inexplicada. Um uso mais reduzido e inspecionável pode ainda ser possível. Um fornecedor diferente pode ser adequado. Ou a decisão pode permanecer humana, porque as provas e a via de correção não são suficientemente sólidas para justificar a automatização. Dizer não faz parte da disciplina das provas.
As provas também precisam de um responsável nomeado após o lançamento. Alguém tem de ser responsável por verificar se a população mudou, se as análises revelam um novo padrão de erros, se um limiar ainda se adequa à carga de trabalho, se os registos podem ser interpretados e se uma alteração desencadeia uma reavaliação. O responsável não tem de executar pessoalmente todos os testes. Mas se nenhuma função for dona da inferência, o sistema irá gradualmente adquirir autoridade por hábito. O hábito é um mau substituto para um registo de decisões.
A parte mais difícil é muitas vezes cultural. As equipas estão habituadas a apresentar modelos bem-sucedidos como produtos e modelos mal-sucedidos como investigação. As provas probabilísticas pedem-lhes que preservem a ambiguidade intermédia: úteis, limitadas, monitorizadas e ainda não autorizadas a tornarem-se mais do que as provas sustentam. Isso pode parecer menos entusiasmante. É mais duradouro.
O que contém um registo de provas proporcionado
O registo adequado depende do uso. Um auxiliar de redação utilizado por um autor tem consequências diferentes de um sistema que influencia o acesso a um serviço público. Ainda assim, um registo proporcionado tem uma forma reconhecível. Identifica a alegação e o propósito pretendido. Identifica o modelo, a configuração e o fluxo de trabalho envolvente. Define o resultado e a população utilizados para avaliar a alegação. Preserva o método, o resultado e os limites significativos. Identifica a regra de decisão, o responsável, a via de análise e os gatilhos de alteração. Cada campo dá a um leitor posterior um ponto por onde começar.
O registo deve distinguir medição de interpretação. Uma observação medida pode dizer que, num conjunto de dados e período especificados, um conjunto declarado de pontuações correspondeu a resultados observados dentro de um intervalo descrito. Uma interpretação pode dizer que isto apoia o uso como sinal de ordenação de análises sob controlos especificados. Uma decisão pode dizer que o sistema pode ser utilizado para esse fim até ocorrer um gatilho de alteração declarado. Colocar as três frases sob um título chamado desempenho só é eficiente se ninguém precisar alguma vez de contestar o raciocínio.
Deve também tornar utilizáveis as incógnitas. Talvez os rótulos cheguem atrasados. Talvez um pequeno grupo linguístico não tenha casos suficientes para uma avaliação de calibração estável. Talvez a implementação seja recente e ainda não exista evidência operacional. O registo pode dizê-lo, colocar um limite temporário à utilização, organizar mais observação ou manter uma via humana. Fingir que a incógnita foi resolvida porque um modelo produziu um número apenas converte incerteza num passivo não documentado.
A disciplina visual é útil aqui. Desenhe a cadeia desde a entrada até à pontuação, da pontuação à explicação apresentada, da explicação à ação humana, e da ação ao resultado observado e à correção. Desenhe onde o estado é capturado, onde se perde e onde uma pessoa pode parar ou inverter o percurso. Se a equipa não consegue desenhar o percurso, é pouco provável que consiga avaliá-lo. Os diagramas não substituem a evidência. Evitam que a evidência seja atribuída à parte errada do sistema.
Acima de tudo, escreva o que o registo não estabelece. Pode não estabelecer causalidade. Pode não estabelecer equidade em todos os grupos. Pode não estabelecer o comportamento após uma alteração de fornecedor. Pode não estabelecer adequação para uma ação de maior consequência. Estas não-afirmações não são um pedido de desculpas. São o que impede uma avaliação limitada de ser usada como autorização universal.
A evidência conquista o direito de permanecer incerto
Há a tentação de pensar que o objetivo da avaliação é eliminar a incerteza. Muitas vezes, o melhor objetivo é localizá-la. Um sistema probabilístico não é defeituoso por não conseguir transformar todos os casos numa certeza. Torna-se perigoso quando a organização trata a incerteza como um detalhe técnico privado enquanto concede autoridade pública ao resultado. O trabalho é decidir qual incerteza é tolerável, visível e recuperável para o objetivo em causa.
Essa decisão deve tornar-se mais exigente à medida que a consequência aumenta. Uma sugestão de baixa consequência pode precisar de um âmbito claro, uma limitação visível e uma correção fácil. Um sistema que influencia direitos, segurança, acesso ou oportunidade material precisa de evidência mais forte sobre o processo completo, monitorização mais cuidadosa, autoridade humana significativa e uma via para contestar e remediar. A pontuação do modelo não determina esse padrão sozinha. O efeito de agir sobre ela determina.
Uma única execução bem-sucedida pode ainda assim valer a pena ser mantida. Pode ser o primeiro espécime num registo útil. Pode revelar uma capacidade, um modo de falha ou uma questão que merece uma avaliação adequada. Mas deve permanecer um espécime até a organização testar a proposição em que quer confiar. A distância entre essas duas coisas é onde vive a engenharia responsável.
Portanto, a resposta ao que conta como evidência quando a máquina é probabilística não é uma pontuação, um gráfico ou um rótulo de conformidade. É um argumento limitado: este resultado, para esta questão, nesta população e período, sob estas condições, foi observado desta forma; isto é o que podemos inferir; isto é o que não podemos inferir; e esta é a ação que estamos, ou não, preparados para deixar que ele mude. Esse argumento não é glamoroso. É inspecionável, o que é melhor.