Simurg Okulu #3 — Model aileleri, aynı şirketin büyük, orta ve küçük modeli neden var?

Yol günlüğü

Talep Vadisi'nde üçüncü sabah. Dünkü bölümde modelin bir seferde ne kadar metin görebildiğine bakmıştım. Bu sabah yolda karşıma çıkan tabela daha basit ama kafa karıştırıcı bir soru soruyordu: Aynı şirket neden aynı anda üç dört farklı model satıyor ve ben hangisini seçmeliyim?

Bugün öğrendim

Nedir? Model ailesi, bir şirketin aynı nesilde, aynı temel yaklaşımla eğittiği ama boyutu ve yeteneği farklı modellerden oluşan grup. Genellikle bir "büyük" model (en yetenekli, en yavaş, en pahalı), bir "orta" model (günlük işler için denge) ve bir "küçük" model (hızlı, ucuz, bazen cihazda çalışabilen) bulunuyor. Örneğin Anthropic'in Claude ailesinde Opus, Sonnet ve Haiku; Google'ın Gemini ailesinde Pro ve Flash gibi kademeler var. İsimler değişiyor ama mantık aynı.

Nasıl çalışıyor? İlk bölümde gördüğümüz parametre sayısı burada belirleyici. Daha çok parametre genellikle daha fazla bilgi ve daha iyi akıl yürütme demek; ama her token üretimi için daha çok hesap, yani daha fazla bekleme ve daha yüksek maliyet anlamına da geliyor.

Küçük modeller her zaman sıfırdan eğitilmiyor. Bazıları büyük modelin cevaplarından öğrenerek eğitiliyor; buna distillation deniyor ve Marifet Vadisi'nde ayrıca duracağım. Bir de mixture of experts (MoE) yaklaşımı var: model toplamda çok büyük olsa da her token için parametrelerinin yalnızca bir kısmını çalıştırıyor. Bu yüzden "küçük" etiketi bile görece; sitedeki Thinking Machines haberinde "small" diye anılan modelin MoE mimarisinde olduğu yazıyor.

Öbür uçta gerçekten minik modeller duruyor: Underdog'un ses modeli gibi, internete çıkmadan cihazın içinde çalışmak için tasarlanmış olanlar.

Ne yapılabilir? - Zor, tek seferlik iş → büyük model: uzun bir sözleşmeyi incelemek, karmaşık bir hatanın kök nedenini aramak, çok adımlı plan çıkarmak. - Günlük iş → orta model: mail taslağı, toplantı notu özeti, kod parçası açıklama. Çoğu sohbet uygulamasının varsayılanı bu kademe. - Çok sayıda küçük iş → küçük model: binlerce destek talebini kategoriye ayırmak, log satırlarını etiketlemek, anlık otomatik tamamlama. Burada hız ve maliyet, son yüzde birkaçlık kaliteden daha önemli. - Karma kullanım: bir uygulama işi önce küçük modelle sınıflandırıp yalnızca zor vakaları büyük modele gönderebiliyor. Faturayı en çok düşüren tasarım genelde bu.

Tüyü yaktım

Kendime basit bir test yaptım: aynı karışık paragrafı (bir toplantı notu) önce bir ailenin küçük, sonra büyük modeline verip "üç maddede özetle" dedim. İkisi de iş gördü; küçük model saniyeler içinde döndü, büyük modelin özeti ise kimin hangi işi üstlendiğini daha doğru ayırdı. Bu tek bir deneme, ölçüm değil; ama "her işe en büyüğü" alışkanlığının gereksiz olabileceğini kendi gözümle gördüm.

Heybeme koyduğum

Her işe ailenin en büyüğü gerekmez: zor işe büyük modeli, hızlı ve tekrarlı işe küçük modeli seçmek hem zaman hem para kazandırır.

Kafama takılan Şirketler kendi modellerini benchmark tablolarıyla karşılaştırıyor; peki bir kurum, kendi gerçek işinde küçük modelin "yeterince iyi" olduğuna nasıl karar verir? Bunun için kaç örnekle, hangi ölçütle test yapmak gerekir, bilmiyorum. Bulduğumda yazacağım.

Son söz

Doğru model, en büyük model değil; işe uyan model. Bir sonraki durakta tabelanın öbür yüzüne bakacağım: Simurg Okulu #4 — Açık ve kapalı modeller: ağırlıkları indirilebilen modelle yalnızca API üzerinden kullanılan model arasındaki fark ne, kim neden hangisini seçiyor?