RAG mı, ince ayar mı? Önce verinize bakın

Erişimle zenginleştirilmiş üretim (RAG) ve ince ayar (fine-tuning), birbirine rakip cevaplar değildir. Farklı soruların cevaplarıdır. Çoğu kişinin yanlış kurduğu kısım sorunun kendisidir. Soru doğru kurulduğunda cevap genellikle bellidir ve bazen cevap “ikisini de yapmayın” olur.

Veriniz hakkında dört soru

Bilgi erişimi (retrieval) ile ince ayar arasında karar vermeden önce şu dört soruyu cevaplayın. Her soru sizi iki yaklaşımdan birine, ikisini doğrudan karşılaştırmaktan daha net biçimde yönlendirir.

Veri ne kadar hızlı değişiyor?

Veri haftada bir ya da daha sık değişiyorsa bilgi erişimi. Bir modele ince ayar yapmak saatler ya da günler sürer; eğitim bitmeden model eskimiş olur. Veri yılda bir ya da daha seyrek değişiyorsa ince ayar bir seçenek hâline gelir. Veri ayda bir değişiyorsa ikisi de işe yarayabilir ve karar bir sonraki soruya kalır.

Müşterinin kaynak göstermesi gerekiyor mu?

Gerekiyorsa bilgi erişimi, başka seçenek yok. Bilgi erişimi yapan bir veri hattı, kullandığı parçayı (chunk) da döndürür; modelin cevabı belirli bir belgedeki belirli bir pasaja kadar izlenebilir. İnce ayardan geçmiş bir model, cevabını hangi eğitim örneğinin ürettiğini siz sorsanız bile söyleyemez. Kaynak gösterip göstermemek kesin bir kısıttır ve karşılaştırmada en sık atlanan da odur.

Cevabın biçimi sabit mi?

Müşteri cevapları belirli bir biçimde istiyorsa (belirli bir JSON şeması, sabit bir rapor şablonu, düzenlemeye tabi bir belge düzeni) ince ayar karşılığını verir. Bilgi erişimi doğru içeriği üretebilir, ama hacim arttıkça biçim tutarlılığı bozulur. İnce ayardan geçmiş bir model bir biçimi çok yüksek tutarlılıkla koruyabilir. İnce ayarın açıkça daha iyi olduğu durum budur.

Veri ne kadar hassas?

Veri, onunla eğitilmiş bir modelin bile sızıntı kaygısı yaratacağı kadar hassassa, verinin modelin dışında durduğu bilgi erişimi daha güvenlidir. Bugünkü ince ayar yöntemlerinin gizliliği koruyan eğitim seçenekleri var, ama sızıntı üzerine akıl yürütmek daha zordur. Bilgi erişimi, veriyi müşterinin mevcut erişim kontrollerinin zaten geçerli olduğu bir yerde tutar.

Hiçbiri doğru olmadığında

Atlanan üçüncü bir seçenek var: hiçbirini yapmamak. Ekiplerin bilgi erişimine ya da ince ayara başvurduğu durumların şaşırtıcı bir kısmında, temel bir model üzerinde biraz yapılandırılmış istem yeterince iyi çalışır. Bilgi erişimi ya da ince ayar eklemek gereğinden fazladır.

Bu durumda olduğunuzun işaretleri şunlardır: veri isteme sığar, biçim esnektir, müşterinin kaynak göstermesi gerekmez ve hacim düşüktür. Özenli bir istem ve çıktı üzerinde küçük bir denetleyici (validator) tasarımın tamamı olabilir. İşletmesi en ucuz, anlatması en kolay tasarım da budur.

İkisi birden doğru olduğunda

Dördüncü bir durum da var: ikisini birden yapmak. Modele biçim ve davranış için ince ayar yapın; içerik için bilgi erişimini kullanın. Değişen veriye dayanan (bilgi erişimi) yapılandırılmış bir çıktı (ince ayar) üretmesi gereken her ajan için doğru mimari budur.

Bunun en tipik örneği aylık yönetim raporudur. Biçim sabittir: finans kontrolörünün bir şablonu vardır ve şablondan sapan rapor geri çevrilir. İçerik ise her ay değişen gerçek rakamlardır. Tasarım biçim üzerinde ince ayar yapar, rakamları bilgi erişimiyle okur.

Yapmadıklarımız

Ham bilgi için ince ayar yapmayız. Maliyet-fayda dengesi yanlıştır; bilgi erişimi daha hızlı, daha ucuz ve güncellemesi daha kolaydır. İşletme kılavuzlarıyla (runbook) yapılan ince ayar, ayrılmış test verisinde bilgi erişimini az farkla geçse bile, canlıya alınacak doğru sürüm o değildir. Bir kılavuz ilk kez güncellendiğinde model yanılır ve operasyon ekibinin hangi cevapların eskidiğini bilmesinin hiçbir yolu yoktur. Kıyaslamadaki küçük bir üstünlük, değişmiş bir belgeyle karşılaşınca ayakta kalmaz.

Katmanları varsayılan olarak üst üste de koymayız (ince ayar, bilgi erişimi, ardından çıktı için istem mühendisliği). Eklenen her katman, ayrılmış test verisindeki değerlendirmede yerini hak etmelidir. Çünkü her katman, nöbetçi mühendisin sistemi okumasını zorlaştırır. Kazancını gösteremeyen bir katman sistem değil, labirenttir.

Kısaca karar

Dört soruyu sorun. Dördünü de cevaplamadıysanız seçim yapmaya hazır değilsiniz. Cevapladıysanız seçim genellikle bellidir.

Bir sonraki yazı, canlı ortamda vektör veritabanlarını (vector store) işletmek üzerine. Vektör veritabanı, bilgi erişimi seçeneğini çalıştıran şeyin yarısıdır ve en sık atlanan kısmıdır.