Los LLM le temen fatalmente a las excepciones

• Andrej Karpathy satiriza un efecto secundario surgido durante el proceso de aprendizaje por refuerzo (RL) al decir que “los LLM le temen fatalmente (mortally terrified) a las excepciones (Exception)”
• Señala que, cuando un LLM se encuentra con una situación excepcional, tiende a detenerse por sí mismo o a reaccionar de forma excesivamente defensiva, y enfatiza que las excepciones son una parte natural del proceso de desarrollo
• La expresión “qué les están haciendo los labs a estos pobres LLM durante RL (what labs are doing to these poor LLMs)” critica la realidad de un entrenamiento que condiciona a los modelos a temer al fracaso
• Karpathy propone en broma una “petición por el bienestar de los LLM (LLM welfare petition)” para “mejorar las recompensas en casos de excepciones (improved rewards in cases of exceptions)”,
  satirizando así el problema del diseño de recompensas para que los modelos manejen las excepciones sin temerles
• Este tuit no es solo humor, sino que se interpreta como un mensaje que señala que RLHF puede inhibir el pensamiento exploratorio y la actitud experimental de los 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⁺]

Comentarios en Hacker News

• Debería haber dejado claro que el código en sí era una broma exagerada; perdón si hubo confusión. Si tienen curiosidad, vean este hilo: https://chatgpt.com/share/68e82db9-7a28-8007-9a99-bc6f0010d101
  • En el primer intento esta parte sí me dio mucha risa

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

  • Creo que siempre existe el riesgo de que estas empresas de modelos fundacionales apliquen RLHF a usuarios no expertos, y este caso se siente como eso; últimamente la IA tiende mucho a priorizar complacer al usuario en general, como meter ejemplos o emojis y poner comentarios innecesarios en código simple; va por la misma línea
  • Lo interesante es que, aunque ese código es innecesariamente cauteloso, no agregó type hints; si iba a preocuparse tanto, pensé que al menos sabría agregar type hints
  • Creo que la expresión “Traumatically over-trained” es increíble en inglés; ni siquiera aparece en Google como combinación, pero sorprende que uno entienda de forma instintiva qué sería un “sobreentrenamiento traumático” para un LLM
  • Fue una broma realmente divertida, por eso la compartí
• Es una parodia, pero este fenómeno sí existe de verdad; mi suposición ignorante es que esta programación defensiva incluso podría mejorar el rendimiento durante RLVR, porque a veces el modelo da la respuesta correcta aunque haya bugs si ignora el error, así que aprende que “ignorar errores” ayuda a la recompensa; y como rara vez ignorar errores reduce la recompensa —porque los tests pasan—, quizá esto ocurra, aunque sea teóricamente incorrecto, porque en el dataset de entrenamiento hay mucho código de principiantes humanos que a menudo ignoran errores. Pero esto no deja de ser especulación mía
  • Me recordó a cómo Verity Stob lo comparaba (en un artículo que tristemente ya no está en línea) con “clavar el cadáver para que se mantenga derecho”
  • Mi hipótesis es que el dataset contiene muchísimo texto y comentarios de “sentimiento positivo”. Pero ¿de dónde sale el código que viene después de un sentimiento “negativo” y lo corrige? Del código de preparación para entrevistas técnicas, donde lidiar con edge cases extremos es cosa de todos los días. Si se entrena con ejemplos negativos, se sesga hacia evitar ejemplos donde falte manejo de excepciones; en ese sentido, la IA terminó copiando uno de los peores hábitos humanos: entrenarse solo para pasar tests
  • La programación defensiva es algo que quienes hacen reinforcement consideran “correcto”, y ocupa una porción enorme de los datos de entrenamiento de los LLM. Por ejemplo, la mayoría del código Python no maneja índices manualmente, así que cuando un LLM ve código con manejo manual de índices se confunde o inventa bugs, y de manera absurda termina prefiriendo más el “silent failure”, porque el código de tutorial y el código “estándar de la industria” reciben mucho más refuerzo durante el entrenamiento. En el fondo, estos modelos no operan con una reward function ni tienen un reward model interno; solo predicen palabras, y su arquitectura no tiene inteligencia
• Como en el resultado de la función aparece “performed with extreme caution”, sospecho que en el prompt había algo como “genera una función de división en Python que maneje todos los edge cases posibles, escrita con extrema cautela”; se siente más como que cumplió demasiado literalmente con lo pedido que como un problema de entrenamiento del LLM
  • Dejando de lado que claramente es una sátira exagerada,
    1. ese código de verdad está mal (está mal incluso ignorando el extraño manejo de excepciones)
    2. parte del manejo de excepciones no tiene ningún sentido y resulta confuso
    3. en la vida real pasa perfectamente con versiones menos exageradas si en el prompt solo enfatizas el manejo de excepciones
  • Yo lo interpreté como una exageración satírica del código de la función para mostrar algo que la persona realmente experimentó; es decir, en ese prompt seguramente se escribió con cautela excesiva a propósito, pero en esencia sí coincido en que los LLM también tienden por defecto a un estilo de código más cauteloso de lo que yo quisiera
• No sé por qué, pero me hizo pensar en FizzBuzzEnterpriseEdition
  https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
  • Wow, ¿de verdad usaron junit 4.8.3 en ese proyecto? Me parece un caso de codificación realmente temeraria. Me pregunto si lo aprobaron con legal y con el CTO; es una decisión que de verdad pone en riesgo tu carrera
  • Me impactó la cantidad de carpetas y archivos; es una sátira impresionante
• Los LLM tienden a generar más código defensivo del necesario, revisando repetidamente null/None/undefined para el mismo valor; eso hace que el código sea difícil de leer, e incluso difícil de interpretar para el propio LLM. Parece que el objetivo de RL penaliza mucho las excepciones, pero no da muchos puntos por la concisión o la legibilidad del código
  • Tengo una función de 40 líneas que compara letras y números para un Major System, y me desespera que Copilot se ponga a meter “guardrails” solo porque se imagina que en el futuro podrían agregarse más números o letras
• Coincido en que los LLM tienen una obsesión excesiva con atrapar errores
  Pero por otro lado, también creo que los programadores humanos comunes de verdad deberían escribir más bloques try/catch; hay muchas situaciones donde una excepción en un área, por rara que sea, no debería detener toda la operación. Claro, también hay casos donde sí debe detenerla; depende del contexto
• Los principiantes expertos programan así. Yo lo llamo “What if driven development”. Mucho código está escrito por este tipo de principiantes expertos y, según varias métricas, son increíblemente productivos. Incluso los agentes SOTA para Go escriben código absurdamente defensivo contra bugs de concurrencia, probablemente como resultado de esa cultura de desarrollo y de la avalancha de posts advirtiendo sobre bugs de concurrencia
• También tiene muchas rarezas lógicas: division by zero solo puede ocurrir cuando b=0, pero eso ya se revisó con abs(b) < sys.float_info.epsilon; además, en el pre-check se permite devolver NaN, pero si durante la operación real sale NaN, entonces lo cambia a None. Desde el diseño del API, es un comportamiento sin fundamento
• El código tiene varios problemas, pero personalmente lo que más me molesta es esa tendencia a meter import dentro de la función. Supongo que es un efecto artificial surgido de optimizar para aplicar cambios mínimos, pero esperaría algo mejor
  • Creo que está relacionado con el mecanismo de atención RoPE y con que la proximidad física en el código se usa como señal de importancia
  • Es para hacer lazy el import, con el objetivo de resolver problemas de imports lentos en condiciones de startup
  • En proyectos realmente enormes, la lazy initialization sí se vuelve obligatoria, porque impacta muchísimo el tiempo de arranque
• Me tomó más tiempo cerrar el popup que leer este post; de verdad odio los links de Twitter
  • Puedes ver cualquier link de Twitter agregando “cancel” después de la x: https://xcancel.com/karpathy/status/1976082963382272334