Anda membangun alat internal yang memungkinkan tim menjalankan 28 unit test pada fitur berbasis LLM tanpa pernah memanggil API model tersebut. Anda melakukannya dengan membungkus model dalam antarmuka yang dapat di-fake (fakeable interface) dan menambahkan tiga lapisan evaluasi: deterministik, heuristik, dan berbasis LLM.

Assertion standar akan langsung rusak saat LLM menghasilkan prosa. Prompt yang sama dapat menghasilkan kalimat yang berbeda pada setiap sesi, sehingga assertEqual(output, expected) akan menandai kegagalan bahkan ketika model berperilaku dengan benar. Sebagian besar grup engineering memilih untuk merilis fitur tanpa verifikasi atau mencoba menguji model itu sendiri, memperlakukan target yang terus berubah seolah-olah itu adalah library statis.

Mengapa masalah ini penting

LLM kini berada di dalam alur kerja yang berhadapan langsung dengan pelanggan—seperti email outreach, balasan dukungan (support replies), dan pembuatan konten. Satu fakta halusinasi atau kebocoran identitas dapat merusak reputasi merek, mengekspos data pribadi, atau memicu pelanggaran kepatuhan. Tanpa strategi pengujian yang andal, tim membuang waktu mengejar kegagalan yang flaky atau merilis bug yang hanya muncul saat sudah di tahap produksi.

Pendekatan: perkecil tanggung jawab model

Langkah pertama adalah membatasi apa yang sebenarnya dilakukan oleh LLM. Dalam sistem penulis, model hanya bertugas menyusun draf pesan outreach. Semua logika routing, manajemen state, dan pemeriksaan keamanan tetap berada di dalam kode biasa. Dengan membatasi model pada satu output yang terdefinisi dengan baik, sistem di sekitarnya tetap deterministik dan dapat diuji.

Untuk memungkinkan hal tersebut, LLM ditempatkan di balik sebuah antarmuka penyedia (provider interface), yang memungkinkan versi fake digunakan dalam pengujian. Di produksi, implementasinya memanggil API eksternal; dalam test suite, sebuah fake yang ringan mengembalikan respons yang sudah disiapkan (canned response). Karena sisa kode hanya berinteraksi dengan antarmuka tersebut, seluruh alur kerja dapat dijalankan melalui unit test yang tidak pernah menyentuh jaringan. Hasilnya adalah inti sistem yang dapat diprediksi yang diverifikasi oleh 28 test tersebut.

Harness evaluasi yang jujur

Bahkan dengan cakupan yang dipersempit, output model tetap tidak deterministik. Oleh karena itu, penulis membangun evaluation harness tiga lapis, di mana setiap lapisan menangani kelas risiko yang berbeda.

  • Lapisan 1 – Pemeriksaan deterministik Aturan regular-expression sederhana menangkap kesalahan konkret seperti ID bangunan yang salah atau token yang dilarang. Pemeriksaan ini cepat dan memberikan hasil lulus/gagal yang biner.

  • Lapisan 2 – Pemeriksaan heuristik Skrip mencari angka atau tanggal yang terhalusinasi, menandai fabrikasi faktual yang nyata. Skrip ini mungkin melewatkan klaim palsu yang tidak memiliki petunjuk numerik, dan penulis secara terbuka mengakui keterbatasan tersebut.

  • Lapisan 3 – LLM judge Model sekunder menilai nada dan profesionalisme. Karena langkah ini mengandalkan sistem probabilistik lainnya, ia hanya digunakan untuk aspek subjektif di mana aturan deterministik tidak mungkin diterapkan.

Kunci dari harness ini adalah dataset yang digunakan untuk evaluasi. Penulis menyandikan pola kegagalan yang diketahui—jebakan spesifik dan pengetahuan domain—sehingga harness tersebut menguji tepat pada kesalahan yang pernah muncul dalam praktik. Ini bukanlah "penangkap segala" yang ajaib, melainkan jaring pengaman yang terarah.

Apa artinya ini bagi tim

  • Batasi tugas LLM. Tanggung jawab yang lebih sedikit membuat isolasi dan pengujian menjadi lebih mudah.
  • Letakkan routing, state, dan keamanan di dalam kode. Logika tradisional tetap deterministik dan dapat diuji sepenuhnya.
  • Ekspos model melalui antarmuka yang dapat di-fake. Unit test berjalan tanpa panggilan eksternal, menjaga suite tetap cepat dan andal.
  • Gunakan evaluasi berlapis. Mulailah dengan aturan deterministik, tambahkan heuristik untuk halusinasi yang diketahui, dan simpan LLM judge untuk pemeriksaan kualitas yang subjektif.
  • Nyatakan batasannya. Tidak ada lapisan yang menjamin kesempurnaan; harness hanya menangkap apa yang Anda program secara eksplisit untuk dideteksi.

Sanggahan: Anda tetap tidak bisa melakukan unit-test pada model itu sendiri

Penulis mengakui bahwa model adalah target yang terus bergerak. Bahkan lapisan LLM judge mewarisi nondeterminisme yang sama dengan apa yang coba ia nilai. Akibatnya, sistem tidak pernah bisa menjamin bahwa setiap halusinasi atau pelanggaran kebijakan akan tertangkap sebelum rilis. Pendekatan ini mengurangi risiko, bukan menghilangkannya, dan ia bergantung pada kemampuan tim untuk menjaga data evaluasi tetap mutakhir seiring munculnya mode kegagalan baru.

Kesimpulan

Anda tidak dapat menulis unit test klasik yang memastikan output persis dari sebuah LLM, tetapi Anda dapat membangun sistem di mana pengaruh model dibatasi, antarmukanya dapat diganti, dan outputnya disaring melalui pemeriksaan berlapis yang transparan. Kombinasi tersebut mengubah komponen yang semula flaky menjadi bagian yang dapat diprediksi dari aplikasi yang lebih besar dan dapat diuji.