Tối qua, tôi đã dạy nanochat d32 cách đếm chữ 'r' trong từ dâu tây (hoặc các biến thể tương tự). Tôi nghĩ đây sẽ là một ví dụ tốt/vui về cách thêm khả năng cho nanochat và tôi đã viết một hướng dẫn đầy đủ ở đây: Điều này được thực hiện thông qua một nhiệm vụ tổng hợp mới `SpellingBee` tạo ra các ví dụ về một người dùng yêu cầu loại vấn đề này, và một giải pháp lý tưởng từ một trợ lý. Sau đó, chúng tôi sẽ huấn luyện giữa/finetune SFT trên những điều này để trang bị cho LLM khả năng, hoặc huấn luyện thêm với RL để làm cho nó mạnh mẽ hơn. Có nhiều chi tiết cần phải chính xác, đặc biệt là ở các kích thước mô hình nhỏ hơn và hướng dẫn sẽ đi qua chúng. Như một cái nhìn tổng quan ngắn gọn: - Bạn phải đảm bảo sự đa dạng trong các lời nhắc/yêu cầu của người dùng - Đối với các mô hình nhỏ như nanochat, đặc biệt, bạn phải rất cẩn thận với các chi tiết phân tách từ để làm cho nhiệm vụ dễ dàng cho LLM. Cụ thể, bạn phải cẩn thận với khoảng trắng, và sau đó bạn phải phân bổ việc tính toán lý luận qua nhiều token của giải pháp một phần: trước tiên chúng tôi chuẩn hóa từ vào dấu ngoặc kép, sau đó chúng tôi đánh vần nó (để phân tách các token), sau đó chúng tôi lặp lại và giữ một bộ đếm rõ ràng, v.v. - Tôi đang khuyến khích mô hình giải quyết mô hình theo hai cách riêng biệt: một cách thủ công (tính toán trong đầu) và cũng thông qua việc sử dụng công cụ của trình thông dịch Python mà nanochat có quyền truy cập. Điều này có chút "khói và gương" vì mọi giải pháp hiện tại đều "sạch", không có sai sót. Một người có thể điều chỉnh nhiệm vụ để mô phỏng sai sót và chứng minh sự phục hồi bằng ví dụ, hoặc chạy RL. Có khả năng, sự kết hợp của cả hai sẽ hoạt động tốt nhất, trong đó cái trước đóng vai trò là prior cho RL và cung cấp cho nó những thứ để làm việc. Nếu nanochat là một mô hình lớn hơn nhiều, bạn sẽ mong đợi hoặc hy vọng khả năng này sẽ dễ dàng "nổi bật" vào một thời điểm nào đó. Nhưng vì "bộ não" của nanochat d32 có kích thước như một ~con ong mật, nếu chúng tôi muốn nó đếm chữ r trong từ dâu tây, chúng tôi phải làm điều đó bằng cách đại diện quá mức trong dữ liệu, để khuyến khích mô hình học nó sớm hơn. Nhưng nó hoạt động! :)

Tôi khá thích bài báo mới về DeepSeek-OCR. Đây là một mô hình OCR tốt (có thể kém hơn một chút so với dots), và đúng là việc thu thập dữ liệu v.v., nhưng dù sao thì điều đó không quan trọng. Phần thú vị hơn đối với tôi (đặc biệt là một người yêu thích thị giác máy tính nhưng tạm thời giả vờ là một người ngôn ngữ tự nhiên) là liệu pixel có phải là đầu vào tốt hơn cho LLM so với văn bản hay không. Liệu các token văn bản có lãng phí và thật tệ ở đầu vào hay không. Có thể hợp lý hơn nếu tất cả các đầu vào cho LLM chỉ nên là hình ảnh. Ngay cả khi bạn có đầu vào văn bản thuần túy, có thể bạn sẽ thích việc render nó và sau đó đưa vào: - nén thông tin nhiều hơn (xem bài báo) => cửa sổ ngữ cảnh ngắn hơn, hiệu quả hơn - dòng thông tin tổng quát hơn đáng kể => không chỉ văn bản, mà ví dụ như văn bản in đậm, văn bản màu, hình ảnh tùy ý. - đầu vào giờ đây có thể được xử lý dễ dàng với sự chú ý hai chiều và như mặc định, không phải là sự chú ý tự hồi quy - mạnh mẽ hơn rất nhiều. - xóa bỏ bộ phân tách (ở đầu vào)!! Tôi đã từng phàn nàn về việc tôi không thích bộ phân tách. Các bộ phân tách thật xấu xí, tách biệt, không phải là giai đoạn end-to-end. Nó "nhập khẩu" tất cả sự xấu xí của Unicode, mã byte, nó thừa hưởng rất nhiều gánh nặng lịch sử, rủi ro bảo mật/thoát hiểm (ví dụ: byte tiếp tục). Nó làm cho hai ký tự trông giống hệt nhau với mắt lại trông như hai token hoàn toàn khác nhau bên trong mạng. Một emoji cười trông như một token kỳ lạ, không phải là... một khuôn mặt cười thực sự, pixel và tất cả, và tất cả việc học chuyển giao mà nó mang theo. Bộ phân tách phải biến mất. OCR chỉ là một trong nhiều nhiệm vụ hữu ích từ thị giác -> văn bản. Và các nhiệm vụ văn bản -> văn bản có thể được biến thành các nhiệm vụ thị giác -> văn bản. Không phải ngược lại. Vậy nên nhiều thông điệp người dùng là hình ảnh, nhưng bộ giải mã (phản hồi của Trợ lý) vẫn là văn bản. Thật khó để xuất ra pixel một cách thực tế... hoặc nếu bạn muốn làm vậy. Bây giờ tôi cũng phải chiến đấu với sự thôi thúc để phát triển một phiên bản chỉ đầu vào hình ảnh của nanochat...

Bài viết ngắn gọn, hay minh họa cách mà sự khuếch tán văn bản (rời rạc) có thể đơn giản như thế nào. Khuếch tán (tức là, làm sạch song song, lặp lại, hàng đầu) là mô hình sinh tổng quát phổ biến trong hình ảnh/video, nhưng hồi quy tự động (tức là, đi từ trái sang phải dưới) là mô hình thống trị trong văn bản. Đối với âm thanh, tôi đã thấy một chút cả hai. Nhiều tài liệu về khuếch tán trông có vẻ dày đặc nhưng nếu bạn loại bỏ hình thức toán học, bạn sẽ có những thuật toán cơ bản đơn giản, ví dụ như cái gì đó gần gũi hơn với việc khớp dòng trong liên tục, hoặc cái gì đó như thế này trong rời rạc. Đó là transformer vani của bạn nhưng với sự chú ý hai chiều, nơi bạn lặp đi lặp lại việc lấy mẫu lại và che lại tất cả các token trong "bảng canvas token" của bạn dựa trên lịch trình tiếng ồn cho đến khi bạn có mẫu cuối cùng ở bước cuối cùng. (Sự chú ý hai chiều mạnh mẽ hơn nhiều, và bạn có được các mô hình ngôn ngữ hồi quy tự động mạnh mẽ hơn nếu bạn huấn luyện với nó, thật không may, điều này làm cho việc huấn luyện trở nên tốn kém hơn nhiều vì bây giờ bạn không thể song song hóa qua chiều chuỗi). Vì vậy, hồi quy tự động đang thực hiện một `.append(token)` vào bảng canvas token trong khi chỉ chú ý ngược lại, trong khi khuếch tán đang làm mới toàn bộ bảng canvas token với một `.setitem(idx, token)` trong khi chú ý hai chiều. Suy nghĩ của con người một cách ngây thơ cảm thấy giống như hồi quy tự động nhưng thật khó để nói rằng không có nhiều thành phần giống như khuếch tán trong một không gian tiềm ẩn của suy nghĩ. Có vẻ như có thể rằng bạn có thể nội suy thêm giữa chúng, hoặc tổng quát chúng xa hơn. Và đó là một thành phần của ngăn xếp LLM mà vẫn cảm thấy có phần linh hoạt.