Ana içeriğe geç
Yapay Zeka · Mühendislik

Kuruma Özel Yapay Zekâ İçin Fine-Tuning Şart mı?

← Yapay Zeka

Yazan Evren BalYayın tarihi  · 6 dk okuma

Read in English →
Veriden öğrenilen mavi eğri, açık belge ve sabit kural şablonunun altında ilerliyor.
Bu yazıyı yapay zekâ ile tartış
Sayfayı kopyala

💡 Özet: Ana Çıkarımlar

  • Güncel bilgiyi modelin ağırlıklarına gömmeyin. Az sayıda belgeyi doğrudan bağlama verin. Geniş ve değişken bir kaynak kümesinde RAG, canlı veride ise API veya veritabanı kullanın.
  • Açık iş kuralları yazılımda kalmalı. İade süresi veya yetki sınırı gibi değişmez kararları modele öğretmek, denetlenebilir bir kuralı gereksiz yere belirsizleştirir.
  • Fine-tuning, örneklerden öğrenilmesi gereken kalıcı bir örüntü varsa anlamlıdır. Önce daha sade yöntemlerin yetersiz kaldığını gösterin, sonra uyarlanan modeli ayrı test verisi ve gerçek iş sonucu üzerinden sınayın.

Bir müşteri, sattığınız cihazın eksi on derecede çalışıp çalışmadığını soruyor. Cevap ürünün bir sayfalık teknik föyünde açıkça yazıyor.

Bu soruyu yanıtlamak için modeli fine-tune eder miydiniz?

Etmemelisiniz. İlgili föyü veya gerekli bölümü soruyla birlikte modele vermek yeterlidir. İki ya da üç kaynak belge varsa onları da aynı bağlama ekleyebilirsiniz.

Belge sayısı binlere çıktığında, içerik sık değiştiğinde veya her kullanıcının görebileceği dokümanlar farklı olduğunda başka bir ihtiyaç doğar. Sistem önce doğru kaynağı bulmalı, sonra ilgili bölümü modele vermelidir. RAG (retrieval-augmented generation) tam olarak bu arama ve getirme işini yapar.

Doğrudan belge vermek de RAG kullanmak da modelin eğitimini değiştirmez. Model, cevap verirken önüne konan güncel kaynaktan yararlanır. Teknik föy değiştiğinde modeli yeniden eğitmez, belgeyi güncellersiniz.

O hâlde fine-tuning ne zaman anlamlı olur?

Bu sorunun cevabı, sistemde eksik olan şeyin bilgi, açık bir kural veya örneklerden öğrenilecek bir örüntü olmasına göre değişir.

Belgede yazan bilgi için model eğitilmez

Kuruma özel sistemlerde sık karşılaşılan ihtiyaçlardan biri bilgiye erişimdir. Model ürün özelliklerini, güncel fiyatı, iade politikasını veya müşterinin sipariş durumunu bilmelidir.

Bilgi bir veya birkaç kısa kaynakta bulunuyorsa doğrudan modele verilebilir. Kaynak sayısı ve kullanıcı sayısı arttığında RAG, kurumsal arama, veritabanı sorgusu veya API daha uygun hale gelir. Hangisinin seçileceği bilginin nerede tutulduğuna, ne kadar sık değiştiğine ve kimlerin erişebileceğine bağlıdır.

Burada fine-tuning çoğu zaman gereksiz bir dolambaçtır. Üstelik modelin eğitim sırasında gördüğü bir bilginin her cevapta doğru kullanılacağını veya güncel kalacağını garanti etmez. Kaynağı çalışma anında vermek, cevabın hangi bilgiye dayandığını görmeyi de kolaylaştırır.

Benzer ayrım şirket kuralları için de geçerlidir. “İade süresi 30 gündür” bir bilgi olabilir. “Süre dolmuşsa talebi temsilciye aktar” ise açık bir iş kuralıdır. Bu kuralı modele örneklerle ezberletmek yerine yazılımda tanımlamak daha güvenilir ve denetlenebilir olabilir.

Bazen cevap bir belgede bulunmaz

Bir perakendecinin gelecek ay ne kadar ürün satacağını tahmin etmek istediğini düşünün. Geçmiş satışlar, kampanyalar, mevsim, tatiller ve stok durumu elinizde olabilir. Fakat hiçbir belgede gelecek ayın satış rakamı yazmaz.

Sistemin geçmiş örneklerdeki ilişkileri öğrenip yeni dönem için tahmin üretmesi gerekir. Burada bir model eğitmek anlamlıdır. Bu model bir zaman serisi modeli, klasik bir makine öğrenmesi yöntemi veya daha özel bir tahmin sistemi olabilir. Büyük bir dil modelini fine-tune etmek zorunda değilsiniz.

Bu ayrım önemli. “Model eğitmek” ile “bir LLM'i fine-tune etmek” aynı karar değildir. Birincisi geçmiş veriden örüntü öğrenen her türlü modeli kapsar. İkincisi, önceden eğitilmiş bir modeli belirli örneklerle daha dar bir göreve uyarlamaktır.

Fine-tuning'i özellikle model doğru bilgiye ve açık talimata sahip olduğu hâlde aynı davranış hatasını tekrarlıyorsa değerlendirmek gerekir. Örneğin gelen metni sürekli yanlış sınıflandırıyor, gerekli alanları tutarlı biçimde çıkaramıyor veya istenen çıktı yapısını sık sık bozuyorsa, temsilî giriş ve doğru çıkış örnekleriyle uyarlama işe yarayabilir.

Yine de önce doğru model, açık talimat, gerekli bağlam ve birkaç iyi örnekle bir başlangıç ölçümü yapılmalıdır. Bunlar hedeflenen kaliteyi karşılamıyorsa, hatanın gerçekten model davranışından kaynaklandığını gösterecek bir test setiyle fine-tuning değerlendirilir.

Fine-tuning'in yerini gösteren gerçek bir örnek

Amazon Pharmacy'nin reçete talimatlarındaki hataları azaltmak için geliştirdiği MEDIC sistemi, bu sınırı iyi gösteriyor.

Doktorların yazdığı reçete talimatları aynı bilgiyi çok farklı biçimlerde ifade edebiliyor. Sistemin metindeki kullanım fiili, doz, uygulama yolu ve sıklık gibi parçaları bulması gerekiyor. Cevap tek bir teknik belgede hazır değil. Modelin çok sayıda farklı yazım biçimi içinden aynı alanları tanımayı öğrenmesi gerekiyor.

Araştırmacılar bu iş için yaklaşık bin uzman etiketli örnekle uyarlanmış küçük bir DistilBERT modeli kullanmış. Model reçete metnindeki gerekli parçaları çıkarıyor. Sonraki aşamada yazılım bu parçaları eczacılık kuralları ve ilaç veritabanlarıyla kontrol ediyor. Bilgi eksik veya çelişkiliyse sistem öneri üretmeyi bırakıyor. Son kontrol de teknisyenler ve eczacılarda kalıyor.

Araştırmacılar, MEDIC'in Amazon Pharmacy'deki uygulama döneminde reçete talimatlarıyla ilgili near-miss olaylarında yüzde 33 azalma raporlamış. Bunlar, yanlış talimat hastaya ulaşmadan önce yakalanan hatalar. Sonuç tek bir kurum ve görevle sınırlı olsa da önemli bir noktayı gösteriyor: Fine-tuning burada güncel bir bilgi kaynağının yerine geçmiyor. Serbest biçimli metinden tutarlı alanlar çıkarma davranışını iyileştiriyor.

Çalışmanın başka bir sonucu daha öğretici. 1,5 milyon örnekle fine-tune edilen daha büyük bir T5 modeli, zor vakalarda kendi sınırını fark etmeyip güvenle talimat üretmeye devam etmiş. MEDIC'in başarısı yalnızca uyarlanmış modelden gelmedi. Dar bir model görevi, açık durma koşulları, doğrulama kaynakları ve insan kontrolü birlikte çalıştı.

RAG ile fine-tuning rakip değildir

RAG sisteme cevap anında doğru bilgiyi getirir. Fine-tuning modelin belirli girdiler karşısındaki davranışını değiştirmeye çalışır. Aynı sistem ikisini birlikte kullanabilir.

Örneğin sistem güncel ürün belgesini RAG ile bulup ilgili bölümü modele verebilir. Modelin bu metinden şirketin kullandığı şemaya uygun alanları çıkarması gerekiyorsa ve iyi hazırlanmış talimatlarla hâlâ tutarsız sonuç veriyorsa, bu dar görev için fine-tuning düşünülebilir.

Microsoft araştırmacılarının tarım soruları üzerinde yaptığı RAG ve fine-tuning karşılaştırması da iki yöntemin birlikte iyileşme sağlayabildiğini gösteriyor. Ancak çalışma tek bir veri kümesi ve belirli modellerle sınırlı. Buradan çıkarılabilecek güvenli sonuç, her iki yöntemin birlikte kullanılması gerektiği değil; farklı sorunları çözdükleri için birbirlerini tamamlayabildikleridir.

Önce neyin eksik olduğunu bulun

Kararı yöntem adlarından değil, eksik parçadan başlatmak daha kolaydır.

Eksik olan ne?İlk bakılacak çözümNeden?
Açıkça yazılı, güncel bilgiDoğrudan bağlam, RAG, arama, veritabanı veya APIBilgi kaynaktan alınabilir ve kaynağı değiştiğinde güncellenebilir
Açık bir iş kuralıTalimat veya yazılım kuralıKural doğrudan uygulanabilir ve denetlenebilir
Geçmiş örneklerde saklı bir ilişkiTahmin, sınıflandırma veya başka bir makine öğrenmesi modeliSonuç belgede yazmaz; verideki örüntünün öğrenilmesi gerekir
Doğru bilgiye rağmen tekrarlanan model davranışıTemsilî verilerle fine-tuningModelin aynı görevi daha tutarlı yapması gerekebilir
Yetki, onay veya güvenlik sınırıErişim kontrolü, yazılım kuralları ve gerektiğinde insan onayıModel eğitimi işlem yetkisi veya sorumluluk oluşturmaz

Fine-tuning'e geçmeden önce dört sorunun cevabı açık olmalıdır:

  1. Model hangi gerçek girdilerde, hangi hatayı tekrarlıyor?
  2. Doğru kaynak, daha açık talimat veya birkaç örnek bu hatayı çözüyor mu?
  3. Eğitimde kullanılmayan temsilî bir test setinde iyileşme ölçülebiliyor mu?
  4. Kazanılan kalite veya maliyet avantajı; veri hazırlama, model sürümlerini izleme ve yeniden eğitim yüküne değiyor mu?

AI projesine model seçerek başlamama nedenini daha önce iş sonucu üzerinden ele almıştım. Fine-tuning kararı da aynı sırayı izlemeli. Önce sistemin neden yetersiz kaldığını bulmak, sonra o eksiği hangi parçanın gidereceğine karar vermek gerekir.

Kuruma özel bir yapay zekâ sistemi kurmak, şirketle ilgili her şeyi modelin içine yerleştirmek demek değildir. Bilgi kaynaktan okunabilir. Kurallar yazılımda uygulanabilir. Geçmiş verideki örüntü için ayrı bir model eğitilebilir. Fine-tuning ise ancak sorun gerçekten modelin tekrarlanan davranışındaysa anlam kazanır.

Bu nedenle ilk soru “RAG mı, fine-tuning mi?” olmamalı. Önce şunu sormak gerekir: Sistemde eksik olan şey bilgi mi, kural mı, yoksa öğrenilmesi gereken bir örüntü mü?

Bir sonraki yazıda, adımları yazılımın yönettiği workflow ile modelin sıradaki adımı seçtiği AI agent arasındaki sınırı ele alacağım.

Model, bilgi, yetki ve ölçümle ilgili diğer kararları yapay zekâ sistemi tasarlama rehberinde bir arada görebilirsiniz.