Agen AI Mengeluarkan Sampah? Masalahnya adalah Anda Tidak Rela Membakar Token

Penulis: Systematic Long Short

Diterjemahkan: Deep潮 TechFlow

Deep潮 Pengantar: Inti dari artikel ini hanya satu kalimat: kualitas output AI Agent sebanding dengan jumlah Token yang Anda investasikan.

Penulis tidak berbicara secara umum tentang teori, melainkan memberikan dua metode konkret yang bisa langsung digunakan hari ini, dan dengan jelas menentukan batasan di mana tumpukan Token tidak bisa lagi diandalkan—yaitu masalah «Novelty».

Bagi pembaca yang sedang menggunakan Agent untuk menulis kode atau menjalankan workflow, informasi yang disajikan sangat padat dan dapat langsung dioperasikan.

Pendahuluan

Baiklah, Anda harus mengakui bahwa judul ini cukup menarik perhatian—tapi sungguh, ini bukan lelucon.

Pada tahun 2023, saat kita masih menggunakan LLM untuk menjalankan kode produksi, orang-orang di sekitar kita terkejut karena persepsi umum saat itu adalah bahwa LLM hanya bisa menghasilkan sampah yang tidak berguna. Tapi kita tahu satu hal yang tidak disadari orang lain: kualitas output dari Agent adalah fungsi dari jumlah Token yang Anda berikan. Sesederhana itu.

Anda bisa membuktikannya sendiri dengan melakukan beberapa eksperimen. Misalnya, minta Agent menyelesaikan tugas pemrograman yang kompleks dan agak tidak umum—misalnya, mengimplementasikan dari awal algoritma optimisasi konveks dengan batasan tertentu. Mulai dengan tingkat pemikiran terendah; lalu tingkatkan ke tingkat tertinggi, minta dia review kode sendiri dan lihat berapa banyak bug yang bisa ditemukan. Coba semua tingkat pemikiran—menengah, tinggi. Anda akan melihat secara langsung: jumlah bug berkurang secara monoton seiring dengan peningkatan jumlah Token yang digunakan.

Tidak sulit dipahami, kan?

Lebih banyak Token = Lebih sedikit kesalahan. Anda bisa melangkah lebih jauh dari logika ini, yang pada dasarnya adalah inti dari proses review kode (yang disederhanakan). Dalam konteks yang sama sekali berbeda, jika Anda menginvestasikan sejumlah besar Token (misalnya, membiarkan Agent menganalisis kode baris per baris dan menilai apakah ada bug), maka Anda bisa menangkap sebagian besar, bahkan semua bug. Proses ini bisa diulang sepuluh, seratus kali, setiap kali dari sudut pandang yang berbeda terhadap basis kode, dan akhirnya Anda bisa menemukan semua bug yang ada.

Gagasan bahwa «semakin banyak Token yang digunakan, semakin baik kualitas Agent» juga didukung oleh bukti empiris: tim-tim yang mengklaim bisa menulis kode langsung ke produksi sepenuhnya dengan Agent, biasanya adalah penyedia model dasar itu sendiri atau perusahaan dengan dana sangat besar.

Jadi, jika Anda masih frustrasi karena Agent tidak mampu menghasilkan kode produksi—saya katakan secara jujur, masalahnya ada di Anda. Atau, lebih tepatnya, di kantong Anda.

Bagaimana menilai apakah Token yang Anda gunakan cukup

Saya pernah menulis satu artikel lengkap yang menyatakan bahwa masalahnya bukan pada kerangka kerja (harness) yang Anda bangun, dan bahwa «menjaga kesederhanaan» tetap bisa menghasilkan sesuatu yang hebat, dan saya tetap berpegang pada pendapat itu. Jika Anda membacanya, mengikuti petunjuknya, tetapi tetap kecewa dengan output Agent, dan mengirim DM kepada saya—saya sudah membaca tapi tidak membalas.

Ini adalah balasan saya.

Kinerja buruk dan ketidakmampuan menyelesaikan masalah dari Agent biasanya disebabkan oleh kurangnya Token yang digunakan.

Berapa banyak Token yang diperlukan untuk menyelesaikan sebuah masalah sepenuhnya tergantung pada skala, kompleksitas, dan tingkat keunikannya.

Contohnya, pertanyaan sederhana seperti «2+2 berapa?», tidak membutuhkan banyak Token.

Namun, permintaan seperti «Buatkan saya sebuah bot yang bisa memindai semua pasar antara Polymarket dan Kalshi, temukan pasar yang secara semantik mirip dan seharusnya diselesaikan dalam urutan tertentu, tetapkan batasan arbitrase tanpa risiko, dan otomatis melakukan trading dengan latensi rendah saat peluang arbitrase muncul»—ini membutuhkan penggunaan Token yang sangat banyak.

Dalam praktik, kami menemukan sesuatu yang menarik.

Jika Anda menginvestasikan cukup banyak Token untuk menangani masalah yang timbul dari skala dan kompleksitasnya, Agent pasti bisa menyelesaikannya. Dengan kata lain, jika Anda ingin membangun sesuatu yang sangat kompleks, dengan banyak komponen dan baris kode, selama Anda menginvestasikan cukup banyak Token ke dalam masalah tersebut, semuanya akan terselesaikan secara tuntas.

Ada satu pengecualian kecil tapi penting.

Masalah Anda tidak boleh terlalu baru atau inovatif. Pada tahap ini, tidak peduli berapa banyak Token yang Anda gunakan, masalah «Novelty» tetap tidak bisa diatasi. Banyak Token bisa mengurangi kesalahan yang disebabkan oleh kompleksitas ke nol, tetapi tidak bisa membuat Agent menciptakan sesuatu yang benar-benar baru dan tidak diketahui sebelumnya.

Sebenarnya, kesimpulan ini memberi kita sedikit kelegaan.

Kami telah menghabiskan banyak tenaga dan mengorbankan banyak Token—sangat banyak—untuk mencoba agar Agent bisa merekonstruksi proses investasi institusional dengan sedikit panduan. Tujuannya adalah untuk memahami berapa tahun lagi kita (sebagai peneliti kuantitatif) akan digantikan sepenuhnya oleh AI. Hasilnya, kami menemukan bahwa Agent sama sekali tidak mampu mendekati proses investasi institusional yang layak. Kami berpendapat ini karena mereka belum pernah melihat hal semacam itu—artinya, proses investasi institusional tidak ada dalam data pelatihan mereka.

Jadi, jika masalah Anda adalah sesuatu yang baru dan inovatif, jangan berharap bisa menyelesaikannya hanya dengan menumpuk Token. Anda harus memimpin proses eksplorasi sendiri. Tapi, begitu Anda sudah memiliki solusi yang pasti, Anda bisa dengan tenang menginvestasikan Token sebanyak yang diperlukan—tidak peduli seberapa besar basis kode atau sekompleks apa pun komponen-komponennya.

Ada satu prinsip heuristik sederhana: anggaran Token harus meningkat secara proporsional dengan jumlah baris kode.

Apa yang sebenarnya dilakukan Token yang lebih banyak

Dalam praktiknya, Token tambahan biasanya meningkatkan kualitas engineering Agent melalui beberapa cara berikut:

Memberikan kesempatan agar Agent menghabiskan lebih banyak waktu untuk beralasan dalam satu percobaan, sehingga berpeluang menemukan kesalahan logika sendiri. Semakin dalam proses beralasan = perencanaan yang lebih baik = peluang keberhasilan yang lebih tinggi.

Mengizinkan Agent melakukan beberapa percobaan independen, mencoba berbagai jalur solusi. Beberapa jalur lebih baik dari yang lain. Dengan mencoba lebih dari sekali, Agent bisa memilih yang terbaik.

Demikian pula, lebih banyak percobaan perencanaan independen memungkinkan Agent untuk menolak arah yang lemah dan mempertahankan yang paling menjanjikan.

Token yang lebih banyak juga memungkinkan Agent menggunakan konteks yang baru untuk mengkritik pekerjaan sebelumnya, memberi kesempatan untuk perbaikan, bukan terjebak dalam «inertia» beralasan yang sama.

Tentu saja, ada satu hal favorit saya: lebih banyak Token berarti Agent bisa menggunakan pengujian dan alat bantu untuk memverifikasi. Menjalankan kode secara nyata dan melihat apakah berjalan dengan benar adalah cara paling andal untuk memastikan jawaban yang benar.

Logika ini berjalan karena kegagalan engineering Agent bukanlah sesuatu yang acak. Hampir selalu disebabkan oleh memilih jalur yang salah terlalu dini, tidak memeriksa apakah jalur tersebut benar-benar bisa dilalui (pada tahap awal), atau tidak cukup anggaran untuk melakukan pemulihan dan rollback setelah menemukan kesalahan.

Cerita ini seperti itu. Secara harfiah, Token adalah kualitas keputusan yang Anda beli. Bayangkan sebagai pekerjaan penelitian: jika Anda meminta seseorang menjawab soal sulit secara langsung, kualitas jawaban akan menurun seiring meningkatnya tekanan waktu.

Pada akhirnya, penelitian adalah tentang menghasilkan sesuatu yang mendasar: «mengetahui jawaban». Manusia menghabiskan waktu biologis untuk menghasilkan jawaban yang lebih baik, sedangkan Agent menghabiskan lebih banyak waktu komputasi untuk mencapai hal yang sama.

Bagaimana meningkatkan Agent Anda

Anda mungkin masih ragu, tapi banyak makalah yang mendukung hal ini, dan jujur saja, keberadaan parameter «reasoning» itu sendiri adalah bukti utama bahwa ini memang jalan yang benar.

Salah satu makalah favorit saya, para peneliti melatih model dengan sejumlah kecil contoh reasoning yang dirancang dengan cermat, lalu memaksa model untuk terus berpikir saat ingin berhenti—caranya adalah dengan menambahkan «Wait» (tunggu) di tempat dia ingin berhenti. Hanya satu langkah ini saja sudah meningkatkan performa benchmark dari 50% menjadi 57%.

Saya ingin menyampaikan secara langsung: jika Anda terus mengeluh bahwa kode yang dihasilkan Agent kurang memuaskan, kemungkinan besar tingkat pemikiran maksimal dalam satu kali proses masih belum cukup.

Saya berikan dua solusi yang sangat sederhana.

Solusi sederhana pertama: WAIT (Tunggu)

Langkah paling mudah yang bisa Anda mulai hari ini: buat sebuah loop otomatis—setelah selesai, biarkan Agent melakukan review sebanyak N kali dengan konteks baru, dan setiap kali menemukan masalah, langsung diperbaiki.

Jika Anda menemukan trik sederhana ini meningkatkan performa engineering Agent Anda, setidaknya Anda memahami bahwa masalahnya hanya soal jumlah Token—maka, bergabunglah dengan klub penggunaan Token.

Solusi sederhana kedua: VERIFY (Verifikasi)

Biarkan Agent memverifikasi pekerjaannya sejak dini dan secara berkala. Tulis pengujian untuk memastikan jalur yang dipilih benar-benar bisa dijalankan. Ini sangat berguna untuk proyek yang sangat kompleks dan bersarang dalam—misalnya, sebuah fungsi yang dipanggil oleh banyak fungsi lain di hilir. Menangkap kesalahan di hulu akan menghemat banyak waktu komputasi (Token) di kemudian hari. Jadi, jika memungkinkan, buatlah checkpoint verifikasi di seluruh proses pembangunan.

Setelah menulis sesuatu dan mengklaim selesai, minta Agent lain untuk memverifikasi. Aliran pemikiran yang tidak terkait bisa menutupi sumber bias sistematis.

Itu saja. Saya bisa menulis banyak tentang topik ini, tapi saya rasa cukup dengan menyadari kedua hal ini dan menerapkannya dengan baik, Anda bisa menyelesaikan 95% masalah. Saya yakin, melakukan hal-hal sederhana secara maksimal, lalu menambahkan kompleksitas sesuai kebutuhan.

Saya sudah menyebutkan bahwa «Novelty» adalah masalah yang tidak bisa diselesaikan hanya dengan Token, dan saya ingin menegaskan lagi, karena Anda pasti akan menghadapi jebakan ini suatu saat dan mengeluh kepada saya bahwa menumpuk Token tidak berguna.

Ketika masalah yang ingin Anda selesaikan tidak ada dalam data pelatihan, Anda adalah orang yang benar-benar harus menyediakan solusi. Oleh karena itu, pengetahuan domain tetap sangat penting.