Crenças que são verdadeiras em software convencional, mas falsas em inteligência artificial

• Muitas pessoas entendem mal a diferença entre software convencional e inteligência artificial
• O público em geral tende a confundir os riscos da IA com o conceito de “bug” do software tradicional, o que gera uma confiança equivocada sobre como resolver esses problemas
• Os erros da IA vêm dos dados de treinamento, não do código e, devido à sua enorme escala, os humanos não conseguem identificar quais dados causaram o problema
• Ao contrário do software convencional, não é possível encontrar e “corrigir” ou “reproduzir” bugs da mesma forma, e o comportamento da IA é não determinístico, mudando até com pequenas variações na entrada
• O desenvolvimento baseado em especificações é quase impossível, e as capacidades ou os riscos da IA não podem ser previstos antecipadamente; às vezes, funcionalidades ocultas e não intencionais só são descobertas depois
• Por isso, a forma tradicional de pensar em TI de que “se surgir um problema, basta corrigir” funciona como um equívoco fatal nas discussões sobre segurança em IA

---

Os limites do conhecimento sobre software convencional

• Muitas pessoas do público e gestores têm a convicção de que, quando se trata dos riscos de software, “código com problema (bug) pode ser corrigido”
• Durante muito tempo, a indústria de software conseguiu fixar com sucesso a ideia de que bugs de código podem causar danos no mundo real
• No software comum, bugs existem, mas mesmo em sistemas complexos, trata-se de um domínio em que correções são possíveis
• Porém, essa abordagem e essa forma de pensar não se aplicam à IA, o que gera confusão e mal-entendidos

Diferença de percepção entre especialistas e não especialistas

• Software convencional e software de IA são essencialmente diferentes na forma como funcionam e na forma como os problemas surgem
• O grupo de especialistas considera essa diferença tão óbvia que muitas vezes deixa de explicá-la, enquanto iniciantes não conseguem percebê-la por conta própria
• Ambos os lados acabam enfrentando dificuldades para se comunicar entre si

Crenças do software convencional aplicadas de forma errada à IA

• 1. Vulnerabilidades de software surgem de erros no código

  • Bugs em software convencional normalmente vêm de erros na escrita do código
  • Mas, no caso da IA, vulnerabilidades ou imprevisibilidade vêm quase sempre dos dados de treinamento
  • Por exemplo, em conjuntos de dados como o FineWeb, com dezenas de bilhões de palavras, é impossível que pessoas examinem tudo
  • Devido à imensidão dos dados com que a IA aprende, é difícil entender completamente o que ela aprendeu, e quase impossível identificar fatores de risco

• 2. É possível encontrar bugs analisando o código

  • No software tradicional, é possível analisar o código e rastrear logicamente a causa de um bug
  • Problemas em IA surgem do efeito combinado dos dados de treinamento, o que torna, na prática, impossível encontrar a causa no conjunto de dados
  • Pesquisadores normalmente tentam enfraquecer o problema com novo treinamento ou adicionando dados, mas é difícil descobrir diretamente a causa por rastreamento lógico
  • A causa de um bug em IA é algo que nem os próprios desenvolvedores conhecem com precisão

• 3. Depois de corrigido, o bug não volta a aparecer

  • Em software, quando um bug descoberto é corrigido, ele não se reproduz novamente exatamente da mesma forma
  • Mas, na IA, mesmo depois de “corrigir” um “bug”, o mesmo comportamento problemático pode reaparecer em entradas não testadas
  • Não é possível ter certeza de que um comportamento anômalo da IA foi totalmente eliminado

• 4. A mesma entrada sempre gera o mesmo resultado

  • Software comum sempre retorna a mesma saída para a mesma entrada
  • Tecnicamente, a IA também pode funcionar assim, mas mudanças mínimas na entrada (como pontuação) podem alterar completamente o resultado
  • Na prática, várias grandes empresas de IA projetam seus sistemas para produzir saídas levemente diferentes mesmo com o mesmo prompt, para parecerem menos mecânicos

• 5. Se houver requisitos claros, é possível atendê-los

  • No software convencional, se você define especificações e requisitos claros, existe um meio de satisfazê-los
  • Mas, na IA, não é possível controlar ou garantir com clareza o comportamento geral desejado pelo projetista
  • Dentro de um escopo limitado (por exemplo: falar em inglês, escrever código etc.), algum controle explícito é possível, mas não há como garantir todos os comportamentos (por exemplo: não incentivar crimes)
  • Depois do lançamento de um serviço de IA, capacidades ocultas ou riscos que nem os desenvolvedores conheciam podem ser descobertos por acaso
  • Garantia e previsão completas da segurança em IA são impossíveis

Caminhos para seguir em frente

• O conhecimento de software generalizado de forma incorreta distorce a confiança e a avaliação de riscos sobre a IA
• É importante compartilhar amplamente com colegas como a IA funciona, quais são seus limites e em que ela difere do software convencional
• É preciso explicar as diferenças estruturais próprias da IA, pouco conhecidas, e transmitir que uma abordagem simples de “patch de bug” não funciona

A lacuna de entendimento entre especialistas e iniciantes

• Se, por meio deste texto, você descobriu pela primeira vez a diferença fundamental entre IA e software convencional, vale a pena compartilhar esse conteúdo com conhecidos
• Se você já conhecia essa diferença, pode ser uma boa ideia conversar sobre isso com pessoas comuns ou não especialistas
• De fato, não são tantas as pessoas que sabem que os dois são essencialmente diferentes

[GN⁺]

Opinião no Hacker News

• Se quiser entender quais são, na prática, as dificuldades de usar LLMs de verdade, vale olhar para o caso da Apple. Há um ano, a Apple fez um grande anúncio do Apple Intelligence e enfatizou fluxos de trabalho de agentes baseados em LLM, mas desde então só adicionou algumas ferramentas menores, como criação de emoji, resumo de notificações e revisão de texto. Até o recurso de resumo de notificações ficou por um tempo “fora de controle” e teve de ser retirado matéria relacionada. No evento do iPhone deste ano, a empresa também reduziu bastante o marketing em torno de IA. Parece que a liderança da Apple subestimou o quão difícil seria implementar LLMs com o nível de acabamento e controle esperado de algo “com cara de Apple”

  • Fico pensando se a Apple não usou IA para desenhar o Liquid Glass. À primeira vista parecia incrível, mas na prática foi uma experiência impossível de usar
  • Os recursos de resumo de notificações e e-mails foram realmente inúteis. Acabei sentindo que passar os olhos diretamente pelas partes importantes era até mais simples
  • Agora a Apple está levando adiante uma estratégia focada em integração com Apple Events usando MCP link relacionado
  • E não foi só a Apple que subestimou essas dificuldades dos LLMs; isso vale para o setor inteiro. Com líderes como Amodei prometendo cognição em nível humano a cada lançamento, a expectativa dos executivos em relação à IA ficou inflada demais. Mas, na prática, fora assistência para programação e chatbots, ainda é difícil apontar exemplos em que a IA tenha realmente transformado ecossistemas altamente refinados como smartphones ou sistemas operacionais
  • Ironicamente, o que eu realmente quero da Siri é só a capacidade de conversar de forma natural no nível do ChatGPT. Consigo manter quase 90% das conversas com GPT, mas a Siri 1) simplesmente não responde, 2) entende errado, ou 3) entende e mesmo assim se recusa a continuar a conversa. Essa experiência é realmente decepcionante

• A frase abaixo me representou muito:

  while it’s possible to demonstrate the safety of an AI for a specific test suite or a known threat, it’s impossible for AI creators to definitively say their AI will never act maliciously or dangerously for any prompt it could be given

  Quando se aplica uma abordagem como MCP, essa possibilidade de risco cresce exponencialmente link do MCP

• Acho que está faltando a premissa mais importante. Nem sempre isso vale para software em geral, mas em IA isso é ainda mais crucial: “a mesma entrada deve produzir a mesma saída”. Isso é indispensável para confiabilidade em processos automatizados

• Costuma-se dizer que bugs de IA são problema de dados, mas isso não é totalmente verdade. Mesmo que a arquitetura do LLM em si ou os dados de treinamento não pareçam ter problema, LLMs são fundamentalmente não determinísticos, então, pelo próprio desenho do algoritmo, a mesma pergunta nem sempre recebe a mesma resposta. Dependendo do cenário, o resultado muda a cada vez como se fosse um lançamento de dados

  • Isso nem sempre é um problema. Tanto em programação quanto em matemática pode haver várias respostas corretas. O problema é que LLMs não têm um processo que garanta a resposta certa e produzem, com base em heurísticas, respostas que apenas “parecem corretas”. Por isso, em partes que exigem raciocínio lógico, LLMs acabam gerando muitos bugs e erros de software

• Sinceramente, me parece mais correto dizer que “com o tempo, todos os bugs vão sendo corrigidos e a confiabilidade da IA vai aumentar”. A tecnologia em si é completamente nova, e a ideia comum no HN de que “não determinístico = lixo” é exagerada, considerando que, nos últimos dois anos, a confiabilidade dos LLMs aumentou algo como 10 vezes

  • O desempenho claramente melhorou, mas acho que a curva de crescimento daqui para frente será logarítmica. Vai melhorar rápido nos próximos anos, desacelerar aos poucos e, em algum momento, chegar ao limite do atual ML baseado em pattern matching. E acho que esse limite não será alto o bastante para substituir completamente programadores em empresas de software
  • O fenômeno de “desalinhamento de intenção” da IA e a busca por poder não são bugs que se resolvem apenas com PR ou testes unitários
  • Ironicamente, pessoas tecnicamente brilhantes no Hacker News continuam repetindo o otimismo de que “no fim das contas, vão corrigir todos os bugs”. Essa postura aparece por toda a comunidade
  • Se eu pensar se as pessoas ficaram muito mais confiáveis do que antes, a resposta me parece ser não. Claro, LLM não é gente, mas uma AGI pode se comportar como gente

• Sobre a ideia de que “todo comportamento errado de um sistema de IA vem dos dados de treinamento”, é preciso ter mais cautela. Mesmo com dados e processo de treinamento perfeitos, a estrutura do modelo ainda pode fazer com que ele continue errando

• Seria bom explicar com mais clareza em que situações um “bug de IA” aparece. Concordo com a defesa de que não se deve colocar um LLM para tomar decisões em tempo real e sem supervisão. Por exemplo, acho cedo demais para uma IA controlar os semáforos de uma cidade. Mas, do ponto de vista de um profissional técnico, a discussão sobre bugs de IA hoje aparece muito mais em “agentes de programação”, e nesse tipo de área quase sempre existe supervisão, então essa preocupação não se aplica de forma tão direta

• É importante fazer as pessoas entenderem que “às vezes a IA funciona surpreendentemente bem, às vezes decepciona, e sem teste você nunca vai saber”. Só que é impossível testar todos os casos. Quando os clientes entendem isso, passam a exigir escopo de teste ou controle, e os fornecedores vão se concentrar em ambientes verificáveis (por exemplo, escrever código) ou em áreas em que precisão não importa tanto (texto, geração de memes). Se você apoia IA, entender isso profundamente é uma vantagem enorme. Por outro lado, as pessoas não se importam com bugs, especificações ou com o colapso do modelo tradicional de programação em si, mas se a IA passar a influenciar eleições ou provocar demissões em massa, haverá uma onda enorme de hostilidade e exigência por regulação. Quando isso acontecer, o setor vai tentar se proteger com os mecanismos de imunidade e evasão regulatória que desenvolveu até aqui (isenção de responsabilidade, exclusão por cláusulas, arbitragem compulsória etc.), e no fim acho que o crescimento da indústria e até os investimentos de toda uma geração podem ficar em risco por causa da reação a um pequeno número de grandes acidentes fortuitos

• O ponto realmente perigoso em IA é o “poder concentrado”. Isso é mais realista do que a preocupação de uma IA com emoções humanas passar a nos tratar como baterias da Matrix

  • Na prática, já existe um clima em que CEOs e executivos nos tratam como baterias da Matrix
  • Na minha opinião, o mais assustador é a poluição informacional. Dados inúteis gerados por IA diluem tanto a informação original que fica difícil até encontrar fontes que ainda prestem
  • Para que algo maligno aconteça, “concentração de poder” é condição necessária. Ou seja, é a mesma lógica de dizer que “Linda é bancária” é sempre mais provável do que “Linda é bancária e ativista feminista”. P(a) > P(a&b), essa é a essência
  • Mesmo que a IA não tenha emoções como “não gostar”, se ela concluir que humanos atrapalham seus objetivos, isso por si só já pode ser perigoso. Superinteligência pode se tornar perigosa mesmo sem emoções
  • O maior problema já é a realidade atual, em que o poder está gigantescamente concentrado de um lado só, e a IA é quase só o enfeite final. O problema de verdade não é a IA

• Ultimamente tenho tentado alertar as pessoas de que “ninguém sabe exatamente como a IA funciona”. Quero enfatizar que construir algo e entender seu princípio não são a mesma coisa. Com humanos é igual

  • O ser humano vive trabalhando e cooperando com gente que também não entende totalmente
  • Na verdade, há especialistas que entendem muito bem redes neurais, transformers, atenção, embeddings e a estrutura dos tokenizers. O que eles não conseguem explicar com clareza é só o peso das conexões entre os neurônios
  • Não entendo essa ideia de que ninguém sabe como a IA funciona. Não temos controle e observação completos do hardware, do software e do estado de execução que usamos? Podemos parar a qualquer momento, inspecionar o estado, acompanhar o fluxo passo a passo. Conhecemos o código-fonte, o compilador e tudo mais. Então o que exatamente é que não sabemos?
  • Ninguém conhece todas as camadas e toda a extensão do cérebro humano. Ainda assim, líderes de toda organização confiam no “cérebro” de seus subordinados para trabalhar