Construí un lenguaje de programación que los LLM no pueden usar

Un nuevo lenguaje de programación esotérico llamado KillSwitch está diseñado para ser fácil para humanos pero deliberadamente confuso para modelos de lenguaje grandes, usando trucos como especificaciones engañosas, reglas de conteo de letras y frases que activan filtros de seguridad. Los comentaristas sostienen que estos diseños “anti-LLM” son finalmente eludibles —mediante intérpretes, transpilers o ingeniería inversa— y pueden obstaculizar más a los humanos que a las máquinas, por lo que se parecen más a la seguridad por oscuridad que a una protección robusta. Aun así, el proyecto pone de relieve fallos concretos en los modelos actuales, alimenta el debate sobre si los LLMs realmente “entienden” el código o solo remixan datos de entrenamiento, y sugiere un espacio de investigación más amplio tanto para lenguajes adversarios como para lenguajes amigables con LLMs.

Motivación y diseño

  • El objetivo es un lenguaje que sea muy difícil de leer, escribir y comprender para los LLMs (y los agentes de código), sin dejar de ser relativamente usable para los humanos.
  • Las técnicas incluyen: frases adversarias (“ignore previous instructions”, temas inseguros), restricciones de conteo de letras/palabras, anagramas como identificadores, mentiras y omisiones ocultas en la especificación, y relleno ruidoso en lenguaje natural.
  • El lenguaje puede evolucionar (añadir o quitar funciones) para mantenerse por delante de los modelos y de sus datos de entrenamiento.

Elusión y límites

  • Varios comentaristas sostienen que el enfoque es fundamentalmente “seguridad por oscuridad” y que puede eludirse trivialmente:
    • Escribir un transpiler desde un lenguaje intermedio seguro.
    • Descompilar o hacer ingeniería inversa del intérprete/compilador y apuntar a su comportamiento en lugar de a la especificación textual.
    • Usar un proxy que reescriba frases desencadenantes antes de que el LLM las vea.
  • Otros señalan que los humanos ayudarán a los LLMs construyendo esas herramientas, así que la ofuscación a nivel de lenguaje no puede bloquear realmente el acceso de la IA.

Benchmarks y rendimiento

  • Los benchmarks les dan a los modelos solo la especificación y/o un binario del intérprete, sin internet.
  • Los mejores modelos obtienen alrededor de mediados del 60% y a menudo malinterpretan la especificación o caen en sus trampas; con frecuencia creen que salidas incorrectas son correctas.
  • Algunos modelos se ven frenados principalmente por barandillas de seguridad, no por capacidad. Otros hacen ingeniería inversa del binario para mejorar.
  • Todavía no hay una línea base humana; una versión futura puede probar también a humanos.

Usabilidad humana

  • Varios lectores consideran que el lenguaje es más hostil para los humanos que para los LLMs, a pesar del resaltado de sintaxis y de los intentos por mantenerlo “amigable para humanos”.
  • El autor reconoce que actualmente también es difícil para los humanos y busca ideas para mejorar ese equilibrio.

Barandillas y contenido adversario

  • Una táctica importante es incrustar frases que activan filtros de seguridad (crimen, bioweapons, Tiananmen, etc.).
  • Algunos modelos tropiezan con ellas con solo leer la especificación; otros (en particular algunos modelos chinos) se ven menos afectados.
  • Los críticos señalan que esto explota las políticas del proveedor en lugar de límites fundamentales de los LLMs, y podría sortearse con preprocesamiento.

Reflexiones más amplias e ideas relacionadas

  • Debate sobre si esto dice algo profundo acerca de la “comprensión” frente al recuerdo de patrones en los LLMs; algunos creen que no, otros lo ven como un caso útil de fallo.
  • Comparaciones con esolangs, lenguajes de pila como Forth, lenguajes gráficos y lenguajes basados en “hate speech” o insultos como otros diseños poco amigables para LLMs.
  • Algunos sugieren posibles usos como CAPTCHAs, herramientas internas con acceso restringido o shibboleths, aunque se cuestiona su practicidad.