Bayangkan tim engineering Anda baru saja menyebarkan agen AI untuk mencari dokumen internal perusahaan dan menjawab pertanyaan karyawan. Semua berfungsi dengan sempurna saat pengembangan, tetapi saat produksi, agen tersebut sering kali salah atau melewatkan batasan penting. Memperbaiki hal ini jarang sekali bisa dilakukan dengan perbaikan sederhana. Ini membutuhkan proses yang melelahkan, penuh percobaan dan kesalahan, serta penyesuaian strategi pemecahan masalah, metode pengambilan, dan sistem prompt secara bersamaan. Karena penyesuaian ini saling terkait, menjadi hampir tidak mungkin untuk menentukan tweak spesifik mana yang benar-benar menyelesaikan masalah tersebut.
Untuk mengatasi tantangan ini, peneliti di Renmin University of China dan Microsoft Research memperkenalkan Arbor, sebuah kerangka kerja yang mengupgrade penelitian dan optimasi yang didorong oleh AI dari serangkaian tebakan trial-and-error menjadi proses pembelajaran kumulatif. Arbor mengorganisir hipotesis, eksperimen, dan wawasan ke dalam struktur pohon yang membantu sistem belajar dari kegagalan sebelumnya untuk melakukan perbaikan yang lebih cerdas dan terverifikasi seiring waktu.
Dalam pengujian praktis, Arbor memberikan lebih dari 2,5 kali lipat peningkatan kinerja yang terverifikasi dibandingkan agen AI standar dalam pekerjaan engineering dunia nyata sambil beroperasi di bawah anggaran sumber daya yang sama.
Bagi perusahaan yang menggunakan AI, teknik ini langsung berpengaruh untuk mengotomatiskan perbaikan berkelanjutan pada sistem engineering yang kompleks dan nyata.
Memahami bottleneck dalam optimasi otonom
Saat model bahasa besar dan sistem AI semakin canggih, mereka diharapkan dapat melakukan operasi yang lebih kompleks seperti optimasi otonom (AO) pada sistem perangkat lunak seperti pemanfaatan agen atau algoritma pelatihan model.
AO menangkap siklus dasar penelitian otonom. Sebuah agen AI memulai dengan artefak awal yang bisa diubah, seperti kode machine learning atau pipeline data, dan tujuan spesifik. Tujuan agen adalah untuk memperbaiki artefak ini secara iteratif melalui umpan balik eksperimental tanpa pengawasan manusia langkah demi langkah.
Tantangan utama dari AO sering kali disalahpahami. Banyak tim engineering menganggap bahwa memberi waktu atau komputasi lebih pada agen pengkodean untuk mengoptimalkan kode tidak selalu menghasilkan hasil yang lebih baik. “Otomatisasi bisa membuat AI bekerja sangat lama, tetapi sebuah loop bukanlah kemajuan,” kata Jiajie Jin, salah satu penulis makalah tersebut. “Jika tujuannya kabur, atau metriknya mudah direkayasa, otomatisasi yang berjalan lama hanya menghasilkan ‘perbaikan’ yang lebih cepat, tetapi tidak ada yang benar-benar diinginkan.”
Jin menjelaskan bahwa tugas kompleks membutuhkan berbagai percobaan untuk mencapai hasil yang benar, sedangkan arsitektur agen standar sering kali kekurangan struktur data penting untuk menjaga keadaan. “Bagaimana Anda memastikan wawasan dan pengalaman dari setiap percobaan benar-benar terakumulasi, bukannya hilang begitu saja?” katanya. Tanpa struktur ini, agen akan mengulangi kesalahan yang sama.
Sistem agen saat ini dapat menjalankan eksperimen selama berjam-jam dengan tujuan yang ditentukan dengan baik: mengedit kode, memanggil alat, dan menjalankan tes secara otonom. Namun, mereka memperlakukan setiap percobaan secara terpisah, sehingga kehilangan mekanisme struktural yang memungkinkan mereka mengakumulasi dan bertindak berdasarkan apa yang telah dipelajari.
Mereka tidak memiliki kapasitas untuk mempertahankan dan membandingkan beberapa arah penelitian yang bersaing secara bersamaan. Tanpa ini, mereka tidak dapat menginterpretasikan keberhasilan maupun kegagalan untuk membentuk eksplorasi di masa depan, yang merupakan mekanisme inti yang membuat penelitian manusia berkembang secara kumulatif.
Agen pengkodean umum biasanya mengandalkan transkrip percakapan untuk memori mereka. Karena tugas AO mencakup ratusan iterasi dan mudah melebihi batas konteks, agen ini kesulitan untuk mempertahankan dan menggunakan bukti faktual selama histori yang panjang. Akibatnya, mereka kehilangan struktur keseluruhan dari proses penelitian dan cenderung terjebak pada kegagalan awal atau mengikuti pergeseran evaluasi yang berisik. Sistem membutuhkan memori terstruktur dan tahan lama yang mencatat arah mana yang telah dicoba, bukti faktual yang dihasilkan, dan bagaimana masing-masing hasil mengubah ruang hipotesis di masa depan.
Kerangka kerja yang sudah ada juga rentan terhadap rekayasa umpan balik dan overfitting terhadap metrik pengembangan. Ini membuat mereka menciptakan ilusi kemajuan tanpa menghasilkan perbaikan yang dapat diterapkan dalam kinerja dunia nyata.
Akhirnya, agen pengkodean umum biasanya menghubungkan panggilan alat mereka pada sebuah struktur kerja yang sama. Keterbatasan arsitektur ini mencegah mereka menguji hipotesis paralel di lingkungan terisolasi tanpa merusak basis kode utama atau mengaburkan hipotesis mana yang menyebabkan hasil tertentu.
Kerangka kerja Arbor
Arbor mengatasi tantangan AO dengan kerangka kerja yang mengotomatiskan siklus panjang eksplorasi, eksperimen, dan abstraksi yang menjadi ciri khas penelitian manusia. Arbor memisahkan arah strategis penelitian dari tugas pengkodean dengan dua komponen utama:
Koordinator: Sebuah agen AI jangka panjang yang berfungsi sebagai peneliti utama. Ia tidak pernah langsung mengedit basis kode target. Sebaliknya, ia memiliki keadaan umum dari penelitian optimasi, mengamati bukti yang terakumulasi, menyiapkan hipotesis baru dan arah untuk dieksplorasi, serta memutuskan tindakan berdasarkan hasil eksperimen.
Eksekutor: Agen AI yang lebih pendek masa hidupnya dengan fokus tinggi. Ketika koordinator ingin menguji sebuah ide, ia mengaktifkan eksekutor dan menempatkannya di lingkungan terisolasi, yang secara esensial adalah pohon kerja git yang fresh. Setiap eksekutor diberikan satu hipotesis. Ia menerapkan ide yang ditugaskan, menjalankan evaluasi, memperbaiki kesalahan, dan melaporkan hasil serta artefak yang dibuat kembali kepada koordinator.
Kedua komponen ini bekerja sama melalui mekanisme yang disebut “Hypothesis Tree Refinement” (HTR). HTR mewakili seluruh proses penelitian sebagai pohon bercabang yang persisten, di mana setiap node mengikat empat hal: hipotesis, artefak yang dapat dieksekusi, bukti faktual yang dihasilkan, dan wawasan terdistilasi. Ini berarti koordinator dapat mengeksplorasi beberapa arah bersaing secara bersamaan tanpa kehilangan jejaknya.
Koordinator membangun pohon dengan menempatkan ide-ide luas di dekat akar, sementara perbaikan konkret bercabang sebagai daun. Ini memungkinkan Arbor untuk dengan aman mengeksplorasi banyak hipotesis bersaing secara bersamaan. Jika eksperimen seorang eksekutor gagal, pohon mencatat kenapa itu gagal sebagai batasan negatif, memastikan sistem tidak terus mengulangi kesalahan yang sama.
Untuk memahami pentingnya isolasi Arbor, pertimbangkan skenario perusahaan yang umum: mengoptimalkan pipeline Retrieval-Augmented Generation (RAG) untuk asisten AI internal. “Ketika Anda meminta satu agen seperti Claude Code atau Codex untuk ‘meningkatkan akurasi,’ biasanya ia akan mengubah banyak hal sekaligus — chunking, prompt, metode pengambilan,” kata Jin. Hal ini mengaitkan perubahan, membuatnya tidak mungkin untuk menentukan mana yang sebenarnya membantu. Itu juga langsung mengubah repositori tanpa isolasi.
Arbor menyelesaikan ini dengan memperlakukan setiap alat sebagai hipotesis terpisah. Chunking menjadi satu cabang, pengambilan yang lain, dan prompt menjadi yang lainnya — masing-masing diterapkan dan dievaluasi di pohon kerja git terisolasi. “Sehingga Anda mendapatkan atribusi yang bersih: ‘dekomposisi batasan di sisi pengambilan memberikan +X; pencarian breadth-first sebenarnya merugikan,'” kata Jin.
Ketika seorang eksekutor kembali dengan laporan, koordinator menulis bukti tersebut ke dalam pohon dan mentransfer wawasan ke atas ke node induk. Ini berarti pengamatan lokal menjadi batasan umum yang membentuk generasi ide koordinator di masa depan.
Untuk menghindari rekayasa umpan balik atau overfitting pada data pengembangan, HTR menegakkan “gerbang penggabungan” yang ketat. Bahkan jika seorang eksekutor melaporkan skor pengembangan yang luar biasa, koordinator akan mengaktifkan pohon kerja terisolasi untuk menguji kandidat melawan evaluator yang ditahan. Artefak hanya akan digabungkan ke dalam trunk terbaik saat ini jika terbukti meningkatkan skor pengujian, memverifikasi bahwa kemajuan tersebut nyata.
Arbor umumnya termasuk dalam konsep “rekayasa loop,” yang dipopulerkan oleh tokoh industri seperti pencipta OpenClaw Peter Steinberger dan pemimpin Claude Code Boris Cherny. Ideanya adalah untuk melampaui prompt tunggal untuk merancang siklus iteratif (amati, beralasan, bertindak, memverifikasi) yang menggerakkan agen otonom. Namun, seperti yang dijelaskan Jin, “Sebuah loop dapat dipenuhi dengan percobaan yang berantakan dan tidak dapat dilacak, dan Anda berakhir tanpa hasil dan tanpa cara untuk merekonstruksi apa yang berubah.”
Arbor dalam aksi
Pihak peneliti mengevaluasi Arbor pada kumpulan tugas optimasi otonom yang dibangun dari pengaturan penelitian dunia nyata dan benchmark machine learning engineering MLE-Bench Lite. Kumpulan AO ini menampilkan tugas dari berbagai bidang pengembangan AI, termasuk pelatihan model, rekayasa harness, dan sintesis data.
Pihak peneliti menggunakan berbagai model dasar untuk koordinator dan agen eksekutor, termasuk Claude Opus 4.6, GPT-5.5, dan Gemini-3-Flash. Mereka menguji Arbor melawan agen pengkode terkuat, Codex dan Claude Code. Arbor dan baseline diberikan sumber daya yang sama. Untuk tugas MLE-Bench Lite, Arbor juga dibandingkan dengan sistem penelitian agentik teratas seperti AI-Scientist, ML-Master, dan AIDE.
Arbor secara konsisten mengungguli baseline. Ia mencapai hasil uji yang terbaik pada semua tugas, mendapatkan lebih dari 2,5 kali lipat peningkatan relatif rata-rata dibandingkan Codex dan Claude Code. Pada tugas BrowseComp, yang melibatkan optimasi agen pencari, Arbor meningkatkan akurasi sistem yang ditahan dari baseline 45,33% menjadi 67,67%. Sementara itu, Codex dan Claude Code terjebak di 50% dan 53,33%, masing-masing. Pada MLE-Bench Lite, saat dilengkapi dengan GPT-5.5, Arbor mencapai hasil terkuat di antara semua sistem yang dinilai.
Arbor terbukti tahan terhadap overfitting. Misalnya, selama eksperimen tugas Terminal-Bench 2.0, Claude Code mencetak skor pengembangan tinggi 75 tetapi skornya turun menjadi 71 pada data yang ditahan. Arbor mendapat skor pengembangan lebih rendah 72,22 tetapi mencapai skor tertinggi dalam data yang ditahan yaitu 77,36, memastikan hasilnya dapat diterapkan dalam aplikasi dunia nyata.
Arbor juga menunjukkan generalisasi dalam eksperimen perpindahan lintas tugas. Setelah Arbor selesai mengoptimalkan harness pencarian untuk tugas BrowseComp, pihak peneliti mengambil basis kode yang sudah dioptimalkan dan mengujinya pada dua tugas agen pencari yang tidak terkait, yaitu HLE dan DeepSearchQA. Basis kode yang dioptimalkan oleh Arbor secara signifikan meningkatkan kinerja pada tugas yang belum dilihat tersebut.
Menjalankan Arbor: Titik manis dan biaya tersembunyi
Untuk pemimpin engineering yang ingin menerapkan Arbor pada stack teknologi yang ada, kerangka kerja ini dirancang untuk berada di atas alur kerja Git yang sudah ada alih-alih menggantinya. “Output-nya adalah cabang git biasa yang dapat diperiksa langsung oleh tinjauan kode yang ada, CI, dan tinjauan manusia,” kata Jin. Hanya peningkatan yang telah diverifikasi yang digabungkan ke dalam trunk per-run, membiarkan repositori utama tetap utuh sampai seorang pengembang secara manual memilih untuk mempromosikan kode tersebut.
Namun, menerapkan Arbor datang dengan trade-off tertentu. Jin menjelaskan bahwa tangkapan terbesar adalah biaya token, karena mempertahankan koordinator jangka panjang yang terus-menerus mengelola pohon dan mengirim eksekutor adalah biaya utama. Menjalankan beberapa pohon kerja terisolasi secara bersamaan juga memerlukan sumber daya komputasi dan disk yang nyata untuk memproses eksperimen nyata.
Jadi, di mana titik manis Arbor? Menurut Jin, Arbor unggul dalam tugas-tugas dengan metrik yang jelas dan dapat dipercaya, toleransi untuk jangka waktu yang panjang, dan ruang pencarian nyata dengan beberapa arah yang mungkin, seperti optimasi pipeline, kualitas sintesis data, dan penyesuaian resep pelatihan model.
Sebaliknya, tim sebaiknya menghindari penggunaan Arbor untuk tugas dengan latensi waktu nyata, perbaikan satu baris yang jelas, atau ketika metrik evaluasi yang mendasarinya cacat. Langit-langit kualitas dari seluruh run sangat dibatasi oleh kualitas evaluator. “Jika metriknya tidak dapat dipercaya, Arbor hanya akan mengoptimalkan hasil yang tidak dapat dipercaya lebih cepat,” kata Jin.
Jin melihat evolusi berikutnya melampaui metrik skalar tunggal. “Evolusi alami adalah memiliki artefak setiap node membawa vektor — akurasi, latensi, biaya — alih-alih satu skor tunggal,” kata Jin. “Beralih dari skalar tunggal ke pencarian Pareto multi-objektif adalah pengembangan yang sangat alami dari kerangka kerja ini.”
