RAG ile fine-tuning farklı ihtiyaçları karşılar. RAG, ilgili belgeyi soru anında bulup modele bağlam olarak verir. Fine-tuning, önceden eğitilmiş modeli örneklerle belirli bir göreve veya yanıt biçimine uyarlar. Güncel ürün bilgisini bulmak için arama tarafını, sürekli aynı biçimde çıktı almak için davranış tarafını değerlendirin.[1][2][3]
Seçimi doğru yapmak için önce hatanın nerede başladığını bulun. Model doğru belgeyi hiç görmemiş olabilir. Doğru belgeyi gördüğü halde metni yanlış yorumlamış veya istenen alanları yanlış biçimde yazmış da olabilir. Bu rehber, bu durumları aynı örnek üzerinden nasıl ayıracağınızı gösteriyor.
Hangi durumda hangi yöntemle başlanır?
| İhtiyaç | İlk yaklaşım | Kontrol |
|---|---|---|
| Sık değişen kılavuzdan cevap | RAG | Güncel belge geliyor mu? |
| İstenen yanıt biçimini açıklama | Talimat ve örnek | Örnekler tutarlı uygulanıyor mu? |
| Tekrarlanan sınıflandırma hatasını azaltma | Fine-tuning denemesi | Yeni örneklerde hata azalıyor mu? |
| Doğru kaynak ve tutarlı yanıt biçimi | Önce RAG, gerekirse fine-tuning | Arama ve çıktı ayrı başarılı mı? |
| Az sayıda kısa kaynağı kullanma | İlgili metni doğrudan bağlama ekleme | Girdi yönetilebilir mi? |
Bu tablo başlangıç seçimi içindir. Bir yaklaşımı seçtikten sonra sonuçları kendi sorularınızla ölçün. Örneğin belgelerinizi yanlış sürümden alan bir sistemin format hatasını düzeltmek, asıl bilgi sorununu çözmez.
RAG hangi bilgiyi nereden alır?
RAG akışında uygulama, kullanıcı sorusuna göre bir kaynaktan ilgili metni getirir. Model bu içeriği bağlamda görür ve ona dayanarak yanıt üretebilir. Kaynak olarak ürün kılavuzu, yardım merkezi veya yetkilendirilmiş başka bir belge kümesi kullanılabilir.[1][4]
Bir işletme, teslimat kapsamını belirten metni güncellediğinde aramanın yeni belgeyi getirmesini ister. Bu değişiklik için sohbet modelini yeniden eğitmek yerine bilgi tabanını güncellemek ve eski belgenin ne zaman aranabileceğini tanımlamak uygundur. Değişiklikten sonra doğru sürümün bulunduğunu ayrıca kontrol edin.
RAG’ın kalitesi kaynakların hazırlanmasına ve arama aşamasına bağlıdır. Doğru metin bulunmuyorsa, önce metin çıkarma, parçalara ayırma ve sorgu eşleştirme adımlarına bakın. Uygulamalı adımlar RAG nedir? rehberimizde yer alıyor.[4]
Fine-tuning modeli nasıl değiştirir?
Fine-tuning, eğitilmiş bir modeli göreve özgü verilerle ek eğitime tabi tutar. Amaç, örneğin belirli bir sınıflandırma düzenini, yanıt biçimini veya alan terminolojisini daha tutarlı uygulamaktır. Başarısını yalnızca eğitim örneklerine bakarak ölçmek yerine daha önce görülmemiş örneklerle değerlendirin.[2][3]
Tam ince ayar model parametrelerini günceller. LoRA gibi yöntemler ise ana model ağırlıklarını dondurup öğrenilebilir ek parametrelerle uyarlama yapabilir. Bu nedenle “ince ayar yaptım” ifadesi bütün ağırlıkların yeniden eğitildiğini anlatmaz. Kullanılan yöntem ve taban model, dağıtım ve bakım için kayda geçirilmelidir.[5]
Örneğin gelen destek talebinden kategori, özet ve aciliyet alanları çıkaran bir sistem düşünün. İyi yazılmış talimat ve örneklere rağmen model aynı sınıfları karıştırıyorsa ek eğitim değerlendirilebilir. Bunun için doğru etiketli, gerçek görev dağılımını temsil eden örnekler gerekir. Sadece en kolay örneklerden oluşan veri, gerçek kullanımı yeterince temsil etmeyebilir.[2][3]
Önce basit bir temel kurun
Eğitim veya arama altyapısı kurmadan önce elinizdeki modele açık bir görev ve birkaç örnek verin. Beklenen alanları, dilini ve hangi durumda açıklama isteyeceğini yazın. Aynı soru grubuyla çıkan sonucu kaydedin. Bu sonuç, sonraki değişiklikleri karşılaştıracağınız başlangıç noktası olur.[2][3]
Örneğin amaç bir destek talebini üç kategoriye ayırmaksa, önce her kategori için bir örnek hazırlayın. Belirsiz bir örnekte modelin ne yapacağını belirtin. Ürün adı bilinmiyorsa, “bilgi eksik” değerinin kabul edildiğini şemaya ekleyin. Bu değişiklik sorunu çözerse eğitim için veri toplamaya başlamadan çalışan bir yönteminiz olur.
Kısa bir belgenin tamamını bağlama eklemek de yararlı bir karşılaştırmadır. Arama adımının gerçekten gerekli olup olmadığını görmek için doğru belgeyi doğrudan modele verin. Uzun belge ve çok sayıda konuşmada bağlam penceresi ve token kullanımı maliyet hesabını etkiler.[4]
Örnek karar: Ürün destek asistanı
Kurgusal bir mağaza asistanı, kullanıcıya doğru ürün kılavuzundan bakım bilgisi veriyor. İlk denemede B-30 için yazılmış bir kuralı A-12’ye uyguluyor. Önce modele giden parçaları açın. Yanlış ürünün metni gelmişse, kaynak filtresini veya arama yöntemini inceleyin.
İkinci denemede doğru A-12 belgesi geliyor ve yanıtın içeriği doğru. Buna rağmen uygulamanın beklediği kaynak alanı bazı cevaplarda boş kalıyor. Bu durumda arama tarafı görevini yapmış olabilir. Talimatı ve çıktı kontrolünü iyileştirin. Yapı sürekli bozuluyorsa ve yeterli örnek birikmişse fine-tuning denemesi için gerekçe oluşur.[2][3]
Üçüncü denemede model, belgede olmayan garanti süresini yazıyor. Önce kullanıcıya kaynak bulunamadığında nasıl yanıt verileceğini tanımlayın. Ardından belirsiz ve eksik kaynaklı soruları da değerlendirme grubuna ekleyin. Eğitim örneklerine yalnızca başarılı cevapları koymak yerine uygun çekimserlik davranışını da temsil edin.
İki yaklaşım birlikte kullanılabilir mi?
Bir ürün asistanı, bilgiyi RAG ile alıp bu bilgiyi kurumun istediği şablonda sunmak için ince ayarlı bir model kullanabilir. İlk RAG araştırması da bilgi getirme ile üretimi bir araya getiren modelleri inceliyor. Pratik bir sistemde arama bileşeniyle model uyarlaması ayrı kararlardır.[1][2]
Birlikte kullanımda “bu cevap doğru mu?” sorusunu ikiye ayırın. Önce arama doğru ve yetkili kaynağı buldu mu? Sonra model, o kaynağa dayanarak doğru biçimde cevap verdi mi? Arama ve model değişikliklerini aynı gün yaparsanız hangi iyileşmenin neye bağlı olduğunu anlamak zorlaşır.
Örneğin önce sadece arama kalitesini düzeltin ve model değişmeden aynı soruları tekrar çalıştırın. Sonra gerekiyorsa ince ayarlı modeli aynı arama sonuçlarıyla deneyin. Bu sıra, ek eğitimin gerçekten katkıda bulunup bulunmadığını ölçmeye yardımcı olur.
İnce ayar için veri nasıl hazırlanır?
Her örnekte modelin göreceği girdi ve istenen çıktı açık olsun. Etiketler tutarsızsa önce iş kuralını düzeltin. Bir kişi “acil” olarak işaretlediği aynı durumun başka kişi tarafından “normal” sayıldığını görürse, modelden tek bir doğru davranış öğrenmesini beklemek güçleşir.[2][3]
Eğitim, doğrulama ve son değerlendirme örneklerini ayırın. Aynı destek konuşmasının çok benzer kopyalarını farklı kümelere dağıtmak, modelin yeni durumlarla ne kadar iyi başa çıktığını olduğundan iyi gösterebilir. Bölme işlemini mümkünse konuşma veya müşteri kaydı düzeyinde yapın.
Hassas veriyi işlemeden önce erişim, saklama ve kaldırma koşullarını değerlendirin. İstenen davranışı göstermek için gerçek ad, adres veya hesap bilgisi gerekmiyorsa bunları örnekten çıkarın. Bir veri örneğini silmekle daha önce eğitilmiş modelden etkisini kaldırmak aynı işlem değildir. Ürünün eğitim ve model yaşam döngüsünü ayrı inceleyin.
Maliyeti tek faturadan okumayın
RAG için dosyaları hazırlama, indeksleme, arama ve yanıta eklenen metin maliyet yaratabilir. Fine-tuning için veri düzenleme, eğitim, modelin çalıştırılması ve yeni sürümlerin sınanması ayrı giderlerdir. Toplamı iş hacminiz ve hata düzeltme sürenizle birlikte değerlendirin.[2][3][4]
Örnek bir pilotta yüz soruluk bir değerlendirme listesi oluşturun. Her yaklaşım için çağrı sayısı, ortalama girdi büyüklüğü, düzeltme süresi ve kabul edilen cevap sayısını kaydedin. Bu sayı bir tavsiye edilen asgari örnek miktarı değildir. Aynı iş üzerinden karşılaştırma yapmanın yolunu gösterir.
Maliyet tablosuna başarısız istek ve yeniden deneme sürelerini de ekleyin. İki yöntem benzer fiyatlı görünse bile yanlış cevapları incelemek için harcanan emek farklı olabilir. Bir yöntem yalnızca üretim anında ucuzsa, model ve veri güncelleme maliyeti hesap dışı kalmış olabilir.
Pilot sonucu nasıl kaydedilir?
İlk sütuna soruyu yazın. İkinci sütunda beklenen belgeyi veya çıkışı belirtin. Sonraki sütunlarda bulunan kaynak, cevap, biçim kontrolü ve düzeltme ihtiyacı yer alsın. Dört ayrı durum özellikle değerlidir: doğru bilgi ve doğru biçim, doğru bilgi ve yanlış biçim, yanlış bilgi ve doğru biçim, ikisinin de yanlış olması.
Karar verirken kritik hatalara ayrı ağırlık verin. Kurgusal destek botunda noktalama hatası ile ürün kullanımında yanlış uyarı aynı önemde değildir. Üretimde kullanıma alma şartınızı örneklerden önce yazın. Böylece sonradan başarılı görünen bir cevaba göre ölçüt değiştirmek zorunda kalmazsınız.
Bir model sürümünü değiştirirken önceki sürümün ayarlarını ve değerlendirme tablosunu saklayın. Ürün ailesi, arama parametreleri veya veri kümesi değiştiğinde aynı soruları yeniden çalıştırın. Böyle bir kayıt, aynı denemenin başka ekip üyesi tarafından incelenebilmesini sağlar.
İki farklı iyileştirmeyi sayılarla ayırın
Yirmi sorudan oluşan kurgusal bir deneme düşünün. İlk çalıştırmada on dört soruda doğru kaynak bulunuyor. Bunların onunda cevap hem doğru bilgi hem doğru biçim taşıyor. Geri kalan altı soruda beklenen belge arama sonuçlarında yer almıyor. Bu durumda önce kaynak seçimini iyileştirmek için ölçülebilir bir hedef var.
Arama güncellemesinden sonra doğru kaynak bulunan soru sayısı on sekize çıkıyor. Cevapların on üçü hem doğru bilgi hem doğru biçim içeriyor. Yeni başarısız örnekleri açıp birinin belgeyi yanlış yorumladığını, dördünün ise çıktı biçimini bozduğunu varsayalım. Bu dağılım, sonraki çalışmanın aramadan çok yanıt ve çıktı kontrolüne odaklanması için gerekçe sunar. Rakamlar bir ürün testi sonucu değil, karar verme örneğidir.
Şimdi aynı on sekiz doğru kaynaklı soruyu modelin iki sürümünde deneyin. Her ikisine aynı belge parçaları ve aynı hedef biçim verilsin. Bir sürümün farklı kaynakla, diğerinin daha temiz belgeyle çalışması karşılaştırmayı bozar. Sonuçta formatı iyileştiren sürümün kaynakta olmayan yeni bilgiler üretip üretmediğini de kaydedin.
Bir görevde iyileşme görürken başka bir görevde gerileme yaşayabilirsiniz. Örneğin daha sıkı biçim eğitimiyle alanlar hep doluyor, ancak bilgi eksikken model boş bırakmak yerine tahmin yazıyor olabilir. Bu durumda biçim kontrolü geçse bile iş gereksinimi karşılanmaz. Eğitim örneklerinde boş değer ve açıklama isteme durumlarını da temsil edin.
Son karar tablosunda veri güncelliği, kaynak doğruluğu, biçim tutarlılığı ve bakım yükü ayrı satırlar olsun. Bir yöntem her satırda en iyi olmak zorunda değildir. Örneğin bir belge arşivi için hızdan önce geçerli sürümün bulunması, bir sınıflandırma uygulaması içinse tutarlı alanlar daha önemli olabilir. Kabul ölçütünü uygulamanın gerçek kullanımına göre koyun.
Sık sorulan sorular
Belgeyi yüklemek fine-tuning sayılır mı?
Belgenin bağlama eklenmesi veya arama için indekslenmesi modelin ek eğitiminden farklıdır. Hangi işlemin gerçekleştiğini kullandığınız ürünün belgelerinden kontrol edin.[1][2]
Fine-tuning güncel bilgiye erişim sağlar mı?
İnce ayar eğitime verilen örneklerden davranış ve görev kalıpları öğrenebilir. Değişen katalog, politika veya destek bilgisi için ayrı güncel kaynak mekanizması tasarlayın.[2][3]
İlk denemede hangisini seçmeliyim?
Önce başarısız örneği inceleyin. Doğru bilgi eksikse bilgi erişimini, bilgi doğru ve çıktı tutarsızsa talimat ve biçimi düzeltin. Basit yaklaşım yetersiz kaldığında ölçebildiğiniz soruna göre RAG veya ince ayarı değerlendirin.
Kaynaklar
- Lewis ve arkadaşları, Retrieval-Augmented Generation. Bilginin alındığı tarih: 6 Kasım 2026.
- Meta, Fine-tuning how-to guide. Bilginin alındığı tarih: 6 Kasım 2026.
- Microsoft Learn, Fine-tuning in Microsoft Foundry. Bilginin alındığı tarih: 6 Kasım 2026.
- Anthropic, Contextual Retrieval. Bilginin alındığı tarih: 6 Kasım 2026.
- Hu ve arkadaşları, LoRA. Bilginin alındığı tarih: 6 Kasım 2026.
