Di Benchmark, TabPFN Selalu Menang. Di Data Nyata, Nggak Semudah Itu
Paper bilang tanpa tuning bisa kalahin XGBoost. Tapi eksperimen di dataset diabetes 253 ribu responden ini ngasih sudut pandang baru.
Di post sebelumnya, saya sempat bahas klaim dari paper TabPFN. Win rate 100% di dataset kecil, 230 kali lebih cepat dari AutoML, dan nggak butuh preprocessing sama sekali. Semua angka ini memang benar. Tapi perlu diingat kalau klaim tersebut diukur di benchmark yang sudah dikurasi, di mana dataset dipilih, dikelompokkan, dan hasilnya dirata-ratakan. Nah, pertanyaannya, gimana kalau kita bawa model ini ke dataset tunggal yang berantakan khas dunia nyata? Ternyata ceritanya bisa agak beda.
Ada pembaca yang request untuk coba bandingin langsung antara XGBoost dan TabPFN v2.5 di dataset yang benar dari lapangan, bukan sekadar benchmark. Pembaca ini juga sekalian merekomendasikan datanya, yaitu Diabetes Health Indicators BRFSS 2015 dari CDC. Dataset ini punya 253.680 respons survei dengan 21 fitur. Tantangan terbesarnya ada di class imbalance 86/14 antara responden yang nggak diabetes banding yang diabetes atau prediabetes. Eksperimen ini dibuat bukan untuk membuktikan paper TabPFN salah, tapi lebih buat nyari tahu klaim mana yang benar berlaku di lapangan dan mana yang butuh konteks tambahan.
Intinya, nggak ada yang bohong di paper tersebut. Hanya saja, ada detail penting yang sering tertutup kalau kita cuma melihat angka agregat dari benchmark.
Dataset ini berasal dari Behavioral Risk Factor Surveillance System (BRFSS). Ini adalah survei kesehatan tahunan yang dijalankan oleh CDC di Amerika Serikat sejak tahun 1984. Setiap tahunnya, survei ini mengumpulkan respons dari lebih dari 400 ribu orang tentang risiko kesehatan, penyakit kronis, dan layanan pencegahan.
Data ini bisa diakses publik di Kaggle dengan nama Diabetes Health Indicators Dataset. Dari dataset asli tahun 2015 yang punya lebih dari 400 ribu respons dan 330 fitur, datanya sudah dibersihkan menjadi tiga file utama.
Untuk eksperimen ini, saya memilih file yang targetnya binary (0 untuk nggak diabetes, 1 untuk diabetes atau prediabetes) dengan total 253.680 respons dan tanpa proses balancing sama sekali. Ada beberapa alasan kuat di balik pilihan ini.
Pertama, distribusi kelas aslinya dipertahankan. Di Kaggle sebenarnya ada versi data yang sudah di-balance 50 banding 50, tapi skenario itu kurang realistis. Di dunia nyata, prevalensi diabetes memang minoritas. Kalau model dites di data yang sengaja dibuat imbang, performanya bakal kelihatan lebih bagus dari yang sebenarnya. File yang saya pakai mempertahankan distribusi asli 86/14, sehingga jauh lebih merepresentasikan kondisi asli di lapangan.
Kondisi imbalance 86/14 ini juga mengubah cara kita melihat metrik evaluasi. Dengan distribusi yang timpang ini, model yang cuma asal menebak “nggak diabetes” untuk semua responden otomatis bakal dapet akurasi 86%. Jadi, akurasi nggak bisa diandalkan di sini. Di konteks medis, yang jauh lebih krusial adalah recall, yaitu kemampuan model mendeteksi pasien yang benar diabetes dari keseluruhan pasien yang memang punya diabetes. Melewatkan satu pasien diabetes atau false negative itu risikonya jauh lebih fatal daripada sekadar false alarm. Selain itu, F1 score juga penting karena memberikan keseimbangan antara recall dan precision. Dua metrik inilah yang bakal jadi fokus utama kita.
Kedua, ukuran sampel penuh. Versi data yang sudah di-balance membuang hampir 75% baris data. Dengan memakai file yang berisi full 253.680 baris, kita bisa ngetes batas atas kapasitas TabPFN v2.5 yang kebetulan punya limit maksimal di angka 50.000 baris. Ini penting biar kita tahu performanya di data yang lebih besar, bukan cuma di data kecil tempat dia biasanya bersinar.
Ketiga, formatnya adalah binary classification. Membedakan apakah seseorang punya diabetes atau nggak biasanya jadi pertanyaan paling pertama di tahap screening, sehingga lebih relevan dan umum dijadikan baseline perbandingan model.
Terakhir, fitur dan datanya nyata. Ini adalah data survei langsung dari orang, jadi jawabannya bervariasi, ada noise, dan mungkin ada bias. Tipe fitur di dalamnya juga campur aduk antara binary, numerik, dan ordinal tanpa normalisasi khusus. Persis seperti kondisi data tabular yang sering ditemui praktisi sehari-hari.
Mengingat batas kapasitas dari TabPFN, eksperimen ini nggak menggunakan seluruh 253 ribu baris data sekaligus. Saya membaginya ke dalam dua ukuran sampel dengan tujuan yang beda.
10.000 baris pertama dipakai untuk mengetes klaim paper TabPFN v2.5 yang bilang win rate mereka 100% saat melawan default XGBoost di dataset yang ukurannya di bawah atau sama dengan 10 ribu baris. Kalau klaim itu benar, TabPFN harus menang telak di tahap ini.
50.000 baris pertama dipakai untuk melihat batas atas kapasitas TabPFN. Paper TabPFN v2.5 menyebutkan kapasitas model sudah dinaikkan menjadi 50 ribu baris, jadi kita bisa cek langsung klaim bahwa mereka masih punya win rate 87% untuk dataset ukuran menengah ini.
Di kedua ukuran sampel tersebut, rasio imbalance kelas tetap dipertahankan di 86/14. Nggak ada teknik undersampling, oversampling, atau SMOTE. Ini sengaja dilakukan biar kita bisa melihat gimana mekanisme bawaan tiap model menghadapi data yang benar timpang, bukan melihat gimana teknik preprocessing menutupi masalah imbalance tersebut.
Untuk evaluasinya, saya menggunakan 5-Fold Stratified Cross-Validation. Buat yang belum familiar, metode ini membagi data jadi lima bagian atau fold. Model akan dilatih dan dites bergantian di tiap bagian. Kata “Stratified” memastikan tiap fold punya proporsi kelas yang sama persis, jadi hasilnya nanti lebih stabil saat dirata-ratakan.
Kedua model kemudian dites dalam beberapa konfigurasi biar adil:
XGBoost Vanilla, yaitu default XGBoost tanpa tuning atau penanganan imbalance sama sekali.
XGBoost Class Weight, yaitu XGBoost yang diberi instruksi scale_pos_weight untuk memberikan bobot lebih ke kelas diabetes saat proses training.
XGBoost Optuna, yaitu XGBoost yang sudah di-tuning pakai Optuna selama 100 trial untuk mencari hyperparameter terbaik. Konfigurasi ini tetap memakai class weight.
Di sisi lain:
TabPFN Vanilla, yaitu TabPFN bawaan tanpa penanganan imbalance.
TabPFN Balanced, yaitu TabPFN dengan instruksi balanced_probabilities=True yang bakal menyesuaikan threshold output biar prediksi antar kelas lebih seimbang. Ini adalah satu-satunya fitur bawaan TabPFN untuk menghadapi imbalance.
Mari kita lihat hasilnya di 10.000 baris pertama. Ini adalah zona nyaman TabPFN, di mana paper mereka mengklaim selalu menang.
| Model | Diabetes Recall | Diabetes F1 | Precision | Macro F1 | Accuracy | Waktu |
|---|---|---|---|---|---|---|
| XGBoost | 22% | 29% | 45% | 61% | 85% | 0.92s |
| TabPFN v2.5 | 13% | 22% | 59% | 57% | 87% | 48.81s |
Tanpa bantuan penanganan imbalance, kedua model benar gagal mendeteksi diabetes. XGBoost hanya bisa menangkap 22% kasus, sementara TabPFN cuma 13%. Akurasi keduanya memang kelihatan tinggi di angka 85-87%, tapi metrik ini sangat mengecoh karena hanya mencerminkan keberhasilan mereka menebak kelas mayoritas yang “nggak diabetes”.
TabPFN memang punya presisi yang lebih baik di 59% dibanding XGBoost yang cuma 45%. Ini artinya, kalau TabPFN bilang seseorang kena diabetes, tebakannya lebih bisa dipercaya. Sayangnya, dari 100 orang yang benar diabetes, TabPFN cuma bisa mendeteksi 13 orang. Untuk konteks screening medis, angka recall serendah ini tentu nggak bisa dipakai. Ini membuktikan bahwa parameter balanced_probabilities=True di TabPFN sifatnya wajib kalau berhadapan dengan data yang imbalanced.
| Model | Diabetes Recall | Diabetes F1 | Precision | Macro F1 | Accuracy | Waktu |
|---|---|---|---|---|---|---|
| XGBoost | 48% | 39% | 33% | 63% | 79% | 0.96s |
| TabPFN v2.5 | 74% | 45% | 32% | 64% | 74% | 45.59s |
Ceritanya berubah drastis setelah class weight diaktifkan. Recall TabPFN langsung melonjak dari 13% ke 74%. Model ini sekarang berhasil menangkap 74% pasien diabetes, jauh meninggalkan XGBoost yang tertahan di angka 48%.
TabPFN juga unggul tipis di F1 score untuk kelas diabetes sebesar 45% dibanding 39%. XGBoost memang unggul di akurasi keseluruhan, tapi seperti yang dibahas sebelumnya, itu terbantu dari prediksi yang gampang di kelas mayoritas. Buat task yang prioritasnya mencegah pasien terlewat, recall 74% dari TabPFN jelas jauh lebih berharga daripada akurasi 79% dari XGBoost.
| Model | Diabetes Recall | Diabetes F1 | Precision | Macro F1 | Accuracy | CV Time | Tuning Time | Total Pipeline |
|---|---|---|---|---|---|---|---|---|
| XGBoost | 59% | 45% | 37% | 66% | 80% | 8.88s | ~99s | ~108s |
| TabPFN v2.5 (Balanced) | 74% | 45% | 32% | 64% | 74% | 45.11s | 0s | 45.11s |
Bahkan setelah melewati 100 trial tuning pakai Optuna, recall XGBoost yang naik ke 59% masih kalah dibandingkan TabPFN bawaan. Hebatnya, TabPFN bisa menyamai skor F1 XGBoost yang sudah di-tuning dengan susah payah, tapi TabPFN melakukannya tanpa effort tuning sama sekali.
Lebih menariknya lagi, total waktu yang dibutuhkan XGBoost dari awal sampai selesai tuning memakan waktu sekitar 108 detik. Ini 2.4 kali lebih lama dari TabPFN yang cuma butuh waktu inferensi 45 detik. Kalau kamu butuh model yang kompetitif tanpa mau repot membuang waktu untuk hyperparameter search, TabPFN benar bekerja dengan baik di skala ini.
Sekarang kita lipat gandakan jumlah datanya jadi 50.000 baris. Tujuannya untuk ngetes batas atas TabPFN dan melihat gimana model ini bersaing soal scaling dibandingkan XGBoost.
| Model | Diabetes Recall | Diabetes F1 | Precision | Macro F1 | Accuracy | Waktu |
|---|---|---|---|---|---|---|
| XGBoost | 17% | 26% | 50% | 59% | 86% | 1.01s |
| TabPFN v2.5 | 15% | 23% | 57% | 58% | 87% | 862.66s |
Pola yang sama kembali terulang. Tanpa penanganan imbalance, kedua model kesulitan menebak kelas minoritas. Yang bikin kaget adalah perbedaan kecepatannya yang jadi sangat ekstrem. TabPFN butuh waktu 862 detik atau sekitar 14 menit, sementara XGBoost menyelesaikannya cuma dalam 1 detik.
| Model | Diabetes Recall | Diabetes F1 | Precision | Macro F1 | Accuracy | Waktu |
|---|---|---|---|---|---|---|
| XGBoost | 69% | 43% | 31% | 63% | 74% | 1.11s |
| TabPFN v2.5 | 73% | 45% | 33% | 65% | 75% | 864.13s |
Dalam konfigurasi balanced, TabPFN masih memimpin di semua metrik krusial. Recall-nya mencapai 73% dibanding XGBoost yang di angka 69%, plus unggul di F1 dan akurasi.
Ada catatan menarik di sini. Recall XGBoost pelan-pelan merangkak naik seiring bertambahnya data. Dari yang awalnya cuma 48% di data 10K, sekarang jadi 69% di data 50K karena modelnya punya lebih banyak contoh untuk dipelajari. Di sisi lain, performa TabPFN luar biasa stabil dan konsisten di kisaran 73-74% nggak peduli ukuran datanya bertambah. Meski jarak performanya mulai menipis, TabPFN tetap ada di depan.
| Model | Diabetes Recall | Diabetes F1 | Precision | Macro F1 | Accuracy | CV Time | Tuning Time | Total Pipeline |
|---|---|---|---|---|---|---|---|---|
| XGBoost | 63% | 44% | 34% | 65% | 78% | 11.99s | 187.48s | ~199s |
| TabPFN v2.5 (Balanced) | 73% | 45% | 33% | 65% | 75% | 863.76s | 0s | 863.76s |
Bahkan setelah dibantu Optuna selama lebih dari 3 menit, recall XGBoost yang sebesar 63% masih ketinggalan 10 poin di belakang TabPFN. Semua pencapaian TabPFN ini diraih murni tanpa tuning tambahan.
Tapi jujur, di skala data sebesar ini kecepatan menjadi kendala utama bagi TabPFN. XGBoost menyelesaikan seluruh proses termasuk tuning cuma dalam 199 detik. Di sisi lain, TabPFN membutuhkan waktu inferensi hampir 14 menit. Kalau kamu ada di proyek yang mengharuskan iterasi model super cepat, gap performa waktu ini jelas nggak bisa diabaikan.
Dari eksperimen barusan, kita bisa mengecek ulang klaim dari paper TabPFN yang sempat saya rangkum di post sebelumnya. Mana yang relevan dan mana yang butuh tambahan konteks?
Sebagai catatan tambahan, penting untuk tahu kalau tiap rilis versi TabPFN dites di kumpulan benchmark yang berbeda. Jadi klaimnya bukan berasal dari satu sumber riset yang sama. TabPFN v1 diuji di 18 dataset OpenML, di mana klaimnya berfokus pada kemenangan mereka melawan AutoML dengan speedup ekstrem. TabPFN v2 dites di puluhan dataset AutoML Benchmark dengan fokus ke limitasi maksimal 10.000 sampel. Sementara TabPFN v2.5 dites di TabArena benchmark yang kapasitasnya diperlebar sampai 50.000 sampel.
Sekarang, mari kita bedah klaim-klaimnya.
Sumber: TabPFN v2.5 paper. Hasil eksperimen nunjukin kalau klaim ini butuh konteks. TabPFN memang menang di recall dan F1 score kalau parameternya diatur dengan benar. Tapi XGBoost lebih unggul di akurasi dan tentu saja jauh lebih cepat. Paper menghitung “win rate” dari rata-rata metrik secara general di banyak dataset sekaligus, sehingga trade-off spesifik seperti kecepatan melawan akurasi jadi nggak kelihatan. Kesimpulannya, siapa yang menang bergantung banget pada metrik apa yang paling krusial untuk masalah yang sedang kamu selesaikan.
Sumber: TabPFN v1 paper. Perbandingan di papernya memang masuk akal di atas kertas, tapi kurang nyambung buat praktisi sehari-hari. Kebanyakan praktisi menggunakan XGBoost default sebagai baseline pertama mereka, bukan AutoML yang butuh waktu lama. Saat dibandingkan dengan XGBoost default di eksperimen kita, XGBoost justru bisa 50 sampai 850 kali lipat lebih cepat dibanding TabPFN.
Sumber: TabPFN v2.5 paper. TabPFN memang bisa dijalankan di data 50 ribu baris dan kualitas prediksinya masih sangat bagus. Tapi masalah utamanya ada di waktu tunggu komputasi. Hanya karena datanya nambah lima kali lipat, waktu inferensinya justru membengkak hampir 19 kali lipat. Kapasitasnya memang membesar, tapi isu scaling komputasinya masih jadi pekerjaan rumah yang belum tuntas.
Sumber: Konklusi umum dari pemaparan paper.
Bagian “tanpa tuning” ini 100% benar. TabPFN berhasil menyamai bahkan melewati kualitas XGBoost yang sudah di-tuning susah payah. Tapi soal “tanpa preprocessing” ternyata ada syarat dan ketentuannya. Kalau berhadapan dengan data yang imbalancenya parah, kita minimal wajib memasukkan instruksi balanced_probabilities=True. Tanpa langkah itu, modelnya bakal lumpuh dan kesulitan mendeteksi kelas minoritas. Bahkan, untuk mendorong performa F1 lebih jauh, penanganan di level data seperti SMOTE atau oversampling mungkin tetap dibutuhkan.
Eksperimen ini jelas nggak bertujuan mematahkan riset paper TabPFN. Hasil di dataset diabetes ini juga nggak bisa dipukul rata buat semua jenis data di luar sana. Ini murni studi kasus tunggal buat melihat perilaku model di data medis yang imbalancenya lumayan parah.
TabPFN berhasil menemukan lebih banyak kasus diabetes dengan konsisten tanpa repot melakukan tuning. Ini pencapaian yang sangat relevan untuk konteks kesehatan. Tapi, trade-off yang ada juga nggak kalah nyata.
TabPFN sangat lambat. Menunggu 14 menit buat sekali run 5-fold di 50.000 baris rasanya terlalu membebani buat proyek yang butuh banyak iterasi cepat. Kalau kecepatan adalah prioritasmu, XGBoost yang menyelesaikan tugas dalam satu detik masih sulit dikalahkan.
Presisi TabPFN juga tergolong rendah. Dari prediksi positif yang dihasilkan TabPFN, banyak di antaranya adalah false alarm. Meskipun XGBoost juga mengalami hal yang serupa di dataset ini, kamu tetap harus hati-hati dalam menerima tebakan positif dari model.
Terlepas dari semua itu, ungkapan lama bahwa algoritma tree-based selalu menang di data tabular mulai terbantahkan. Tapi ini bukan berarti TabPFN adalah solusi ajaib untuk semua masalah. Jawabannya balik lagi, sangat bergantung sama karakteristik data, waktu komputasi, dan metrik yang mau kamu kejar.
Yang paling menarik dari kemunculan TabPFN adalah pergeseran pola pikir. Bertahun-tahun lamanya kita selalu mendesain dan menyesuaikan algoritma secara manual. TabPFN ngasih bukti kalau kemampuan algoritma itu sendiri ternyata bisa “dipelajari” oleh model Transformer. Pertanyaannya bukan lagi sekadar siapa model yang bakal selalu menang, tapi bagaimana kita merumuskan masalah distribusi data agar model bisa menjadi algoritma yang paling tepat untuk menyelesaikannya.
Eksperimen ini dijalankan di atas mesin dengan GPU NVIDIA GeForce RTX 5060 versi laptop. Seluruh kode dan alur datanya tersedia dan bisa kamu cek di GitHub.