Testing Regresi AI Agent: Memastikan Update Baru Tidak Merusak yang Sudah Berjalan Baik

Update Kecil yang Ternyata Merusak Hal Lain

Salah satu masalah yang sering muncul setelah AI agent berjalan cukup lama adalah update kecil di satu bagian instruksi ternyata mengubah perilaku di bagian lain yang tidak disangka-sangka. Tim menambahkan aturan baru untuk menangani satu kasus spesifik, lalu beberapa hari kemudian baru sadar bahwa penambahan itu membuat agent jadi lebih kaku atau salah menjawab kasus lain yang sebelumnya berjalan baik.

Ini setara dengan apa yang di dunia pengembangan software disebut regresi, yaitu perubahan yang dimaksudkan untuk memperbaiki sesuatu, tapi tanpa sengaja merusak sesuatu yang lain yang sebelumnya sudah bekerja dengan benar.

Kenapa AI Agent Rentan terhadap Ini

Instruksi atau prompt yang mengatur perilaku AI agent biasanya berupa teks yang saling berkaitan, bukan kode dengan struktur modular yang jelas batasannya seperti software konvensional. Menambah satu kalimat instruksi bisa saja mengubah cara model menafsirkan kalimat instruksi lain di dekatnya, meski keduanya kelihatan tidak berhubungan langsung. Basis pengetahuan yang dipakai agent untuk menjawab pertanyaan juga bisa punya efek serupa, menambah satu dokumen baru kadang membuat agent lebih sering mengutip dokumen itu untuk pertanyaan yang sebenarnya lebih cocok dijawab dari sumber lain.

Bedanya dengan Red-Teaming dan A/B Testing yang Sudah Umum Dibahas

Red-teaming pre-launch fokus menguji ketahanan agent terhadap percobaan penyalahgunaan sebelum sistem pertama kali dipakai. A/B testing membandingkan dua versi untuk melihat mana yang performanya lebih baik. Testing regresi punya fokus berbeda, yaitu memastikan versi baru tidak menjadi lebih buruk dibanding versi sebelumnya untuk kasus-kasus yang dulu sudah terbukti berjalan benar. Ketiganya saling melengkapi, bukan saling menggantikan.

Cara Sederhana Menerapkannya Tanpa Tim Teknis Besar

  • Menyimpan kumpulan contoh pertanyaan dan jawaban yang sudah dianggap benar, idealnya diambil dari percakapan nyata pelanggan, bukan hanya contoh buatan tim.
  • Setiap kali ada perubahan instruksi atau penambahan data, jalankan ulang kumpulan contoh itu dan bandingkan jawabannya dengan hasil sebelumnya, bukan cuma menguji kasus baru yang jadi alasan perubahan.
  • Kalau ada jawaban yang berubah untuk contoh lama, itu bukan berarti otomatis salah, tapi wajib dicek dulu apakah perubahannya memang disengaja atau efek samping yang tidak diinginkan.
  • Menyimpan catatan riwayat perubahan instruksi seiring waktu, supaya kalau muncul masalah, tim bisa menelusuri perubahan mana yang paling mungkin jadi penyebabnya.

Penutup

Testing regresi terdengar seperti istilah teknis yang rumit, padahal intinya sederhana yaitu jangan hanya menguji hal baru, tapi juga pastikan hal lama tetap bekerja seperti sebelumnya. Kebiasaan ini terasa merepotkan di awal, tapi jauh lebih murah dibanding menemukan sendiri dari komplain pelanggan bahwa sesuatu yang dulu berjalan baik kini jadi salah jawab.

Leave a Comment