Tagger 26M đánh bại SLM 360M ở bài sửa lỗi on-device

Một tagger 26M tham số đạt F0.5 0.799 ở bài sửa lỗi văn bản tiếng Anh, cao hơn SmolLM2 360M fine-tune LoRA (0.663) — và nhỏ hơn 14 lần.

Con số đến từ báo cáo build của nhóm Mindscend cho một bàn phím điện thoại chạy offline. Điểm đáng chú ý không phải "model nhỏ thắng model to", mà là chọn sai dạng bài toán thì fine-tune bao nhiêu cũng không cứu được.

Vì sao model sinh văn bản thua ở bài sửa lỗi

Nhóm tác giả giải thích gọn: "Generative correction regenerates every token, so every token is a chance to change something that was fine." Mỗi token sinh ra là một cơ hội phá hỏng chỗ vốn đã đúng.

Cột đáng sợ nhất trong bảng họ công bố là false positive — tỉ lệ model sửa cả câu vốn đã đúng:

Model	Params	F0.5	False positives
Gemma 3 270M + LoRA	270M	0.571	23,1%
SmolLM2 360M + LoRA	360M	0.663	20,1%
tagger v1.5	26M	0.799	2,4%

Tagger không sinh text: nó gán một nhãn edit cho từng từ ($KEEP, $REPLACE_, $APPEND_) rồi chạy lại trên chính output của mình, tối đa 3 lượt. Kiến trúc công bố: encoder-only transformer, 8 layer, d_model 384, 26.2M tham số, 15.000 nhãn edit — train trên một laptop RTX 3080 Ti, tổng khoảng 9 giờ.

Ràng buộc on-device mới là thứ quyết định kiến trúc

Phần này đáng đọc nếu bạn định nhét LLM vào app mobile. Ràng buộc thật của một keyboard extension, theo nhóm tác giả: "~60-80 MB of memory on iOS before jetsam kills it, no GPU guarantees, and it has to stay responsive while you type." Không mạng — bàn phím iOS không xin Full Access, app Android không khai báo quyền INTERNET.

Với trần RAM đó, một SLM 360M gần như hết cửa. Bản ship họ báo cáo: Core ML 8-bit 26 MB trên iOS (99,96% khớp nhãn fp32), ONNX int8 27 MB trên Android (99,1%), ~4 ms mỗi câu trên CPU. Peak memory trên iPhone 16 Pro Max là 81 MB khi đã nạp model.

Một chi tiết đáng mượn: protected span. Trong vùng đã nhận diện là tên riêng, số, email hay URL, model chỉ được phép chọn $KEEP — và nhóm báo cáo 0,0% span bị phá trên toàn bộ suite 4.356 case. Rule rẻ tiền ở inference đôi khi đáng giá hơn một vòng train nữa.

Cái bẫy: train lâu hơn làm model tệ đi

Phần hữu ích nhất của báo cáo là chỗ họ kể về lỗi. Hai bản v1.3 và v1.4 train lâu hơn nhưng thua v1.2: false positive trên văn bản đúng tăng từ 3,1% lên 7,4% và 9,1%.

Nguyên nhân: script fine-tune quy đổi "ngân sách thời gian" thành số step bằng cách đo tốc độ ở step 300. Bản v1.2 vô tình đo trúng lúc VRAM spill nên nhận lịch train ngắn; sau khi sửa, các bản sau chạy gấp 2-3 lần số step — và bản train dài mới là bản tệ. Checkpoint picker thì chấm theo F0.5 trên synthetic pair: điểm đó vẫn tăng (0.9655 → 0.9739) trong khi false positive trên văn bản đúng thật cũng tăng.

Mang gì về dự án của bạn

Ba thứ áp dụng được ngay, kể cả khi bạn không làm bàn phím:

• Fix cứng số step, đừng fix thời gian. Ngân sách thời gian làm các run mất khả năng so sánh — đúng như khuyến nghị nhóm rút ra sau sự cố.
• Đo false positive như một metric riêng. F-score giấu đúng cái lỗi người dùng cảm nhận rõ nhất; chọn checkpoint bằng dev set văn bản sạch thật, không phải test suite.
• Thử khung tagging trước khi fine-tune SLM cho các bài "sửa tại chỗ": chuẩn hoá địa chỉ, tách trường form, gán nhãn log.

Weights mở Apache-2.0 trên Hugging Face (Mindscend/mindtype-tagger-v1.5), nên benchmark lại trên tập của bạn là việc một buổi chiều. Lưu ý: mọi số liệu trên là do nhóm tác giả tự đo, chưa có bên thứ ba kiểm chứng; riêng lỗi thì quá khứ vẫn yếu (F0.5 0.119), đừng kỳ vọng nó thay một model rewrite đầy đủ.