Ontem à noite eu ensinei nanochat d32 como contar 'r' em morango (ou variações semelhantes). Achei que este seria um exemplo bom / divertido de como adicionar recursos ao nanochat e escrevi um guia completo aqui: Isso é feito por meio de uma nova tarefa sintética 'SpellingBee' que gera exemplos de um usuário solicitando esse tipo de problema e uma solução ideal de um assistente. Em seguida, ajustamos no meio do treinamento / SFT para dotar o LLM com a capacidade ou treinamos ainda mais com o RL para torná-lo mais robusto. Há muitos detalhes a serem acertados, especialmente em modelos menores, e o guia os percorre. Como uma breve visão geral: - Você deve garantir a diversidade nas solicitações/consultas do usuário - Especialmente para modelos pequenos como o nanochat, você deve ter muito cuidado com os detalhes de tokenização para facilitar a tarefa de um LLM. Em particular, você deve ter cuidado com o espaço em branco e, em seguida, 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 resolvê-lo de duas maneiras distintas: uma maneira manual (aritmética mental em sua cabeça) e também por meio do uso da ferramenta do interpretador Python ao qual o nanochat tem acesso. Isso é um pouco "fumaça e espelhos" porque toda solução atm é "limpa", sem erros. Pode-se ajustar a tarefa para simular erros e demonstrar recuperações por exemplo, ou executar RL. Provavelmente, uma combinação de ambos funciona melhor, onde o primeiro atua como o prior para o RL e dá a ele coisas para trabalhar. Se o nanochat fosse um modelo muito maior, você esperaria ou esperaria que esse recurso "aparecesse" mais facilmente em algum momento. Mas como o "cérebro" do nanochat d32 é do tamanho de uma ~abelha, se quisermos que ele conte r's em morango, temos que fazê-lo super-representando-o nos dados, para encorajar o modelo a aprendê-lo mais cedo. Mas funciona! :)

Eu gosto bastante do novo artigo DeepSeek-OCR. É um bom modelo de OCR (talvez um pouco pior do que pontos), e sim, coleta de dados etc., mas de qualquer maneira não importa. A parte mais interessante para mim (especialmente como uma visão computacional no coração que está temporariamente disfarçada de pessoa de linguagem natural) é se os pixels são melhores entradas para LLMs do que texto. Se os tokens de texto são um desperdício e simplesmente terríveis, na entrada. Talvez faça mais sentido que todas as entradas para LLMs sejam apenas imagens. Mesmo que você tenha entrada de texto puro, talvez prefira renderizá-la e depois alimentá-la: - Mais compactação de informações (consulte o artigo) = > janelas de contexto mais curtas, mais eficiência - fluxo de informações significativamente mais geral = > 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 autorregressiva - muito mais poderosa. - exclua o tokenizer (na entrada)!! Eu já reclamei sobre o quanto não gosto do tokenizador. Os tokenizadores são feios, separados, não de ponta a ponta. Ele "importa" toda a feiúra do Unicode, codificações de bytes, herda muita bagagem histórica, risco de segurança / jailbreak (por exemplo, bytes de continuação). Isso faz com que dois caracteres que parecem idênticos aos olhos pareçam dois tokens completamente diferentes internamente na rede. Um emoji sorridente parece um símbolo estranho, não um... rosto sorridente real, pixels e tudo, e todo o aprendizado de transferência que isso traz. O tokenizer deve ir. O OCR é apenas uma das muitas tarefas úteis de visão > texto. E as tarefas de texto -> texto podem ser transformadas em tarefas de visão ->texto. Não vice-versa. Muitos a mensagem do usuário é imagens, mas o decodificador (a resposta do Assistente) permanece texto. É muito menos óbvio como produzir pixels de forma realista ... ou se você quiser. Agora eu também tenho que lutar contra o desejo de fazer uma missão secundária de uma versão somente de entrada de imagem do nanochat ...

Postagem curta e agradável ilustrando como a difusão de texto (discreta) pode ser simples. A difusão (ou seja, redução de ruído paralela e iterada, superior) é o paradigma generativo generalizado na imagem / vídeo, mas a autorregressão (ou seja, ir da esquerda para a direita inferior) é o paradigma dominante no texto. Para áudio, vi um pouco de ambos. Muitos artigos de difusão parecem um pouco densos, mas se você retirar o formalismo matemático, acabará com algoritmos de linha de base simples, por exemplo, algo muito mais próximo da correspondência de fluxo em contínuo, ou algo assim em discreto. É o seu transformador de baunilha, mas com atenção bidirecional, onde você reamostra e mascara iterativamente todos os tokens em 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 autorregressivos muito mais fortes se treinar com ela, infelizmente torna o treinamento muito mais caro porque agora você não pode paralelizar entre o escurecimento da sequência). Portanto, a regressão automática está fazendo um '.append(token)' na tela de tokens enquanto atende apenas de trás para frente, enquanto a difusão está atualizando toda a tela do token com um '.setitem(idx, token)' enquanto atende bidirecionalmente. O pensamento humano ingenuamente parece um pouco mais com a auto-regressão, mas é difícil dizer que não há mais componentes semelhantes à difusão em algum espaço latente de pensamento. Parece bem 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 ao impulso de fazer uma busca secundária no treinamento de nanochat com difusão.