Dua ejen AI boleh menyunting fail yang sama, kedua-duanya menerima pengakuan “berjaya”, namun hanya satu daripada perubahan mereka yang kekal. Dalam ujian ringkas dengan lima ejen serentak, empat daripada lima penulisan hilang tanpa sebarang ralat atau catatan log—sebuah anomali “lost-update” klasik yang membazirkan token yang telah dibayar untuk kerja yang hilang tersebut.
Mengapa masalah ini penting
Apabila ejen AI menulis semula hasil, perkhidmatan asas akan mengenakan caj bagi setiap token yang dijana. Jika penulisan tersebut dipadam secara senyap (overwritten), penyedia tetap mengenakan caj untuk pengiraan yang menghasilkan output yang dibuang itu. Dalam saluran paip (pipeline) berbilang ejen—seperti kumpulan ejen (agent swarms), pekerja pembersihan data selari, atau mana-mana sistem di mana beberapa bot berkongsi fail pelan atau buku nota (scratchpad)—kerugian tersembunyi ini boleh melonjak menjadi kebocoran kos yang ketara. Anomali ini juga mengancam integriti data: langkah-langkah seterusnya mungkin bertindak berdasarkan maklumat yang tidak lengkap atau lapuk, yang membawa kepada ralat berantai (cascading errors).
Bagaimana anomali ini berlaku
Punca utamanya ialah keadaan perlumbaan (race condition):
- Dua (atau lebih) ejen membaca versi sumber yang sama, contohnya fail pelan JSON.
- Setiap ejen melakukan penaakulan atau transformasi sendiri berdasarkan tangkapan skrin (snapshot) tersebut.
- Kedua-dua ejen mengeluarkan operasi penulisan kembali ke storan kongsi.
- Sistem storan menerima penulisan kedua, memadam penulisan pertama tanpa sebarang pengesanan konflik.
- Kedua-dua ejen menerima “ACK” yang mengesahkan penulisan berjaya, walaupun sumbangan pertama telah hilang.
Pengakuan sistem storan hanya membuktikan bahawa penulisan telah berlaku; ia tidak menjamin bahawa penulisan tersebut selamat berbanding kemas kini serentak yang lain. Log append-only, yang sering dianggap sebagai pelindung, berkelakuan dengan cara yang sama: ia merekodkan bahawa penulisan telah berlaku tetapi tidak menghalang penulisan kemudian daripada memadam penulisan sebelumnya.
Apa yang dilakukan oleh gerbang compare-and-set
Gerbang compare-and-set (CAS) menambah semakan versi sebelum penulisan diterima:
- Read (Baca): Ejen mengambil nombor versi semasa (atau hash) fail tersebut.
- Compute (Kira): Ejen melakukan kerjanya, menghasilkan versi fail yang baharu.
- Write (Tulis): Ejen menghantar kandungan baharu bersama dengan versi yang dibacanya pada asalnya.
- Validate (Sahkan): Lapisan storan membandingkan versi yang dibekalkan dengan versi semasa. Jika ia berbeza, penulisan ditolak; jika tidak, ia diteruskan dan versi akan ditingkatkan.
Jika versi telah berubah, ejen akan mengetahui bahawa pandangannya sudah lapuk dan mesti mengulangi keseluruhan kitaran—baca, kira, tulis—menggunakan versi yang segar. Ini menukarkan tindakan pemadaman senyap kepada kegagalan eksplisit yang boleh dicatatkan, dicuba semula, dan diambil kira.
Harga bagi keselamatan
Gerbang CAS tidak percuma. Dalam simulasi lima ejen yang sama:
| Senario | Percubaan penulisan | Sumbangan berjaya | Kos token |
|---|---|---|---|
| Tanpa gerbang CAS | 5 | 1 | 5 unit |
| Dengan gerbang CAS | 5 | 5 (selepas cubaan semula) | 9 unit |
Gerbang tersebut menambah kitaran baca-kira-tulis tambahan untuk ejen yang menghadapi konflik versi, sekali gus meningkatkan perbelanjaan token. Pertukaran (trade-off) ini jelas: tanpa gerbang, anda kehilangan data secara senyap; dengan gerbang, anda membayar premium yang sederhana tetapi mendapat keterlihatan terhadap setiap konflik.
Sejauh manakah kegagalan ini biasa berlaku?
Walaupun dengan hanya dua ejen, ujian menunjukkan 75% kemungkinan bahawa salah satu penulisan akan hilang. Dengan lima ejen, kadar kehilangan menghampiri 100%. Angka-angka tersebut menunjukkan bahawa anggapan “biasanya okay” adalah satu andaian yang berbahaya bagi mana-mana aliran kerja berbilang ejen pada tahap pengeluaran (production).
Hujah balas: bila perlu melangkau gerbang
Jika sesebuah sistem menjalankan ejen tunggal bagi setiap sumber atau menguatkuasakan penserilkan (serialization) yang ketat pada tahap yang lebih tinggi, semakan CAS tambahan mungkin tidak diperlukan. Walau bagaimanapun, pengiraan risiko mesti merangkumi kos tersembunyi untuk menjalankan semula kerja yang gagal dan potensi impak hiliran akibat kehilangan data.
Apa yang perlu diperhatikan seterusnya
- Sokongan alatan (Tooling support): Cari API storan yang mendedahkan nombor versi atau ETag dan menyediakan operasi CAS atomik secara terus.
- Metrik: Pasang instrumen pada ejen anda untuk merekodkan kekerapan penulisan ditolak disebabkan ketidakpadanan versi. Kadar konflik yang meningkat menandakan anda perlu menskalakan sumber atau mereka bentuk semula aliran kerja.
- Strategi cubaan semula (Retry strategies): Kaedah exponential back-off yang ringkas berfungsi dengan baik, tetapi perlu sedar bahawa cubaan semula yang berulang kali meningkatkan penggunaan token. Imbangkan had cubaan semula dengan kehilangan data yang boleh diterima.
- Pendekatan hibrid: Sesetengah pasukan menggabungkan log append-only untuk keboleh-audit dengan gerbang CAS untuk ketekalan, bagi memastikan terdapat rekod tentang apa yang berlaku dan perlindungan terhadap pemadaman data.
Kesimpulan
Anomali kemas kini yang hilang menukarkan saluran paip AI berasaskan token menjadi lubang hitam yang membocorkan wang. Gerbang versi compare-and-set menambah beban tambahan token yang kecil, tetapi menukarkan kehilangan data secara senyap kepada peristiwa yang nyata dan boleh dicuba semula. Bagi mana-mana sistem di mana pelbagai ejen berkongsi keadaan—pangkalan data, fail pelan, atau nota lakaran—menyematkan semakan versi sebelum penulisan adalah insurans termurah terhadap kos tersembunyi dan aliran kerja yang rosak.