Di episode #49 kemarin saya melihat model lahir dari pipeline panjang: pretraining, SFT, lalu RLHF/DPO. Kali ini saya mau masuk lebih dalam ke satu jenis model yang belakangan muncul di mana-mana: reasoning model. Inti yang saya catat sederhana — model ini diberi “waktu berpikir” tambahan saat dijalankan, bukan saat dilatih. Di dunia teknis ini disebut test-time compute, dan ternyata ada riset yang menunjukkan cara ini bisa lebih efektif daripada sekadar memperbesar jumlah parameter model.
Chain-of-thought: kenapa “berpikir dulu” membantu
Bayangkan dua cara menjawab soal matematika. Cara pertama: model langsung menebak jawaban akhir seperti function yang langsung return. Cara kedua: model menulis langkah-langkah dulu — menyebut angka, mengurutkan operasi, baru menyimpulkan. Cara kedua jauh lebih jarang salah, karena model “mengerjakan” soalnya di konteksnya sendiri, bukan menebak dari pola terakhir token.
Inilah chain-of-thought. Yang menarik, ini bukan trik prompting saja — model reasoning modern memang dilatih menghasilkan jejak penalaran panjang itu sebelum jawaban akhir. Jejak ini sering disebut “thinking” atau “reasoning trace”, dan di beberapa produk muncul sebagai panel terpisah yang bisa dibuka user.
Test-time compute: kompute yang dibelanjakan saat inferensi
Di episode #47 dan #48 saya membahas bahwa biaya melatih model itu besar dan terjadi sekali. Test-time compute memindahkan sebagian “usaha” ke saat model dipakai: semakin banyak token penalaran yang dihasilkan untuk satu pertanyaan, semakin besar peluang jawabannya benar. Analogi programmer-nya: bukan menulis function yang sempurna sekali jadi, tapi memberi function itu loop iterasi sampai hasilnya lolos kondisi berhenti.
Ada temuan riset yang membuat saya berhenti sejenak. Paper Snell dkk. (ICLR 2025, “Scaling LLM Test-Time Compute Optimally Can Be More Effective than Scaling Parameters for Reasoning”) menemukan bahwa mengalokasikan kompute inferensi secara adaptif per soal bisa meningkatkan efisiensi lebih dari 4x dibanding baseline best-of-N pada soal matematika — dan pada soal yang cukup sulit, model kecil dengan test-time compute yang cukup bisa mengalahkan model 14x lebih besar dengan FLOPs yang sama. Artinya: pilihan antara “model besar diam-diam” dan “model kecil tapi rajin berpikir” bukan pilihan yang jelas sebelum kita ukur.
Bagaimana model seperti ini dilatih
Titik baliknya adalah rilis DeepSeek-R1 (January 2025, paper arXiv 2501.12948). Inti metodenya: reinforcement learning murni dengan reward berbasis hasil — apakah jawaban akhir benar atau tidak — tanpa mengajarkan format penalaran secara manual. Dari proses itu jejak berpikir yang terstruktur muncul sendiri, yang oleh timnya disebut “aha moment”. R1 juga menunjukkan jalur distilasi: penalaran yang mahal dihasilkan model besar, lalu dipindahkan ke model kecil lewat SFT. Ini nyambung langsung dengan materi post-training di episode #49 — reasoning model bukan arsitektur baru, melainkan hasil tahap pelatihan yang berbeda.
Kapan worth it, kapan buang-buang token
Saya merangkum keputusannya seperti ini:
| Tugas | Pakai | Alasan |
|---|---|---|
| Bug kompleks, desain arsitektur, matematika, perencanaan multi-langkah | Reasoning model | Salah langkah awal = salah hasil akhir; biaya token sepadan |
| Ringkasan, klasifikasi, ekstraksi field, format JSON | Model biasa | Tidak butuh penalaran panjang; reasoning menambah latensi tanpa nilai |
| Tidak yakin | Uji dua-duanya | Bandingkan di eval kecil milik sendiri (episode #30) |
Dua peringatan yang saya catat. Pertama, reasoning itu mahal dan lambat — token penalaran dihitung seperti token biasa, jadi biayanya naik dan latensi memanjang (relevan dengan pembelian biaya di episode #43). Kedua, ada kecenderungan overthinking: survey “Reasoning on a Budget” (arXiv 2507.02076) mencatat banyak model menerapkan jumlah kompute inferensi yang tetap tanpa melihat kesulitan soal — mengerjakan soal mudah terlalu lama, sementara soal sulit justru kurang. Makanya beberapa produk kini menyediakan pengaturan upaya penalaran (low/medium/high) atau mode thinking hibrida yang bisa dimatikan, supaya developer bisa menyesuaikan anggaran per tugas.
Praktik di produk
Yang saya terapkan saat memilih model reasoning untuk produk: (1) tentukan dulu tugas mana yang benar-benar butuh penalaran, (2) ukur dengan eval kecil sendiri — bukan benchmark publik, (3) pantau jumlah token penalaran per permintaan sebagai metrik biaya, (4) sediakan fallback ke model biasa kalau reasoning gagal atau terlalu lambat. Pola “router ke model murah dulu, naik ke mahal kalau gagal” ini akan kita bahas lebih serius di episode #62 soal biaya dan skala.
Inti pelajaran untuk saya: reasoning model bukan “AI yang lebih pintar” secara ajaib — ia hanya mengalokasikan lebih banyak kompute ke saat menjawab, dan itu keputusan engineering yang bisa kita ukur, batasi, dan bayar sesuai kebutuhan.
Sumber
- DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning — arXiv:2501.12948, Januari 2025
- A Survey of Test-Time Compute: From Intuitive Inference to Deliberate Reasoning — arXiv:2501.02497, 2025
- Reasoning on a Budget: A Survey of Adaptive and Controllable Test-Time Compute in LLMs — arXiv:2507.02076, Juli 2025
- Scaling LLM Test-Time Compute Optimally Can be More Effective than Scaling Parameters for Reasoning — Snell dkk., ICLR 2025
- Episode terkait di seri ini: #47 Transformer dari Dalam, #48 Tokenisasi & Context Window, #49 Pretraining ke Post-Training, #30 Evals untuk LLM & Agent, #43 AI di Produksi
Komentar Terbaru