Amazon Web Services (AWS) da bu ayrımı benzer biçimde ele alıyor: Özel dokümanlara dayalı soru-cevap uygulamalarında RAG ile başlamak, modelin belirli ek görevlerde veya içerik üretiminde daha başarılı olması gerektiğinde fine-tuning'i değerlendirmek mantıklı bir yaklaşım olabilir. Kaynak: AWS Prescriptive Guidance.
[HEADING=1]4. Gerçek Hayat Senaryosu: E-Ticaret Şirketi Hangisini Seçmeli?[/HEADING]
Somut bir işletme örneği üzerinden düşünelim. Bir e-ticaret şirketinin 20 bin ürün kaydı, yüzlerce destek makalesi ve her gün binlerce müşteri mesajı olduğunu varsayalım. Buradaki 20 bin ürün ve binlerce mesaj, açıklama amacıyla oluşturulmuş varsayımsal rakamlardır; belirli bir şirketin yayımlanmış verileri değildir.
Şirketin üç temel ihtiyacı olsun.
Birinci ihtiyaç: Güncel ürün bilgileri.
Müşteri, “Bu bilgisayarın RAM kapasitesi kaç GB ve garanti süresi ne kadar?” diye soruyor. Ürün özellikleri değişebildiği için cevapların güncel katalogdan gelmesi gerekir.
Bu durumda RAG veya doğrudan yapılandırılmış veri tabanı sorgulaması daha uygun olabilir. Hatta fiyat ve stok gibi kesin değerlerde, serbest metin aramasından ziyade ürün veri tabanına yapılan kontrollü bir sorgu tercih edilebilir.
İkinci ihtiyaç: Müşteri mesajlarını sınıflandırmak.
Şirket, gelen mesajların iade, kargo, ödeme ve teknik destek kategorilerine otomatik ayrılmasını istiyor. Üstelik sonuçların sabit bir şemada sunulması gerekiyor.
Burada fine-tuning yararlı olabilir. Model, geçmişte doğru biçimde etiketlenmiş örneklerden yararlanarak sınıflandırma kurallarını daha tutarlı uygulayabilir. Ancak iyi hazırlanmış talimatlar ve birkaç örnek zaten yeterli sonuç veriyorsa fine-tuning'e hemen geçmek gereksiz maliyet oluşturabilir.
Üçüncü ihtiyaç: Müşteriye uygun bir üslupla yanıt vermek.
Şirket, müşterinin sorununu küçümsemeyen, açık, empatik ve çözüm odaklı bir iletişim dili kullanmak istiyor. Aynı zamanda her yanıtın belirli iş kurallarına uymasını bekliyor.
Burada da fine-tuning, doğru örneklerle belirli bir iletişim tarzını öğrenmeye yardımcı olabilir. RAG ise güncel iade koşullarını ve şirket politikalarını yanıtın içine taşır.
Bu üç ihtiyaç birlikte düşünüldüğünde, en mantıklı mimari şu olabilir: Ürün bilgileri ve şirket politikaları için güncel veri erişimi, mesaj sınıflandırma ve iletişim tutarlılığı için gerekirse fine-tuning.
Asıl içgörü şu: Bir işletmenin bütün yapay zekâ ihtiyaçlarını tek bir teknikle çözmeye çalışmak yerine, her işin hata türünü belirlemek daha değerlidir. Yanlış fiyat vermekle kaba bir yanıt üretmek aynı problem değildir. İlki çoğunlukla veri erişimi ve doğrulama, ikincisi ise davranış tasarımı ve kalite değerlendirmesi gerektirir.
[HEADING=1]5. Performans, Maliyet ve Hız Açısından Hangisi Avantajlı?[/HEADING]
Fine-tuning ve RAG karşılaştırmasında sık yapılan bir hata, maliyeti yalnızca ilk kurulum üzerinden değerlendirmektir.
RAG sisteminde belge depolama, indeks oluşturma, arama altyapısı, modelin kullandığı ek bağlam ve sistemin bakım giderleri bulunabilir. Her kullanıcı sorusunda ilgili belgelerin aranması ve modele aktarılması, gecikmeyi ve kullanım maliyetini etkileyebilir.
Fine-tuning tarafında ise veri hazırlama, eğitim denemeleri, değerlendirme, model sürümlerinin yönetimi ve yeni gereksinimler ortaya çıktığında yeniden uyarlama gibi giderler vardır. Buna karşılık, belirli görevlerde daha kısa talimatlarla ve daha az örnekle çalışmak mümkün olabilir.
Örneğin, günde 100 bin kısa mesajı sınıflandıran bir işletme için küçük ve iyi uyarlanmış bir model ekonomik olabilir. Buna karşılık, her gün değişen mevzuat ve şirket belgeleri hakkında sorular yanıtlayan bir uygulama için RAG daha esnek bir çözüm sunabilir. Bunlar kesin maliyet sonuçları değil, ölçülmesi gereken olası avantajlardır.
OpenAI'nin optimizasyon rehberi, fine-tuning'in bazı uygulamalarda daha küçük modellerle benzer görev başarısına ulaşmaya ve her istekte uzun talimatlar göndermemeye yardımcı olabileceğini belirtiyor. Aynı rehber, RAG'de getirilen içeriklerin ilgililiğinin ayrıca değerlendirilmesi gerektiğini vurguluyor. Kaynak: OpenAI, Optimizing LLM Accuracy.
Peki maliyeti nasıl ölçmeliyiz?
- İstek başına maliyet: Bir sorunun cevaplanması için arama, model kullanımı ve diğer işlem giderleri ne kadar?
- Hata başına maliyet: Yanlış bir cevap müşteri kaybına, para iadesine veya operasyonel zarara neden oluyor mu?
- Bakım maliyeti: Belgeler değiştiğinde veya iş kuralları güncellendiğinde ne kadar çalışma gerekiyor?
- Gecikme: Kullanıcı kabul edilebilir sürede cevap alabiliyor mu?
- İnsan denetimi: Çıktıları kontrol etmek ve hataları düzeltmek için kaç dakika harcanıyor?
Örneğin, varsayımsal bir sistemde 100 bin isteğin her biri için yalnızca 0,002 dolar tasarruf sağlanması, aynı istek hacminde 200 dolar tasarruf anlamına gelir. Hesap basittir: 100.000 × 0,002 = 200 dolar. Fakat bu tutar, toplam sahip olma maliyetinin yalnızca bir bileşenidir; arama altyapısı, geliştirme, bakım ve hata maliyetleri hesaba katılmadan hangi yöntemin daha ucuz olduğu söylenemez.
[HEADING=1]6. Doğruluk, Halüsinasyon ve Güvenilirlik Meselesi[/HEADING]
Bir yapay zekâ uygulamasının düzgün cümleler kurması, doğru bilgi verdiği anlamına gelmez. Özellikle hukuk, finans, sağlık ve müşteri hizmetleri gibi alanlarda bu ayrım çok önemlidir.
RAG'in avantajı, modelin yanıtını belirli belgelerle ilişkilendirebilmesidir. Fakat sistem yanlış belgeyi getirirse veya model kaynakta bulunmayan bir sonucu çıkarırsa yine hata oluşabilir. Kaynak gösterilmesi de tek başına cevabın doğru olduğunun kanıtı değildir.
Fine-tuning tarafında ise model, eğitim örneklerinde gördüğü kalıpları öğrenebilir; ancak eksik, çelişkili veya hatalı etiketlenmiş veriler yanlış davranışlara yol açabilir. Modelin geçmişte gördüğü bir bilgiyle yeni durum arasındaki farkı kendiliğinden doğru ayırt edeceği varsayılmamalıdır.
Bu nedenle iki yöntemde de değerlendirme yapılmalıdır. Örneğin, şirketin daha önce yanıtlanmış 500 gerçek müşteri sorusundan oluşan bir test kümesi hazırladığını düşünelim. Bu 500 soruluk örnek, burada önerilen bir değerlendirme tasarımıdır; belirli bir araştırmanın sonucu değildir.
Soruların bir bölümü sık karşılaşılan basit durumları, bir bölümü istisnaları, bir bölümü de güncel bilgi gerektiren konuları kapsamalıdır. Sistem şu ölçütlerle değerlendirilebilir:
- Cevapların doğruluğu
- Getirilen belgelerin soruyla ilgisi
- Kaynakların cevabı gerçekten destekleyip desteklemediği
- Yanıt biçiminin kurallara uygunluğu
- Yanlış bilgi üretme sıklığı
- İnsan denetimi gerektiren cevapların oranı
ABD Ulusal Standartlar ve Teknoloji Enstitüsü (NIST), üretken yapay zekâ risklerinin yönetiminde verilerin kaynağının belgelenmesini, test ve değerlendirme yapılmasını, doğruluk ve güvenilirliğin uygun yöntemlerle incelenmesini öneriyor. Kaynak: NIST, AI 600-1 Generative AI Profile.
Buradan çıkarılabilecek önemli sonuç, teknik seçimden önce başarının ne anlama geldiğini belirlemektir. Yanıtların yüzde 95'inin doğru olması bir uygulamada yeterli olabilirken, başka bir uygulamada kalan yüzde 5'lik hata kabul edilemez sonuçlar doğurabilir. Üstelik bu yüzde 95, ölçülmüş bir test sonucu değil, başarı eşiğini açıklamak için kullanılan varsayımsal bir örnektir.
[HEADING=1]7. İnsan Odaklı Tasarım: Güven, İletişim ve Kullanıcı Deneyimi[/HEADING]
Bu konuyu yalnızca mühendislik açısından ele almak eksik kalır. Çünkü bir yapay zekâ sisteminin başarısı, teknik performansın yanında insanların o sisteme ne kadar güvendiğiyle de ilişkilidir.
[HEADING=1]4. Gerçek Hayat Senaryosu: E-Ticaret Şirketi Hangisini Seçmeli?[/HEADING]
Somut bir işletme örneği üzerinden düşünelim. Bir e-ticaret şirketinin 20 bin ürün kaydı, yüzlerce destek makalesi ve her gün binlerce müşteri mesajı olduğunu varsayalım. Buradaki 20 bin ürün ve binlerce mesaj, açıklama amacıyla oluşturulmuş varsayımsal rakamlardır; belirli bir şirketin yayımlanmış verileri değildir.
Şirketin üç temel ihtiyacı olsun.
Birinci ihtiyaç: Güncel ürün bilgileri.
Müşteri, “Bu bilgisayarın RAM kapasitesi kaç GB ve garanti süresi ne kadar?” diye soruyor. Ürün özellikleri değişebildiği için cevapların güncel katalogdan gelmesi gerekir.
Bu durumda RAG veya doğrudan yapılandırılmış veri tabanı sorgulaması daha uygun olabilir. Hatta fiyat ve stok gibi kesin değerlerde, serbest metin aramasından ziyade ürün veri tabanına yapılan kontrollü bir sorgu tercih edilebilir.
İkinci ihtiyaç: Müşteri mesajlarını sınıflandırmak.
Şirket, gelen mesajların iade, kargo, ödeme ve teknik destek kategorilerine otomatik ayrılmasını istiyor. Üstelik sonuçların sabit bir şemada sunulması gerekiyor.
Burada fine-tuning yararlı olabilir. Model, geçmişte doğru biçimde etiketlenmiş örneklerden yararlanarak sınıflandırma kurallarını daha tutarlı uygulayabilir. Ancak iyi hazırlanmış talimatlar ve birkaç örnek zaten yeterli sonuç veriyorsa fine-tuning'e hemen geçmek gereksiz maliyet oluşturabilir.
Üçüncü ihtiyaç: Müşteriye uygun bir üslupla yanıt vermek.
Şirket, müşterinin sorununu küçümsemeyen, açık, empatik ve çözüm odaklı bir iletişim dili kullanmak istiyor. Aynı zamanda her yanıtın belirli iş kurallarına uymasını bekliyor.
Burada da fine-tuning, doğru örneklerle belirli bir iletişim tarzını öğrenmeye yardımcı olabilir. RAG ise güncel iade koşullarını ve şirket politikalarını yanıtın içine taşır.
Bu üç ihtiyaç birlikte düşünüldüğünde, en mantıklı mimari şu olabilir: Ürün bilgileri ve şirket politikaları için güncel veri erişimi, mesaj sınıflandırma ve iletişim tutarlılığı için gerekirse fine-tuning.
Asıl içgörü şu: Bir işletmenin bütün yapay zekâ ihtiyaçlarını tek bir teknikle çözmeye çalışmak yerine, her işin hata türünü belirlemek daha değerlidir. Yanlış fiyat vermekle kaba bir yanıt üretmek aynı problem değildir. İlki çoğunlukla veri erişimi ve doğrulama, ikincisi ise davranış tasarımı ve kalite değerlendirmesi gerektirir.
[HEADING=1]5. Performans, Maliyet ve Hız Açısından Hangisi Avantajlı?[/HEADING]
Fine-tuning ve RAG karşılaştırmasında sık yapılan bir hata, maliyeti yalnızca ilk kurulum üzerinden değerlendirmektir.
RAG sisteminde belge depolama, indeks oluşturma, arama altyapısı, modelin kullandığı ek bağlam ve sistemin bakım giderleri bulunabilir. Her kullanıcı sorusunda ilgili belgelerin aranması ve modele aktarılması, gecikmeyi ve kullanım maliyetini etkileyebilir.
Fine-tuning tarafında ise veri hazırlama, eğitim denemeleri, değerlendirme, model sürümlerinin yönetimi ve yeni gereksinimler ortaya çıktığında yeniden uyarlama gibi giderler vardır. Buna karşılık, belirli görevlerde daha kısa talimatlarla ve daha az örnekle çalışmak mümkün olabilir.
Örneğin, günde 100 bin kısa mesajı sınıflandıran bir işletme için küçük ve iyi uyarlanmış bir model ekonomik olabilir. Buna karşılık, her gün değişen mevzuat ve şirket belgeleri hakkında sorular yanıtlayan bir uygulama için RAG daha esnek bir çözüm sunabilir. Bunlar kesin maliyet sonuçları değil, ölçülmesi gereken olası avantajlardır.
OpenAI'nin optimizasyon rehberi, fine-tuning'in bazı uygulamalarda daha küçük modellerle benzer görev başarısına ulaşmaya ve her istekte uzun talimatlar göndermemeye yardımcı olabileceğini belirtiyor. Aynı rehber, RAG'de getirilen içeriklerin ilgililiğinin ayrıca değerlendirilmesi gerektiğini vurguluyor. Kaynak: OpenAI, Optimizing LLM Accuracy.
Peki maliyeti nasıl ölçmeliyiz?
- İstek başına maliyet: Bir sorunun cevaplanması için arama, model kullanımı ve diğer işlem giderleri ne kadar?
- Hata başına maliyet: Yanlış bir cevap müşteri kaybına, para iadesine veya operasyonel zarara neden oluyor mu?
- Bakım maliyeti: Belgeler değiştiğinde veya iş kuralları güncellendiğinde ne kadar çalışma gerekiyor?
- Gecikme: Kullanıcı kabul edilebilir sürede cevap alabiliyor mu?
- İnsan denetimi: Çıktıları kontrol etmek ve hataları düzeltmek için kaç dakika harcanıyor?
Örneğin, varsayımsal bir sistemde 100 bin isteğin her biri için yalnızca 0,002 dolar tasarruf sağlanması, aynı istek hacminde 200 dolar tasarruf anlamına gelir. Hesap basittir: 100.000 × 0,002 = 200 dolar. Fakat bu tutar, toplam sahip olma maliyetinin yalnızca bir bileşenidir; arama altyapısı, geliştirme, bakım ve hata maliyetleri hesaba katılmadan hangi yöntemin daha ucuz olduğu söylenemez.
[HEADING=1]6. Doğruluk, Halüsinasyon ve Güvenilirlik Meselesi[/HEADING]
Bir yapay zekâ uygulamasının düzgün cümleler kurması, doğru bilgi verdiği anlamına gelmez. Özellikle hukuk, finans, sağlık ve müşteri hizmetleri gibi alanlarda bu ayrım çok önemlidir.
RAG'in avantajı, modelin yanıtını belirli belgelerle ilişkilendirebilmesidir. Fakat sistem yanlış belgeyi getirirse veya model kaynakta bulunmayan bir sonucu çıkarırsa yine hata oluşabilir. Kaynak gösterilmesi de tek başına cevabın doğru olduğunun kanıtı değildir.
Fine-tuning tarafında ise model, eğitim örneklerinde gördüğü kalıpları öğrenebilir; ancak eksik, çelişkili veya hatalı etiketlenmiş veriler yanlış davranışlara yol açabilir. Modelin geçmişte gördüğü bir bilgiyle yeni durum arasındaki farkı kendiliğinden doğru ayırt edeceği varsayılmamalıdır.
Bu nedenle iki yöntemde de değerlendirme yapılmalıdır. Örneğin, şirketin daha önce yanıtlanmış 500 gerçek müşteri sorusundan oluşan bir test kümesi hazırladığını düşünelim. Bu 500 soruluk örnek, burada önerilen bir değerlendirme tasarımıdır; belirli bir araştırmanın sonucu değildir.
Soruların bir bölümü sık karşılaşılan basit durumları, bir bölümü istisnaları, bir bölümü de güncel bilgi gerektiren konuları kapsamalıdır. Sistem şu ölçütlerle değerlendirilebilir:
- Cevapların doğruluğu
- Getirilen belgelerin soruyla ilgisi
- Kaynakların cevabı gerçekten destekleyip desteklemediği
- Yanıt biçiminin kurallara uygunluğu
- Yanlış bilgi üretme sıklığı
- İnsan denetimi gerektiren cevapların oranı
ABD Ulusal Standartlar ve Teknoloji Enstitüsü (NIST), üretken yapay zekâ risklerinin yönetiminde verilerin kaynağının belgelenmesini, test ve değerlendirme yapılmasını, doğruluk ve güvenilirliğin uygun yöntemlerle incelenmesini öneriyor. Kaynak: NIST, AI 600-1 Generative AI Profile.
Buradan çıkarılabilecek önemli sonuç, teknik seçimden önce başarının ne anlama geldiğini belirlemektir. Yanıtların yüzde 95'inin doğru olması bir uygulamada yeterli olabilirken, başka bir uygulamada kalan yüzde 5'lik hata kabul edilemez sonuçlar doğurabilir. Üstelik bu yüzde 95, ölçülmüş bir test sonucu değil, başarı eşiğini açıklamak için kullanılan varsayımsal bir örnektir.
[HEADING=1]7. İnsan Odaklı Tasarım: Güven, İletişim ve Kullanıcı Deneyimi[/HEADING]
Bu konuyu yalnızca mühendislik açısından ele almak eksik kalır. Çünkü bir yapay zekâ sisteminin başarısı, teknik performansın yanında insanların o sisteme ne kadar güvendiğiyle de ilişkilidir.