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

> Belgeyi modele vermek ne zaman yeterli, RAG ne zaman gerekir, fine-tuning hangi durumda gerçekten anlamlı olur? Kararı bilgi, kural ve öğrenilecek örüntü üzerinden ele alıyorum.

> 💡 **Ö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](https://www.nature.com/articles/s41591-024-02933-8){.dofollow target="_blank" rel="noopener"}, 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ı](https://www.microsoft.com/en-us/research/publication/rag-vs-fine-tuning-pipelines-tradeoffs-and-a-case-study-on-agriculture/){.dofollow target="_blank" rel="noopener"} 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üm | Neden? |
|---|---|---|
| Açıkça yazılı, güncel bilgi | Doğrudan bağlam, RAG, arama, veritabanı veya API | Bilgi 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şki | Tahmin, sınıflandırma veya başka bir makine öğrenmesi modeli | Sonuç belgede yazmaz; verideki örüntünün öğrenilmesi gerekir |
| Doğru bilgiye rağmen tekrarlanan model davranışı | Temsilî verilerle fine-tuning | Modelin 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](/tr/ai-projesine-model-secerek-baslamayin){target="_blank" rel="noopener"} 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](/tr/sirketiniz-icin-yapay-zeka-sistemi-nasil-tasarlanir) bir arada görebilirsiniz.

---

Language: Turkish
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/tr/kuruma-ozel-yapay-zeka-icin-fine-tuning-sart-mi