O número que está quase certo.
No trabalho regulado, a resposta perigosa não é a que está obviamente errada. É a que parece estar bem.
Durante os testes, um sistema que eu tinha construído respondeu a uma pergunta sobre uma única loja com um número correto. A aritmética estava certa. Os dados eram reais. O número era o total de toda a rede.
Cálculo certo, dados reais, âmbito errado. Nada o assinalou. Quem não souber os números de cor deixa esse passar sem dar por isso.
A falha para a qual todos se preparam é a errada
Pergunte a qualquer pessoa qual é o risco de um modelo de linguagem e ouvirá a mesma palavra: alucinação. O modelo inventa uma fonte, forja um caso, tira um número do nada. É uma falha real, e é aquela sobre a qual todos os compradores perguntam.
É também a falha fácil. Um número inventado costuma parecer inventado. Uma citação que não existe pode ser verificada. A resposta obviamente errada é apanhada, porque alguém a jusante a lê e para.
A resposta quase certa não é apanhada. Chega com exatamente a mesma confiança que tudo o resto. Fica num relatório, alguém toma uma decisão com base nela, e ninguém a questiona, porque não há nada a questionar. Parece estar bem.
Porque é que isto importa mais em auditoria do que em qualquer outro lado
Na maior parte do software, uma resposta aproximada degrada-se suavemente. Uma recomendação fica ligeiramente ao lado. Uma previsão fica com uma margem um pouco larga. O utilizador ajusta.
Num dossier de auditoria, não há degradação suave. Um número ou é o que pertence ao papel de trabalho, ou não é. Uma conclusão ou é sustentada pela prova que lhe está anexada, ou não é. Quem faz a revisão três meses depois, ou o regulador dois anos depois, não está a ler o seu raciocínio. Está a ler um número e o documento que está por trás dele.
É por isso que uma resposta quase certa custa mais do que resposta nenhuma. A ausência de resposta é uma lacuna, e uma lacuna vê-se. Uma resposta quase certa é um buraco com um chão pintado por cima.
O que mudámos por causa disso
Esse único erro ensinou-me mais do que todo o resto do projeto. Mudou a pergunta de «qual é a precisão do modelo» para «o que é que o modelo está sequer autorizado a fazer».
Daí saíram três coisas, que hoje estão em todos os sistemas que entregamos.
O modelo não calcula. São motores determinísticos que fazem a aritmética. Os números são calculados e bloqueados antes de o modelo os ver. O modelo escreve à volta de números que não pode alterar. Não tem oportunidade de estar quase certo, porque nunca é ele quem faz as contas.
Nada chega ao ecrã sem uma verificação automática. Se a verificação falhar, o utilizador recebe um resumo simples em vez de uma resposta bem acabada. Um resultado visivelmente incompleto é mais seguro do que um resultado errado apresentado com confiança.
Cada sistema é testado nos dois modos de falha. Não só «alguma vez dá uma resposta falsa», mas também «alguma vez recusa uma pergunta a que devia ter respondido». São precisos os dois. Um sistema que nunca diz que não acaba por lhe mentir. Um que diz que não demasiadas vezes é ignorado, e um controlo ignorado não protege ninguém.
A parte que não é um problema técnico
Pôr um modelo a fazer algo impressionante leva uma tarde. Construir algo que se possa deixar a sós com os dossiers de uma sociedade é um exercício diferente, e a maior parte dele não tem a ver com o modelo.
Tem a ver com decidir, antes de começar, o que a máquina não está autorizada a fazer. Essa lista é mais curta do que a lista do que pode fazer, e vale mais.