RAG & Pengetahuan

Tuning Halus atau Mengambil: Keputusan tentang Apa yang Berubah, Bukan Preferensi Anda

Pengaturan halus mengkodekan perilaku; pengambilan menyediakan fakta. Bertanya mana yang lebih baik adalah bertanya pertanyaan yang salah — tanyakan seberapa sering pengetahuan dasar berubah dan apakah Anda harus mengutipnya.

Dua Mekanisme yang Sering Disalahartikan

Fine-tuning mengubah bobot. Retrieval mengubah prompt. Mereka sering dibahas sebagai teknik yang bersaing untuk pekerjaan yang sama, itulah mengapa banyak tim memilih salah satu berdasarkan insting dan kemudian menghabiskan waktu sekuarter untuk menemukan mengapa tidak sesuai.

Mereka memecahkan masalah yang berbeda. Fine-tuning baik dalam bentuk: nada, bentuk output, kepatuhan tugas, idiom domain. Retrieval baik dalam konten: fakta spesifik, dokumen yang tidak ada saat pelatihan, apa pun yang perlu Anda kutip.

Aturan Keputusan

Mulai dengan dua pertanyaan. Pertama: seberapa sering pengetahuan ini berubah? Apa pun yang memiliki kadens lebih pendek dari siklus pelatihan ulang Anda harus dimasukkan dalam retrieval, karena model yang telah fine-tuning menjadi usang secara diam-diam dan Anda tidak akan menyadari sampai pengguna melakukannya. Kedua: apakah Anda perlu menunjukkan dari mana jawaban berasal? Jika ya, retrieval tidak opsional — pembaruan bobot tidak dapat menghasilkan kutipan.

Hanya setelah kedua pertanyaan tersebut kembali menguntungkan Anda harus mempertimbangkan fine-tuning. Kasus yang tersisa sempit tetapi nyata: Anda memerlukan perilaku atau format yang stabil yang tidak dapat diproduksi secara andal oleh prompting, pada anggaran token atau latensi yang membuat retrieval menjadi lebih buruk.

Mode Kegagalan Masing-Masing

Fine-tuning gagal secara diam-diam. Model menjadi fasih dalam kosakata domain Anda sementara tetap percaya salah tentang fakta saat ini, dan karena terdengar benar, tidak ada yang memeriksa. Ini juga menciptakan kewajiban pemeliharaan: setiap upgrade model dasar berarti mengulangi pelatihan dan menjalankan evaluasi ulang.

Retrieval gagal secara terlihat, yang merupakan fitur. Retrieval yang buruk menghasilkan konteks yang tidak relevan, dan Anda dapat mengukurnya. Biayanya adalah Anda sekarang memiliki pipeline: parsing, chunking, embedding, kesegaran indeks, dan filtering izin. Sebagian besar masalah kualitas di sistem RAG ada di pipeline tersebut, bukan di model.

Apa yang Biasanya Bekerja

Retrieval terlebih dahulu, untuk hampir semua hal, karena dapat diukur dan reversible. Kemudian fine-tune secara sempit untuk bentuk, sekali Anda memiliki jejak yang menunjukkan kesenjangan perilaku yang konsisten yang tidak dapat ditutup oleh prompting dan contoh few-shot. Melakukannya dalam urutan tersebut berarti Anda akan memiliki set evaluasi siap sebelum Anda membutuhkannya, yang merupakan hal yang paling kurang dimiliki tim ketika mereka memulai.

Yang bisa Anda lakukan sekarang

  • Pengaturan halus untuk bentuk dan perilaku; pengambilan untuk konten dan fakta
  • Tanyakan seberapa sering pengetahuan berubah dan apakah Anda harus mengutipnya — itu memutuskan sebagian besar kasus
  • Pengaturan halus gagal secara diam-diam; pengambilan gagal secara terlihat, yang membuatnya lebih mudah dioperasikan
  • Bangun set evaluasi dengan pengambilan terlebih dahulu, lalu lakukan pengaturan halus secara sempit jika jejak menunjukkan kesenjangan nyata
Paket rekomendasi

Playbook RAG di Production

Strategi chunking, setup reranking, evaluation harness, dan tujuh mode kegagalan yang membunuh setiap demo RAG di minggu ketiga.

$19 Beli →