Kualitas Output Agen AI Berhubungan dengan Pembakaran Token

Penulis: Systematic Long Short

Diterjemahkan oleh Deep潮 TechFlow

DeepChao导读：这篇文章的核心论点只有一句话：AI Agent 的输出质量与您投入的 Token 数量成正比。

Penulis tidak membahas teori secara umum, tetapi memberikan dua metode spesifik yang bisa langsung digunakan hari ini, serta secara jelas menetapkan batasan di mana Token tidak bisa dibangun—masalah 'kebaruan'.

Untuk pembaca yang sedang menulis kode atau menjalankan alur kerja menggunakan Agent, kepadatan informasi dan keterlaksanaannya sangat tinggi.

Baiklah, Anda harus mengakui bahwa judul ini memang menarik perhatian—tapi serius, ini bukan lelucon.

Pada tahun 2023, ketika kami masih menggunakan LLM untuk menjalankan kode produksi, orang-orang di sekitar kami terkejut, karena pada saat itu pemahaman umum adalah LLM hanya menghasilkan sampah yang tidak bisa digunakan. Tetapi kami mengetahui satu hal yang tidak disadari orang lain: kualitas output Agent adalah fungsi dari jumlah Token yang Anda gunakan. Itu saja.

Anda bisa melihatnya sendiri dengan menjalankan beberapa eksperimen. Biarkan Agent menyelesaikan tugas pemrograman yang kompleks dan agak jarang—misalnya, mengimplementasikan algoritma optimasi konveks dengan kendala dari awal. Pertama, gunakan tingkat pemikiran terendah; kemudian beralih ke tingkat pemikiran tertinggi, biarkan ia meninjau kodenya sendiri dan lihat berapa banyak bug yang bisa ditemukan. Coba juga tingkat menengah dan tinggi. Anda akan secara intuitif melihat: jumlah bug berkurang secara monoton seiring peningkatan jumlah Token yang diinvestasikan.

Ini tidak sulit dipahami, kan?

Semakin banyak token = semakin sedikit kesalahan. Anda bisa mendorong logika ini lebih jauh; ini pada dasarnya adalah ide inti (yang disederhanakan) di balik produk review kode. Dalam konteks sama sekali baru, gunakan sejumlah besar token (misalnya, biarkan ia menganalisis kode baris demi baris, menilai apakah setiap baris memiliki bug) — dengan cara ini, Anda hampir pasti dapat menemukan sebagian besar, bahkan semua bug. Proses ini dapat diulang sepuluh kali, seratus kali, setiap kali memandang repositori kode dari "sudut pandang yang berbeda," dan pada akhirnya Anda akan mampu mengungkap semua bug.

Pandangan bahwa "semakin banyak Token yang dibakar, semakin meningkat kualitas Agent" didukung oleh bukti empiris: tim yang mengklaim dapat menggunakan Agent untuk menulis kode secara penuh dan langsung mendorongnya ke produksi, baik merupakan penyedia model dasar itu sendiri, atau perusahaan dengan dana yang sangat besar.

Jadi, jika Anda masih kesulitan membuat Agent menghasilkan kode produksi—bilang saja jujur, masalahnya ada pada Anda. Atau, lebih tepatnya, ada pada dompet Anda.

Saya pernah menulis seluruh artikel yang menyatakan bahwa masalahnya sama sekali bukan pada kerangka (harness) yang Anda bangun—tetap sederhana pun tetap bisa menghasilkan sesuatu yang luar biasa, dan saya masih mempertahankan pandangan ini. Anda sudah membaca artikel itu, mengikuti petunjuknya, tetapi tetap kecewa dengan output Agent. Anda mengirimkan DM kepada saya, dan saya sudah membacanya, tetapi belum membalas.

This one is the reply.

Kinerja Agent-mu buruk dan tidak bisa menyelesaikan masalah, sebagian besar karena kamu membakar Token yang tidak cukup.

Jumlah Token yang diperlukan untuk menyelesaikan sebuah masalah sepenuhnya tergantung pada skala, kompleksitas, dan kebaruan masalah tersebut.

「2+2 sama dengan berapa？」Tidak memerlukan banyak Token.

"Buatkan saya bot yang dapat memindai semua pasar di Polymarket dan Kalshi, menemukan pasar yang secara semantik serupa dan seharusnya diselesaikan pada peristiwa yang sama, menetapkan batas arbitrase tanpa risiko, dan secara otomatis melakukan perdagangan dengan latensi rendah begitu ada peluang arbitrase" — ini akan menghabiskan banyak Token.

Kami menemukan hal yang menarik dalam praktiknya.

Jika Anda menginvestasikan cukup banyak Token untuk menangani masalah yang disebabkan oleh skala dan kompleksitas, agen pasti akan menyelesaikannya. Dengan kata lain, jika Anda ingin membangun sesuatu yang sangat kompleks dengan banyak komponen dan baris kode, selama Anda mencurahkan cukup banyak Token ke dalam masalah-masalah tersebut, pada akhirnya semuanya akan teratasi sepenuhnya.

Ada satu pengecualian kecil namun penting.

Pertanyaanmu tidak bisa terlalu baru. Pada tahap saat ini, berapa pun jumlah Token tidak dapat menyelesaikan masalah "kebaruan". Jumlah Token yang cukup banyak dapat mengurangi kesalahan yang disebabkan oleh kompleksitas hingga nol, tetapi tidak dapat membuat Agent menciptakan sesuatu yang tidak diketahuinya.

Kesimpulan ini sebenarnya membuat kita lega.

Kami menghabiskan banyak usaha, membakar—sangat, sangat, sangat banyak—Token, untuk mencoba apakah Agent dapat merekonstruksi proses investasi institusional tanpa panduan sama sekali. Sebagian alasan ini adalah untuk memahami seberapa jauh kami (sebagai peneliti kuantitatif) masih jauh dari penggantian total oleh AI. Hasilnya, Agent sama sekali tidak mampu mendekati proses investasi institusional yang layak. Kami percaya sebagian alasannya adalah mereka belum pernah melihat hal semacam ini—artinya, proses investasi institusional sama sekali tidak ada dalam data pelatihan.

Jadi, jika pertanyaan Anda bersifat baru, jangan harap bisa menyelesaikannya hanya dengan mengumpulkan Token. Anda perlu memandu proses eksplorasi sendiri. Namun, setelah Anda menentukan solusi implementasi, Anda bisa dengan tenang mengumpulkan Token untuk menjalankannya—tidak masalah seberapa besar kodebase atau seberapa kompleks komponennya.

Ada prinsip heuristik sederhana: anggaran token harus meningkat sebanding dengan jumlah baris kode.

Dalam praktiknya, token tambahan biasanya meningkatkan kualitas teknis Agent melalui beberapa cara berikut:

Luangkan lebih banyak waktu untuk bernalar dalam satu upaya yang sama, sehingga memiliki peluang untuk menemukan kesalahan logika sendiri. Semakin dalam nalar = semakin baik perencanaan = semakin tinggi peluang keberhasilan pada percobaan pertama.

Izinkan itu melakukan beberapa upaya independen, menempuh jalur pemecahan yang berbeda. Beberapa jalur lebih baik daripada yang lain. Dengan mengizinkan lebih dari satu upaya, ia dapat memilih yang paling optimal.

Demikian pula, lebih banyak upaya perencanaan mandiri mencoba memungkinkannya melepaskan arah lemah dan mempertahankan yang paling menjanjikan.

Lebih banyak token memungkinkannya mengevaluasi pekerjaan sebelumnya dalam konteks baru, memberinya kesempatan untuk memperbaiki diri, bukan terjebak dalam 「inersia penalaran」 tertentu.

Tentu, dan yang paling saya sukai: lebih banyak token berarti dapat diverifikasi dengan pengujian dan alat. Menjalankan kode secara langsung untuk melihat apakah ia berjalan adalah cara paling andal untuk memastikan jawaban benar.

Logika ini berjalan karena kegagalan teknis Agent bukanlah acak. Hampir selalu disebabkan oleh pemilihan jalur yang salah terlalu dini, tidak memeriksa apakah jalur tersebut benar-benar dapat ditempuh (pada tahap awal), atau tidak memiliki anggaran yang cukup untuk memulihkan dan mundur setelah menemukan kesalahan.

Ceritanya seperti ini. Token secara harfiah adalah kualitas keputusan yang Anda beli. Bayangkan ini sebagai pekerjaan penelitian: jika Anda meminta seseorang menjawab pertanyaan sulit secara langsung, kualitas jawabannya akan menurun seiring meningkatnya tekanan waktu.

Penelitian, pada dasarnya, adalah hal dasar yang menghasilkan “mengetahui jawaban”. Manusia menghabiskan waktu secara biologis untuk menghasilkan jawaban yang lebih baik, sedangkan Agent menghabiskan lebih banyak waktu komputasi untuk menghasilkan jawaban yang lebih baik.

Anda mungkin masih ragu-ragu, tetapi banyak makalah yang mendukung hal ini; sejujurnya, keberadaan tombol pengatur "reasoning" saja sudah cukup menjadi bukti yang Anda butuhkan.

Sebuah makalah favorit saya, peneliti melatih dengan sejumlah kecil sampel penalaran yang dipilih dengan cermat, lalu menggunakan metode untuk memaksa model terus berpikir saat ingin berhenti—yaitu dengan menambahkan "Wait" (tunggu) di tempat yang ingin dihentikannya. Hanya dengan hal ini, hasil pada sebuah pengujian patokan naik dari 50% menjadi 57%.

Saya ingin mengatakannya sejelas mungkin: jika Anda terus mengeluh bahwa kode yang ditulis oleh Agent kurang memuaskan, level pemikiran tertinggi sekali jalan mungkin masih belum cukup untuk Anda.

Saya berikan Anda dua solusi sangat sederhana.

Cara sederhana satu: WAIT (tunggu)

Hal paling sederhana yang bisa kamu mulai lakukan hari ini: buat siklus otomatis—setelah dibangun, biarkan Agent meninjau N kali dengan konteks baru, dan perbaiki setiap kali menemukan masalah.

Jika kamu menemukan trik sederhana ini meningkatkan efektivitas teknik Agent-mu, maka kamu setidaknya menyadari bahwa masalahmu hanyalah masalah jumlah Token—mari bergabung dengan klub pembakaran Token.

Cara sederhana kedua: VERIFY (Verifikasi)

Biarkan Agent memverifikasi pekerjaannya sejak dini dan secara sering. Tulis pengujian untuk membuktikan bahwa jalur yang dipilih benar-benar berjalan. Ini sangat berguna untuk proyek yang sangat kompleks dan memiliki kedalaman nesting—suatu fungsi mungkin dipanggil oleh banyak fungsi lain di hilir. Menangkap kesalahan di hulu dapat menghemat banyak waktu komputasi (Token) di tahap selanjutnya. Jadi, jika memungkinkan, atur "titik verifikasi" di sepanjang proses pembangunan.

Setelah menyelesaikan satu bagian, agen utama mengatakan selesai? Biarkan agen kedua memverifikasi ulang. Alur pemikiran yang tidak relevan dapat menutupi sumber bias sistematis.

It's basically just these two points. I could write much more on this topic, but I believe that if you simply recognize these two things and implement them well, they will solve 95% of your problems. I firmly believe in mastering the simple things and adding complexity only as needed.

Saya sudah menyebutkan bahwa "novelty" adalah masalah yang tidak bisa diselesaikan dengan Token, dan saya ingin menekankan lagi, karena suatu hari nanti Anda akan menghadapi masalah ini, lalu datang mengeluh kepada saya bahwa menumpuk Token tidak berguna.

Ketika masalah yang ingin Anda selesaikan tidak ada dalam dataset pelatihan, Anda lah orang yang benar-benar perlu menyediakan solusinya. Oleh karena itu, keahlian domain tetap sangat penting.