RAG atau Penyetelan Halus? Pelajaran dari Proyek Klien Nyata tentang Cara Memilih

Hampir setiap percakapan tentang AI di perusahaan yang saya ikuti sampai pada pilihan yang sama dalam satu jam pertama. Klien memiliki model bahasa besar yang tampak mengesankan saat didemonstrasikan, tetapi tidak mengenal produk, kebijakan, atau gaya penulisan mereka. Seseorang di ruangan itu bertanya: haruskah kita menyetel halus model dengan data kita, atau membangun sistem generasi berbantuan pengambilan (RAG) di sekelilingnya?

Sejujurnya, pertanyaan itu biasanya dirumuskan dengan keliru. RAG dan penyetelan halus menyelesaikan masalah yang berbeda. Tim yang menganggap keduanya sebagai opsi yang saling bersaing cenderung menghabiskan waktu berbulan-bulan dan banyak anggaran GPU untuk memperbaiki hal yang salah. Berikut cara kami menentukan pilihan dalam praktik, serta hal-hal yang pernah kami lihat berhasil maupun gagal.

Mulailah dengan Menentukan Kekurangan Model

Ketika model memberikan jawaban buruk untuk tugas bisnis, ada satu dari dua hal yang kurang.

Yang kurang adalah pengetahuan. Model tidak mengetahui daftar harga terbaru, klausul dalam kontrak pemasok Anda tahun 2025, atau langkah pemecahan masalah untuk produk yang diluncurkan bulan lalu. Ini masalah fakta.

Yang kurang adalah perilaku. Model cukup tahu, tetapi tidak merespons sesuai kebutuhan Anda. Model mengabaikan format keluaran, menggunakan nada yang keliru, salah menafsirkan kode internal, atau tidak mampu menjalankan tugas spesifik yang berulang, seperti mengelompokkan tiket ke dalam 40 kategori Anda. Ini masalah keterampilan.

RAG adalah alat untuk mengatasi masalah pertama. Penyetelan halus adalah alat untuk mengatasi masalah kedua. Sebagian besar kebingungan yang saya temui muncul karena orang berusaha menggunakan penyetelan halus untuk mengajarkan fakta.

Mengapa Penyetelan Halus Bukan Cara yang Tepat untuk Menambahkan Pengetahuan

Kita mungkin tergoda untuk berpikir bahwa jika model dilatih dengan dokumen kita, model akan “mengetahui” isinya. Dalam praktiknya, model jauh lebih mampu mempelajari gaya dokumen tersebut daripada fakta di dalamnya. Para peneliti di Microsoft membandingkan kedua pendekatan itu secara langsung untuk pertanyaan yang membutuhkan banyak pengetahuan dan menemukan bahwa RAG secara konsisten mengungguli penyetelan halus tanpa pengawasan, baik untuk fakta yang pernah dipelajari model saat pelatihan maupun fakta yang benar-benar baru.

Ada juga kendala praktis. Fakta berubah. Setiap kali kebijakan atau katalog Anda berubah, model yang telah disetel halus menjadi kedaluwarsa sampai dilatih ulang. Anda juga kehilangan keterlacakan: ketika model yang telah disetel halus menyebutkan suatu angka, Anda tidak dapat menunjukkan dokumen asalnya. Bagi klien di sektor asuransi dan layanan kesehatan yang tunduk pada regulasi, hal itu saja biasanya sudah cukup untuk mengakhiri pembahasan.

RAG, yang pertama kali dijelaskan dalam makalah tahun 2020 karya Lewis dan kolega, menyimpan pengetahuan di luar model. Saat menerima pertanyaan, Anda mengambil bagian-bagian teks yang relevan dan memberikannya kepada model sebagai konteks. Untuk memperbarui pengetahuan, Anda cukup memperbarui indeks, bukan melatih ulang model. Selain itu, setiap jawaban dapat mencantumkan sumbernya.

Salah satu klien kami di bidang logistik adalah contoh yang tepat. Pelanggannya menginginkan jawaban langsung tentang lokasi kiriman mereka dan dokumen yang belum tersedia. Informasi itu berubah setiap beberapa menit. Pelatihan sebanyak apa pun tidak akan membuat model selalu mutakhir, jadi asisten yang kami bangun menjawab pertanyaan berdasarkan data pelacakan langsung dan data IoT, bukan dari ingatan. Pengambilan informasi adalah satu-satunya rancangan yang dapat berhasil.

Kapan Penyetelan Halus Berguna

Penyetelan halus belum usang. Penerapannya hanya lebih terbatas daripada yang dibayangkan orang. Kami menggunakannya dalam tiga situasi:

• Format keluaran yang ketat dan berulang. Jika model harus menghasilkan keluaran terstruktur yang sama ribuan kali sehari, misalnya mengekstrak kolom dari faktur ke dalam skema JSON tetap, model kecil yang disetel halus sering kali lebih andal dan jauh lebih murah daripada menggunakan perintah untuk model besar.
• Bahasa khusus bidang. Di sejumlah bidang, ada singkatan yang salah ditafsirkan oleh model dasar. Kode status logistik, singkatan klinis, dan kode produk internal adalah contoh umum. Penyetelan halus sederhana dapat mengatasi masalah ini.
• Biaya dan latensi dalam skala besar. Setelah tugas didefinisikan dengan baik, model kecil yang disetel halus dapat menggantikan model umum berukuran besar. Metode seperti LoRA membuatnya terjangkau karena yang dilatih hanya sekumpulan kecil bobot tambahan, bukan seluruh model.

Perhatikan bahwa tidak satu pun dari situasi ini berkaitan dengan fakta. Semuanya berkaitan dengan mengajari model cara menjalankan tugas yang sudah Anda pahami dengan baik.

Sebagian Besar Kegagalan RAG Berasal dari Kegagalan Pengambilan Informasi

Ketika sebuah tim berkata kepada saya, “Kami sudah mencoba RAG, tetapi tidak berhasil,” biasanya masalahnya bukan pada model, melainkan pada tahap pengambilan informasi. Kualitas model hanya bisa sebaik bagian-bagian teks yang diberikan kepadanya.

Perbaikannya memang tidak spektakuler, tetapi efektif:

• Buat potongan berdasarkan makna, bukan jumlah karakter. Memotong kontrak setiap 500 karakter akan membelah klausul menjadi dua. Pemotongan berdasarkan bagian dan judul akan menjaga konteks tetap utuh.
• Tambahkan konteks ke setiap potongan. Potongan yang hanya menyebutkan “batasnya adalah 30 hari” tidak berguna tanpa informasi tentang kebijakan yang dimaksud. Anthropic melaporkan bahwa menambahkan konteks singkat dari dokumen ke setiap potongan sebelum pengindeksan—pendekatan yang mereka sebut pengambilan kontekstual—mengurangi kegagalan pengambilan sebesar 49%, dan sebesar 67% jika dipadukan dengan pemeringkatan ulang.
• Gabungkan pencarian kata kunci dan pencarian vektor. Pencarian vektor unggul dalam mengenali makna, tetapi lemah dalam menangani istilah yang harus dicocokkan secara persis, seperti nomor suku cadang. Pencarian hibrida mencakup keduanya.
• Uji proses pengambilan informasi secara terpisah. Susun kumpulan pertanyaan nyata dengan bagian sumber yang diketahui benar, lalu ukur apakah bagian yang tepat muncul di antara hasil teratas sebelum menilai jawaban akhirnya.

Kapan Menggunakan Keduanya

Dalam penerapan nyata, sistem yang paling andal sering menggabungkan keduanya. RAG menyediakan fakta. Model yang hanya disetel halus menangani format, nada, dan bahasa khusus bidang. Penelitian bergerak ke arah yang sama: pendekatan RAFT dari UC Berkeley menyetel model secara khusus agar lebih baik dalam memanfaatkan dokumen yang diambil dan mengabaikan dokumen yang tidak relevan.

Namun, urutannya penting. Kami hampir selalu membangun RAG terlebih dahulu, mengukur kekurangannya, lalu memutuskan apakah penyetelan halus sepadan. Memulai dengan penyetelan halus berarti membayar biaya pelatihan sebelum mengetahui kesenjangan yang sebenarnya.

Daftar Periksa Sederhana untuk Mengambil Keputusan

1. Apakah tugas ini bergantung pada fakta yang berubah lebih dari sekali dalam satu kuartal? Gunakan RAG.
2. Apakah pengguna atau auditor perlu mengetahui sumber suatu jawaban? Gunakan RAG.
3. Apakah masalahnya terletak pada format, nada, atau kosakata jawaban, bukan pada faktanya? Pertimbangkan penyetelan halus.
4. Apakah ini tugas khusus yang dijalankan dalam volume tinggi, dengan biaya atau kecepatan sebagai pertimbangan? Pertimbangkan untuk menyetel model yang lebih kecil.
5. Sudahkah Anda mengukur kualitas pengambilan informasi secara terpisah? Jika belum, lakukan itu sebelum hal lain.

Kesimpulan

RAG dan penyetelan halus bukanlah dua pendekatan yang saling bersaing. Yang satu memberi model informasi yang tepat, sedangkan yang lain membentuk perilakunya. Pastikan Anda memahami masalah yang sebenarnya, perbaiki proses pengambilan informasi sebelum menyalahkan model, dan anggap penyetelan halus sebagai optimasi yang baru layak dilakukan setelah sistem berfungsi, bukan jalan pintas untuk membuatnya berfungsi.