Na noite passada, ensinei ao nanochat d32 como contar 'r' em morango (ou variações semelhantes). Achei que este seria um bom/exemplo divertido de como adicionar capacidades ao nanochat e escrevi um guia completo aqui: Isto é feito através de uma nova tarefa sintética `SpellingBee` que gera exemplos de um usuário pedindo esse tipo de problema, e uma solução ideal de um assistente. Em seguida, fazemos um midtrain/SFT finetune sobre esses exemplos para dotar o LLM da capacidade, ou treinamos mais com RL para torná-lo mais robusto. Há muitos detalhes a acertar, especialmente em tamanhos de modelo menores, e o guia passa por eles. Como uma breve visão geral: - Você deve garantir diversidade nos prompts/consultas dos usuários - Para modelos pequenos como o nanochat, especialmente, você deve ter muito cuidado com os detalhes de tokenização para facilitar a tarefa para um LLM. Em particular, você deve ter cuidado com os espaços em branco, e então deve espalhar o cálculo do raciocínio por muitos tokens de solução parcial: primeiro padronizamos a palavra entre aspas, depois a soletramos (para quebrar os tokens), depois iteramos e mantemos um contador explícito, etc. - Estou incentivando o modelo a resolver a tarefa de duas maneiras separadas: uma maneira manual (aritmética mental na sua cabeça) e também através do uso da ferramenta do interpretador Python ao qual o nanochat tem acesso. Isso é um pouco "ilusão de ótica" porque toda solução atualmente é "limpa", sem erros. Poder-se-ia ajustar a tarefa para simular erros e demonstrar recuperações por exemplo, ou rodar RL. Muito provavelmente, uma combinação de ambos funciona melhor, onde o primeiro atua como o anterior para o RL e fornece coisas para trabalhar. Se o nanochat fosse um modelo muito maior, você esperaria ou esperaria que essa capacidade "aparecesse" mais facilmente em algum momento. Mas como o "cérebro" do nanochat d32 é do tamanho de uma ~abelha, se quisermos que ele conte os 'r's em morango, temos que fazer isso super-representando-o nos dados, para incentivar o modelo a aprendê-lo mais cedo. Mas funciona! :)

Gosto bastante do novo artigo DeepSeek-OCR. É um bom modelo de OCR (talvez um pouco pior que os pontos), e sim, a coleta de dados, etc., mas de qualquer forma, isso não importa. A parte mais interessante para mim (especialmente como alguém que é um entusiasta de visão computacional e que está temporariamente a disfarçar-se de pessoa de linguagem natural) é se os pixels são melhores entradas para LLMs do que o texto. Se os tokens de texto são desperdícios e apenas terríveis, na entrada. Talvez faça mais sentido que todas as entradas para LLMs sejam apenas imagens. Mesmo que você tenha uma entrada de texto puro, talvez prefira renderizá-la e depois alimentá-la: - mais compressão de informação (veja o artigo) => janelas de contexto mais curtas, mais eficiência - fluxo de informação geral significativamente maior => não apenas texto, mas por exemplo, texto em negrito, texto colorido, imagens arbitrárias. - a entrada agora pode ser processada com atenção bidirecional facilmente e como padrão, não atenção autoregressiva - muito mais poderosa. - delete o tokenizer (na entrada)!! Já reclamei sobre o quanto não gosto do tokenizer. Os tokenizers são feios, separados, não são uma etapa de ponta a ponta. Ele "importa" toda a feiura do Unicode, codificações de bytes, herda muito do peso histórico, risco de segurança/jailbreak (por exemplo, bytes de continuação). Faz com que dois caracteres que parecem idênticos aos olhos pareçam como dois tokens completamente diferentes internamente na rede. Um emoji sorridente parece um token estranho, não um... rosto sorridente real, pixels e tudo, e todo o aprendizado de transferência que isso traz. O tokenizer deve ir embora. OCR é apenas uma das muitas tarefas úteis de visão -> texto. E tarefas de texto -> texto podem ser transformadas em tarefas de visão -> texto. Não o contrário. Então, muitas vezes a mensagem do usuário é imagens, mas o decodificador (a resposta do Assistente) permanece texto. É muito menos óbvio como output pixels de forma realista... ou se você gostaria de fazê-lo. Agora também tenho que lutar contra a vontade de criar uma versão apenas de entrada de imagem do nanochat...

Postagem agradável e curta que ilustra quão simples pode ser a difusão de texto (discreta). A difusão (ou seja, denoising paralelo e iterado, top) é o paradigma gerativo predominante em imagem/vídeo, mas a autoregressão (ou seja, ir da esquerda para a direita, para baixo) é o paradigma dominante em texto. Para áudio, já vi um pouco de ambos. Muitos artigos sobre difusão parecem um pouco densos, mas se você retirar o formalismo matemático, acaba com algoritmos de base simples, por exemplo, algo muito mais próximo do flow matching em contínuo, ou algo assim em discreto. É o seu transformer vanilla, mas com atenção bidirecional, onde você reamostra e remarca iterativamente todos os tokens na sua "tela de tokens" com base em um cronograma de ruído até obter a amostra final na última etapa. (A atenção bidirecional é muito mais poderosa, e você obtém modelos de linguagem autoregressivos muito mais fortes se treinar com ela, infelizmente isso torna o treinamento muito mais caro porque agora você não pode paralelizar ao longo da dimensão da sequência). Assim, a autoregressão está fazendo um `.append(token)` na tela de tokens enquanto apenas atende para trás, enquanto a difusão está atualizando toda a tela de tokens com um `.setitem(idx, token)` enquanto atende bidirecionalmente. O pensamento humano, de forma ingênua, parece um pouco mais com a autoregressão, mas é difícil dizer que não há mais componentes semelhantes à difusão em algum espaço latente de pensamento. Parece bastante possível que você possa interpolar ainda mais entre eles ou generalizá-los ainda mais. E é um componente da pilha LLM que ainda parece um pouco fungível. Agora devo resistir à vontade de me desviar para treinar o nanochat com difusão.