Mengatasi Konflik Steering dan Abstensi pada Model Frozen Language

Masalah: Dilema Antara Akurasi dan Efisiensi pada Frozen LLM

Saat menggunakan model bahasa beku (*frozen language models*) untuk tugas penalaran, pengembang menghadapi dua kelemahan yang saling terkait. Pertama, model gagal memanfaatkan bukti yang sebenarnya sudah tersimpan dalam *residual stream* mereka sendiri. Kedua, model gagal mendeteksi ketika input tidak cukup untuk menjawab, sehingga terjadi konfabulasi.

Untuk mengatasi hal ini, dua jalur penelitian sering diterapkan secara terpisah. *Conditional steering probe* menulis ulang *residual stream* pada lapisan tengah untuk memulihkan akurasi penalaran dari *backbone* beku. Sementara itu, *zero-shot sufficiency direction* membaca *residual stream* untuk mendeteksi kapan informasi tidak cukup dan model harus melakukan abstensi. Namun, saat kedua teknik ini dijalankan bersamaan dalam satu *forward pass*, terjadi interferensi yang merusak kinerja keduanya.

Mengapa Interferensi Terjadi dalam Satu Forward Pass

Masalah inti terletak pada manipulasi *residual stream*. *Steering probe* menulis informasi pada lapisan tengah untuk meningkatkan akurasi penalaran, tetapi tindakan ini secara tidak sengaja menggeser *state* yang dibaca oleh *sufficiency direction* untuk menentukan kecukupan input.

Jika Anda mencoba menjalankan kedua proses secara terpisah untuk menghindari interferensi, biaya inferensi menjadi dua kali lipat karena memerlukan *forward pass* tambahan. Sebaliknya, jika dijalankan bersamaan tanpa mitigasi, terjadi penurunan transfer lintas domain hingga 8 poin AUROC pada model kecil. Hal ini menciptakan dilema praktis: akurasi tinggi dengan biaya ganda, atau efisiensi tinggi dengan akurasi yang terganggu.

Dilema ini sangat relevan bagi pengembang yang men-deploy model dalam produksi. Biaya inferensi ganda tidak praktis untuk skala besar, sementara penurunan AUROC yang signifikan mengurangi keandalan sistem abstensi yang justru dirancang untuk mencegah jawaban yang tidak dapat diandalkan.

Solusi: Implementasi Arsitektur YOPO

Metode YOPO (You Only Pass Once) menggabungkan tiga fungsi—menjawab (*answering*), mengarahkan (*steering*), dan abstensi (*abstaining*)—dalam satu *forward pass* pada model beku. Pendekatan ini diuji pada *backbone* Qwen2.5 dengan ukuran 1.5B, 3B, dan 7B.

1. Mempertahankan Arah Abstensi Tetap

Alih-alih melatih ulang *sufficiency direction*, YOPO mempertahankan arah deteksi dalam kondisi aslinya. Ini memastikan bahwa deteksi tetap mampu membaca informasi yang diperlukan untuk menentukan apakah input cukup atau tidak, tanpa terpengaruh oleh perubahan yang diperkenalkan oleh *steering*.

2. Rekonstruksi Residual Stream dengan Jaringan Kecil

Komponen kunci YOPO adalah melatih jaringan kecil untuk merekonstruksi *residual stream* asli (sebelum *steering*) dari *residual stream* yang telah dimanipulasi (*steered*).

Langkah-langkah implementasinya:

3. Eksekusi Satu Pass

Setelah jaringan rekonstruksi dilatih, sistem bekerja sebagai berikut:

Pendekatan ini memungkinkan ketiga operasi berjalan tanpa interferensi karena *sufficiency direction* membaca rekonstruksi *pre-steering*, bukan *state* yang sudah dimanipulasi.

Hasil dan Pertimbangan Evaluasi

Berdasarkan paper, YOPO melaporkan peningkatan akurasi tiga arah dibandingkan *baseline* beku. Namun, penting untuk dicatat bahwa paper sendiri mengidentifikasi bahwa konstruksi *alphaNLI* yang mereka gunakan mengandung kebocoran artefak permukaan (*surface artifact*). Oleh karena itu, klaim arsitektur utama dianchor pada replikasi dengan label asli (*native-label*) menggunakan dataset SQuAD2, RepLiQA, dan MuSiQue.

YOPO melaporkan bahwa satu *pass* mengungguli referensi dua *pass* di setiap skala model yang diuji dan pada sepuluh *backbone* dari enam keluarga model. Paper juga menyatakan bahwa *label-free direction* adalah satu-satunya keluarga *gate* yang bertahan transfer lintas domain, dan menyajikan *benchmark* answer-or-abstain pada empat domain.

Untuk pengembang yang ingin menerapkan pendekatan ini, perhatikan bahwa hasil pada *alphaNLI* mungkin tidak sepenuhnya mencerminkan kemampuan arsitektur karena masalah kebocoran data yang diidentifikasi penulis sendiri. Evaluasi pada dataset dengan label asli seperti SQuAD2, RepLiQA, dan MuSiQue memberikan gambaran yang lebih dapat diandalkan tentang kinerja sebenarnya dari sistem ini.