Ngày 3 tháng 9, Hugging Face công bố một bản ghi huấn luyện đầy đủ: lấy một mô hình vốn để viết code, huấn luyện cho đến khi nó biết vẽ tranh màu nước. Toàn bộ quy trình không có mô hình khuếch tán, cũng không có bất kỳ thành phần sinh ảnh nào. Mô hình xuất ra một đoạn JavaScript gọi thư viện cọ vẽ p5.brush; chạy đoạn code đó, một bức tranh màu nước hiện lên trên khung vẽ.
Tác giả là Sergio Paniego, ý tưởng ban đầu đến từ Surya Narreddi. Mô hình nền được chọn là Qwen3.5-35B-A3B, huấn luyện bằng GRPO trong thư viện TRL, LoRA gắn trên toàn bộ các lớp tuyến tính, tốc độ học 5e-5, dùng bộ lập lịch constant_with_warmup. Phần thực thi code, render hình và tính điểm được đóng gói trong một môi trường OpenEnv: mô hình sinh code, môi trường chạy code đó, chụp lại màn hình rồi đưa cho bộ chấm điểm.
Trong hàm thưởng không có đúng sai, chỉ có một kho tham chiếu
Hai năm qua, những kịch bản mà học tăng cường chạy tốt trên các mô hình lớn hầu hết đều có một điểm chung: một tiêu chí tự động phân định đúng sai — toán có đáp án chuẩn, code có bài kiểm thử đơn vị. Tranh màu nước thì không có gì như vậy. Cách giải quyết trong bản ghi này là tách "đẹp hay không" thành hai tín hiệu có thể chấm điểm được.
Hàm thưởng gồm bốn thành phần. Code chạy được chiếm 0,05 điểm trọng số, độ dài code chiếm 0,05, chín phần mười còn lại chia cho hai tín hiệu thẩm mỹ: một mô hình giám khảo so sánh theo cặp, và một bộ chấm điểm ưu tiên của con người tên HPSv3. Trọng số của hai phần này hoán đổi tùy thí nghiệm: nhóm "judge-led" cho giám khảo trọng số 0,60, HPSv3 0,30; nhóm "hps-led" thì ngược lại.
Tiêu chuẩn của giám khảo đến từ một kho tham chiếu được chấm điểm thủ công, tổng cộng 178 bức tranh. Mỗi bức tranh mô hình sinh ra sẽ được so sánh với một tác phẩm lấy từ kho này. Chính kho tranh đó cũng định nghĩa thế nào là "đa dạng" — nguyên văn trong bài blog: "The pool decides what counts as variety, the same way it decides what counts as quality". Trên thực tế, 178 bức tranh này đã đóng khung giới hạn trên cho toàn bộ mục tiêu huấn luyện.
Ba lượt chạy, ba đường cong
Tác giả chạy ba nhóm thí nghiệm đối chứng. Nhóm chỉ dùng HPSv3 chấm điểm chạy 60 bước, phần thưởng trung bình tăng từ 0,58 lên 0,71; nhóm judge-led chạy 110 bước, tăng từ 0,45 lên 0,72; nhóm hps-led cũng chạy 110 bước, tăng từ 0,57 lên 0,82 — cả điểm xuất phát lẫn điểm kết thúc đều cao nhất trong ba nhóm.
Mức tăng lớn nhất thuộc về nhóm judge-led với +0,27, nhưng điểm xuất phát của nhóm này cũng thấp nhất. Nhóm hps-led tăng 0,24 nhưng dừng ở mức 0,82 — đặt bộ chấm điểm ưu tiên của con người ở vị trí chủ đạo, mô hình giám khảo chỉ bổ trợ, cho kết quả ổn định hơn so với làm ngược lại. Nhóm chỉ dùng bộ chấm điểm, không có giám khảo, chỉ tăng 0,13 — mức tăng nhỏ nhất trong ba nhóm. Lớp so sánh theo cặp thực sự đóng góp thêm một tín hiệu, không phải là chi tiết trang trí có cũng được không có cũng được.
Một GPU, 34 giờ, khoảng một trăm đô la
Phần phần cứng khá đơn giản. Toàn bộ quá trình chỉ dùng một GPU H200: chạy 60 bước mất 18 giờ, chạy 110 bước mất 34 giờ. Phần render đặt trên một Space cấu hình CPU, bộ chấm điểm HPSv3 đặt trên một Space cấu hình a100-large.
Tính theo giá thuê H200 trên cloud hiện nay, khoảng 3 đến 4 đô la một giờ, một lượt huấn luyện đầy đủ 110 bước rơi vào khoảng 100 đến 140 đô la; cộng thêm chi phí cho bộ chấm điểm và render, tổng hóa đơn tính toán của cả dự án khoảng vài trăm đô la. Với một nhóm chỉ muốn kiểm chứng xem "sở thích thẩm mỹ có thể dùng làm phần thưởng hay không", ngưỡng chi phí này thấp đến mức có thể thử ngay không cần đắn đo.
Phần mở nguồn khá đầy đủ: công thức huấn luyện và các script được đăng trên GitHub, cùng với bộ dữ liệu 178 bức tranh tham chiếu, một Space môi trường RL có thể sao chép trực tiếp, Space của bộ chấm điểm HPSv3, ba bộ điều hợp LoRA cùng với các bộ dữ liệu rollout tương ứng, và một phòng trưng bày cho phép xem lại toàn bộ kết quả sinh ra. Ai muốn tái hiện lại không cần tự dựng môi trường, chỉ cần sao chép Space rồi chỉnh trọng số phần thưởng là có thể bắt đầu.
Đi theo hướng này, có khá nhiều kịch bản có thể vay mượn cách làm. Giao diện của một thành phần frontend trông ra sao, bố cục một tấm poster dày thưa thế nào, màu sắc của một biểu đồ có hợp lý hay không — đây đều là những việc không có đúng sai rõ ràng, nhưng con người chỉ cần liếc mắt là phân biệt được cái nào hơn, mà trước đây rất khó đưa vào hàm thưởng của RL. Cách làm bây giờ là trước tiên gom một kho tham chiếu vài trăm mẫu, tìm một bộ chấm điểm ưu tiên đủ tốt, phần còn lại giao cho GRPO. Điểm khó vẫn nằm ở kho tham chiếu: kho lệch thì mô hình cũng lệch theo, mà lệch một cách rất nhất quán.
Nguồn tham khảo: blog chính thức của Hugging Face, tài liệu dự án TRL và OpenEnv, CocoLoop; số bước, khoảng phần thưởng và thời lượng chạy trên một GPU của ba nhóm thí nghiệm đã được đối chiếu từng mục theo bản ghi huấn luyện trong bài blog, chi phí tính toán là ước tính thô dựa trên giá niêm yết công khai.