Tadi malam saya mengajari nanochat d32 cara menghitung 'r' dalam stroberi (atau variasi serupa). Saya pikir ini akan menjadi contoh yang bagus/menyenangkan tentang cara menambahkan kemampuan ke nanochat dan saya menulis panduan lengkap di sini: Ini dilakukan melalui tugas sintetis baru 'SpellingBee' yang menghasilkan contoh pengguna yang meminta masalah semacam ini, dan solusi ideal dari asisten. Kami kemudian menyempurnakan ini untuk memberikan kemampuan LLM, atau melatih lebih lanjut dengan RL untuk membuatnya lebih kuat. Ada banyak detail yang harus diperbaiki, terutama pada ukuran model yang lebih kecil dan panduan melangkahnya. Sebagai gambaran singkat: - Anda harus memastikan keragaman dalam perintah/kueri pengguna - Untuk model kecil seperti nanochat khususnya, Anda harus benar-benar berhati-hati dengan detail tokenisasi untuk memudahkan tugas LLM. Secara khusus, Anda harus berhati-hati dengan spasi kosong, dan kemudian Anda harus menyebarkan perhitungan penalaran di banyak token solusi parsial: pertama kita menstandarkan kata menjadi tanda kutip, kemudian kita mengejanya (untuk memecah token), kemudian kita mengulangi dan menyimpan penghitung eksplisit, dll. - Saya mendorong model untuk memecahkan model dengan dua cara terpisah: cara manual (aritmatika mental di kepalanya) dan juga melalui penggunaan alat penerjemah Python yang dapat diakses oleh nanochat. Ini sedikit "asap dan cermin" karena setiap solusi atm "bersih", tanpa kesalahan. Seseorang dapat menyesuaikan tugas untuk mensimulasikan kesalahan dan mendemonstrasikan pemulihan dengan contoh, atau menjalankan RL. Kemungkinan besar, kombinasi keduanya bekerja paling baik, di mana yang pertama bertindak sebagai pendahulu untuk RL dan memberinya hal-hal untuk dikerjakan. Jika nanochat adalah model yang jauh lebih besar, Anda akan mengharapkan atau berharap kemampuan ini lebih mudah "muncul" di beberapa titik. Tetapi karena nanochat d32 "otak" adalah ukuran ~lebah madu, jika kita ingin menghitung r dalam stroberi, kita harus melakukannya dengan merepresentasikannya secara berlebihan dalam data, untuk mendorong model mempelajarinya lebih awal. Tapi itu berhasil! :)

Saya cukup menyukai makalah DeepSeek-OCR baru. Ini adalah model OCR yang bagus (mungkin sedikit lebih buruk dari titik), dan ya pengumpulan data dll., Tapi bagaimanapun itu tidak masalah. Bagian yang lebih menarik bagi saya (terutama sebagai visi komputer di hati yang untuk sementara menyamar sebagai orang bahasa alami) adalah apakah piksel adalah input yang lebih baik untuk LLM daripada teks. Apakah token teks boros dan mengerikan, pada input. Mungkin lebih masuk akal bahwa semua input ke LLM hanya boleh berupa gambar. Bahkan jika Anda kebetulan memiliki input teks murni, mungkin Anda lebih suka merendernya dan kemudian memasukkannya: - Kompresi informasi lebih banyak (lihat makalah) => jendela konteks yang lebih pendek, lebih efisiensi - aliran informasi yang jauh lebih umum => bukan hanya teks, tetapi misalnya teks tebal, teks berwarna, gambar sewenang-wenang. - Input sekarang dapat diproses dengan perhatian dua arah dengan mudah dan sebagai default, bukan perhatian regresif otomatis - jauh lebih kuat. - hapus tokenizer (di input)!! Saya sudah mengoceh tentang betapa saya tidak menyukai tokenizer. Tokenizer jelek, terpisah, bukan tahap ujung ke ujung. Ini "mengimpor" semua keburukan Unicode, pengkodean byte, mewarisi banyak bagasi historis, risiko keamanan/jailbreak (misalnya byte kelanjutan). Itu membuat dua karakter yang terlihat identik dengan mata terlihat sebagai dua token yang sama sekali berbeda secara internal dalam jaringan. Emoji tersenyum terlihat seperti token aneh, bukan... wajah tersenyum yang sebenarnya, piksel dan semuanya, dan semua pembelajaran transfer yang dibawa. Tokenizer harus pergi. OCR hanyalah salah satu dari banyak tugas teks > visi yang berguna. Dan tugas teks -> teks dapat dibuat menjadi tugas visi->teks. Tidak sebaliknya. Begitu banyak pesan Pengguna adalah gambar, tetapi dekoder (respons Asisten) tetap teks. Jauh lebih jelas bagaimana menghasilkan piksel secara realistis... atau jika Anda mau. Sekarang saya juga harus melawan keinginan untuk mencari sampingan versi nanochat khusus input gambar...

Bagus dan singkat posting yang menggambarkan betapa sederhananya difusi teks (diskrit). Difusi (yaitu paralel, denoise berulang, atas) adalah paradigma generatif yang meresap dalam gambar/video, tetapi autoregresi (yaitu pergi ke kiri ke kanan bawah) adalah paradigma dominan dalam teks. Untuk audio saya telah melihat sedikit dari keduanya. Banyak makalah difusi terlihat agak padat tetapi jika Anda melucuti formalisme matematika, Anda berakhir dengan algoritma dasar sederhana, misalnya sesuatu yang jauh lebih dekat dengan pencocokan aliran dalam kontinu, atau sesuatu seperti ini dalam diskrit. Ini adalah transformator vanilla Anda tetapi dengan perhatian dua arah, di mana Anda secara berulang mengambil sampel ulang dan menutupi ulang semua token di "kanvas token" Anda berdasarkan jadwal kebisingan sampai Anda mendapatkan sampel akhir pada langkah terakhir. (Perhatian dua arah jauh lebih kuat, dan Anda mendapatkan model bahasa regresif otomatis yang jauh lebih kuat jika Anda berlatih dengannya, sayangnya itu membuat pelatihan jauh lebih mahal karena sekarang Anda tidak dapat menyejajarkan merentasi redup urutan). Jadi regresi otomatis melakukan '.append(token)' ke kanvas token sambil hanya menghadiri mundur, sementara difusi menyegarkan seluruh kanvas token dengan '.setitem(idx, token)' saat menghadiri dua arah. Pikiran manusia secara naif terasa sedikit lebih seperti autoregresi tetapi sulit untuk mengatakan bahwa tidak ada lebih banyak komponen seperti difusi dalam beberapa ruang berpikir laten. Rasanya sangat mungkin bahwa Anda dapat menginterpolasi lebih lanjut di antara mereka, atau menggeneralisasikannya lebih lanjut. Dan itu adalah komponen dari tumpukan LLM yang masih terasa sedikit dapat dipertukarkan. Sekarang saya harus menahan keinginan untuk misi sampingan ke dalam pelatihan nanochat dengan difusi.