E se a IA não puder verificar aquilo que diz?

Grande parte da discussão actual sobre inteligência artificial assenta numa pergunta que raramente se formula de forma explícita: quando um modelo de linguagem nos dá uma resposta, o que nos permite acreditar que essa resposta foi calculada, verificada ou demonstrada? Costumamos tratar as chamadas «alucinações» como erros de informação: referências inventadas, factos incorrectos, números mal calculados, afirmações plausíveis que não correspondem à realidade. No artigo Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models, Varin Sikka e Vishal Sikka abordam o problema por outro lado. Em vez de perguntarem apenas o que o modelo sabe, procuram saber o que consegue efectivamente calcular.

Um LLM recebe uma sequência de tokens e produz outra, calculando a cada passo a probabilidade do token seguinte. Esse mecanismo dispõe de recursos computacionais finitos. Segundo os autores, há tarefas que exigem mais cálculo do que o modelo consegue realizar nas condições em que opera. Podemos, portanto, pedir-lhe uma solução que ultrapassa esses recursos e receber, ainda assim, uma resposta bem formada e dita com segurança. O texto sai; o cálculo necessário para o sustentar pode não ter sido feito.

Pense-se numa tarefa que exige enumerar todas as combinações possíveis de um conjunto de elementos. O número de combinações cresce exponencialmente com a dimensão do conjunto. Para conjuntos pequenos, o modelo pode produzir uma resposta correcta. À medida que o conjunto aumenta, porém, torna-se mais difícil garantir que não omitiu casos nem introduziu repetições. Os exemplos discutidos por Sikka e Sikka, incluindo a composição de tokens e a multiplicação de matrizes, servem para explorar essa diferença entre produzir uma sequência plausível e executar a computação pedida.

«Alucinação» passa, assim, a designar falhas de natureza distinta. Uma resposta pode estar errada porque o modelo recuperou mal uma informação ou estabeleceu uma associação inadequada. Pode também falhar porque a tarefa exigia uma computação que não foi realizada. A resposta até pode coincidir com a solução correcta; essa coincidência, por si só, não demonstra que o modelo tenha resolvido o problema.

A distinção torna-se mais importante quando passamos dos modelos que respondem a perguntas para agentes que executam tarefas. Um agente pode escrever e correr código, fazer reservas, tratar documentos ou interagir com outros sistemas. Se apresentar como concluída uma operação que não conseguiu verificar, o erro deixa de ficar circunscrito à resposta lida por uma pessoa: pode propagar-se às acções seguintes.

Seria tentador resolver o problema entregando a verificação a uma segunda IA. Mas verificar nem sempre significa olhar para o resultado e reconhecer que parece certo. No Traveling Salesperson Problem, por exemplo, é simples somar as distâncias de um percurso proposto; o difícil é garantir que não existe outro mais curto. Essa garantia exige uma justificação que exclua alternativas melhores, e produzi-la pode ser computacionalmente exigente. Um segundo modelo que se limite a declarar «verificado» não fornece essa justificação.

A pergunta deixa então de ser apenas «a resposta está certa?» e passa a ser «que operação, fora da fluência do texto, permite confirmá-la?». Uma resposta correcta pode ter sido obtida sem um processo que assegure a sua correcção. Por isso, em tarefas onde o erro tem consequências, importa saber se há uma forma independente de conferir o resultado, um cálculo reproduzível, uma prova ou outro mecanismo adequado ao problema.

Os modelos de reasoning complicam, mas não eliminam, esta questão. Ao gerarem mais tokens intermédios, podem decompor problemas e dedicar-lhes mais computação. Isso melhora o desempenho em muitas situações, mas não transforma automaticamente uma explicação extensa numa demonstração. Sikka e Sikka relacionam estes limites com aquilo a que chamam reasoning collapse: a degradação do desempenho quando a dimensão ou a dificuldade de certas tarefas ultrapassa determinado ponto.

A consequência prática não é deixar de usar LLM. É distinguir os papéis que lhes atribuímos. Podem ajudar a formular hipóteses, organizar informação e propor caminhos para uma solução. Quando a tarefa exige cálculo exacto, prova ou garantias formais, a confiança deve assentar também em ferramentas e procedimentos capazes de testar o resultado. Num agente que executa tarefas, a fluência já não é apenas um risco para quem lê: pode tornar-se uma acção tomada sem prova suficiente.

Varin Sikka e Vishal Sikka, «Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models».