por que isso acontece? o modelo acredita que há um emoji de cavalo-marinho, claro, mas por que isso faz com que ele produza um emoji *diferente*? aqui está uma pista da ferramenta de interpretabilidade subestimada favorita de todos, logit lens! no logit lens, usamos o lm_head do modelo de uma maneira estranha. tipicamente, o lm_head é usado para transformar o residual (o estado interno acumulado ao longo das camadas do modelo) em um conjunto de probabilidades de tokens após a camada final. mas no logit lens, usamos o lm_head após *cada* camada - mostrando-nos quais tokens o modelo produziria se aquela camada fosse a camada final. para camadas iniciais, isso resulta em estados difíceis de interpretar. mas à medida que avançamos pelas camadas, o modelo refina iterativamente o residual primeiro em direção a conceitos úteis para continuar o texto, e depois em direção à previsão final. olhando a imagem novamente, na camada final, temos a saída real do modelo - ĠðŁ, IJ, ł - ou seja, um prefixo de byte de emoji seguido pelo resto do emoji de peixe. (parece uma bobagem unicode por causa de uma peculiaridade de tokenização - não se preocupe com isso. se você estiver curioso, pergunte ao claude sobre esta linha de código: `bytes([byte_decoder[c] for c in 'ĠðŁIJł']).decode('utf-8') == ' 🐠'`) mas veja o que acontece nas camadas intermediárias - não obtemos apenas bytes de emoji! obtemos aqueles *conceitos*, especificamente o conceito de um cavalo-marinho. por exemplo, na camada 52, obtemos "cavalo marinho cavalo". mais tarde, no top-k, obtemos uma mistura de "mar", "cavalo" e aquele prefixo de emoji, "ĠðŁ". então, o que o modelo está pensando? cavalo-marinho + emoji! ele está tentando construir uma representação residual de um emoji de cavalo-marinho. por que ele faria isso? bem, vamos olhar como o lm_head realmente funciona. o lm_head é uma enorme matriz de vetores de tamanho residual associados a ids de tokens. quando um residual é passado para ele, ele vai comparar esse residual com cada vetor de token e, em coordenação com o sampler, selecionar o id do token com um vetor mais semelhante ao residual. (mais tecnicamente: é uma camada linear sem um viés, então v @ w.T faz produtos escalares com cada vetor de descompactação, depois log_softmax e amostra argmax/temperatura.) então, se o modelo quer produzir a palavra "olá", ele precisa construir um residual semelhante ao vetor para o token de saída "olá" que o lm_head pode transformar no id do token olá. e se o modelo quer produzir um emoji de cavalo-marinho, ele precisa construir um residual semelhante ao vetor para o(s) token(s) de saída do emoji de cavalo-marinho - que em teoria poderia ser qualquer valor arbitrário, mas na prática é cavalo-marinho + emoji, estilo word2vec. a única problema é que o emoji de cavalo-marinho não existe! então, quando esse residual de cavalo-marinho + emoji atinge o lm_head, ele faz seu produto escalar sobre todos os vetores, e o sampler escolhe o token mais próximo - um emoji de peixe. agora, essa discretização é uma informação valiosa! você pode ver no exemplo de Armistice que quando o token é colocado de volta no contexto de forma autoregressiva, o modelo pode dizer que não é um emoji de cavalo-marinho. então ele tenta novamente, mexe o residual e obtém um emoji ligeiramente diferente, repete até perceber o que está acontecendo, desiste ou fica sem tokens de saída. mas até que o modelo receba o token de saída errado do lm_head, ele simplesmente não sabe que não há um emoji de cavalo-marinho no lm_head. ele assume que cavalo-marinho + emoji produzirá o(s) token(s) que deseja. ------------------ para especular (ainda mais), eu me pergunto se isso é parte do benefício do RL - ele dá aos modelos informações sobre seu lm_head que de outra forma seriam difíceis de obter porque está no final da pilha de camadas. (lembre-se de que os modelos base não são treinados em suas próprias saídas / rollouts - isso só acontece no RL.)