Keputusan RAG vs fine-tuning sering muncul ketika perusahaan ingin AI memahami dokumen internal. Namun, “memahami data perusahaan” bisa berarti dua kebutuhan berbeda: menemukan informasi terbaru dari sumber yang tepat, atau mengikuti cara menjawab dan mengerjakan tugas yang lebih konsisten.
Jika masalahnya adalah SOP yang sering berubah, melatih ulang model belum tentu menjadi langkah pertama yang tepat. Sebaliknya, menambahkan pencarian dokumen tidak otomatis memperbaiki kebiasaan model yang gagal mengikuti format keluaran. Pemilik knowledge management dan tim TI perlu memisahkan kedua masalah sebelum menetapkan anggaran pilot.
Apa Yang Diubah Oleh RAG Dan Fine-Tuning?
Retrieval-augmented generation atau RAG mengambil informasi dari sumber eksternal dan menyertakannya sebagai konteks ketika model menjawab. Sumber dapat berupa dokumen yang telah diproses dan diindeks. Pendekatan ini berbeda dari menyimpan seluruh pengetahuan perusahaan sebagai perubahan bobot model. Definisi dasarnya tersedia pada glosarium RAG NIST.
Fine-tuning menyesuaikan model yang sudah dilatih menggunakan data contoh tambahan. Dalam rancangan tertentu, tujuannya memperbaiki perilaku pada tugas, gaya, atau format yang ditargetkan. Hasilnya tetap harus dievaluasi; proses pelatihan bukan bukti bahwa model akan selalu benar.
Perbandingan AWS mengenai RAG dan fine-tuning menjelaskan bahwa kedua pendekatan dapat digunakan bersama. Ini bukan pilihan yang selalu saling menggantikan, dan keduanya memerlukan pekerjaan data serta pengujian yang berbeda.
Pisahkan Masalah Pengetahuan Dari Masalah Perilaku
Ketika Jawaban Memerlukan Informasi Terbaru
Bayangkan petugas menanyakan prosedur persetujuan pembelian yang berlaku untuk unit tertentu. Jawaban perlu mengikuti dokumen yang disahkan, tanggal berlaku, dan hak akses petugas tersebut. Dalam skenario ilustratif ini, pencarian sumber yang benar menjadi pusat persoalan. RAG layak diuji sebagai kandidat, disertai metadata versi dan pengendalian akses.
Ketika Model Sudah Memiliki Informasi Tetapi Salah Mengerjakan Tugas
Contoh berbeda: semua informasi sudah diberikan, tetapi model sering mengisi kategori yang tidak diperbolehkan atau menyusun ringkasan dengan struktur yang berubah-ubah. Mulailah dengan instruksi, contoh, dan validasi keluaran. Fine-tuning baru menjadi kandidat jika kegagalan yang sama tetap muncul secara konsisten dan tersedia data pelatihan yang layak.
Jangan menjadikan fine-tuning sebagai respons otomatis terhadap setiap kesalahan. Identifikasi dulu apakah penyebabnya retrieval yang salah, konteks yang tidak cukup, instruksi yang bertentangan, atau kriteria penilaian yang belum jelas.
Siapkan Data Yang Berbeda Untuk Dua Pendekatan
Untuk RAG, inventaris sumber perlu menunjukkan pemilik dokumen, versi, masa berlaku, kelompok pengguna yang boleh membaca, dan mekanisme pencabutan dokumen. Dokumen hasil pindai juga membutuhkan pemeriksaan hasil ekstraksi; kualitas file asli tidak selalu sama dengan kualitas teks yang masuk ke indeks.
Untuk fine-tuning, fokusnya adalah pasangan contoh dan hasil yang diharapkan, konsistensi label, hak penggunaan data, serta pemisahan data pelatihan dan data evaluasi. Contoh yang saling bertentangan dapat mengaburkan perilaku sasaran. Menambahkan lebih banyak contoh bukan pengganti peninjauan kualitasnya.
- Pemilik pengetahuan: memutuskan sumber mana yang sah dan kapan sumber harus ditarik.
- Tim data atau ML: menyiapkan indeks atau dataset sesuai pendekatan yang diuji.
- Tim keamanan dan TI: menetapkan batas akses, penyimpanan, integrasi, serta pencatatan.
- Pengguna proses: menilai apakah jawaban atau keluaran dapat dipakai untuk pekerjaan nyata.
Jika dokumen perusahaan masih berupa hasil pindai, gunakan panduan menguji RAG dokumen pindai sebagai pemeriksaan tambahan. Keputusan memilih arsitektur tidak menghapus masalah kualitas ekstraksi.
Jangan Menyamakan RAG Dengan Jaminan Jawaban Benar
RAG dapat memberikan konteks yang relevan, tetapi rantai kerjanya masih bisa gagal. Sumber yang salah dapat terambil; potongan dokumen dapat kehilangan pengecualian penting; model dapat menyimpulkan sesuatu yang tidak didukung sumber. Kutipan juga harus diperiksa, bukan hanya ditampilkan.
Fine-tuning memiliki batas lain. Informasi yang dipelajari pada saat pelatihan tidak otomatis mengikuti pembaruan kebijakan setelahnya. Model yang mengikuti format dengan baik pun belum tentu mempunyai fakta terbaru. Karena itu, pisahkan penilaian ketepatan sumber, ketepatan isi, dan kepatuhan format.
Pengendalian dokumen tidak selesai pada tahap model. Perusahaan tetap memerlukan otorisasi yang dijalankan oleh aplikasi dan sistem sumber. Baca evaluasi RAG berdasarkan hak akses dokumen untuk membatasi jawaban sesuai pengguna.
Bandingkan Kandidat Dengan Set Uji Yang Sama
Susun pertanyaan atau tugas evaluasi yang mewakili pekerjaan. Sertakan pertanyaan yang jawabannya ada, tidak ada, sudah kedaluwarsa, dan dibatasi untuk kelompok lain. Gunakan pertanyaan yang sama saat membandingkan baseline instruksi sederhana, kandidat RAG, dan kandidat penyesuaian model bila memang diperlukan.
Nilai ketepatan jawaban terhadap sumber yang disahkan, proporsi keluaran yang harus dikoreksi, dan kemampuan menyatakan bahwa bukti tidak cukup. Ukur pula waktu pengguna untuk memeriksa hasil. Jawaban yang cepat tetapi membutuhkan pemeriksaan ulang panjang dapat mengurangi manfaat operasional.
Untuk tugas berformat, hitung keluaran yang lolos validasi struktur serta keluaran yang benar secara substansi. Kedua ukuran ini harus dipisah. Valid JSON atau kategori yang sah belum membuktikan klasifikasi bisnisnya benar.
Susun Biaya Berdasarkan Siklus Operasi
Perbandingan biaya sebaiknya memasukkan persiapan data, pengujian, penggunaan model, pemeliharaan sumber, dan koreksi manusia. Pada RAG, tanyakan siapa yang menangani pengindeksan ulang dan pencabutan akses. Pada fine-tuning, tanyakan siapa yang mengelola dataset, menjalankan evaluasi ulang, dan memutuskan kapan model perlu diperbarui.
Artikel ini tidak memberikan harga vendor atau estimasi penghematan. Harga, model yang mendukung fine-tuning, dan batas penggunaan dapat berubah. Minta penawaran berdasarkan rancangan aktual dan bedakan biaya awal dari biaya operasi. Untuk struktur pembahasan biaya, gunakan TCO pilot AI dan biaya per kasus.
Keputusan Awal Yang Dapat Diuji
Jika kebutuhan utamanya menjawab dari dokumen yang berubah, mulai dengan kandidat retrieval dan perbaikan pengelolaan sumber. Jika informasi sudah lengkap tetapi perilaku tugas belum konsisten, uji instruksi serta validasi dahulu, lalu pertimbangkan fine-tuning dengan bukti kegagalan yang jelas. Kombinasi keduanya baru layak ditambah bila masing-masing menyelesaikan masalah yang terukur.
Siapkan contoh pertanyaan, dokumen sumber, contoh jawaban yang diterima, dan alasan jawaban yang ditolak. Melalui layanan AI dan machine learning Layana, bahan tersebut dapat menjadi dasar diskusi kebutuhan data dan rancangan pilot. Pilihan akhir perlu mengikuti risiko proses, kemampuan tim, dan hasil evaluasi.
Gambar utama merupakan ilustrasi AI, bukan dokumentasi proyek Layana.