Dua agen AI dapat mengedit file yang sama, keduanya menerima konfirmasi “success”, namun hanya satu perubahan yang tersimpan. Dalam pengujian sederhana dengan lima agen konkuren, empat dari lima penulisan hilang tanpa ada kesalahan atau entri log—sebuah anomali lost-update klasik yang membuang-buang token yang telah dibayarkan untuk pekerjaan yang lenyap tersebut.
Mengapa masalah ini penting
Saat agen AI menuliskan kembali sebuah hasil, layanan yang mendasarinya mengenakan biaya per token yang dihasilkan. Jika penulisan tersebut tertimpa secara diam-diam, penyedia layanan tetap menagih biaya komputasi yang menghasilkan output yang terbuang tersebut. Dalam alur kerja multi-agen—seperti agent swarms, pekerja pembersihan data paralel, atau sistem apa pun di mana beberapa bot berbagi file rencana atau scratchpad—kerugian tersembunyi ini dapat membengkak menjadi kebocoran biaya yang signifikan. Anomali ini juga mengancam integritas data: langkah-langkah selanjutnya mungkin bertindak berdasarkan informasi yang tidak lengkap atau usang, yang menyebabkan kesalahan beruntun (cascading errors).
Bagaimana anomali ini terjadi
Penyebab utamanya adalah race condition:
- Dua (atau lebih) agen membaca versi sumber daya yang sama, misalnya file rencana JSON.
- Masing-masing melakukan penalaran atau transformasi berdasarkan cuplikan (snapshot) tersebut.
- Kedua agen melakukan operasi penulisan kembali ke penyimpanan bersama.
- Sistem penyimpanan menerima penulisan kedua, menimpa penulisan pertama tanpa ada deteksi konflik.
- Kedua agen menerima “ACK” yang mengonfirmasi bahwa penulisan berhasil, meskipun kontribusi pertama telah hilang.
Konfirmasi dari sistem penyimpanan hanya membuktikan bahwa penulisan telah terjadi; hal itu tidak menjamin bahwa penulisan tersebut aman terhadap pembaruan konkuren lainnya. Log append-only, yang sering dianggap sebagai pengaman, berperilaku dengan cara yang sama: ia mencatat bahwa penulisan telah terjadi tetapi tidak mencegah penulisan berikutnya menimpa penulisan sebelumnya.
Apa yang dilakukan gerbang compare-and-set
Gerbang compare-and-set (CAS) menambahkan pemeriksaan versi sebelum penulisan diterima:
- Read: Agen mengambil nomor versi saat ini (atau hash) dari file tersebut.
- Compute: Agen melakukan pekerjaannya, menghasilkan versi baru dari file tersebut.
- Write: Agen mengirimkan konten baru bersama dengan versi yang dibacanya di awal.
- Validate: Lapisan penyimpanan membandingkan versi yang diberikan dengan versi saat ini. Jika berbeda, penulisan ditolak; jika tidak, proses berlanjut dan versi ditingkatkan.
Jika versi telah berubah, agen mengetahui bahwa tampilannya sudah usang dan harus mengulang seluruh siklus—baca, hitung, tulis—menggunakan versi terbaru. Hal ini mengubah penimpaan yang tidak terlihat menjadi kegagalan eksplisit yang dapat dicatat, dicoba kembali, dan dipertanggungjawabkan.
Harga dari sebuah keamanan
Gerbang CAS tidaklah gratis. Dalam simulasi lima agen yang sama:
| Skenario | Penulisan yang dicoba | Kontribusi berhasil | Biaya token |
|---|---|---|---|
| Tanpa gerbang CAS | 5 | 1 | 5 unit |
| Dengan gerbang CAS | 5 | 5 (setelah pengulangan) | 9 unit |
Gerbang ini menambah siklus baca-hitung-tulis ekstra bagi agen yang mengalami konflik versi, sehingga meningkatkan pengeluaran token. Pertukarannya jelas: tanpa gerbang Anda kehilangan data secara diam-diam; dengan gerbang Anda membayar premi yang moderat tetapi mendapatkan visibilitas terhadap setiap konflik.
Seberapa umum kegagalan ini terjadi?
Bahkan dengan hanya dua agen, pengujian menunjukkan peluang 75% bahwa salah satu penulisan akan hilang. Dengan lima agen, tingkat kehilangan mendekati 100%. Angka-angka tersebut menunjukkan bahwa asumsi “biasanya baik-baik saja” adalah asumsi yang berbahaya untuk alur kerja multi-agen tingkat produksi mana pun.
Argumen tandingan: kapan harus melewatkan gerbang ini
Jika sebuah sistem menjalankan satu agen per sumber daya atau menerapkan serialisasi ketat pada tingkat yang lebih tinggi, pemeriksaan CAS tambahan mungkin tidak diperlukan. Namun, perhitungan risiko harus menyertakan biaya tersembunyi dari menjalankan kembali pekerjaan yang gagal dan potensi dampak hilangnya data pada langkah selanjutnya.
Apa yang perlu diperhatikan selanjutnya
- Dukungan alat (Tooling support): Cari API penyimpanan yang mengekspos nomor versi atau ETag dan menyediakan operasi CAS atomik secara langsung.
- Metrik: Pasang instrumen pada agen Anda untuk mencatat seberapa sering penulisan ditolak karena ketidakcocokan versi. Tingkat konflik yang meningkat menandakan bahwa Anda perlu menskalakan sumber daya atau merancang ulang alur kerja.
- Strategi pengulangan (Retry strategies): Exponential back-off sederhana bekerja dengan baik, tetapi sadarilah bahwa pengulangan yang berulang kali akan meningkatkan konsumsi token. Seimbangkan batas pengulangan dengan kehilangan data yang dapat diterima.
- Pendekatan hibrida: Beberapa tim menggabungkan log append-only untuk auditabilitas dengan gerbang CAS untuk konsistensi, guna memastikan adanya catatan tentang apa yang terjadi sekaligus perlindungan terhadap penimpaan.
Kesimpulan
Anomali lost-update mengubah pipeline AI berbasis token menjadi lubang hitam yang menguras uang. Gerbang versi compare-and-set menambah sedikit overhead token, tetapi mengubah kehilangan data yang tidak terdeteksi menjadi peristiwa yang terlihat dan dapat dicoba ulang. Untuk sistem apa pun di mana beberapa agen berbagi state—seperti database, file rencana, atau scratchpad—menyematkan pemeriksaan versi sebelum penulisan adalah asuransi termurah terhadap biaya tersembunyi dan alur kerja yang rusak.