TabPFN và TabICL so với XGBoost được tinh chỉnh: mô hình không cần huấn luyện thắng 14/14

Công nghệ28 tháng 9, 2026·15 phút đọc

Các mô hình nền tảng dạng bảng (tabular foundation model) như TabPFN và TabICL có thể dự đoán trên một bảng dữ liệu mà không cần huấn luyện, nhờ học trong ngữ cảnh (in-context learning). Thử nghiệm trên 14 bộ dữ liệu chuẩn cho thấy TabICL đánh bại XGBoost được tinh chỉnh về chỉ số AUC ở cả 14/14 trường hợp, đồng thời tiết kiệm thời gian đáng kể nhờ bỏ qua bước tìm siêu tham số.

TabPFN và TabICL so với XGBoost được tinh chỉnh: mô hình không cần huấn luyện thắng 14/14

TabPFN và TabICL so với XGBoost được tinh chỉnh: mô hình không cần huấn luyện thắng 14/14

Các mô hình nền tảng dạng bảng (tabular foundation model) như TabPFN và TabICL hứa hẹn dự đoán trên một bảng dữ liệu mà không cần huấn luyện, thậm chí vượt qua cả XGBoost được tinh chỉnh kỹ lưỡng. Một thử nghiệm độc lập trên 14 bộ dữ liệu chuẩn cho thấy TabICL thắng về chỉ số AUC ở cả 14/14 trường hợp, và lợi thế này không hề suy giảm khi kích thước bảng tăng lên tới 32.000 dòng.

Mô hình nền tảng dạng bảng hoạt động như thế nào?

Một mô hình nền tảng dạng bảng (tabular foundation model) được tiền huấn luyện trên hàng triệu bảng dữ liệu tổng hợp được sinh ra có chủ đích. Khi một bảng mới xuất hiện, mô hình không điều chỉnh bất kỳ trọng số nào: nó nhận các dòng huấn luyện như phần ngữ cảnh (context) và đưa ra dự đoán chỉ trong một lượt lan truyền tiến (forward pass).

Đây chính là ý tưởng học trong ngữ cảnh (in-context learning) mà chúng ta đã biết từ các mô hình ngôn ngữ lớn, nhưng được chuyển từ chữ sang các cột dữ liệu. Vì vậy, cách dùng từ "huấn luyện" ở đây có phần lạ lẫm: đoạn mã vẫn gọi hàm fit, nhưng bên trong không có hạ gradient (gradient descent) nào cả, chỉ là việc sao chép dữ liệu vào GPU.

Điều đó cũng lý giải tại sao chi phí lại xuất hiện ở nơi bạn không ngờ tới. Việc khớp mô hình gần như miễn phí, còn dự đoán mới là khâu tốn kém — hoàn toàn ngược lại với mô hình cây quyết định.

Minh họa quá trình dự đoán một lượt của mô hình nền tảng dạng bảngMinh họa quá trình dự đoán một lượt của mô hình nền tảng dạng bảng

Bối cảnh: bài toán bảng dữ liệu phổ biến đến mức nào?

Một bảng dữ liệu đơn giản là một bảng tính: các dòng là các trường hợp, các cột là các thuộc tính. Và nhiệm vụ luôn giống nhau — dự đoán một cột từ các cột còn lại:

  • Bảng khách hàng với thời gian gắn bó, gói dịch vụ, mức sử dụng và khiếu nại, để ước lượng ai sẽ rời bỏ trong tháng tới.
  • Nhật ký giao dịch với số tiền, đơn vị bán, giờ và quốc gia, để đánh dấu giao dịch gian lận.
  • Lịch sử hồ sơ vay vốn với thu nhập, nợ và hành vi thanh toán, để ước lượng ai sẽ không trả được nợ.
  • Dữ liệu cảm biến từ một cỗ máy, để đoán trước khi nào nó hỏng.
  • Hồ sơ bệnh nhân với triệu chứng và kết quả xét nghiệm, để ưu tiên ai được khám trước.

Đây là một nửa khối lượng công việc dữ liệu ở bất kỳ doanh nghiệp nào. Đây cũng là mảnh đất mà học sâu (deep learning) đã thua suốt nhiều năm: với dữ liệu dạng bảng, một ensemble cây tăng cường gradient (gradient-boosted tree) tốt vẫn là câu trả lời đúng.

Quy tắc của bài benchmark

Một bài benchmark được xây dựng cẩu thả sẽ nói ra bất cứ điều gì bạn muốn. Dưới đây là các quy tắc được đặt ra trước khi nhìn thấy bất kỳ con số nào:

  • Dữ liệu là của bên thứ ba và thuộc đúng lĩnh vực đang tranh luận: bộ chuẩn tabular của Grinsztajn.
  • XGBoost được đưa vào ở dạng đã tinh chỉnh, không phải để trang trí. Có hai phiên bản: một với tham số cố định hợp lý, và một với tìm kiếm ngẫu nhiên trên 25 tổ hợp cùng kiểm định chéo ba lớp.
  • Cùng cách chia, cùng seed, cùng cột cho mọi mô hình. Biến phân loại được mã hóa thành số nguyên.
  • Năm seed cho mỗi bộ dữ liệu, lấy giá trị trung vị.
  • Thời gian dự đoán bao gồm hai lượt suy luận (lớp và xác suất), khiến các mô hình nền tảng trở nên tốn kém hơn — tức là con số công bố cho chúng bị đẩy lên, không có lợi cho chúng.
  • Hai nhân CPU được để rảnh, và mọi thứ chạy trên GPU RTX 4070 Ti SUPER 16 GB.

Những trục trặc trước khi có con số đầu tiên

Công bố chỉ bảng kết quả cuối cùng sẽ là che giấu sự thật. Đây là những gì đã xảy ra trên đường đi.

PyTorch âm thầm tắt GPU

Dòng đầu tiên của kết quả báo device: cpu dù card đồ họa vẫn rảnh và hiển thị bình thường. Nguyên nhân: PyTorch phân giải sang bản dựng cho CUDA 13.0 trong khi driver của máy chỉ hỗ trợ 12.8. Thay vì báo lỗi, nó âm thầm tắt GPU và tiếp tục chạy bằng CPU.

Cách khắc phục là ghim đúng phiên bản:

pip install --no-cache-dir \
--index-url https://download.pytorch.org/whl/cu128 torch==2.9.1+cu128

API của OpenML trả về lỗi 504 trên mọi endpoint

Kế hoạch ban đầu là lấy dữ liệu từ OpenML — nguồn chuẩn cho các so sánh kiểu này. Nhưng nó thất bại hoàn toàn trong suốt quá trình chạy, với lỗi 504 ở tất cả các endpoint dù đã thử lại bốn lần với thời gian chờ tăng dần. Giải pháp là chuyển sang dùng file CSV cùng bộ chuẩn được lưu trên HuggingFace, phản hồi chỉ trong 250 mili-giây.

Mô hình được trích dẫn nhiều nhất không còn tải được nếu không có tài khoản

Đây là phát hiện đáng chú ý nhất vì nó không mang tính kỹ thuật. TabPFN là cái tên xuất hiện trong gần như mọi bài viết về chủ đề này. Nhưng khi cài đặt phiên bản hiện tại 8.3.0, ngay lần khớp mô hình đầu tiên đã báo lỗi:

TabPFNLicenseError: TabPFN requires a one-time license acceptance to download model weights for local inference, but no interactive terminal is available.

Muốn tải trọng số, bạn phải mở trình duyệt, đăng ký tài khoản, chấp nhận giấy phép và xuất một token. Mô hình nền tảng dạng bảng nổi tiếng nhất đã không còn là thứ bạn cài rồi chạy ngay được nữa.

Có hai lối thoát, và cả hai đều đã được thử:

  • Dòng TabPFN 2.x vẫn tải trọng số mà không cần đăng ký. Phiên bản 2.2.1 chạy được ngay lần đầu.
  • TabICL, từ nhóm Soda của Inria, dùng giấy phép BSD ba điều khoản và tải về không có rào cản nào. Hóa ra nó cũng là mô hình tốt hơn trong hai.

So sánh hai mô hình nền tảng dạng bảngSo sánh hai mô hình nền tảng dạng bảng

Kết quả đo lường

Mười bốn bộ dữ liệu, tất cả được cắt gọn về 3.000 dòng. Độ chính xác là trung vị của năm seed.

Bộ dữ liệuKích thướcTabICLTabPFN 2.2.1XGBoostXGB tinh chỉnh
bank-marketing3000 × 70.79440.79670.77110.7833
credit3000 × 100.76670.75780.74780.7533
heloc3000 × 220.72220.73000.70220.7078
pol3000 × 260.98440.98330.97780.9756
eye_movements3000 × 200.61000.61110.59440.5833
california3000 × 80.89670.89780.88330.8767
house_16H3000 × 160.88110.87440.87220.8711
MagicTelescope3000 × 100.87780.86220.84890.8456
electricity3000 × 70.81780.81110.81560.8178
Diabetes130US3000 × 70.59110.59330.56440.5900
default-of-credit3000 × 200.69560.69670.68780.6944
compas-two-years3000 × 110.67330.67670.64440.6700
Bioresponse3000 × 4190.79220.75670.78440.7744
albert3000 × 310.65000.66110.65110.6611

So với XGBoost được tinh chỉnh, xét theo độ chính xác:

  • TabICL: thắng 12, hòa 1 (electricity), thua 1 (albert). Chênh lệch trung bình +0,0106.
  • TabPFN 2.2.1: thắng 11, hòa 1 (albert), thua 2 (electricity và Bioresponse). Chênh lệch trung bình +0,0075.

Độ chính xác là một thước đo thô: nó phụ thuộc vào ngưỡng và xử phạt khác nhau tùy theo mức cân bằng giữa các lớp. Diện tích dưới đường cong (AUC) mang tính thông tin cao hơn, và ở đó kết quả trở nên rõ ràng hơn:

Mô hìnhThắng về AUCChênh lệch trung bình
TabICL14/14+0,0114
TabPFN 2.2.113/14+0,0089

TabICL đánh bại XGBoost được tinh chỉnh trên mọi bộ dữ liệu, không có ngoại lệ. Ngay cả trên albert, nơi nó thua về độ chính xác, nó vẫn có AUC tốt hơn (0,7101 so với 0,7094).

Tuy nhiên, cần điều chỉnh lại sự hào hứng: thắng 14/14 là tín hiệu mạnh mẽ về tính ổn định, chứ không phải sự vượt trội áp đảo — chênh lệch trung bình chỉ là một phần trăm. Không ai nhận ra điều đó trên một bảng điều khiển. Điều đáng chú ý nằm ở khía cạnh khác.

Chi phí đảo ngược so với kỳ vọng

Hãy nhìn lại cột thời gian trong bảng gốc. TabICL xử lý một bộ dữ liệu trong chưa đầy một giây mà không cần tinh chỉnh gì cả. XGBoost được tinh chỉnh mất từ 0,7 đến 27,2 giây để tìm siêu tham số, và vẫn cho kết quả thấp hơn.

Đó mới là lập luận thực sự, và nó không nằm ở độ chính xác. Nó nằm ở chỗ phần việc tốn kém nhất — phần ngốn thời gian của cả máy lẫn con người — đơn giản là biến mất.

Bất ngờ: lợi thế không suy giảm khi dữ liệu lớn lên

Đây là chỗ mà kỳ vọng cho rằng lời hứa sẽ sụp đổ. Phản đối tiêu chuẩn dành cho các mô hình này là chúng chỉ hoạt động trên những bảng nhỏ, vì các dòng huấn luyện phải vừa với ngữ cảnh của transformer.

Bộ dữ liệu jannis với 57.580 dòng được cắt dần thành các kích thước tăng dần, ba seed cho mỗi kích thước:

Số dòngTabICLXGBoostXGB tinh chỉnhGiây TabICLGiây XGB tinh chỉnh
5000.75330.77330.75330.73.2
1.0000.77330.74670.75330.94.9
2.0000.78000.75830.76671.19.4
4.0000.78170.76920.77251.821.1
8.0000.79580.76580.75832.619.7
16.0000.80900.77850.78525.334.6
32.0000.82300.78940.792911.750.3

Lợi thế không hề sụp đổ, mà còn cố kết lại ở quy mô lớn: chênh lệch +0,030 tại 32.000 dòng. Và tỷ lệ thời gian mở ra theo hướng ngược với trực giác: 11,7 giây so với 50,3 giây.

Cần nói rõ điều gì tăng đều và điều gì không. Độ chính xác tuyệt đối của TabICL tăng đều đặn qua cả bảy phép đo. Ngược lại, lợi thế so với XGBoost thì thất thường, lúc lên lúc xuống. Tại mốc 4.000 dòng, lợi thế +0,009 còn nhỏ hơn cả độ phân tán giữa ba seed.

Nơi nó thực sự vững chắc là ở đỉnh: tại 32.000 dòng, seed tệ nhất của TabICL (0,8216) vẫn nằm trên seed tốt nhất của XGBoost (0,7950). Ở đó không có khả năng chồng lấn.

Đồ thị so sánh hiệu năng theo kích thước dữ liệuĐồ thị so sánh hiệu năng theo kích thước dữ liệu

Nơi chúng thực sự gặp giới hạn

Bioresponse là bộ dữ liệu tiết lộ vấn đề: 419 cột. TabPFN 2.2.1 tụt xuống 0,7567 — tệ nhất trong bốn đối thủ, thấp hơn cả XGBoost chưa tinh chỉnh — và tiêu tốn 18,1 giây, gấp 25 lần bình thường. TabICL trụ vững hơn nhiều (0,7922, tốt nhất trong bốn) nhưng cũng phải trả giá: 6,0 giây so với mức thường 0,8 giây.

Cách lý giải là chiều rộng của bảng, chứ không phải chiều dài, mới là trục gây sức ép thực sự. Điều này hợp lý: số cột đi vào chi phí attention của transformer, và quá trình tiền huấn luyện tổng hợp bao phủ tốt các bảng vài chục cột, chứ không phải hàng trăm cột.

Những điều phép đo này chưa nói được

Thà liệt kê các giới hạn còn hơn giả vờ chúng không tồn tại:

  • Chỉ phân loại nhị phân. Không kiểm tra hồi quy hay phân loại đa lớp.
  • Ngưỡng 3.000 dòng trong bảng chính. Phần khảo sát quy mô đạt 32.000, nhưng chỉ trên một bộ dữ liệu.
  • Tìm kiếm siêu tham số chỉ gồm 25 tổ hợp. Tinh chỉnh mạnh tay hơn sẽ thu hẹp một phần khoảng cách.
  • Tìm kiếm của XGBoost tối ưu cho độ chính xác, rồi mới so sánh thêm bằng AUC. Nghĩa là kết quả "14/14 về AUC" là so với một mô hình boosting chưa được tinh chỉnh cho chính chỉ số đó.
  • Biến phân loại được mã hóa số nguyên cho tất cả mọi người. Cách xử lý tốt hơn sẽ có lợi cho XGBoost nhiều hơn.
  • Mã hóa và điền giá trị thiếu được tính trên toàn bộ bảng trước khi chia. Đây là rò rỉ giống nhau cho cả bốn mô hình, nên không thay đổi ai thắng, nhưng nó thổi phồng mọi kết quả một chút.
  • Nhiều chiến thắng về độ chính xác nhỏ hơn cả dao động giữa các seed.
  • Phát hiện về bảng rộng chỉ dựa trên một bộ dữ liệu.
  • Phiên bản TabPFN hiện tại 8.3.0 không được đo vì rào cản giấy phép.
  • CPU bị chia sẻ với công việc khác, ảnh hưởng đến thời gian của XGBoost nhiều hơn GPU.

Khi nào nên dùng và khi nào không

Nên dùng với bất kỳ bảng nào từ một nghìn đến ba mươi nghìn dòng, có ít hơn một trăm cột, nơi thời gian của con người đáng giá hơn phần trăm cuối cùng. Một giây tính toán, không cần tinh chỉnh, và một kết quả mà theo đo lường của tác giả là tốt hơn một cách nhất quán. Để khám phá dữ liệu ban đầu, thật khó biện minh cho việc không làm điều đó.

Không nên dùng trên những bảng rất rộng, nơi mô hình suy giảm và trở nên đắt đỏ. Cũng không nên dùng trong môi trường sản xuất không có GPU, hay nơi bạn cần một artifact nhỏ gọn có thể kiểm tra và triển khai trong container nhẹ: một cây đã huấn luyện chỉ nặng vài kilobyte và chạy ở đâu cũng được, trong khi ở đây bạn phải nạp cả một transformer.

Và nếu tiêu chí bao gồm khả năng kiểm toán nguồn gốc của trọng số, thì câu trả lời hiện nay là TabICL. Không phải vì hiệu năng — dù nó cũng là mô hình tốt hơn trong hai — mà vì đây là mô hình bạn vẫn có thể tải về và chạy mà không cần xin phép bất kỳ ai.

Kết luận cho người làm dữ liệu tại Việt Nam

Với các đội ngũ phát triển sản phẩm và phân tích dữ liệu tại Việt Nam, kết quả này đáng để lưu tâm ở góc độ thực dụng. Phần lớn thời gian trong một dự án machine learning truyền thống bị tiêu tốn vào việc tìm siêu tham số và kiểm định chéo — công việc vừa nhàm chán vừa ngốn tài nguyên tính toán.

Các mô hình nền tảng dạng bảng đề xuất bỏ qua hoàn toàn nghi thức đó: đưa bảng dữ liệu vào, nhận câu trả lời trong vài giây. Đối với những đội ngũ có ít GPU hoặc không có chuyên gia tinh chỉnh mô hình, đây có thể là một lựa chọn đáng thử cho các bài toán như dự đoán rời bỏ khách hàng, phát hiện gian lận giao dịch, hay phân loại hồ sơ tín dụng.

Tuy nhiên, cần lưu ý hai điều. Thứ nhất, các mô hình này vẫn cần GPU để chạy, điều có thể là rào cản với nhiều doanh nghiệp. Thứ hai, TabICL với giấy phép BSD là lựa chọn an toàn hơn về mặt pháp lý và vận hành so với TabPFN, vốn đã chuyển sang yêu cầu tài khoản và chấp nhận giấy phép từ dòng phiên bản 8 trở đi — một yếu tố quan trọng với các tổ chức cần kiểm soát chặt chẽ chuỗi cung ứng phần mềm.

Đo lường thực hiện ngày 16 tháng 8 năm 2026 trên GPU RTX 4070 Ti SUPER 16 GB, với torch 2.9.1+cu128, XGBoost 3.4.1, TabICL 2.1.1 và TabPFN 2.2.1. Dữ liệu từ bộ chuẩn tabular của inria-soda.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗