RAG mi, ince ayar mı? Gerçek müşteri projeleri doğru seçimi yapmayı bize nasıl öğretti?

Kurumsal yapay zekâ üzerine yaptığım görüşmelerin neredeyse hepsi, ilk saat içinde aynı ikileme geliyor. Müşterinin demosu etkileyici olan, ancak ürünlerini, politikalarını veya yazım tarzlarını bilmeyen büyük bir dil modeli var. Odadakilerden biri şu soruyu soruyor: Modeli verilerimizle ince ayardan mı geçirmeliyiz, yoksa çevresinde erişim destekli üretim (RAG) mi kurmalıyız?

Dürüst yanıt şu: Bu soru genellikle yanlış çerçeveleniyor. RAG ve ince ayar farklı sorunları çözer. Bunları birbirine rakip seçenekler olarak gören ekipler, yanlış sorunu çözmeye çalışırken aylar ve büyük miktarda GPU bütçesi harcama eğiliminde. İşte uygulamada nasıl karar verdiğimiz ve nelerin işe yaradığını ya da yaramadığını gördüğümüz.

Modelin Neyi Bilmediğini Belirleyerek Başlayın

Bir model, işle ilgili bir görevde kötü yanıt verdiğinde iki şeyden biri eksiktir.

Bilgi eksiktir. Model en güncel fiyat listenizi, 2025 tarihli tedarikçi sözleşmenizdeki maddeyi veya geçen ay piyasaya sürülen bir ürünün sorun giderme adımlarını bilmez. Bu, olgularla ilgili bir sorundur.

Davranış eksiktir. Model yeterince bilgi sahibidir, ancak ihtiyacınız olan şekilde yanıt vermez. Çıktı biçiminizi göz ardı eder, yanlış bir üslupla yazar, kurum içi kodlarınızı yanlış yorumlar veya biletleri 40 kategorinize ayırmak gibi dar kapsamlı ve tekrarlanan bir görevi yerine getiremez. Bu, beceriyle ilgili bir sorundur.

İlk sorunun çözümü RAG’dir. İkinci sorunun çözümü ise ince ayardır. Gördüğüm kafa karışıklığının çoğu, olguları öğretmek için ince ayar kullanmaya çalışmaktan kaynaklanıyor.

Bilgi Eklemek İçin İnce Ayar Neden Kötü Bir Yöntem?

Bir modeli belgelerinizle eğitirseniz bunları “bileceğini” düşünmek cazip gelebilir. Uygulamada model, belgelerin üslubunu içerdikleri olgulardan çok daha güvenilir biçimde öğrenir. Microsoft’taki araştırmacılar, bilgi ağırlıklı sorular için iki yaklaşımı doğrudan karşılaştırdı ve RAG’nin denetimsiz ince ayardan sürekli olarak daha iyi sonuç verdiğini buldu; bu, hem modelin eğitim sırasında gördüğü olgular hem de tamamen yeni olgular için geçerliydi.

Bunun pratikte yol açtığı sorunlar da var. Olgular değişir. Politikanız veya kataloğunuz her değiştiğinde, yeniden eğitilene kadar ince ayardan geçirilmiş model güncelliğini yitirir. Ayrıca izlenebilirliği de kaybedersiniz: İnce ayardan geçirilmiş bir model bir rakam verdiğinde, bunun geldiği belgeyi gösteremezsiniz. Sigorta ve sağlık hizmetleri alanındaki düzenlemelere tabi müşteriler için bu, genellikle görüşmeyi sona erdirmeye tek başına yeter.

İlk kez Lewis ve çalışma arkadaşlarının 2020 tarihli makalesinde açıklanan RAG, bilgiyi modelin dışında tutar. Sorunun yöneltildiği sırada ilgili bölümleri bulup bağlam olarak modele verirsiniz. Bilgiyi güncellemek için yeniden eğitim yapmak değil, bir dizini güncellemek gerekir. Üstelik her yanıt, kaynağına atıfta bulunabilir.

Bir lojistik müşterimiz buna iyi bir örnek. Müşterinin müşterileri, gönderilerinin nerede olduğu ve hangi belgelerin eksik olduğu hakkında anında yanıt almak istiyordu. Bu bilgiler birkaç dakikada bir değişiyor. Ne kadar eğitim verilirse verilsin model güncel tutulamazdı; bu nedenle geliştirdiğimiz asistan, yanıt verirken hafızasından değil, canlı takip ve IoT verilerinden yararlanıyor. İşe yarayabilecek tek tasarım, bilgi getirmeye dayalı olan tasarımdı.

İnce Ayar Nerede İşe Yarar?

İnce ayar ortadan kalkmış değil. Yalnızca insanların beklediğinden daha dar bir kullanım alanına sahip. Üç durumda tercih ediyoruz:

• Sık tekrarlanan, katı çıktı biçimleri. Bir modelin her gün binlerce kez aynı yapılandırılmış çıktıyı üretmesi gerektiğinde (örneğin faturadaki alanları sabit bir JSON şemasına çıkarması gerektiğinde), ince ayardan geçirilmiş küçük bir model çoğu zaman daha büyük bir modele istem vermekten daha güvenilir ve çok daha ucuzdur.
• Alan terminolojisi. Bazı alanlarda temel modelin yanlış yorumladığı kısaltmalar kullanılır. Lojistik durum kodları, klinik kısaltmalar ve kurum içi ürün kodları buna yaygın örneklerdir. Mütevazı ölçekte bir ince ayar bu sorunu çözebilir.
• Yüksek kullanım hacminde maliyet ve gecikme. Bir görev net biçimde tanımlandıktan sonra, ince ayardan geçirilmiş küçük bir model büyük ve genel amaçlı bir modelin yerini alabilir. LoRA gibi yöntemler bunu ekonomik hâle getirir; çünkü modelin tamamını değil, az sayıdaki ek ağırlığı eğitirsiniz.

Bunların hiçbirinin olgularla ilgili olmadığına dikkat edin. Hepsi, zaten iyi anladığınız bir görevde modele nasıl davranacağını öğretmekle ilgilidir.

RAG Hatalarının Çoğu, Bilgi Getirme Hatalarıdır

Bir ekip bana “RAG’yi denedik, işe yaramadı” dediğinde sorun nadiren modelin kendisidir. Sorun, bilgi getirme aşamasındadır. Modelin başarısı, kendisine sunulan bölümlerin başarısını aşamaz.

Çözümler gösterişli değil, ancak etkili:

• Karakter sayısına göre değil, anlama göre parçalara ayırın. Bir sözleşmeyi her 500 karakterde bir bölmek, maddeleri ortadan ikiye ayırır. Bölümleri ve başlıkları temel alarak ayırmak ise bağlamı korur.
• Her parçaya bağlam ekleyin. Hangi politikaya ait olduğunu bilmeden “sınır 30 gündür” diyen bir parçanın hiçbir yararı yoktur. Anthropic, dizine eklemeden önce her parçaya kısa belge bağlamı eklemenin (şirketin bağlamsal bilgi getirme adını verdiği bir yaklaşım) başarısız bilgi getirme oranını %49, yeniden sıralamayla birlikte kullanıldığında ise %67 azalttığını bildirdi.
• Anahtar sözcük aramasını vektör aramasıyla birleştirin. Vektör araması anlamı bulmada başarılı, parça numaraları gibi tam terimleri bulmada ise zayıftır. Hibrit arama her ikisini de kapsar.
• Erişim kalitesini ayrı olarak test edin. Doğru kaynak pasajları bilinen gerçek sorulardan oluşan bir küme hazırlayın ve nihai yanıtları değerlendirmeden önce doğru pasajın en üst sıralardaki sonuçlarda yer alıp almadığını ölçün.

Her İkisini Ne Zaman Kullanmalı?

Üretimde en güçlü sistemler çoğu zaman bu iki yaklaşımı bir araya getirir. RAG olguları sağlar. Hafifçe ince ayar yapılmış bir model biçimi, tonu ve alana özgü dili üstlenir. Araştırmalar da aynı yönde ilerliyor: UC Berkeley’nin RAFT yaklaşımı, getirilen belgelerden daha iyi yararlanmak ve ilgisiz belgeleri göz ardı etmek üzere bir modeli özel olarak ince ayardan geçirir.

Ancak sıralama önemlidir. Neredeyse her zaman önce RAG’i kurar, eksik kaldığı noktaları ölçer ve ancak bundan sonra ince ayarın buna değip değmeyeceğine karar veririz. İnce ayarla başlamak, asıl eksikliğin ne olduğunu öğrenmeden önce eğitim maliyetini üstlenmek demektir.

Basit Bir Karar Kontrol Listesi

1. Görev, üç ayda birden daha sık değişen bilgilere mi bağlı? RAG kullanın.
2. Kullanıcıların veya denetçilerin bir yanıtın nereden geldiğini görmesi gerekiyor mu? RAG kullanın.
3. Sorun, yanıtların bilgileri değil de biçimi, tonu veya sözcük dağarcığı mı? İnce ayarı değerlendirin.
4. Maliyet veya hızın önemli olduğu, yüksek hacimde yürütülen dar kapsamlı bir görev mi? Daha küçük bir modeli ince ayardan geçirmeyi değerlendirin.
5. Erişim kalitesini tek başına ölçtünüz mü? Ölçmediyseniz, başka bir şey yapmadan önce bunu yapın.

Özetle

RAG ve ince ayar birbirinin rakibi değildir. Biri modele doğru bilgileri sağlar, diğeri ise modelin nasıl davranacağını şekillendirir. Gerçekte hangi sorunla karşı karşıya olduğunuzu netleştirin, modeli suçlamadan önce erişim sorunlarını giderin ve ince ayarı, sistem çalışır hâle geldikten sonra hak ederek ulaştığınız bir optimizasyon olarak görün; sistemi çalıştırmanın kestirme yolu olarak değil.