Aynı temsili görevler, güvenlik vakaları, çalışma koşulları ve maliyet varsayımları, adaylar arasındaki farkı görünür kılan tek zemin oluyor. Model kıyasında her adayı bu zemine oturtuyoruz, sıralamayı ondan sonra yapıyoruz.

Sistemin hangi müdahale sınıfına ihtiyaç duyduğu netleştikten sonra sıra modeli seçmeye geliyor. Adayların her birini aynı gerçek görevler, güvenlik vakaları, latency koşulları ve maliyet varsayımlarıyla deniyoruz. Elinizde tekrarlanabilir bir baseline ve seçimin hangi koşullarda geçerli olduğunu gösteren bir kayıt kalıyor.

Elinizde seçilen modeli, elenen adayları, geçerlilik koşullarını ve yeni kıyası başlatacak olayı gösteren tekrarlanabilir bir benchmark ile seçim kaydı kalıyor.

Model Seçimi ve Baseline Karşılaştırması illüstrasyonu: bir modeli hedef davranışa ve başlangıç seviyesine göre ayarlayan ekip

Birlikte çalıştığımız 500'den fazla markadan birkaçı

Tüm referansları gör
  • Decathlon
  • Kuveyt Türk
  • GAP
  • Abdi İbrahim
  • Capital Dergisi

Adil bir kıyas için bütün adaylar aynı sözleşme ve kanıt setiyle değerlendiriliyor. Modele özgü sınırlar da sonuçların yanında duruyor.

  1. Karşılaştırmanın şartlarını baştan yazıyoruz

    Koşular başlamadan önce adayları, hedef görevleri, kritik vakaları, güvenlik kontrollerini, çalışma koşullarını, maliyet varsayımlarını, kapsam dışını ve seçim yetkisini birlikte netleştiriyoruz.

    Yapay zeka desteği
    Kullanım senaryosundan ilk aday seti ve görev listesini model taslaklıyor. Seçim sorumlusu taslağı gerçek karara göre düzeltiyor.
    İnsan onayı
    Sözleşme, karar verici kişinin önündeki seçimi gerçekten yansıtıyor mu? Karar verici kişi, sözleşmenin vereceği kararı doğru yansıttığını onaylıyor.
  2. Kanıt setinin adaylara adil davranmasını kontrol ediyoruz

    Gerçek vakaları ve olumsuz örnekleri baseline kanıtı, bağımlılıklar ve inceleme ölçütleriyle bir araya getiriyoruz. Ardından setin tek bir modelin güçlü yanlarına göre biçimlenip biçimlenmediğine insanlar bakıyor.

    Yapay zeka desteği
    Taslak kanıt setinde bir adayı kayırabilecek görev kategorilerini model işaretliyor. Seçim sorumlusu her bulguyu inceliyor.
    İnsan onayı
    Önemli kullanıcı, görev ve istisnalar adil biçimde kapsanıyor mu? Karar verici kişi, kanıt setinin adaylara adil davrandığını onaylıyor.
  3. Her modeli aynı koşullarda çalıştırıyoruz

    Koşuları bağımsız değerlendirme liderimiz yürütüyor. Kalite, güvenlik, latency, maliyet, hata davranışı ve işletim kısıtlarını kesit kesit uzmanlarımız karşılaştırıyor. Kritik hatalar, sıralamaya girmeden önce ayrıca inceleniyor.

    Yapay zeka desteği
    Model, koşu çıktılarını aday ve kesit bazında ayırıp ilk karşılaştırma tablosunu hazırlıyor. Uzmanlar tabloyu kanıtla karşılaştırıp doğruluyor.
    İnsan onayı
    Hangi adaylar kabul kontrollerini hangi koşullarla karşılıyor? Her kritik kesit hatasını nihai sıralamaya almadan önce bir uzman inceliyor.
  4. Seçimi ve sınırlarını kayda geçiriyoruz

    Seçilen aday, elenen alternatifler, istisnalar ve açık kaygılar aynı kayıtta yer alıyor. Sorumlu kişiyi ve yeniden incelemeyi başlatacak olayı ya da tarihi de belirtiyoruz.

    Yapay zeka desteği
    İncelenmiş bulgulardan seçilen ve elenen adayları kapsayan ilk seçim kaydını model hazırlıyor. Karar verici kişi kaydı düzeltip koşulları onaylıyor.
    İnsan onayı
    Seçim, kanıtın gösterdiğinden fazlasını iddia etmeden test kapsamı için destekleniyor mu? Karar verici kişi, nihai adayı ve geçerlilik koşullarını onaylıyor.

Başka bir inceleyen, sunum dosyalarını yorumlamak zorunda kalmadan karşılaştırmanın nasıl yapıldığını izleyebilmelidir.

  • Matris

    Tekrarlanabilir model kıyası ve seçim kaydı

    Aday sonuçlarını ve test koşullarını, seçim gerekçesi, elenen seçenekler, geçerlilik koşulları ve sorumlu kişiyle aynı yerde topluyoruz.

  • Risk kaydı

    Model sürümleri, ölçütler ve kanıt boşluğu envanteri

    Gerçek vakalar, baseline'lar ve ölçütlerin yanında model sürümlerini, sistem bağımlılıklarını, varsayımları ve kanıt boşluklarını gösteriyor.

  • Test kanıtı

    Kalite, güvenlik, latency ve taşınabilirlik karnesi

    Kalite, güvenlik, latency, maliyet, taşınabilirlik ve hata bulguları önemli görev ve istisnalara göre ayrılıyor.

  • Karar kaydı

    Seçilen aday, koşullar ve inceleme tetikleyici listesi

    Seçilen aday ile onaylı koşulların ardından kalan kaygılar, elenen modeller, işletim sorumlusu ve inceleme tarihi yer alıyor.

Müdahale sınıfı belli olduğu hâlde model seçiminin mühendislik, risk, maliyet ve işletim incelemesinden geçmesi gerekiyorsa bu çalışma doğru adımdır.

Şu durumlarda iyi bir seçim

  • Adaylar ayrı demolarda uygun görünüyor, ama aynı temsili görevlerde ve kayıtlı koşullarda henüz yan yana çalıştırılmıyor.
  • Bir model kalite ölçütlerinde öne çıkıyor, ama güvenlik, latency, maliyet veya taşınabilirlik seçim sorumlusunu başka adaya yöneltiyor.
  • Seçim sorumlusunun gerçek vakaları ve mevcut baseline'ı var, ama kritik istisnalar nihai adayın belirlenmesini hâlâ engelliyor.
  • Aday listesi belli, ama hedef görevler, güvenlik vakaları ve işletim kısıtları tek bir karşılaştırma sözleşmesinde buluşmuyor.
  • Benchmark koşuları yeniden üretilebiliyor, ama varsayımlar, bağımlılıklar, kanıt kapsamı ve hata analizi aynı kayıtta görünmüyor.
  • Kalite bu kıyasta bir modeli öne çıkarıyor, ama latency, maliyet ya da taşınabilirlik başka bir adaya işaret ediyor.
  • Bir aday ilk sırada görünüyor, ama onaylı koşullar, elenen seçenekler, kalan kaygılar, sorumlu ve inceleme tetikleyicisi kayda girmiyor.

Şu durumlarda başka bir çalışma daha doğru

  • Test edilen görev, sürüm ve koşulların dışına taşan evrensel bir en iyi model arıyorsunuz, ama bu kıyas yalnızca kaydedilen kapsam için konuşuyor.
  • Kıyas yalnızca parlak demo vakalarına dayanıyor, bu yüzden hedef kullanıcıları, görevleri ve kritik istisnaları temsil edemiyor.
  • Satın alma, production entegrasyonu veya yayın onayı bekliyorsunuz, çünkü bu kararlar karşılaştırma sözleşmesinin dışında kalıyor.

Bunlardan biri sizin durumunuza daha yakınsa, buradan başlayın: Model özelleştirmeyi incele

Zeo'nun kod yazıp teslim eden tarafı burası. Kıdemli mühendislerimiz agent, chatbot ve RAG sistemleri geliştiriyor, çevrelerindeki otomasyon ve veri işlerini üstleniyor, sistemler canlıya çıktıktan sonra da işletmeyi sürdürüyor. 2011'den beri 500'den fazla markayla çalıştık.

  • OpenRouter

    Aday modelleri tek noktadan aynı benchmark ile test eden erişim alanı

  • Together AI

    Açık ağırlıklı adayları kapalı API'lerle aynı koşullarda barındıran altyapı

  • Braintrust

    Her aday modeli aynı görev ve kriterlerle çalıştıran test ortamı

  • Helicone

    Adayların benchmark sırasındaki gerçek latency ve maliyetini ölçen sistem

  • Ragas

    Kaynağa dayalı yanıt kalitesini tüm adaylarda aynı puanlayan değerlendirme bileşeni

  • Arize Phoenix

    Aday modellerin ayrıştığı noktaları ve tercihler arasındaki dengeleri görselleştiren araç

Modelleri, gerçek görevleri, mevcut baseline'ı ve seçim yetkilisini getirin. İnceleyen herkesin izleyebileceği bir kıyas çerçevesi kuralım.
Model kıyasını konuşalım

Kıyasa başlayabilmek için sizden neler istiyoruz?

Aday modelleri ve sürümlerini, hedef görevleri, normal ve kritik vakaları, mevcut baseline kanıtını birlikte topluyoruz. Güvenlik ve kalite gereksinimleriyle latency ve maliyet kısıtlarını da bilmemiz gerekiyor. Dağıtım varsayımları, bilinen bağımlılıklar ve adayı kabul etmeye ya da reddetmeye yetkili kişi bu çerçeveyi tamamlıyor.

Bu kıyas bize en iyi modeli söyler mi?

Test ettiğimiz görevler, sürümler, kısıtlar ve kabul kontrolleri içinde en uygun adayı gösterebilir. Bu sonuç evrensel bir kazanan anlamına gelmez. Seçim kaydı kapsamı, istisnaları ve geçerlilik koşullarını önerinin yanında tutuyor.

Karşılaştırma ne zaman karar vermek için yeterli olur?

Karar verici kişi, kabul kontrolleriyle kritik istisnaları hedef görev ve kısıtlardaki tekrarlanabilir koşulara kadar izleyebilmelidir. Çelişen bulgular ve eksik kanıtlar açık kalıyor. Bunları genel ortalamaya karıştırmıyoruz. Bu görünürlük oluştuğunda karar onaylanabilir, koşula bağlanabilir, ek kanıtla genişletilebilir ya da reddedilebilir.

Kıyası hangi durumda yeniden çalıştırmalıyız?

Model sürümü, görev dağılımı, güvenlik gereksinimi, latency veya maliyet profili, sağlayıcı koşulları ya da dağıtım ortamı değiştiğinde seçimi yeniden ele almak gerekir. Kritik bir hata pattern'i de yeni kıyası başlatabilir. Teslim kaydında hem tetikleyiciyi hem de sorumlu kişiyi belirtiyoruz.