Strands Decider: Vì sao không dùng encoder?

Khi ra mắt strands-decider-2B cách đây một tuần, nhiều người đã đặt câu hỏi: tại sao lại dùng một LLM cải tiến mà không phải là encoder như BERT? Trực giác của họ cho rằng mô hình hai chiều (bidirectional — mỗi token được biểu diễn dựa trên cả các token trước và sau nó) sẽ vượt trội hơn mô hình nhân quả (causal — chỉ dùng các token phía trước). Đây cũng chính là lý do encoder thường được dùng làm bộ phân loại.

Marc Brooker, tác giả bài viết, thẳng thắn thừa nhận ông không phải chuyên gia phát triển mô hình. Ông đã cố gắng phân tích một cách định lượng và cẩn thận để bù đắp phần nào cho sự thiếu chuyên môn sâu. Câu hỏi mà ông đặt ra rất hợp lý, bởi nếu nhìn kỹ, strands-decider đang "lạm dụng" một decoder như thể nó là encoder.

Năm thiết kế được đem ra so sánh

Để kiểm chứng giả thuyết này, tác giả đã so sánh năm thiết kế kiến trúc khác nhau. Ông cũng đo thử ModernBERT và ettin-encoder-1b ở dạng đóng băng (frozen), nhưng nhận thấy chúng kém hơn T5Gemma khi so sánh theo số lượng tham số tương đương, nên không đầu tư thời gian huấn luyện thêm.

Biểu đồ độ chính xác và hiệu chuẩn Brier của các kiến trúc

Về độ chính xác và hiệu chuẩn (calibration), phiên bản b2 thể hiện rất tốt: đánh bại v19 trên cả độ chính xác JevBench lẫn chỉ số Brier, đồng thời đạt Brier tốt hơn trên JF100 ở cùng mức độ chính xác. Tuy nhiên cần lưu ý rằng b2 có khoảng 8B tham số so với 2B của v19, nên đây không phải là so sánh tương đương.

Điều thú vị hơn nằm ở cặp v19 và e1b. E1b nhỉnh hơn v19 một chút về độ chính xác trên JevBench (nhưng nằm trong khoảng biến động giữa các lần chạy của v19), với hiệu chuẩn hơi kém hơn, và ngang bằng về hiệu chuẩn trên JF100 nhưng hiệu suất yếu hơn chút ít.

Cho đến đây, các encoder chưa tạo ra khoảng cách áp đảo.

Độ trễ: encoder thắng, nhưng có bẫy

Các mô hình chỉ dùng encoder thắng rõ rệt về độ trễ, với trung vị khoảng 35ms so với 65ms của v19. Các mô hình encoder-decoder chậm nhất. Với độ trễ chỉ bằng một nửa mà hiệu suất tương đương, e1b trông như một chiến thắng lớn. Nhưng mọi chuyện trở nên phức tạp hơn khi đi sâu vào dữ liệu.

Biểu đồ phân bố độ trễ của các mô hình

E1b thắng đậm ở các prompt ngắn, nhưng mở rộng kém hơn khi prompt dài ra. Điều này nhất quán với hiệu suất trung vị ấn tượng. Việc điều này có quan trọng hay không phụ thuộc vào hỗn hợp khối lượng công việc thực tế: cả JF100 lẫn JevBench đều có xu hướng ngắn, nên có lợi cho e1b.

Sự khác biệt về khả năng mở rộng đến từ chi phí tính toán của hai mô hình. E1b có 26 lớp attention đầy đủ với chi phí tính toán bậc hai (quadratic) đi kèm, trong khi 75% các lớp của v19 là Gated DeltaNet với chi phí tính toán tuyến tính. Những lớp này có chi phí cố định cao hơn nhưng chi phí tiệm cận tốt hơn, dẫn đến độ trễ nền cao hơn.

Xu hướng độ trễ theo độ dài prompt

Một kết quả phụ đáng chú ý

Quay lại với e1a — ứng viên chỉ dùng encoder 2,6B không dùng mặt nạ (unmasked). Trên các tập đánh giá, nó đánh bại v19 ở bảy trong chín tác vụ, và chỉ kém hơn rất nhẹ ở hai tác vụ còn lại. Nhưng nó lại kém hơn đáng kể ở JevBench (153 so với 168), và kém hơn một chút ở JF100 (158 so với 162).

Điều này gợi ý rằng encoder tổng quát hóa kém hơn, ít nhất là khi không dùng cách tiếp cận có mặt nạ như e1b. Liệu việc có thể "nhìn" vào câu hỏi khi đọc trạng thái có thực sự là một điểm yếu?

Vậy encoder hay decoder?

Câu trả lời vẫn chưa ngã ngũ. Thí nghiệm này bị nhiễu (confounded) nặng nề khi thay đổi đồng thời kiến trúc, mô hình nền, và việc tinh chỉnh theo chỉ dẫn so với mô hình nền. Tuy nhiên, ta đã học được vài điều thú vị: không bên nào là người thắng tuyệt đối cho loại công việc này ở quy mô hiện tại.

Độ trễ thấp và hiệu suất tương đương của encoder là lợi thế thực sự, nhưng lợi thế đó teo dần khi prompt dài ra. Ngược lại, decoder có độ trễ nền cao hơn nhưng mở rộng tốt hơn.

Mã nguồn của thí nghiệm hiện nằm trong một nhánh riêng. Tác giả cho rằng chưa đáng để hợp nhất vào nhánh chính của strands-decider, nhưng có thể sẽ làm vậy sau một số phát triển tiếp theo.

Bài học cho cộng đồng phát triển AI Việt Nam: việc lựa chọn kiến trúc không nên dựa trên trực giác đơn thuần mà cần dựa trên đặc điểm khối lượng công việc thực tế. Nếu ứng dụng của bạn chủ yếu xử lý văn bản ngắn và cần độ trễ thấp — như chatbot hỗ trợ khách hàng hay phân loại tin nhắn — encoder có thể là lựa chọn hợp lý. Nhưng nếu cần xử lý ngữ cảnh dài, chẳng hạn phân tích tài liệu pháp lý hay hợp đồng dài, thì kiến trúc lai với các lớp tính toán tuyến tính như Gated DeltaNet sẽ tỏ ra vượt trội hơn về lâu dài.