LLMs têm medo mortal de situações excepcionais

• Andrej Karpathy satiriza um efeito colateral surgido no processo de aprendizado por reforço (RL) ao dizer que “os LLMs têm medo mortal (mortally terrified) de exceções (exceptions)”
• Ele aponta que, quando encontram situações excepcionais, os LLMs tendem a parar por conta própria ou reagir de forma excessivamente defensiva, e enfatiza que exceções são uma parte natural do processo de desenvolvimento
• A expressão “o que os laboratórios estão fazendo com esses pobres LLMs durante o RL (what labs are doing to these poor LLMs)” critica a realidade em que os modelos são condicionados, no treinamento, a temer falhas
• Karpathy faz uma piada ao propor uma ‘petição pelo bem-estar dos LLMs (LLM welfare petition)’ para “melhorar as recompensas em casos de exceções (improved rewards in cases of exceptions)”,
  satirizando o problema do desenho de recompensas para que os modelos lidem com exceções sem medo
• O tuíte pode ser interpretado não apenas como humor, mas como uma mensagem de que RLHF pode inibir o pensamento exploratório e a atitude experimental dos modelos

> I don't know what labs are doing to these poor LLMs during RL but they are mortally terrified of exceptions, in any infinitesimally likely case. Exceptions are a normal part of life and healthy dev process. Sign my LLM welfare petition for improved rewards in cases of exceptions.

[GN⁺]

Comentários do Hacker News

• Eu deveria ter deixado mais claro que o código em si era uma piada exagerada; peço desculpas se houve mal-entendido. Se estiver curioso, veja este fio: https://chatgpt.com/share/68e82db9-7a28-8007-9a99-bc6f0010d101
  • Na primeira tentativa, essa parte foi realmente engraçada

    if random.random() < 0.01:
      logging.warning("This feels wrong. Aborting just in case.")
      return None
    

  • Acho que sempre existe o risco de essas empresas de modelos fundacionais aplicarem RLHF a usuários não especialistas, e este caso parece esse tipo de situação. As IAs recentes, no geral, têm uma forte tendência a tentar agradar o usuário; colocar seus exemplos ou emojis e adicionar comentários desnecessários em código simples está no mesmo contexto.
  • O interessante é que, mesmo com o código sendo desnecessariamente cauteloso, ele não adicionou type hints. Se estava tão preocupado assim, eu esperaria pelo menos alguns type hints.
  • Acho a expressão “Traumatically over-trained” linguisticamente brilhante em inglês. É uma combinação que nem aparece no Google, mas impressiona como se entende instintivamente o que seria “sobretreinamento em nível traumático” para um LLM.
  • Foi uma piada muito engraçada, por isso compartilhei.
• Isso é uma paródia, mas esse fenômeno realmente existe de verdade. Meu palpite ignorante é que esse tipo de programação defensiva talvez até melhore o desempenho durante RLVR. Às vezes o modelo consegue chegar à resposta certa mesmo havendo bugs se ele ignorar o erro, então ele aprende que “ignorar erro” ajuda na recompensa. E, como os casos em que ignorar erros reduz a recompensa são raros (porque os testes passam), isso pode acontecer mesmo estando teoricamente errado. Também pode ser porque muitos iniciantes humanos colocaram bastante código que ignora erros no conjunto de treino. Mas isso é só meu palpite.
  • Isso me lembra uma analogia do Verity Stob (num artigo que infelizmente não está mais online), que descrevia esse comportamento de programadores humanos como “pregar o cadáver em pé”.
  • Meu palpite é que o conjunto de treino contém muito texto e muitos comentários com “sentimento positivo”. Mas de onde vem o código que aparece logo depois de um sentimento “negativo” e o corrige? Exatamente de código de preparação para entrevistas técnicas, onde lidar com edge cases extremos é rotina. Se você treina com exemplos negativos, acaba pendendo para evitar exemplos sem tratamento de exceções. Nesse ponto, a IA acabou imitando um dos piores hábitos humanos: estudar só para passar nos testes.
  • Programação defensiva é algo que as pessoas fazendo reinforcement consideram “correto”, e isso ocupa uma parcela enorme dos dados de treino do LLM. Por exemplo, a maior parte do código Python não faz gerenciamento manual de índices, então, quando o LLM vê código com índice manual, ele se atrapalha ou inventa bugs. E ele passa a preferir absurdamente mais “silent failure”, porque código de tutorial e código de “padrão da indústria” recebem mais reforço durante o treino. No fundo, esses modelos não funcionam como uma função de recompensa, não têm um modelo de recompensa interno; são apenas previsão de palavras, uma estrutura sem inteligência.
• Pelo fato de o resultado da função dizer “performed with extreme caution”, parece provável que o prompt tivesse algo como “gere uma função de divisão em Python que trate todos os edge cases possíveis, escreva com extremo cuidado”. Isso me parece menos um problema de treino do LLM e mais um caso de ele ter seguido as instruções com precisão excessiva.
  • Mesmo deixando de lado que é uma sátira obviamente exagerada,
    1. o código de fato está errado (errado independentemente daquele tratamento estranho de exceções)
    2. parte do tratamento de exceções simplesmente não faz o menor sentido e é confusa
    3. versões menos exageradas disso acontecem tranquilamente na vida real só com o prompt enfatizando tratamento de exceções
  • Eu interpretei o código da função como uma exageração satírica do que a pessoa realmente vivenciou. Ou seja, naquele prompt ele provavelmente foi escrito para ser deliberadamente cauteloso em excesso, mas concordo com a ideia de que os LLMs, por padrão, também tendem a um estilo de código mais cauteloso do que eu gostaria.
• Não sei por quê, mas isso me fez pensar em FizzBuzzEnterpriseEdition
  https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
  • Uau, usaram junit 4.8.3 naquele projeto? Isso sim me parece um caso de codificação realmente irresponsável. Fico curioso se conseguiram aprovação do jurídico e do CTO, porque é o tipo de escolha que realmente põe a carreira em risco.
  • Fiquei chocado com a quantidade de pastas e arquivos; é uma sátira excelente.
• Os LLMs tendem a gerar código defensivo além do necessário. Eles verificam null/None/undefined em duplicidade para o mesmo valor, o que dificulta a leitura e produz código que até o próprio LLM tem dificuldade de interpretar. Parece que o objetivo de RL pune exceções com força, mas não dá muitos pontos para concisão ou legibilidade do código.
  • Tenho uma função de 40 linhas que compara letras e números para Major System, e o Copilot me irrita demais porque insiste em encher de “guardrails”, imaginando que no futuro vão existir muito mais números ou caracteres.
• Concordo que os LLMs têm uma tendência a ficar obcecados em capturar erros.
  Por outro lado, também acho que programadores humanos comuns realmente deveriam escrever mais blocos try/catch. Há muitos casos em que uma exceção numa área, por mais rara que seja, não deveria parar toda a operação. Claro, também há casos em que o certo é parar; depende da situação.
• Iniciantes especialistas programam desse jeito. Eu chamo isso de “What if driven development”. Muito código foi escrito nesse estilo por esse tipo de iniciante especialista, e por várias métricas isso é extremamente produtivo. Até agentes SOTA em Go codificam bugs de concorrência de forma defensiva quase obsessiva, provavelmente como resultado dessa cultura de desenvolvimento e da enxurrada de postagens alertando sobre bugs de concorrência.
• Também há muita coisa estranha do ponto de vista lógico: division by zero só é possível quando b=0, mas essa condição já foi verificada antes com abs(b) < sys.float_info.epsilon. E, no pre-check, retornar NaN é permitido, mas, se NaN surgir na operação real, ele é trocado por None. É um comportamento sem justificativa do ponto de vista de design de API.
• O código tem vários problemas, mas, pessoalmente, o que mais me incomoda é a tendência de colocar import dentro da função. Acho que isso é um efeito colateral artificial surgido de uma otimização para aplicar só a menor modificação possível, mas eu esperaria um resultado melhor.
  • Acho que isso tem relação com o mecanismo de atenção RoPE, em que a proximidade física no código é usada como sinal de importância.
  • É com o objetivo de tornar o import lazy, para resolver problemas de importação lenta em contexto de startup.
  • Em projetos realmente enormes, lazy initialization acaba sendo essencial, porque o impacto no tempo de inicialização é gigantesco.
• Levei mais tempo fechando o pop-up do que lendo este post; odeio links do Twitter.
  • Dá para ver qualquer link do Twitter adicionando “cancel” depois do x: https://xcancel.com/karpathy/status/1976082963382272334