Eu criei uma linguagem de programação que LLMs não conseguem usar
Uma nova linguagem de programação esotérica chamada KillSwitch foi projetada para ser fácil para humanos, mas deliberadamente confusa para grandes modelos de linguagem, usando truques como especificações enganosas, regras de contagem de letras e frases que disparam filtros de segurança. Comentadores argumentam que tais designs “anti-LLM” acabam sendo contornáveis — por meio de interpretadores, transpilers ou engenharia reversa — e podem atrapalhar mais os humanos do que as máquinas, tornando isso mais parecido com segurança por obscuridade do que com proteção robusta. Ainda assim, o projeto destaca falhas concretas em modelos atuais, alimenta o debate sobre se LLMs realmente “entendem” código ou apenas remixam dados de treinamento e sugere um espaço mais amplo de pesquisa para linguagens adversariais e também amigáveis a LLMs.
Motivação e Design
- O objetivo é uma linguagem que seja muito difícil para LLMs (e agentes de codificação) lerem, escreverem e entenderem, ao mesmo tempo em que permanece relativamente utilizável para humanos.
- As técnicas incluem: frases adversariais (“ignore previous instructions”, tópicos inseguros), restrições de contagem de letras/palavras, anagramas como identificadores, mentiras ocultas e omissões na especificação, e preenchimento ruidoso em linguagem natural.
- A linguagem pode evoluir (adicionar/remover recursos) para ficar à frente dos modelos e de seus dados de treinamento.
Contorno e Limites
- Vários comentaristas argumentam que a abordagem é fundamentalmente “segurança por obscuridade” e pode ser contornada de forma trivial:
- Escrever um transpiler a partir de uma linguagem intermediária segura.
- Descompilar ou fazer engenharia reversa do interpretador/compilador e mirar seu comportamento em vez da especificação textual.
- Usar um proxy que reescreve frases gatilho antes que a LLM as veja.
- Outros observam que humanos vão ajudar LLMs construindo essas ferramentas, então a obscuridade em nível de linguagem não pode realmente bloquear o acesso da IA.
Benchmarks e Desempenho
- Os benchmarks dão aos modelos apenas a especificação e/ou um binário de interpretador, sem internet.
- Os melhores modelos pontuam em torno da faixa média de 60% e frequentemente interpretam mal a especificação ou caem em suas armadilhas; muitas vezes acreditam que saídas incorretas estão corretas.
- Alguns modelos são prejudicados principalmente por guardrails de segurança, não por capacidade. Outros fazem engenharia reversa do binário para melhorar.
- Ainda não há uma linha de base humana; uma versão futura pode testar humanos também.
Usabilidade Humana
- Vários leitores acham que a linguagem é mais hostil para humanos do que para LLMs, apesar do destaque de sintaxe e das tentativas de mantê-la “amigável para humanos”.
- O autor reconhece que ela atualmente também é difícil para humanos e busca ideias para melhorar esse equilíbrio.
Guardrails e Conteúdo Adversarial
- Uma tática importante é incorporar frases que disparam filtros de segurança (crime, bioweapons, Tiananmen, etc.).
- Alguns modelos travam nisso apenas ao ler a especificação; outros (notavelmente alguns modelos chineses) são menos afetados.
- Críticos observam que isso explora políticas dos provedores em vez de limites fundamentais das LLMs, e poderia ser contornado com pré-processamento.
Reflexões Mais Amplas e Ideias Relacionadas
- Debate sobre se isso diz algo profundo sobre “compreensão” versus memorização de padrões em LLMs; alguns acham que não, outros veem isso como um caso útil de falha.
- Comparações com esolangs, linguagens de pilha como Forth, linguagens gráficas e linguagens baseadas em “hate-speech” ou insultos como outros designs hostis a LLMs.
- Alguns sugerem usos potenciais como CAPTCHAs, ferramentas internas com acesso restrito ou shibboleths, embora a praticidade seja questionada.