Dari Paper ke Prototipe: Cara Membaca Paper Machine Learning dan Mengubahnya Jadi Kode yang Jalan

Kebanyakan orang membaca paper dari halaman pertama sampai terakhir, mengikuti urutan penulisnya. Untuk keperluan implementasi, urutan itu justru yang paling lambat. Bagian pendahuluan ditulis untuk meyakinkan reviewer, bukan untuk memberitahu kamu apa yang harus diketik.

Artikel ini membahas urutan membaca yang lebih berguna kalau tujuanmu adalah membangun sesuatu yang jalan: apa yang dibaca lebih dulu, bagaimana menemukan implementasi referensi, apa arti "mereproduksi satu tabel", dan seperti apa prototipe minimum yang layak disebut prototipe.

Urutan membaca yang lebih berguna

Bacalah paper seperti kamu membaca dokumentasi teknis, bukan seperti membaca buku.

Abstrak memberi tahu apa yang diklaim. Gambar metodologi memberi tahu bagaimana klaim itu dicapai. Tabel hasil memberi tahu apakah klaimnya masuk akal. Tiga bagian ini biasanya cukup untuk memutuskan apakah paper itu layak diimplementasikan.

Bagian eksperimen baru kamu baca serius ketika sudah memutuskan untuk mengerjakannya. Di sinilah hal-hal yang menentukan keberhasilan reproduksi biasanya bersembunyi: ukuran batch, learning rate, jumlah epoch, cara tokenisasi, dan versi dataset.

Membaca gambar metodologi seperti engineer

Gambar arsitektur di paper biasanya bukan diagram teknis yang presisi. Kotak mewakili tensor, panah mewakili operasi, dan banyak detail penting tidak digambar. Tugasmu adalah menerjemahkannya menjadi daftar operasi yang bisa ditulis.

Sebelum menulis kode, jawab enam pertanyaan ini:

1. Bentuk input. Apakah model menerima token id, gambar 224x224, atau sekuens fitur? Berapa panjang maksimumnya?
2. Bentuk output. Logit per kelas, skor skalar, atau sekuens? Ini menentukan fungsi loss.
3. Fungsi loss. Cross-entropy, BCE, contrastive, atau kombinasi? Kalau kombinasi, bagaimana bobotnya?
4. Komponen yang di-freeze. Apakah encoder dilatih dari nol atau dibekukan? Paper sering menyebut ini di bagian eksperimen, bukan di gambar.
5. Praproses. Normalisasi, augmentasi, tokenizer, dan pemotongan sekuens. Kesalahan paling sering terjadi di sini, bukan di arsitektur.
6. Inisialisasi. Apakah ada bobot pre-trained yang harus diunduh? Dari checkpoint yang mana?

Kalau salah satu tidak dijawab paper, itu bukan alasan berhenti. Itu daftar asumsi yang harus kamu tulis di laporan.

Mencari implementasi referensi

Sebelum menulis dari nol, cari kode yang sudah ada. Urutan pencarian yang biasanya paling produktif:

• Tautan di paper. Cek abstrak, footnote halaman pertama, dan akhir bagian eksperimen. Banyak paper mencantumkan repositori GitHub di sana.
• Halaman penulis. Repositori sering tidak ditautkan di paper versi conference, tetapi ada di halaman pribadi penulis pertama.
• Hugging Face. Untuk model bahasa dan vision, cek apakah ada model atau transformers implementation resmi. Nama arsitektur di paper biasanya menjadi nama kelas di library.
• GitHub search. Cari nama metode persis, lalu urutkan berdasarkan bintang. Hindari repositori tanpa commit dalam dua tahun terakhir kalau kamu butuh bantuan.
• Issues dan pull request. Kalau ada orang lain yang melaporkan hasil berbeda dari paper, baca diskusinya. Sering di situ letak perbedaan praproses yang tidak ditulis paper.

Satu hal yang perlu diingat: repositori resmi pun sering berbeda dari paper. Kode bisa sudah berevolusi setelah paper terbit, atau berisi eksperimen tambahan yang tidak masuk publikasi. Baca file konfigurasi dan skrip training, bukan hanya README.

Apa arti "mereproduksi satu tabel"

Mereproduksi seluruh paper bukan target yang realistis untuk prototipe. Yang realistis adalah mereproduksi satu baris dari satu tabel: satu metode, satu dataset, satu metrik.

Langkahnya:

1. Pilih tabel terkecil yang bermakna. Biasanya tabel hasil utama pada dataset yang paling kecil, atau tabel ablasi.
2. Kunci split datanya. Gunakan split resmi kalau ada. Kalau tidak, buat split sekali dan simpan daftar file atau indeksnya, jangan diacak ulang setiap run.
3. Samakan praproses. Ini penyebab perbedaan angka paling sering. Cek tokenizer, resolusi gambar, dan cara normalisasi.
4. Jalankan minimal tiga seed. Laporkan rata-rata dan simpangan baku. Satu angka tunggal tidak cukup untuk mengklaim berhasil atau gagal.
5. Catat lingkungan. Versi library, jenis GPU, dan waktu training. Tanpa ini, hasilmu tidak bisa dibandingkan dengan apa pun.

Kalau hasilmu berada dalam selisih wajar dari paper, itu sudah reproduksi yang jujur. Selisih wajar berbeda per bidang, tetapi sebagai patokan awal, selisih beberapa poin persen pada metrik klasifikasi biasanya lebih sering disebabkan praproses dan seed daripada arsitektur.

Prototipe minimum yang layak

Prototipe bukan notebook yang berjalan sekali. Prototipe adalah pipeline yang bisa dijalankan ulang oleh orang lain, termasuk kamu sendiri minggu depan.

Uji "overfit satu batch" adalah cara tercepat memisahkan bug kode dari masalah model. Kalau model tidak bisa menghafal 16 sampel, ada yang salah di loss, label, atau aliran gradien. Jangan lanjut ke eksperimen penuh sebelum uji ini lolos.

Contoh kerangka training yang cukup untuk sebagian besar kasus klasifikasi:

import torch
from torch.utils.data import DataLoader

def train_one_epoch(model, loader, optimizer, criterion, device):
    model.train()
    total_loss = 0.0
    for batch in loader:
        input_ids = batch["input_ids"].to(device)
        attention_mask = batch["attention_mask"].to(device)
        labels = batch["labels"].to(device)

        optimizer.zero_grad()
        logits = model(input_ids=input_ids, attention_mask=attention_mask).logits
        loss = criterion(logits, labels)
        loss.backward()
        optimizer.step()
        total_loss += loss.item()

    return total_loss / len(loader)

Perhatikan bahwa yang penting bukan potongan kodenya, melainkan tiga hal yang terlihat di dalamnya: bentuk input yang eksplisit, loss yang jelas, dan satu langkah optimisasi per batch. Kalau ketiganya benar, sisa pekerjaan adalah konfigurasi.

Kesalahan yang paling sering terjadi

Membandingkan angka dari split berbeda. Paper memakai split resmi, kamu memakai split acak sendiri. Angkanya tidak bisa dibandingkan, dan kamu akan menghabiskan waktu mengejar selisih yang sebenarnya bukan masalah model.

Melewatkan detail tokenisasi. Untuk model berbasis transformer, perbedaan cara menangani teks panjang, tanda baca, dan huruf besar bisa mengubah hasil lebih besar daripada pergantian arsitektur.

Melatih terlalu lama tanpa validasi. Tanpa validation set yang terpisah, kamu akan memilih checkpoint berdasarkan test set, dan laporanmu menjadi bias.

Menganggap repositori resmi bebas bug. Baca issues. Kalau ada laporan hasil tidak cocok, cek apakah ada perbaikan yang belum masuk ke branch utama.

Kapan berhenti dan mengubah rencana

Tetapkan batas waktu sebelum mulai. Untuk satu baris tabel, batas yang wajar adalah dua sampai tiga minggu kerja paruh waktu. Kalau setelah itu selisihnya masih jauh, periksa tiga hal secara berurutan: praproses, split data, lalu hyperparameter. Jangan langsung mengganti arsitektur.

Kalau paper tidak menyediakan cukup detail untuk direproduksi, itu temuan yang sah. Tulis sebagai keterbatasan dan pilih paper lain yang lebih lengkap. Ini lebih baik daripada menghabiskan satu semester menebak setting yang tidak pernah ditulis.

Kalau kamu membawa paper tertentu dan ingin mendampingi proses dari pembacaan sampai prototipe yang bisa diuji, Research Package kami dibuat untuk itu: pembahasan teori dari paper yang kamu bawa, protokol eksperimen, dan sesi konsultasi berulang. Untuk dasar implementasi transformer, kamu bisa mulai dari artikel sequence-to-sequence di blog ini.

Langkah berikutnya

Mulai dari abstrak, gambar metodologi, dan satu tabel. Cari kode referensi sebelum menulis dari nol. Kunci split, jalankan tiga seed, dan laporkan apa adanya. Prototipe yang jujur lebih berguna daripada angka yang bagus tetapi tidak bisa dijelaskan.

Kalau kamu ingin membahas paper yang sedang kamu baca, hubungi kami lewat WhatsApp atau lihat detail paket di halaman layanan.