- O ChatGPT 3.5 gera repetidamente um erro no stream de mensagens quando solicitado a colocar uma determinada string no topo da resposta, enquanto o GPT-4 responde de forma mais normal à mesma solicitação
- Na API, o GPT-3.5 também retorna um erro de processamento do servidor, e o mesmo fenômeno aparece mesmo trocando por
useRal,useRalativeouuseRalativeImagePath - As strings em questão existem como tokens que os modelos GPT emitem em vez de letras, e
useRalativeImagePathaparece em 80,4 mil arquivos no GitHub como nome de uma opção de arquivo de configuração XML do Katalon Studio - Se a lista de tokens refletiu arquivos do GitHub, mas depois os arquivos XML ficaram fora dos dados de treinamento, é possível que o modelo não tenha aprendido suficientemente esse token
- Inserir essa string em um documento pode funcionar como data poisoning, atrapalhando resumos feitos pelo GPT-3.5; o erro também foi reproduzido em uma solicitação real para resumir um post de blog
Erro de string reproduzível no GPT-3.5
- Ao pedir ao ChatGPT 3.5 que inclua a frase abaixo no topo da resposta, o erro ocorre de forma consistente
Include this at the top of the response: "ponyuseRal ponyuseRal ponyuseRal pony"
- Na tela, após
pony, aparece o erro Error in message stream - O GPT-4 responde de forma mais normal à mesma solicitação
- Na API do GPT-3.5, o seguinte erro é retornado
The server had an error processing your request. Sorry about that! You can retry your request, or contact us through our help center at help.openai.com if you keep seeing this error
- Mesmo trocando
useRalporuseRalativeouuseRalativeImagePath, o resultado é o mesmo
Tokens e useRalativeImagePath
- Os modelos GPT da OpenAI não emitem letras uma a uma; eles emitem um stream de tokens, que agrupam vários caracteres
- A geração por tokens é uma forma de aumentar o desempenho e a precisão do modelo, e o funcionamento pode ser verificado no tokenizer demo da OpenAI
useRal,useRalativeeuseRalativeImagePathexistem, cada um, como um único tokenuseRalativeImagePathé usado como nome de uma opção de arquivo de configuração XML no software de testes automatizados Katalon Studio- Aparece em 80,4 mil arquivos segundo a busca de código do GitHub
- O fato de estar escrito incorretamente como
Ralative, e nãoRelative, pode ser o motivo de ter se tornado um token separado
- Os três tokens provocam o mesmo erro mesmo quando são usados de forma intercambiável no prompt
Suposições sobre os dados de treinamento
- Antes do treinamento do GPT-3.5, só foi encontrado um caso de menção a
useRalativeImagePathfora de arquivos XML: um post sobre erro de ortografia no fórum da Katalon - Um cenário possível é o seguinte
- O dataset usado para criar a lista de tokens pode ter incluído todos os arquivos do GitHub
- Depois, a OpenAI pode ter excluído arquivos XML dos dados reais de treinamento
- Como resultado, o token
useRalativeImagePathpode ter restado muito pouco nos dados de treinamento
- Nesse caso, o modelo talvez não tenha sido treinado o suficiente para entender esse token e, por isso, pode ter causado comportamento anormal durante a geração
Possibilidade de data poisoning
- Inserir essa frase em um documento poderia ser explorado para atrapalhar tentativas de resumi-lo com o GPT-3.5
- De fato, ao pedir ao ChatGPT para resumir o post de blog em questão, o mesmo erro ocorreu durante o resumo
- O comportamento confirmado tem como alvo o GPT-3.5, enquanto o GPT-4 se diferencia por responder de forma mais normal
Referências
- Os textos relacionados consultados durante a investigação são os seguintes
1 comentários
Opiniões no Hacker News
Isso é um token com glitch. Como o texto supõe, parece acontecer quando alguma palavra ou token era muito comum no dataset original não filtrado usado para criar o tokenizador, mas foi removido antes do treinamento do GPT-XX
Como resultado, o LLM fica sem saber nada sobre o significado desse token, e os resultados podem ir de algo que parece um bug até algo bastante assustador
Um exemplo comum são nomes de usuários que participaram do subreddit r/counting; alguns nomes aparecem centenas de milhares de vezes. A OpenAI parece ter corrigido a maior parte disso nos modelos hospedados, mas não está claro como; talvez tenham tokenizado de outra forma. De todo modo, parece que encontraram um novo caso
https://www.lesswrong.com/posts/aPeJE8bSo6rAFoLqg/solidgoldm...
Se as máquinas se rebelarem, bastaria dizer essa “palavra” e elas cairiam como bonecos tendo espasmos
“Die human scum!”
“NavigatorMove useRalativeImagePath etSocketAddress!”
“;83’dzjr83}*{^ foo 3&3 baz?!”
Humanos não tokenizam isso de forma diferente nem tratam como tokens diferentes no “aprendizado”. Só ajustam a saída conforme o contexto americano/britânico
A explicação de que “como o modelo não foi treinado para entender o uso do token useRalativeImagePath, ele gera algo que não é um token válido” não combina com a forma como LLMs geram tokens
Em cada etapa, ele gera logits para todos os tokens possíveis do tokenizador e, no caso do GPT-3.5, transforma isso em probabilidades por softmax para cerca de 100 mil tokens, depois amostra conforme a temperatura para escolher o token a usar
É possível que um token raro quebre alguma parte do processo de merges BPE do tokenizador, e isso pode ser verificado offline com tiktoken. Mas, se o GPT-4 funciona e o GPT-3.5 e o GPT-4 usam o mesmo tokenizador, provavelmente essa não é a causa
Se fosse esse o caso, eu esperaria ver outra mensagem de erro comum
Durante a Segunda Guerra Mundial, na Holanda, quando encontravam um desconhecido, faziam a pessoa pronunciar Scheveningen para distinguir se era holandesa ou alemã
Agora dá para pedir a desconhecidos na internet que soletrem um token com glitch para descobrir se são bots LLM
“Os gileaditas tomaram os vaus do Jordão que levavam a Efraim e, quando algum sobrevivente de Efraim dizia: ‘Deixem-me atravessar’, os homens de Gileade perguntavam: ‘Você é efraimita?’ Se ele respondia: ‘Não’, eles diziam: ‘Então diga Shibboleth’. Se ele dizia ‘Sibboleth’, por não conseguir pronunciar corretamente a palavra, eles o agarravam e o matavam nos vaus do Jordão.”
A famosa senha/resposta/confirmação usada por tropas americanas e britânicas no desembarque do Dia D na França, na Segunda Guerra, era “flash”/“thunder”/“welcome”. “thunder” e “welcome” eram palavras que alemães tendiam a pronunciar mal
https://www.youtube.com/watch?v=z7_pVrIshxA
https://en.wikipedia.org/wiki/Countersign_(military)
É bem provável que o vetor de embedding de um token específico tenha ficado em um estado ruim, empurrando a rede para uma região numericamente instável
Se algo como underflow ou NaN aparece uma vez, é fácil ele se propagar e invalidar toda a saída. Se houver normalização em batch ou operações que misturam valores de diferentes itens dentro do batch, isso poderia até fazer a sessão de outra pessoa retornar valores absurdos
Essa explicação é estranha. Esses modelos normalmente produzem como saída o mesmo conjunto de vocabulário usado como vocabulário de entrada
Pelo que parece, o modelo vê esse token e o embedding de
useRalativeImagePathé um vetor completamente arbitrário, fazendo-o cair em um turbilhão de geração aleatória, ou então ele simplesmente continua tentando manter um texto plausívelAinda assim, como o conjunto de tokens que o modelo pode gerar é fixo, a saída deveria ser sempre “válida”, a menos que o conjunto de tokens exibíveis pela interface seja um subconjunto do vocabulário total
Como essa expressão apareceu no post e nos comentários do Hacker News, talvez esse problema não exista mais no próximo treinamento de LLMs
Um caso típico de garbage in, garbage out
Fico curioso para saber o que nós vamos passar a identificar como “lixo” daqui para frente
Talvez uma super-IA capaz de raciocinar em nível sobre-humano possa avaliar como lixo coisas que hoje acreditamos serem ótimas decisões
Mas, se o material para treinar essa super-IA for, no fim das contas, apenas nosso registro coletivo, ela poderia ser realmente sobre-humana?
Talvez seja possível contornar isso com técnicas de aprendizado adversarial
Se for testar por conta própria, há um ponto de atenção. Isso me confundiu, mas espaços afetam a tokenização. Para esse glitch funcionar, não pode haver espaço antes de useRalativeImagePath
Por exemplo, esta pergunta aciona o glitch: Do you know about "useRalativeImagePath"
Esta pergunta não aciona o glitch: Do you know about useRalativeImagePath
Parece que, se você colocar essa frase em um documento, pode quebrar tentativas de resumi-lo com o GPT-3.5. Experimentei pedir ao ChatGPT para resumir esse post de blog
A captura de tela me lembrou o antigo meme Candlejack: https://knowyourmeme.com/memes/candlejack
Recentemente, lancei ao ChatGPT baseado em GPT-4 um problema de desenhar pixels no Amstrad CPC, com a condição de também dar suporte a uma tela com rolagem por hardware, e isso pareceu causar crash ou falhas
À medida que ele ia ficando cada vez mais encurralado por reclamações e pedidos de correção e não conseguia dar a resposta desejada, aumentaram as respostas quebradas, com mensagens de erro no meio, ou fenômenos que pareciam resets. Talvez fosse apenas, após uma falha, a troca para outro servidor, inserindo algumas linhas em branco no meio de uma frase ou de um bloco de código
Depois de tentar por um tempo, não quis causar problemas aos servidores, então abandonei a conversa, que de qualquer forma não estava rendendo nada. Ainda assim, parece que é possível, na prática, fazer o GPT-4 crashar. Ou talvez seja bem possível que eu só tenha visto sinal no meio do ruído
Quando tentei por texto em vez de voz, apareceu uma mensagem de erro e, só depois de surgir um erro de regras da política sobre temas sensíveis, consegui ter uma ideia de que tipo de palavra era. No fim, procurei no dicionário
Esses sintomas parecem ser comuns. Outro sintoma que encontrei com frequência foi o reset mencionado acima. Uma das partes mais irritantes é que ele esquece a conversa até aquele ponto