1. Varyantları hazırlamadan önce soruyu yazın
Yararlı bir karşılaştırma belirli bir karara yanıt verir: maksimum uzunluğu artırmak kesilen yanıtları önler mi? Bir ayrıntı düzeyi gerekli hatları koruyor mu? Daha büyük bir grup hatasız tamamlıyor mu? Bir soru ve tek bir parametre seçin. "En iyi ayarları bulmak" ilk oturum için fazla geniştir.
A'ya referans, B'ye varyant deyin. Değiştirilen tam değeri not edin. Modeli, boyutları ve geçiş sayısını aynı anda değiştirmek farklı bir sonuç üretebilir ama hangi değişikliğin bunu açıkladığını göstermez. Bu denemeleri ayrı karşılaştırmalar için saklayın.
2. Küçük bir veri kümesini ve değerlendirme kurallarını sabitleyin
A ve B için aynı girdileri bir araya getirin. Projenin zorluklarını içeriyorsa bir düzine kadar durum, sınırlı bir ilk karar için yeterli olabilir: görselde ince metin, uzun belge, eksik veri veya alışılmadık format. Bu sayı pratik bir tercihtir, istatistiksel bir garanti değildir. Yalnızca zaten başarılı olan örnekleri dahil etmekten kaçının.
Her girdi için testten önce başarı koşullarını yazın. Bir sunum tercihini engelleyici bir kusurdan ayırın. Bir belge asistanında, daha hoş bir yanıt bir kural uyduruyorsa yine de reddedilebilir. Bir ürün görselinde, çekici bir renk önemli bir öğenin kaybolmasını telafi etmez.
Ayrıca kabul edilen asgari durum sayısını, yasak kusurları ve azami kontrol süresini belirleyin. Sonuçları incelerken projeye özgü bu eşikler aynı kalmalıdır.
| Sabitlenecekler | Örnek not | Bu neden önemli |
|---|---|---|
| Girdiler | cas-01 ile cas-12, aynı dosyalar ve aynı ifadeler | Aynı zorlukları karşılaştırın |
| Kalite ölçütü | Belgede doğrulanabilir ve uydurma içermeyen yanıt | Akıcı bir çıktının bir hatayı gizlemesini önleyin |
| Kritik başarısızlık | Eksik kuralın kesin olarak sunulması | Toplam daha iyi görünse bile bir kusuru reddedin |
| Değişken | A: en fazla 128; B: en fazla 256 yeni token | Farkı tanımlanmış bir değişikliğe bağlayın |
3. Aynı oturumu ve aynı bağımlılıkları koruyun
Modeli, sürümünü, uzantıları, hesaplama motorunu ve diğer parametreleri koruyun. İki varyant arasında başka bir işlem başlatmadan aynı ortamı ve aynı GPU'yu kullanın. Kontrol edemediklerinizi not edin: görünen eşzamanlı etkinlik, dayatılan sürüm değişikliği veya farklı yükleme. Bu değişikliklerden etkilenen bir karşılaştırma daha fazla dikkat gerektirir.
Araç rastgele bir tohum kullanıyorsa ve bunu sabitlemenize izin veriyorsa, her pasaj çifti için değeri koruyun. Bu, karşılaştırmayı kolaylaştırır ancak her yerde aynı çıktıyı garanti etmez. PyTorch, aynı tohumla bile sürümler veya platformlar arasında tam yeniden üretilebilirliğin garanti edilmediğini belirtir.
Aynı kimlik listesiyle A ve B adında iki klasör oluşturun. Ham çıktıları herhangi bir manuel düzeltmeden önce saklayın. Sonradan yapılan bir düzeltme, ilk dosyayı üreten ayara atfedilmemeli; çalışma süresiyle birlikte ek bir işlem olarak görünmelidir.
4. Bir kontrol turu atın, ardından çiftleri karşılaştırın
Önce basit bir girdinin alınan dosyaya veya yanıta kadar gittiğini doğrulayın. Bu bölüm yöntemi kontrol eder. İlk yükleme veya özel bir hazırlık durumunu ayrıca belirtin: A'nın tam başlangıcını, tüm öğeleri zaten yüklü olan bir B bölümüyle karşılaştırmayın.
Aynı senaryoları A ve B için çalıştırın. Araç izin veriyorsa sıralamayı değiştirin, ardından birkaç belirleyici çifti ters sırayla yeniden oynatın. Tek bir sonucun ya da sıralama avantajının tüm sonucu belirlemediğinden emin olun.
Hataları ve reddedilen çıktıları da kaydedin. B büyük bir girdide başarısız olursa, ortalamasını iyileştirmek için onu tablodan çıkarmayın. Gerekirse nedeni ayrı bir B2 denemesinde düzeltin. Böylece, zorluklar ilerledikçe varyantın değiştiği bir dosya yerine okunabilir bir karşılaştırmayı korursunuz.
5. Kabul edilen sonucu ve gözlenen süreyi ayırın
Önce kullanım boyutunda veya aracında kaliteyi inceleyin. Mümkünse değerlendirme sırasında A ve B adlarını geçici olarak gizleyin. Bir kişi çıktıları karışık bir sırayla inceleyip ardından eşleşmelerini yeniden kurabilir. Duyurduğunuz ölçütleri ve her ret için kısa bir gerekçeyi saklayın.
Süre için tek bir tanım seçin: örneğin başlatmadan kaydedilen tam çıktıya kadar. Ardından insan kontrolünü ve düzeltmeleri ayırın. Bir GPU çağrısı etrafındaki kronometre her zaman tamamlanan hesaplamanın ölçüsü değildir: PyTorch/CUDA ile işlemler asenkron olabilir. Yalnızca hesaplamayı yalıtmak istiyorsanız aracın belgelediği ölçüm yöntemini kullanın.
Tekrarlar çakışıyorsa veya zamanlama yaklaşık kalıyorsa "süre farkı sonuçsuz" diye not edin. Tek bir çalıştırmadaki küçük bir fark, kesinmiş gibi sunulan bir kazanç yüzdesini haklı çıkarmaz.
Örnek: bir doküman asistanı için 128 veya 256 yeni token
Küçük bir ekip on iki sabit soruya eksiksiz yanıtlar ister. Aynı modeli, aynı belgeleri, aynı talimatı ve aynı GPU'yu korur. Yalnızca yanıt sınırı değişir: A 128 yeni token'a izin verir, B 256'ya. Transformers'ta max_new_tokens, giriş metninin token'larını saymadan üretimi sınırlar. Bir token bir kelime değildir: sınır kesin bir cümle sayısı tanımlamaz.
Denemeden önce ekip örnek bir kural belirler: on ikiden en az on kabul edilen yanıt ve uydurulmuş hiçbir kural yok. Aşağıdaki tablo, sonuçların okunmasına dair kurgusal bir senaryodur. Ölçülmüş bir asistanı tanımlamaz ve bu değerlerin sizin modeliniz üzerindeki etkisini öngörmez.
A minimuma ulaştı, B daha fazla kabul edilen yanıt alıyor ancak kritik bir kusuru var. Bu kapsam için A'nın tutulmasına, yanıtların gözden geçirilmesine ve başka bir karşılaştırmadan önce B'deki kusurun nedeninin araştırılmasına karar verildi. Daha uzun olması ne kalitenin kanıtı ne de uydurmanın kesin nedenidir.
Ekip, A ile B'yi birbirinden ayıran soruları ve hâlihazırda doğru yanıtlanmış iki soruyu yeniden oynatır. Kusur A ile de ortaya çıkarsa, kararı askıya alır: başlangıçtaki veri kümesi kararlılığı ortaya koymaya yetmemişti. Yalnızca en elverişli olanı saklamak yerine her iki geçişin kaydını da tutar.
| Senaryo kriteri | A: en fazla 128 token | B: maksimum 256 token |
|---|---|---|
| Kabul edilen yanıtlar | 12 üzerinden 10 | 12 üzerinden 11 |
| Kritik kusurlar | 0 | 1 uydurma kural |
| Süre | Gerçek oturumda not edilmeli | Aynı yöntemle not edilmeli |
| Duyurulan kurala uyum | Evet, bu sınırlı senaryoda | Hayır, en iyi toplam olmasına rağmen |
Testinizin izin vermediği sonuçlardan kaçının
Çıktılarından biri göz alıcı diye, diğerleri bozulurken B'yi seçmeyin. Yol boyunca derlemi değiştirmeyin, iki tekrarı iki farklı giriş olarak saymayın ve bir başarısızlığı paydadan silmeyin. Sunulan on iki giriş, bazıları hiç dosya üretmemiş olsa da açıklanacak on iki durum olarak kalır.
Seçilen ayar, incelenen girişler, sürümler ve ölçütler için geçerlidir. On kat daha uzun bir belge ya da farklı görseller için artık uygun olmayabilir. Aşamalı olarak temsili durumlar ekleyin. Bu ilerleme kontrolü genişletir; küçük bir testi sistem sertifikasyonuna dönüştürmez.
Kısa bir karar ve bir sonraki kontrolü saklayın
Nihai dosyanız derlemi, iki yapılandırmayı, çıktıları, kimlik bazında kararları ve birkaç satır sonucu içerir. Seçilen ayarı, nedenini ve sınırını belirtin: «A bu on iki soruda korundu; iki yanıt hâlâ gözden geçirilmeli; ek uzun belgeler kapsanmıyor». Başka biri, oturuma katılmadan seçimi anlayabilmelidir.
Bir sonraki teşhis için A'yı referans olarak saklayın. Hiçbir varyant ölçütleri karşılamıyorsa, teslimat için hiçbirini seçmeyin; yeni bir hipotez oluşturun. Bu devamı başlatmadan önce kopyalama ve kontrol için zaman ayırın. Net bir sınırla tamamlanan bir deneme zaten bir karar getirir; bir kazanan bulana kadar sürdürmek zorunda değildir.