Вчора ввечері я навчив nanochat d32 рахувати 'r' у полуниці (або подібних варіаціях). Я подумав, що це буде хорошим/цікавим прикладом того, як додати можливості до наночату, і я написав повний посібник тут: Це робиться за допомогою нового синтетичного завдання «SpellingBee», яке генерує приклади користувачів, які просять про такого роду проблеми, і ідеальне рішення від помічника. Потім ми вдосконалюємо їх midtrain/SFT, щоб наділити LLM можливостями, або продовжуємо тренуватися з RL, щоб зробити його більш надійним. Є багато деталей, які потрібно виправити, особливо при невеликих розмірах моделей, і керівництво проходить через них. В якості короткого огляду: - Ви повинні забезпечити різноманітність підказок/запитів користувачів - Особливо для невеликих моделей, таких як наночат, ви повинні бути дуже обережні з деталями токенізації, щоб полегшити завдання для LLM. Зокрема, вам потрібно бути обережним з пробілами, а потім вам доведеться розподілити обчислення міркувань на багато лексем часткового рішення: спочатку ми стандартизуємо слово в лапки, потім ми вимовляємо його (щоб розбити лексеми), потім ми перебираємо та зберігаємо явний лічильник тощо. - Я заохочую модель розв'язувати модель двома окремими способами: ручним способом (ментальна арифметика в голові), а також за допомогою інструментального використання інтерпретатора Python, до якого має доступ наночат. Це трохи «дим і дзеркала», тому що кожне рішення банкомат «чистий», без помилок. Можна було або коригувати завдання, щоб імітувати помилки та демонструвати відновлення на прикладі, або запускати РЛ. Швидше за все, найкраще працює комбінація обох, де перший виступає в ролі пріора для РЛ і дає йому можливості для роботи. Якби наночат був набагато більшою моделлю, ви б очікували або сподівалися, що ця можливість легше «вискочить» у якийсь момент. Але оскільки "мозок" nanochat d32 розміром з ~медоносну бджолу, якщо ми хочемо, щоб він рахував r у полуниці, ми повинні зробити це, надмірно представляючи це в даних, щоб заохотити модель вивчити це раніше. Але це працює! :)

Мені дуже подобається новий папір DeepSeek-OCR. Це хороша модель OCR (можливо, трохи гірша за точки), і так, збір даних тощо, але в будь-якому випадку це не має значення. Найцікавіша частина для мене (особливо як для комп'ютерного зору в душі, який тимчасово маскується під людину з природною мовою) полягає в тому, чи є пікселі кращими вхідними даними для LLM, ніж текст. Чи то текстові токени марнотратні і просто жахливі, на вході. Можливо, має сенс те, що всі вхідні дані для LLM повинні бути лише зображеннями. Навіть якщо у вас є чисте введення тексту, можливо, ви віддаєте перевагу його рендерингу, а потім вводити це: - більше стиснення інформації (див. статтю) => коротші контекстні вікна, більша ефективність - значно більше загального потоку інформації = > не просто текст, але, наприклад, жирний текст, кольоровий текст, довільні зображення. - Вхідні дані тепер можуть бути легко оброблені за допомогою двонаправленої уваги і, за замовчуванням, не авторегресивної уваги - набагато потужніше. - видалити токенізатор (на вході)!! Я вже бурчав про те, як сильно мені не подобається токенізатор. Токенізатори – це негарна, окрема, а не наскрізна стадія. Він "імпортує" всю потворність Юнікоду, байтові кодування, він успадковує багато історичного багажу, ризику безпеки/джейлбрейка (наприклад, байти продовження). Це змушує двох символів, які виглядають ідентично оку, виглядати як два абсолютно різні токени всередині мережі. Усміхнений смайлик виглядає як дивний жетон, а не... Справжнє усміхнене обличчя, пікселі та все інше, а також усе навчання передачі, яке приносить із собою. Токенізатор повинен піти. OCR – це лише одне з багатьох корисних завдань із зору > тексту. А текстові -> текстові завдання можна зробити візіонерськими ->текстовими завданнями. А не навпаки. Дуже багато повідомлень Користувача є зображеннями, але декодер (відповідь Асистента) залишається текстом. Набагато менш очевидно, як реалістично виводити пікселі... або якщо ви цього хочете. Тепер мені також доводиться боротися з бажанням знайти версію наночату лише з введенням зображень...

Гарний короткий пост, який ілюструє, наскільки простим може бути текстовий (дискретний) дифузія. Дифузія (тобто паралельне, повторюване знешумлення, зверху) є поширеною генеративною парадигмою в зображенні/відео, але авторегресія (тобто перехід зліва направо вниз) є домінуючою парадигмою в тексті. Що стосується аудіо, я бачив потроху і те, і інше. Багато дифузійних паперів виглядають трохи щільними, але якщо ви відкинете математичний формалізм, ви отримаєте прості базові алгоритми, наприклад, щось набагато ближче до узгодження потоку в безперервному, або щось подібне до цього в дискретному. Це ваш ванільний трансформатор, але з двосторонньою увагою, де ви ітеративно повторно відбираєте та маскуєте всі токени у вашому «полотні токенів» на основі шумового графіка, доки не отримаєте остаточний зразок на останньому кроці. (Двонаправлена увага набагато потужніша, і ви отримуєте набагато сильніші авторегресійні мовні моделі, якщо тренуєтеся з нею, на жаль, це робить навчання набагато дорожчим, тому що тепер ви не можете розпаралелювати послідовності тьмяними). Таким чином, авторегресія виконує '.append(token)' до полотна токенів, при цьому спостерігаючи лише у зворотному напрямку, тоді як дифузія оновлює все полотно токена '.setitem(idx, token)' при двонаправленому відвідуванні. Людське мислення наївно більше схоже на авторегресію, але важко сказати, що в якомусь латентному просторі думки немає більше дифузійних компонентів. Цілком можливо, що ви можете ще більше інтерполювати між ними, або узагальнити їх далі. І це компонент стека LLM, який все ще здається трохи взаємозамінним. Тепер я повинен чинити опір спокусі піти на другий план у тренувальний наночат з дифузією.