Agen LLM gagal karena data race: mengapa kontrol konkurensi itu penting

9 September 20264 tampilan

Laporan posisi baru menegaskan bahwa masalah sistem multi-agen sebaiknya dipandang sebagai pelanggaran isolasi transaksi dan akses memori paralel. Para penulis mengusulkan untuk menanamkan deteksi konflik dan manajemen sumber daya bersama yang eksplisit ke dalam kerangka MAS itu sendiri, bukan menyempurnakannya setelah kejadian.

Agen LLM gagal karena data race: mengapa kontrol konkurensi itu penting

Sistem multi-agen: potensi yang luntur saat diskalakan

Janji sistem multi-agen berbasis model bahasa besar memang tampak menarik: beberapa agen LLM dapat berbagi tugas besar, saling berkonsultasi, dan bersama-sama menemukan solusi. Namun, praktik menunjukkan efek sebaliknya: semakin banyak agen yang terhubung dalam kerja sama, semakin tidak stabil sistemnya. Secara intuitif, tampaknya masalahnya ada pada koordinasi, tetapi sekelompok peneliti dalam artikel posisi di arXiv mengusulkan untuk melihat situasi ini lebih dalam.

Akar dari banyak kegagalan terletak pada cara agen mengakses keadaan bersama. Masing-masing membaca dan menulis data di penyimpanan bersama — catatan, hasil, versi fakta. Ketika jumlah akses menjadi banyak, muncullah kondisi balapan data klasik. Jika ini adalah program multithread biasa, para insinyur akan segera mencurigai masalah sinkronisasi. Tetapi karena para peserta sistem tampak "cerdas", kesalahan mereka sering dianggap sebagai kesalahpahaman, padahal sebenarnya ini adalah perilaku khas dari akses paralel ke sumber daya bersama.

"Perenungan" yang lama — dua kali lebih berbahaya

Keunikan agen LLM menambah kompleksitas tambahan. Proses penalaran model memakan waktu yang cukup lama, dan selama itu agen bekerja dengan snapshot keadaan yang dilihatnya saat permintaan dibuat. Sementara model "berpikir", agen lain tidak tinggal diam: mereka memperbarui data bersama. Ketika kembali dengan solusi yang siap, agen mungkin mendasarkan keputusannya pada gambaran dunia yang sudah usang.

Dengan bertambahnya jumlah agen, jendela pemikiran panjang seperti ini semakin banyak, dan seiring itu pula probabilitas berbagai anomali meningkat. Satu agen tidak menyadari bahwa subtugas sudah diselesaikan oleh rekannya, lalu mulai menduplikasi pekerjaan. Dua agen mencoba menulis hasil akhir, dan tulisan terakhir menimpa tulisan sebelumnya tanpa peringatan apa pun. Seseorang membaca data saat yang lain belum selesai memperbaruinya, dan mendapatkan versi antara yang tidak konsisten. Semua ini tampak seperti kekacauan, tetapi sebenarnya mengikuti pola yang sudah dikenal dari teori basis data — pembacaan usang, pembaruan yang hilang, dan pelanggaran integritas keadaan.

Kegagalan komunikasi juga hanya akibat

Mengapa begitu mudah salah mendiagnosis? Ambil contoh gangguan koordinasi. Agen-agen telah membagi peran dengan jelas dan, tampaknya, menyepakati tindakan. Tetapi jika basis fakta bersama terus berubah, satu agen mungkin bertindak berdasarkan keadaan yang sudah ditulis ulang oleh rekannya. Dari luar, ini terlihat seperti ketidakselarasan rencana atau pemahaman instruksi yang buruk. Namun, akar penyebabnya — bukan koordinasi yang lemah, melainkan tidak adanya kontrol atas akses simultan ke data.

Hal yang sama berlaku untuk komunikasi. Pesan itu sendiri mungkin disusun dengan sempurna dan dikirim tepat waktu. Tetapi jika pada saat penerima mulai memprosesnya, data bersama sudah berubah, makna pesan akan terdistorsi. Kegagalan semacam ini sangat sulit untuk direproduksi: semuanya bergantung pada ketepatan waktu. Selama jumlah agen sedikit, masalah ini hampir tidak muncul, tetapi saat diskalakan, jumlah operasi yang tumpang tindih meningkat, dan kesalahan mulai muncul dengan keteraturan yang mengkhawatirkan.

Kontrol konkurensi — sebagai fondasi, bukan tambalan

Solusi yang diusulkan para peneliti terletak pada pemindahan pendekatan yang sudah teruji dari dunia basis data ke arsitektur sistem multi-agen. Alih-alih mengandalkan LLM untuk entah bagaimana "bernegosiasi", platform harus secara eksplisit mengelola akses konkuren. Secara praktis, ini berarti tiga arah kerja:

  • Deteksi konflik. Sistem melacak upaya simultan agen untuk memodifikasi data yang sama dan mencegah tabrakan sebelum menyebabkan kerusakan hasil.
  • Jaminan isolasi. Setiap agen harus bekerja dengan snapshot keadaan yang utuh atau memiliki mekanisme yang mencegah pembacaan catatan yang belum selesai.
  • Akses terstruktur ke sumber daya. Alih-alih akses langsung ke konteks bersama, digunakan antarmuka eksplisit: kunci, versi operasi, antrean penulisan, atau pembaruan atomik.

Para penulis menekankan bahwa kontrol konkurensi tidak bisa ditambahkan setelah sistem mulai bermasalah. Ini harus menjadi keputusan arsitektural tingkat "fondasi" yang menjadi dasar bagi semua desain lainnya. Jika aturan kerja dengan keadaan bersama dipikirkan terlebih dahulu, dan koordinasi agen dibangun di atasnya, banyak masalah keandalan tidak akan sempat muncul.

Kesimpulan

Sistem multi-agen berbasis LLM memiliki potensi besar, tetapi kerentanannya tidak terkait dengan kelemahan model individual, melainkan dengan upaya kita memaksa beberapa pelaksana paralel untuk bekerja dengan satu keadaan yang berubah tanpa mekanisme perlindungan dasar. Dengan mengakui kondisi balapan data sebagai sumber utama kegagalan, pengembang mendapatkan kesempatan untuk menerapkan solusi yang sudah lama dikenal — isolasi, deteksi konflik, dan pengurutan akses. Mungkin ini kurang spektakuler dibandingkan menyempurnakan prompt, tetapi justru pendekatan inilah yang memungkinkan sistem multi-agen tetap andal seiring bertambahnya jumlah peserta.

Pertanyaan yang sering ditanyakan

Agen LLM gagal karena data race: mengapa kontrol konkurensi itu penting