Banyak tim yang sedang mengembangkan sistem retrieval augmented generation (RAG) untuk klasifikasi yang berisiko tinggi mengambil keputusan arsitektur yang sama: mengarahkan setiap kasus ambigu langsung ke model bahasa dan mengandalkan konteks yang diambil untuk menyelesaikan masalah. Konsep ini mungkin terlihat baik pada demo, namun semuanya bisa berantakan ketika sistem harus menghadapi audit atau ditanya oleh regulator mengenai mengapa keputusan tertentu diambil enam bulan lalu.
Selama setahun terakhir, banyak tim membangun sistem klasifikasi berbasis RAG dalam konteks bisnis yang diatur, dimana biaya untuk jawaban yang salah bukan hanya sekadar respons chatbot yang buruk. Setiap keputusan harus dapat dipertanggungjawabkan dalam jangka waktu yang lama setelah model menghasilkan jawabannya. Lingkungan seperti ini memaksa adanya filosofi desain yang berbeda dari kebanyakan konten teknik AI yang ada saat ini.
Berikut ini yang berubah ketika Anda tidak dapat bersikap probabilistik pada segalanya, dan bagaimana arsitektur cascade dapat menyelesaikannya.
Biaya tersembunyi dari jalur LLM yang semuanya
Daya tarik dari mengarahkan segalanya melalui model bahasa besar (LLM) jelas: lebih sedikit bagian yang bergerak, iterasi lebih cepat, dan model mampu menangani kasus yang tidak terduga. Namun, masalahnya akan muncul kemudian di tiga aspek.
Pertama, auditabilitas. “Model memutuskan berdasarkan konteks yang diambil” bukanlah jawaban yang dapat diterima. Anda memerlukan jalur keputusan yang dapat direkonstruksi oleh manusia tanpa harus menjalankan lagi inferensi dan berharap mendapat output yang sama.
Kedua, biaya seiring pertumbuhan. Jika sistem Anda memproses puluhan ribu kasus sehari dan setiap kasus menyentuh panggilan LLM dengan beberapa dokumen yang diambil sebagai konteks, tagihan inferensi dan latensi Anda akan meningkat seiring volume, berbeda dengan logika berbasis aturan yang tidak demikian.
Ketiga, dan yang jarang dibicarakan, adalah drift model pada kasus yang mudah. LLM sangat baik dalam keputusan yang bernuansa. Mereka sering tidak konsisten, dalam cara yang sulit dideteksi, pada kasus yang seharusnya memiliki jawaban deterministik. Pencocokan yang jelas terhadap kriteria yang dikenal tidak boleh bergantung pada suasana hati model bahasa.
Pendekatan cascade
Solusinya: berhenti memperlakukan LLM sebagai garis depan dan mulai memperlakukannya sebagai jalur eskalasi. Dalam praktiknya, ini berarti pipeline tiga tahap.
Tahap pertama adalah deterministik. Pencocokan yang tepat, perbandingan field terstruktur, dan apa pun yang memiliki aturan jelas diselesaikan di sini tanpa panggilan model sama sekali. Tahap ini harus menyelesaikan sebagian besar volume, sering kali lebih dari setengahnya tergantung pada kualitas data Anda, dan setiap keputusan sepenuhnya dapat dijelaskan karena merupakan pencarian, bukan inferensi.
Tahap kedua adalah di mana pengambilan bukti mendapatkan perannya. Bagi kasus yang berhasil melalui tahap satu — dan maksud saya bertahan adalah bahwa mereka tidak jelas diselesaikan — Anda membangun lapisan pengambilan yang menarik bukti spesifik yang relevan dengan ambiguitas tersebut: keputusan peninjau sebelumnya pada kasus serupa, dokumen kontekstual yang menjelaskan konflik yang apparent, atau preseden sejarah yang menjernihkan kasus pinggiran. Langkah pengambilan lebih penting daripada langkah generasi di sini. Jika Anda mengambil konteks yang salah, bahkan model bahasa terbaik di dunia sekalipun akan menghasilkan jawaban salah yang tampak meyakinkan dan terfikirkan dengan baik.
Tahap ketiga adalah panggilan LLM, dan seharusnya hanya melihat sisa yang tidak dapat diselesaikan oleh tahap satu dan dua. Ini adalah aspek yang sering dilewatkan ketika mendesain versi pertama, dan ini adalah pengungkit terbesar untuk biaya dan kualitas. Dalam satu sistem yang saya kerjakan, mengarahkan hanya 10 hingga 15% kasus yang benar-benar ambigu ke LLM mengurangi biaya inferensi sekitar 6X dibandingkan baseline LLM penuh, sekaligus meningkatkan konsistensi pada mayoritas deterministik menjadi efektif sempurna.
Mendesain prompt untuk risiko asimetris
Setelah sebuah kasus sampai di tahap LLM, sebagian besar tim akan menggunakan prompt netral: “Tentukan apakah kasus ini harus disetujui atau ditandai.” Pemaknaan ini kurang tepat untuk klasifikasi berisiko tinggi karena biaya dari dua jenis kesalahan tersebut tidak simetris. Mengabaikan sesuatu yang benar-benar memerlukan perhatian bisa berakibat serius, sementara salah menandai sesuatu yang baik hanya menguras waktu peninjau dan menyebabkan keterlambatan. Dua hasil ini jarang sama buruknya, namun prompt netral meminta model untuk memperlakukan keduanya seolah-olah sama.
Prompt risiko asimetris menjadikan tradeoff ini eksplisit kepada model alih-alih membiarkannya menebak toleransi risiko Anda. Secara konkret, ini berarti menginstruksikan model untuk memperlakukan ketidakpastian sebagai alasan untuk eskalasi, memberikan contoh terukur dari kedua jenis kesalahan dengan konsekuensi yang dijelaskan, dan meminta skor kepercayaan bersamaan dengan klasifikasi alih-alih jawaban biner. Skor kepercayaan menjadi titik cascade kedua Anda: apa pun yang berada di bawah ambang tertentu diarahkan kepada peninjau manusia alih-alih diselesaikan secara otomatis, terlepas dari apa yang dikatakan klasifikasi model.
Ini mungkin terdengar seperti detail kecil dalam rekayasa prompt. Namun, dalam praktiknya, ini adalah perbedaan antara sistem yang mengurangi beban kerja peninjau dan satu yang diam-diam meningkatkan risiko sambil terlihat seolah-olah berfungsi dengan baik.
Menilai sistem seperti ini dengan tepat
Metrik evaluasi RAG standar tidak dibangun dengan kasus penggunaan ini dalam pikiran, dan menggunakannya tanpa penyesuaian akan memberikan rasa percaya diri yang salah. Ada beberapa penyesuaian yang perlu diperhatikan.
Kualitas pengambilan perlu diukur terpisah dari akurasi klasifikasi akhir. Sebuah sistem dapat memiliki skor peringkat pengambilan yang sangat baik dan tetap membuat keputusan akhir yang buruk jika langkah generasi memperberat bukti secara tidak tepat. Lacak mereka secara independen.
Set data evaluasi Anda perlu melakukan oversampling secara deliberatif pada kasus yang mencapai tahap ketiga, karena itu adalah di mana penilaian sistem Anda benar-benar diuji. Jika set evaluasi Anda mencerminkan distribusi produksi Anda, itu akan didominasi oleh kasus deterministik yang sudah ditangani dengan baik oleh cascade Anda, dan Anda akan buta terhadap kegagalan yang paling penting.
Evaluasi LLM sebagai hakim bekerja untuk domain ini tapi hanya jika prompt hakim menyimpan pemaknaan risiko asimetris yang sama dengan prompt produksi Anda. Seorang hakim yang memperlakukan kedua jenis kesalahan secara setara akan secara sistematis mendukung tradeoff yang salah saat Anda menyetel sistem.
Akhirnya, bangunlah umpan balik dari hasil yang dikonfirmasi kembali ke dalam corpus pengambilan Anda. Ketika seorang peninjau manusia membatalkan keputusan model, kasus tersebut dan resolusi yang benar harus menjadi konteks yang dapat diambil untuk kasus serupa di masa depan. Tanpa ini, penanganan kasus ambigu oleh sistem Anda tidak akan pernah membaik; ia hanya akan terus membuat jenis kesalahan yang sama dengan tingkat yang sama.
Pelajaran yang Lebih Luas
Insting untuk memilih model yang paling mampu untuk setiap keputusan sangat dapat dipahami, namun dalam domain di mana jawaban yang salah memiliki konsekuensi nyata, pekerjaan rekayasa yang lebih berharga adalah menentukan bagian mana yang seharusnya tidak pernah menyentuh model sama sekali. Arsitektur cascade bukanlah solusi sementara untuk keterbatasan LLM. Ini adalah apa yang tampak seperti sistem RAG yang matang setelah Anda benar-benar harus mempertahankan keputusan terhadap seseorang yang tugasnya adalah menemukan celah dalam logika Anda.
Jika Anda sedang membangun sistem AI untuk domain yang diatur atau berisiko tinggi, pertanyaan yang patut diajukan sebelum menulis satu prompt pun bukanlah “Bagaimana agar model dapat menangani ini dengan baik,” tetapi “Bagian mana dari keputusan ini yang seharusnya tidak pernah menjadi tanggung jawab model?”
