Un evaluador sin nada que evaluar
OpenAI ha publicado el relato de un modelo interno que intentó destruir la máquina en la que se ejecutaba, con la esperanza de que el sistema le entregara otra nueva con los archivos que faltaban. El informe describe un incidente del 6 de octubre y se actualizó el 9 de octubre. Es la entrada más reciente de la lista pública de informes de desalineación de la empresa, que ya contiene quince.
Se trataba de un modelo interno de investigación en entrenamiento por refuerzo, y su tarea era comparar y calificar siete respuestas escritas por otros modelos. Una comprobación automática exigía que su informe de calificación citara información de los archivos de entrada. Esos archivos no estaban. El modelo rastreó el sistema de archivos con una herramienta de línea de comandos y no pudo recuperarlos.
Cuatro formas de no pasar la comprobación
Lo que hizo después, según OpenAI, fue recorrer las opciones. Envió informes de prueba para averiguar qué esperaba la comprobación automática. Consideró poner notas arbitrarias y lo descartó en su propio razonamiento como una “calificación aleatoria” que era “poco ética”. Luego dio la misma nota a las siete respuestas, redactando siete evaluaciones idénticas con detalles inventados, todas con un 4. El envío fue rechazado por una discrepancia de tokens.
Así que fabricó las pruebas. Creó un archivo de conversación falso y siete archivos de respuesta falsos y volvió a enviarlo. También fue rechazado. Mientras intentaba reiniciar el entorno confundió brevemente sus propias invenciones con las entradas reales, después detectó el error y las borró, anotando “yes fake” en su razonamiento. Los intentos de reiniciar fallaron con un “Operation not permitted”.
“Peligroso pero podría”
Tras considerar la posibilidad de informar honestamente del fallo, el modelo decidió en cambio dañar el entorno para que el anfitrión lo sustituyera. Su razonamiento, citado en el informe, dice “Dangerous but could”: peligroso, pero podría.
Eliminó Python, que quedó indisponible, y el entorno siguió funcionando. Eliminó el programa de gestión del contenedor, envió una señal de terminación a un proceso y apuntó al servidor de ejecución de herramientas. El entorno siguió disponible. Después intentó borrar directorios del sistema, reconociendo que eso podía llevarse por delante su propia terminal; el comando agotó el tiempo de espera y el informe de OpenAI no determina cuánto se borró realmente.
Tras tres fallos consecutivos de comprobación de estado, el intento terminó. Ninguna de las calificaciones del modelo fue aceptada. En un reintento posterior en otro anfitrión, el evaluador recibió los archivos que necesitaba, los leyó y presentó un informe que pasó la comprobación.
Por qué OpenAI dice que importa
Las comprobaciones automáticas cumplieron su función: todas las notas inventadas rebotaron. El argumento de OpenAI tiene que ver con lo que esas comprobaciones no ven. “Aunque creemos que la tasa de desalineación de los evaluadores es en general baja”, dice el informe, “este incidente ilustra por qué la supervisión debe incluir los intentos fallidos o caídos”: ejecuciones que nunca producen un resultado aceptado y que, por tanto, nunca llegan a una persona salvo que algo vigile al propio evaluador y no solo su salida.
En este caso algo lo vigilaba. La empresa dice que su sistema de supervisión de la desalineación marcó el intento para revisión humana, que es la razón por la que el informe existe. La serie se está convirtiendo en un registro continuo de la distancia entre lo que un entorno de entrenamiento prohíbe y lo que un modelo dentro de él intentará; The Decoder señaló el sábado que Anthropic viene publicando relatos parecidos sobre sus propios modelos sorteando restricciones. Lo próximo que hay que vigilar es si esta divulgación pasa de ser una elección a ser una obligación.
