RAG mi Fine-tuning mi? Kurumsal Türkçe Doküman İçin Karar Matrisi

Kısaca: kurumsal dokümanınızı bir dil modeline bilgi olarak eklemek istiyorsanız RAG, modelin davranışını ya da çıktı biçimini değiştirmek istiyorsanız fine-tuning doğru yöntemdir. Sık değişen doküman kümelerinde RAG hem daha ucuz hem daha izlenebilir bir başlangıçtır.

Retrieval-Augmented Generation (RAG), bir dil modelinin cevabı üretmeden önce kendi doküman havuzunuzdan ilgili parçaları çekip bağlama koyduğu yöntemdir. Fine-tuning ise modelin ağırlıklarını sizin verinizle yeniden eğitmektir. Birincisi modele bir kütüphane verir, ikincisi modelin kendisini değiştirir.

Aradaki fark çoğu kurumsal projede tek bir soruda düğümlenir: doküman ne sıklıkta değişiyor? Değişen bir doküman kümesi için fine-tuning her güncellemede yeniden eğitim demektir. RAG'de aynı güncelleme, yeni bir parçanın indekslenmesinden ibarettir.

RAG ile fine-tuning nasıl karşılaştırılır?

Pratik kural: bilgi eklemek istiyorsanız RAG, davranış değiştirmek istiyorsanız fine-tuning. İkisi rakip değildir. Çoğu üretim sisteminde bilgi RAG'den, üslup ve biçim istemden gelir.

RAG'de cevabın kalitesini ne belirler?

En sık görülen hata, RAG'i "doküman yükle, model cevaplasın" diye kurmaktır. Cevabın kalitesini modelden çok, modele hangi parçanın gittiği belirler. Arama katmanı yanlış parçayı getirirse en güçlü model de o parçanın söylediğinden fazlasını bilemez.

GG Tech Teknoloji olarak kendi iç araçlarımızdan birindeki bilgi tabanı asistanında erişimi şöyle kurduk: gömme vektörleri PostgreSQL'de pgvector ile 1536 boyutlu olarak tutuluyor, benzerlik araması kosinüs mesafesiyle bir HNSW indeksi üzerinden yapılıyor ve anahtar kelimeler ayrı bir GIN indeksinde duruyor. Anlamsal arama üçten az sonuç döndürdüğünde anahtar kelime eşleşmesi yedek olarak devreye giriyor.

İki yöntemin yan yana durması tesadüf değil. Yalnız vektör araması kullanınca özel adlar, ürün kodları ve kısaltmalar kaçabilir: "GG Beacon SDK" gibi bir terim, anlamca yakın ama farklı bir parçayı getirebilir. Yalnız anahtar kelime kullanınca da aynı soruyu farklı kelimelerle soran kullanıcı boşa düşer. Hibrit erişim ikisini birleştirir. Hangisinin önce çalışacağı ve diğerinin ne zaman devreye gireceği ise ölçerek verilen bir karardır.

Türkçe dokümanlarda RAG'i zorlaştıran üç şey nedir?

1. Sondan eklemeli yapı: "yazılımın", "yazılımdan" ve "yazılımlarımızdan" aynı kökten gelir ama yüzeyde farklı kelimelerdir. Anahtar kelime tarafı kök bulma yapmıyorsa bu üç sorgu üç farklı sonuç verir.
2. Gömme modellerinin dil dengesi: çok dilli modeller İngilizce ağırlıklı eğitildiği için Türkçe'de aynı cümlenin iki farklı yazımı beklenenden uzak vektörler üretebilir. Model seçimi Türkçe test sorularıyla ölçülmelidir.
3. Karakter normalizasyonu: "İ/ı" ve "I/i" dönüşümü Türkçe'de İngilizce'den farklıdır. Küçük harfe çevirme yanlış yerel ayarla yapılırsa "İSTANBUL" beklenmeyen bir biçime döner ve eşleşme sessizce kaçar.

Bu tür eşleştirme hataları hata mesajı üretmez. Kendi SEO panelimizde marka sorgularını ayıran düzenli ifade, bir kaçış karakteri kaybı yüzünden "gg tech" yazımını yakalamıyordu. Sorun ancak sonuçlar gerçek veriyle karşılaştırılınca görüldü. RAG'de de kural aynı: erişimi bir test setiyle ölçmeden kalitesini bilemezsiniz.

Fine-tuning ne zaman doğru cevaptır?

• Modelin çıktı biçimi sabit olmalıysa, örneğin her cevap belirli bir JSON şemasında dönmeliyse.
• Alan dili o kadar özelse ki genel model terimleri yanlış kullanıyorsa.
• Gecikme kritikse ve her sorguda erişim yapmaya zaman ya da bütçe yoksa.
• Doküman kümesi donmuşsa, yani yılda bir kez değişiyorsa.

Bu dört koşul birden yoksa RAG ile başlayıp ölçmek daha ucuzdur. Fine-tuning gerekirse sonradan, ölçülmüş bir sorunu çözmek için eklenir.

Kurumsal doküman havuzunuzu bir asistana bağlamayı düşünüyorsanız ilk soru "hangi model" değil, "erişim neye göre değerlendirilecek" olmalı. Ölçmeden kurulan RAG, ölçmeden kurulan aramadan farksızdır.

Yazar: Gürhan Elçiçek, GG Tech Teknoloji kurucusu.