Вчера вечером я научил nanochat d32 считать букву 'r' в слове strawberry (или в подобных вариантах). Я подумал, что это будет хорошим/веселым примером того, как добавить возможности в nanochat, и я написал полный гид здесь: Это делается с помощью новой синтетической задачи `SpellingBee`, которая генерирует примеры того, как пользователь задает подобную задачу, и идеальное решение от помощника. Затем мы проводим промежуточное обучение/SFT на этих примерах, чтобы наделить LLM этой способностью, или продолжаем обучение с помощью RL, чтобы сделать его более устойчивым. Есть много деталей, которые нужно учесть, особенно для меньших моделей, и гид проходит через них. В качестве краткого обзора: - Вы должны обеспечить разнообразие в запросах/вопросах пользователей - Для небольших моделей, таких как nanochat, особенно важно быть очень внимательным к деталям токенизации, чтобы сделать задачу легкой для LLM. В частности, нужно быть осторожным с пробелами, а затем распределить вычисление рассуждений по многим токенам частичного решения: сначала мы стандартизируем слово в кавычках, затем мы его произносим (чтобы разбить токены), затем мы итеративно продолжаем и ведем явный счетчик и т.д. - Я поощряю модель решать задачу двумя отдельными способами: вручную (умственная арифметика в голове) и также с помощью инструмента Python интерпретатора, к которому имеет доступ nanochat. Это немного "дым и зеркала", потому что каждое решение на данный момент "чистое", без ошибок. Можно либо изменить задачу, чтобы смоделировать ошибки и продемонстрировать восстановление на примере, либо запустить RL. Скорее всего, комбинация обоих методов будет работать лучше, где первый будет служить приоритетом для RL и даст ему материалы для работы. Если бы nanochat была гораздо большей моделью, вы бы ожидали или надеялись, что эта способность "всплывет" в какой-то момент. Но поскольку "мозг" nanochat d32 размером с ~пчелу, если мы хотим, чтобы он считал буквы r в слове strawberry, нам нужно сделать это, чрезмерно представляя его в данных, чтобы побудить модель выучить это раньше. Но это работает! :)

Мне довольно нравится новая работа DeepSeek-OCR. Это хорошая модель OCR (возможно, немного хуже, чем dots), и да, сбор данных и т.д., но в любом случае это не имеет значения. Более интересная часть для меня (особенно как для человека, который по сути является специалистом по компьютерному зрению и временно маскируется под специалиста по естественному языку) заключается в том, являются ли пиксели лучшими входными данными для LLM, чем текст. Являются ли текстовые токены расточительными и просто ужасными на входе. Возможно, имеет больше смысла, что все входные данные для LLM должны быть только изображениями. Даже если у вас есть чистый текстовый ввод, возможно, вы предпочли бы отобразить его, а затем подать это: - больше сжатия информации (см. статью) => более короткие контекстные окна, больше эффективности - значительно более общий поток информации => не только текст, но, например, жирный текст, цветной текст, произвольные изображения. - ввод теперь можно обрабатывать с двунаправленным вниманием легко и по умолчанию, а не с авторегрессионным вниманием - это гораздо более мощно. - удалить токенизатор (на входе)!! Я уже высказывался о том, как сильно я не люблю токенизатор. Токенизаторы уродливы, отдельны, не являются этапом end-to-end. Он "импортирует" всю уродливость Unicode, байтовых кодировок, наследует много исторического багажа, рисков безопасности/взлома (например, байты продолжения). Он делает так, что два символа, которые выглядят идентично для глаза, выглядят как два совершенно разных токена внутри сети. Улыбающийся эмодзи выглядит как странный токен, а не как... настоящая улыбающаяся мордочка, пиксели и все такое, и все обучение с переносом, которое это приносит. Токенизатор должен уйти. OCR - это всего лишь одна из многих полезных задач преобразования изображения в текст. А задачи преобразования текста в текст могут быть преобразованы в задачи преобразования изображения в текст. Не наоборот. Так что многие сообщения пользователей - это изображения, но декодер (ответ Ассистента) остается текстом. Намного менее очевидно, как реалистично выводить пиксели... или хотите ли вы этого. Теперь мне также нужно бороться с желанием создать версию nanochat только с вводом изображений...

Хороший, короткий пост, иллюстрирующий, насколько простым может быть текстовое (дискретное) диффузионное моделирование. Диффузия (т.е. параллельное, итеративное денойзинг, топ) является повсеместной генеративной парадигмой в изображениях/видео, но автогрессия (т.е. движение слева направо, снизу вверх) является доминирующей парадигмой в тексте. Что касается аудио, я видел немного того и другого. Много диффузионных статей выглядят довольно сложными, но если убрать математический формализм, вы получите простые базовые алгоритмы, например, что-то гораздо ближе к сопоставлению потоков в непрерывном, или что-то подобное в дискретном. Это ваш ванильный трансформер, но с двунаправленным вниманием, где вы итеративно повторно выбираете и повторно маскируете все токены в вашем "канвасе токенов" на основе графика шума, пока не получите финальный образец на последнем шаге. (Двунаправленное внимание гораздо мощнее, и вы получаете гораздо более сильные автогрессивные языковые модели, если обучаете с ним, к сожалению, это делает обучение гораздо более дорогим, потому что теперь вы не можете параллелить по размерности последовательности). Таким образом, автогрессия выполняет `.append(token)` к канвасу токенов, в то время как диффузия обновляет весь канвас токенов с помощью `.setitem(idx, token)`, одновременно обращая внимание в обе стороны. Человеческое мышление наивно кажется немного более похожим на автогрессию, но трудно сказать, что в некотором скрытом пространстве мышления нет более диффузионных компонентов. Кажется вполне возможным, что вы можете дополнительно интерполировать между ними или обобщить их дальше. И это компонент стека LLM, который все еще кажется немного изменчивым. Теперь я должен сопротивляться искушению уйти в сторону и заняться обучением nanochat с помощью диффузии.