İşiniz için LLM nasıl seçilir?

Model seçiminde hangi kriterler gerçekten önemli?

LLM seçimi, bir iş görevini hangi dil modeliyle, hangi erişim yoluyla ve hangi veri koşullarında çalıştıracağınıza karar verme sürecidir. Kavramın kendisi için LLM nedir sayfamıza bakabilirsiniz.

Genel kıyas tabloları başlangıç için faydalıdır ama sizin görevinizi ölçmez. Seçimi belirleyen kriterler çoğu zaman şunlardır:

• Görev kalitesi: Sınıflandırma, özetleme, belge çıkarımı, araç kullanımı ve uzun akıl yürütme farklı modellerde farklı sonuç verir.
• Dil: Türkçe ekleri, resmi yazışma dilini ve sektör terimlerini doğru işleyip işlemediği.
• Bağlam uzunluğu: Uzun sözleşme veya teknik şartname okunacaksa önemlidir. Güncel sınırlar sağlayıcı dokümanında model bazında yazar.
• Gecikme ve hacim: Canlı sohbette yanıt süresi, toplu işlemde birim maliyet öne çıkar.
• Maliyeti belirleyen etken: Girdi ve çıktı token hacmi, önbellek kullanımı, toplu (batch) işleme seçeneği.
• Veri koşulları: Eğitimde kullanılmama, saklama süresi ve verinin işlendiği bölge.

Model aileleri genellikle kademelidir. Anthropic Claude ailesini Haiku, Sonnet ve Opus gibi kademelerle sunar; Google Gemini için Pro, Flash ve Flash-Lite kademeleri vardır. Hızlı ve ucuz kademe sınıflandırma ve yönlendirme gibi işlerde çoğu zaman yeterlidir; büyük kademe ise zor akıl yürütme işlerinde fark yaratır. Model adları ve sürümleri hızla değiştiği için bu yazıda yazım tarihi itibarıyla aile düzeyinde kalıyoruz.

Doğrudan API mı, bulut sağlayıcı üzerinden mi?

Aynı modele birden fazla yoldan erişebilirsiniz. Anthropic’in model sayfası, Claude modellerinin Claude API’nin yanında Amazon Bedrock, Google Cloud ve Microsoft Foundry üzerinden de sunulduğunu listeler. OpenAI modelleri Azure üzerinden, Gemini modelleri Google Cloud üzerinden de kullanılabilir.

Bulut sağlayıcı yolunun avantajı, mevcut faturalama, kimlik yönetimi, ağ kuralları ve bölge seçimiyle birlikte gelmesidir. Şirketiniz zaten Azure veya Google Cloud kullanıyorsa güvenlik ekibinin onay süreci genellikle daha kısadır. Doğrudan API yolunda ise yeni özellikler çoğu zaman önce gelir ve kurulum daha basittir. Karar, çoğunlukla modelden çok mevcut bulut altyapınıza bağlıdır.

Veri saklama, eğitimde kullanmama ve bölge nasıl karşılaştırılır?

Bu üç konu ayrı sorulardır ve ayrı ayrı teyit edilmelidir.

Eğitimde kullanma. OpenAI’ın kurumsal gizlilik sayfası, API ve kurumsal ürünlerden gelen iş verisinin varsayılan olarak model eğitiminde kullanılmadığını belirtir.

Saklama süresi. Aynı sayfa, API girdi ve çıktılarının hizmet sağlamak ve kötüye kullanımı tespit etmek için 30 güne kadar saklanabileceğini, uygun uç noktalar için sıfır veri saklama (zero data retention) talep edilebileceğini söyler.

Bölge. Microsoft Foundry’de dağıtım türü, verinin nerede işlendiğini belirler: Global türlerde herhangi bir Azure bölgesinde, Data Zone türlerinde ABD, AB veya Asya-Pasifik veri bölgesi içinde, Standard türde seçilen Azure coğrafyası içinde. Google Cloud tarafında global uç noktalar veri yerleşimi garantisi vermez; AB çok bölgeli uç noktası işlemeyi AB üye devletleri içinde tutar.

Türkiye’deki kişisel verileri yurt dışındaki bir sağlayıcıya göndermek, KVKK kapsamında yurt dışına aktarım sorusunu doğurur. Hangi verinin modele gideceğini, maskeleme gerekip gerekmediğini ve aktarım dayanağını hukuk danışmanınızla birlikte değerlendirin.

Kapalı model mi, açık model mi?

Açık ağırlıklı modeller kendi sunucunuzda veya özel bulut ortamınızda çalıştırılabilir. Veri dışarı çıkmaz ve modelin sürümü sizin kontrolünüzdedir. Karşılığında GPU kapasitesi, güncelleme, güvenlik yaması ve izleme sizin sorumluluğunuza geçer.

Açık model genellikle şu durumlarda mantıklıdır: veri hiçbir koşulda dışarı çıkamıyorsa, iş hacmi sabit ve yüksekse ya da belirli bir dar görev için küçük bir modeli fine-tuning ile uyarlamak istiyorsanız. Hacim düşük ve değişkense, kapalı bir modelin API üzerinden kullanımı çoğu zaman daha az işletme yükü getirir.

Aşağıdaki tablo seçenekleri yan yana koyar ve yalnız sağlayıcı dokümanlarına dayanır. Kalite ve maliyet hücrelerinde ölçüm yerine nasıl test edileceği yazılıdır, çünkü bu değerler göreve ve zamana göre değişir.

Kriter	OpenAI API	Anthropic Claude	Google Gemini	Azure (Foundry)	Açık model, kendi sunucunuzda
Görev kalitesi	Kendi test setinizle ölçün	Kendi test setinizle ölçün	Kendi test setinizle ölçün	Barındırılan modele bağlı	Model boyutuna bağlı; test edin
Türkçe	Kendi örneklerinizle deneyin	Kendi örneklerinizle deneyin	Kendi örneklerinizle deneyin	Barındırılan modele bağlı	Modelin dil kapsamına bakın
Kademe seçeneği	Farklı boyutta modeller	Haiku, Sonnet, Opus kademeleri	Pro, Flash, Flash-Lite kademeleri	Katalogdaki modeller	Boyut seçimi sizde
Erişim yolu	Doğrudan API, Azure	Claude API, Bedrock, Google Cloud, Foundry	Gemini API, Google Cloud	Azure aboneliği içinde	Kendi altyapınız
Eğitimde kullanma	Varsayılan olarak hayır (kurumsal gizlilik sayfası)	Sözleşmeden teyit edin	Sözleşmeden teyit edin	Sözleşmeden teyit edin	Veri sizde kalır
Bölge seçeneği	Güncel dokümandan teyit edin	Bulut sağlayıcıda bölgesel uç nokta	Google Cloud’da AB çok bölgeli uç nokta	Global, Data Zone, Standard	Sunucunuz neredeyse orası
Maliyet etkeni	Token hacmi	Token hacmi, önbellek	Token hacmi	Token veya ayrılmış kapasite	GPU ve işletme ekibi

Türkçe kalite ve maliyet kendi verinizle nasıl test edilir?

1. Görev başına 30 ila 100 gerçek örnek toplayın. Müşteri e-postaları, fatura satırları, sözleşme maddeleri. Kişisel verileri maskeleyin.
2. Beklenen çıktıyı yazın. Sınıflandırmada doğru etiket, çıkarımda doğru alanlar, özetlemede kontrol listesi.
3. İki üç adayı aynı istemle çalıştırın. Her modelin dokümanındaki istem önerilerine göre küçük ayarlar yapın ama test setini değiştirmeyin.
4. Kaliteyi, gecikmeyi ve token tüketimini birlikte kaydedin. Maliyeti, kendi aylık hacminizle çarparak hesaplayın.
5. Hataları okuyun. Puan kadar, hatanın türü de önemlidir: Türkçe ek hatası mı, yanlış alan mı, uydurma bilgi mi?

Embedding modeli de aynı yöntemle ayrıca seçilir; arama kalitesi çoğu zaman sohbet modelinden çok embedding seçimine bağlıdır.

Son olarak tek model mi, görev başına model mi sorusu var. Tek model başlangıçta basittir. Hacim arttıkça görevleri ayırmak mantıklı hale gelir: gelen talebi sınıflandırmak için hızlı ve ucuz bir kademe, zor vakalar için büyük bir kademe. Bu yönlendirme, model çağrılarını tek bir katmanda toplarsanız sonradan da eklenebilir. Doküman analizi veya içerik otomasyonu gibi hacimli işlerde fark en çok burada görülür.

Nereden başlamalı?

Önce görevi ve veri kurallarını yazın, sonra modele bakın. KOBİ’ler için çoğu zaman tek bir sağlayıcı ve iyi bir test seti yeterlidir; teknoloji ve yazılım ekiplerinde ise çoklu model ve yönlendirme daha erken gündeme gelir.

Corrplus’ta model seçimini keşif aşamasında, müşterinin kendi örnekleriyle yapılan karşılaştırmalı bir testle yapıyoruz ve sonucu veri ve bölge değerlendirmesiyle birlikte yazılı hale getiriyoruz. Ayrıntılar için LLM entegrasyonu ve yapay zeka danışmanlığı sayfalarımıza bakabilirsiniz.