Điều kỳ lạ nhất là: tôi không có bất kỳ nền tảng nào về học máy, không biết quy trình tiêu chuẩn để huấn luyện mô hình, cũng không hiểu rõ nhiều chi tiết kỹ thuật. Những gì tôi làm cơ bản chỉ là liên tục đưa yêu cầu và phản hồi kết quả cho Sol, để nó tự mình tìm ra vấn đề, thiết kế thí nghiệm và liên tục lặp lại.

Tác giả bài viết: Anshu

Bài dịch, nguồn: ME News

Đây là lần đầu tiên tôi thực sự có cảm giác “AGI dường như đã đến”.

Tôi đã huấn luyện một mô hình tự động sửa lỗi riêng của mình bằng GPT-5.6 Sol. Cuối cùng, mô hình địa phương chỉ với 1,7 tỷ tham số này đã có hiệu suất略微 vượt trội hơn GPT-5.6 Sol trên bộ kiểm tra.

Điều kỳ lạ nhất là: tôi không có bất kỳ nền tảng nào về học máy, không biết quy trình tiêu chuẩn để huấn luyện mô hình, cũng không hiểu rõ nhiều chi tiết kỹ thuật. Những gì tôi làm cơ bản chỉ là liên tục đưa yêu cầu và phản hồi kết quả cho Sol, để nó tự mình tìm ra vấn đề, thiết kế thí nghiệm và liên tục lặp lại.

Toàn bộ quá trình không tốn bất kỳ chi phí nào.

Tất cả bắt nguồn từ một “vấn đề gõ phím” ngày càng nghiêm trọng

Sau khi trò chuyện lâu dài với AI, tôi nhận thấy kỹ năng gõ phím của mình ngày càng kém đi.

Tôi đã quen với việc gõ nhanh và không còn kiểm tra kỹ lỗi chính tả, thứ tự chữ cái hay thiếu chữ. Thay vì tái đào tạo kỹ năng gõ phím của mình, tôi quyết định áp dụng một giải pháp phù hợp hơn với thời đại AI: tiếp tục dùng thêm AI để giải quyết vấn đề.

Sửa lỗi tự động truyền thống sẽ liên tục chỉnh sửa văn bản trong quá trình nhập, dễ làm gián đoạn tư duy. Ý tưởng của tôi là cho phép người dùng nhập nhanh mà không bị làm phiền, dù có nhiều lỗi, và sau khi nhập xong, AI sẽ dọn dẹp tất cả một lần.

Đồng thời, tôi mong muốn mô hình này nhỏ nhất có thể.

Mô hình càng nhỏ, tốc độ chạy càng nhanh, mức tiêu thụ điện năng càng thấp và càng phù hợp để chạy hoàn toàn tại địa phương. Dù vì hiệu suất, thời lượng pin, hay chỉ đơn thuần vì sự tò mò thử nghiệm, tôi đều muốn xem: một mô hình địa phương đủ nhỏ có thể thực hiện khả năng tự sửa lỗi đến mức nào.

Vì vậy, tôi quyết định tự huấn luyện một cái.

让 Sol 成为一名自动做实验的研究员

Ý tưởng cho dự án này đến từ thí nghiệm “autoresearch” của Andrej Karpathy.

Tôi đã thiết kế một luồng công việc lặp lại cho Sol thông qua chế độ /goal của Codex:

Chọn một thí nghiệm, thực hiện thí nghiệm và ghi lại kết quả vào tài liệu; nếu thất bại, hãy từ bỏ hướng này; sau đó lên kế hoạch cho thí nghiệm tiếp theo, đồng thời tránh lặp lại những lỗi đã được xác minh.

Tôi chỉ cung cấp một vài mẫu đầu vào bắt buộc phải vượt qua, mục tiêu độ trễ nghiêm ngặt và hiệu quả cuối cùng mong muốn, sau đó để Sol tự chạy.

Điều xảy ra tiếp theo vượt quá mong đợi của tôi.

Sol đã tìm kiếm và so sánh nhiều mô hình nền tảng ứng cử viên, bao gồm Qwen 3.5, Gemma 4 và Liquid LFM 2.5. Sau đó, nó tìm thấy một bộ dữ liệu liên quan đến văn bản gõ thật trên Hugging Face.

Nhưng dữ liệu thực tế vẫn chưa đủ.

Để tạo ra các lỗi chính tả gần với đầu vào thực tế của người dùng, Sol đã viết một trình mô phỏng “gõ phím Mac bằng ngón tay”. Nó mô phỏng điểm rơi của ngón tay dựa trên bố cục vật lý của bàn phím bằng phân phối Gauss, và tạo ra nhiều lỗi phổ biến như:

Nhấn vào các phím liền kề;
Letters reversed;
重复输入；
Missing characters;
Đồng thời chạm vào nhiều phím bằng ngón tay.

Sau khi có mô hình cơ sở, dữ liệu văn bản và trình mô phỏng lỗi bàn phím, Sol đã tinh chỉnh trực tiếp trên MacBook của tôi bằng MLX.

Trong chưa đầy một giờ, nó đã tạo ra bản mẫu có thể vận hành.

Vấn đề là độ chính xác của phiên bản đầu tiên không lý tưởng.

Rào cản đầu tiên: Tokenizer không hiểu được lỗi chính tả

Sol đã đọc các bài báo liên quan và thiết kế một loạt các bài kiểm tra, cuối cùng kết luận: điểm nghẽn chính của mô hình không nằm ở dữ liệu huấn luyện, mà ở Tokenizer, tức là bộ phân từ.

Các mô hình ngôn ngữ lớn thường không hiểu văn bản từng ký tự một, mà trước tiên sẽ chia văn bản thành các Token. Các từ bình thường có thể được phân tách thành các đơn vị ngữ nghĩa ổn định, nhưng các lỗi chính tả thường phá vỡ cấu trúc Token ban đầu.

Điều này có nghĩa là một lỗi đánh chữ rất rõ ràng đối với con người có thể trở thành một bộ token hoàn toàn xa lạ trong mắt mô hình.

Mô hình khó có thể thực sự “hiểu” lỗi, mà chỉ có thể ghi nhớ máy móc mối quan hệ ánh xạ giữa cách viết sai và cách viết đúng. Cách làm này không chỉ có khả năng khái quát kém, mà còn không thể tận dụng tối đa kiến thức ngôn ngữ sẵn có của mô hình.

Sol đã thử đầu tiên ByT5 của Google.

ByT5 là một mô hình không phụ thuộc vào Tokenizer truyền thống, mà xử lý trực tiếp các chuỗi byte. Nỗ lực này mang lại sự cải thiện rõ rệt, nhưng do ByT5 được phát hành khá sớm và bản thân mô hình có kiến thức ngôn ngữ hạn chế, hiệu suất cuối cùng vẫn không thể đạt đến mức của GPT-5.6 Sol.

Sau khi nghiên cứu thêm, Sol nhận ra rằng vấn đề không nhất thiết phải được giải quyết bằng cách “hủy bỏ hoàn toàn Tokenizer”.

Nó đã chọn T5Gemma, một mô hình có kiến trúc Encoder-Decoder.

Khác với các mô hình chỉ dự đoán token tiếp theo, mô hình Encoder-Decoder có thể sử dụng bộ mã hóa để hiểu đầy đủ đầu vào, sau đó bộ giải mã tạo ra văn bản đã được sửa đổi. Quan trọng hơn, Sol còn có thể tiếp tục huấn luyện sau cho bộ mã hóa, giúp mô hình nhận diện tốt hơn các đầu vào chứa lỗi chính tả.

This route significantly raises the model's performance ceiling.

Rào cản thứ hai: Hàm mất mát truyền thống khuyến khích mô hình “không sửa đổi”

Sau khi thay đổi kiến trúc mô hình, một vấn đề mới đã xuất hiện.

Mô hình đã có thể sửa chính xác một số lỗi, nhưng thường bỏ qua các vấn đề chính tả rõ ràng khác. Ngay cả khi có lỗi trong đầu vào, nó vẫn có xu hướng sao chép nguyên bản.

Sol cuối cùng phát hiện ra rằng vấn đề đến từ hàm tổn thất entropy chéo phổ biến nhất.

Trong dữ liệu tự sửa lỗi, phần lớn ký tự vốn đã đúng, tỷ lệ ký tự thực sự cần sửa đổi chỉ chiếm một phần rất nhỏ. Nếu huấn luyện trực tiếp bằng cross-entropy tiêu chuẩn, chiến lược an toàn nhất của mô hình sẽ là “cố gắng đừng sửa gì cả”.

Vì sao sao chép nguyên văn có thể mang lại câu trả lời chính xác ở hầu hết các vị trí, trong khi sửa đổi chủ động lại có thể gây ra lỗi.

Nói cách khác, các mục tiêu đào tạo truyền thống đang thưởng cho mô hình duy trì trạng thái không đổi.

Để giải quyết vấn đề này, Sol đã viết một hàm tổn thất tùy chỉnh.

Nó đầu tiên căn chỉnh văn bản gốc với văn bản đích ở cấp độ byte, sau đó sử dụng thuật toán lập trình động để tính toán đường dẫn chỉnh sửa tối thiểu giữa hai đoạn văn bản, xác định những vị trí nào thuộc về bản sao, những vị trí nào là chèn, xóa hoặc thay thế thực sự.

Trên cơ sở này, Sol đã tăng đáng kể trọng số huấn luyện tương ứng với việc “sửa đúng”, đồng thời giảm lợi ích mang lại từ việc sao chép ký tự đơn thuần.

Sau nhiều vòng điều chỉnh tham số, độ chính xác sửa lỗi của mô hình đã tăng đáng kể.

Rào cản thứ ba: Một khi mô hình đi sai, không thể quay lại

Vấn đề chính cuối cùng đến từ cơ chế sinh tự hồi quy.

Mô hình khi tạo văn bản chỉ có thể dự đoán token tiếp theo dựa trên nội dung đã được tạo ra trước đó. Một khi có sai sót ở bất kỳ bước nào trước đó, các bước tiếp theo sẽ được xây dựng trên kết quả sai lệch, và mô hình không thể quay lại sửa đổi thực sự.

Về mặt lý thuyết, có thể huấn luyện mô hình để “suy nghĩ” trước khi trả lời, giống như mô hình suy luận, nhưng điều này sẽ làm tăng đáng kể độ trễ và không phù hợp với các tình huống tự động sửa lỗi yêu cầu phản hồi tức thì.

Sol cuối cùng đã tìm ra một giải pháp tinh tế hơn: Beam Search, hay còn gọi là tìm kiếm束.

Mô hình không còn chỉ chọn một đường dẫn duy nhất có xác suất cao nhất tại từng bước, mà đồng thời giữ lại nhiều nhánh sinh có thể, khám phá song song các kết quả sửa lỗi khác nhau. Sau khi kết thúc tìm kiếm, đường dẫn hoàn chỉnh có xác suất logarit tích lũy cao nhất sẽ được chọn.

Điều này tương đương với việc thay thế suy luận đơn luồng bằng tìm kiếm song song.

Beam Search rõ ràng đã cải thiện đáng kể kết quả cuối cùng, nhưng cũng gây ra một vấn đề về trải nghiệm: người dùng không thấy bất kỳ đầu ra nào cho đến khi quá trình tìm kiếm hoàn tất.

Sol sau đó đã đưa ra một quan sát rất thông minh.

Sau mỗi vòng tìm kiếm, có thể so sánh tất cả các nhánh đang được giữ lại. Chỉ cần các nhánh này có cùng phần đầu, thì đoạn “tiền tố chung dài nhất” này chắc chắn sẽ xuất hiện trong kết quả cuối cùng.

Do đó, hệ thống có thể hiển thị ngay nội dung này cho người dùng.

Trong quá trình tìm kiếm liên tục, các nhánh yếu dần bị loại bỏ, tiền tố chung của các nhánh còn lại cũng ngày càng dài hơn. Cuối cùng, người dùng không thấy kết quả xuất hiện đột ngột một lần, mà là văn bản sửa lỗi được tạo ra liên tục.

Sol đã biến toàn bộ quy trình thành một đường ống suy luận MLX tùy chỉnh, sử dụng GPU MacBook để giải mã song song.

Cuối cùng, độ trễ đầu tiên của token chỉ khoảng 40 miligiây, đủ nhanh và toàn bộ quá trình được thực hiện hoàn toàn tại chỗ.

Kết quả cuối cùng: Mô hình 1,7 tỷ tham số vượt qua GPT-5.6 Sol

The final evaluation uses "error reduction rate" as the metric; the higher the value, the more input errors the model has corrected.

Kết quả đánh giá như sau:

Apple tự động sửa lỗi: 49.66%
GPT-5.6 Luna: 82.47%
GPT-5.6 Terra: 87,64%
GPT-5.6 Sol: 90.56%
Mô hình 1,7 tỷ tham số mà chúng tôi đã huấn luyện: 91,02%

Mô hình cục bộ nhỏ này cuối cùng đã vượt qua GPT-5.6 Sol với lợi thế rất nhỏ.

Tôi cũng đã kiểm tra kỹ lưỡng để đảm bảo không có rò rỉ dữ liệu hay hành vi “gian lận” của mô hình. Trong quá trình kiểm tra, chúng tôi chủ động loại bỏ các từ xuất hiện trong dữ liệu huấn luyện, nhằm xác minh rằng mô hình không chỉ đơn thuần ghi nhớ máy móc mối quan hệ giữa lỗi và câu trả lời.

Tổng chi phí của toàn bộ dự án là:

Một lần đặt lại hạn mức mô hình và chi tiêu tiền mặt 0 USD.

Điều thực sự khiến tôi kinh ngạc không chỉ là điểm số cuối cùng

Trong quá trình dự án, còn có rất nhiều thí nghiệm chưa được triển khai, bao gồm các hướng khác nhau như học so sánh, GRPO, DPO, che khuất động, v.v.

Không phải mọi nỗ lực đều thành công, nhưng Sol có thể chủ động đọc tài liệu, xác định vấn đề, đưa ra giả thuyết, thiết kế thí nghiệm, phân tích kết quả, và dựa trên kinh nghiệm thất bại để lên kế hoạch cho lần thử nghiệm tiếp theo.

Đối với tôi, điều thực sự gây ấn tượng không phải là việc “một mô hình 1,7 tỷ tham số đã vượt qua GPT-5.6 Sol”.

Hơn nữa, một người hoàn toàn không có nền tảng học máy giờ đây đã có thể sử dụng AI để thực hiện các quy trình thí nghiệm trước đây cần đến đội ngũ nghiên cứu chuyên nghiệp.

Tôi không nắm vững tất cả các kiến thức nền tảng, cũng không thiết kế sẵn một lộ trình kỹ thuật hoàn chỉnh. Tôi chỉ rõ ràng mình muốn giải quyết vấn đề gì, sau đó không ngừng thúc đẩy Sol tiếp tục tìm kiếm câu trả lời.

Nó không chỉ viết mã mà còn đảm nhận vai trò của nhà nghiên cứu, kỹ sư và người thiết kế thí nghiệm.

Đây có thể là khoảnh khắc đầu tiên tôi thực sự “cảm nhận được AGI”.

Đừng để sự thiếu kinh nghiệm ngăn cản bạn bắt đầu thử nghiệm.

Khi AI có thể giúp người bình thường vượt qua rào cản chuyên môn, nhiều dự án công nghệ trước đây dường như không thể với tới có thể đã không còn xa vời nữa.