Aynı dört soruda yükselmek neyi gösterir?
Ekip bir promptu deniyor, yanlış cevapları inceliyor ve talimatı düzeltiyor. İkinci denemede puan yükseliyor; üçüncüde bütün sorular geçiyor. Bu yararlı bir geliştirme döngüsüdür. Ancak artık o sorular promptun tasarımını etkilemiştir. Aynı puanı yeni ve görülmemiş görevlerde başarı kanıtı diye sunmak, geliştirme ölçümünün kapsamını genişletir.
Burada model ağırlıklarını eğitmiyoruz; prompt, örnekler ve cevap kuralları üzerinde çalışıyoruz. Yine de test cevaplarını gördükten sonra tasarımı değiştirmek, sonraki sonucun bağımsızlığı açısından önemlidir. Bu yazıdaki kartlar, sürümler ve puanlar sentetiktir. Gerçek bir model veya hizmet karşılaştırması yapılmamıştır. Amacımız başarılı bir pilot ilan etmek değil, hangi sonucun hangi kararı desteklediğini açık bir kayıtla göstermek.
Görev: Sentetik oda taleplerini dört kurala göre kabul, ret veya bilgi eksik olarak sınıflandır. D1–D4: Geliştirme kartları; cevapları ekipçe görülebilir. H1–H4: Kapalı son test; V2 seçilene kadar cevaplar geliştiriciye gösterilmez. Kartlar birbirinin kopyası değildir. Başarı ölçütü: Kartın kararı ve kaynak gerekçesi birlikte doğru olmalı. Bu küçük set istatistiksel yeterlilik iddiası taşımaz.
Kapalı testin ayrı olması yalnızca dosyayı başka klasöre taşımak değildir. Ekip kartların cevaplarını veya hata açıklamalarını daha önce görmüşse bu bilgi geliştirmeyi etkileyebilir. Kayıtta kimlerin hangi içeriğe ne zaman eriştiği yer almalıdır. Burada bir değerlendirme sorumlusu H kartlarını tutar; geliştirici V2’yi seçip dondurana kadar H sonuçları açılmaz.
Önce geliştirin, sonra seçilen sürümü sınayın
Google’ın veri bölme rehberi, geliştirme sırasında kullanılan doğrulama kümesi ile son değerlendirme kümesini ayırır ve aynı kümenin tekrar kullanımla aşınabileceğini anlatır. Bu yaklaşımı prompt geliştirmeye uyarlıyoruz. Rehberden belirli bir bölme yüzdesi veya dört kartın yeterli olduğu sonucu çıkarmıyoruz. Görev kapsamına uygun, birbirini tekrar etmeyen ve gerçek kullanım çeşitliliğini temsil eden örnekler ayrıca gerekir.Kaynak: Google — Datasets: Dividing the original dataset
| Sürüm | D1 | D2 | D3 | D4 | Geliştirme sonucu |
|---|---|---|---|---|---|
| V0 | Geçti | Geçti | Kaldı | Kaldı | 2/4 |
| V1 | Geçti | Geçti | Geçti | Kaldı | 3/4 |
| V2 | Geçti | Geçti | Geçti | Geçti | 4/4 |
V1, D3’te eksik alan varken kesin karar verilmesini önleyecek talimat ekliyor. V2, D4’teki koşullu sınır için kaynak gerekçesini zorunlu hale getiriyor. Bu değişikliklerin ikisi de görülen hatalardan öğreniyor; bunu saklamak gerekmez. Geliştirme raporunda iyileşmenin hangi örneği hedeflediği açıkça yazılır. Sorun, bu aynı örnekleri daha sonra bağımsız son test diye yeniden adlandırmaktır.
D1–D4 geliştirme kartlarında V0=2/4, V1=3/4, V2=4/4. H1–H4 sonuçları V2 seçilene kadar kapalı. V2 seçildikten sonra H sonucu 3/4 ve H4 yanlış. Ekip H4 cevabını görüp V3 yazıyor; V3 aynı H setinde 4/4 oluyor. Her sonucu geliştirme, ilk kapalı değerlendirme veya görülmüş testte tekrar olarak sınıflandır. V3 için bağımsız başarı iddiası üretme. Sonraki değerlendirme için hangi yeni kanıtın gerektiğini belirt.
H4’ü düzeltmek testi yeniden kapatmaz
| Sıra | Olay | O anda bilinen bilgi | Rapor kapsamı |
|---|---|---|---|
| 1 | V2 seçilip donduruldu | D sonuçları açık; H kapalı | Geliştirme seçimi |
| 2 | V2, H1–H4 üzerinde değerlendirildi | H1–H3 geçti; H4 kaldı | İlk kapalı test: 3/4 |
| 3 | H4 cevabı ve gerekçesi incelendi | H4 artık geliştirmeye açık | Bağımsızlık sınırı kaydedilir |
| 4 | V3, H4 hatası için değiştirildi | H4 bilgisi tasarıma girdi | Yeni geliştirme sürümü |
| 5 | V3 aynı H setinde denendi | Dört sonuç artık görülmüş | Tekrar sonucu: 4/4 |
V2 için H setindeki 3/4, bu dört kapalı kart üzerindeki ilk değerlendirmedir. Bu sonuç başka görevlerde aynı oranın korunacağını garanti etmez. V3’ün 4/4 sonucu ise H4 hatasının düzeltildiğini gösteren yararlı bir tekrar kontrolüdür. Ancak V3 bu kartın doğru cevabından etkilenmiştir. İki sayıyı yan yana koyup “bağımsız başarı yüzde 75’ten yüzde 100’e çıktı” demek uygun değildir.
V3’ü yeni bir son değerlendirmeye almak için önceden geliştirmede kullanılmamış yeni kartlar gerekir. Bunları aynı dört kartın isimlerini değiştirerek üretmek yeterli olmayabilir; karar mantığı ve zorlayıcı koşullar da çeşitlenmelidir. Yeni setin görev kapsamı ve kabul ölçütü, sonuç görülmeden belirlenmelidir. Yeni örnek toplamak mümkün değilse sınırlamayı raporlayın ve elinizdeki sonucu yalnızca görülen testlerde düzeltme olarak adlandırın.
V2: D geliştirmesinde 4/4; ilk kapalı H değerlendirmesinde 3/4. V3: H4 geri bildirimiyle değiştirildi; aynı H setinde 4/4. V3 için bağımsız son test henüz yok. Yeni ve geliştirmede görülmemiş kartlarla değerlendirme planlanmalı. Bu kayıt canlı kullanım onayı değildir.
- Sürüm seçimi son test sonuçları açılmadan yapıldı mı?
- Test cevabı veya hata gerekçesi prompta, örneğe ya da kurala girdi mi?
- Kart kimlikleri ve içerik sürümleri değişmeden izleniyor mu?
- Tekrar testi ile ilk kapalı değerlendirme ayrı raporlanıyor mu?
- Örneklerin görev çeşitliliği ve kritik koşulları kapsadığı ayrıca incelendi mi?
H2 daha önce görülmüşse ne söyleyebilirsiniz?
Alıştırmada geliştiricinin V2 seçilmeden önce H2’nin doğru cevabını bir sunumda gördüğü ortaya çıksın. Diğer H kartlarına eriştiğine dair bilgi yok. Orijinal H sonuçları H1, H2 ve H3 için geçti, H4 için kaldı. Raporu nasıl düzeltirsiniz? H2’nin dosya adı değişmediği için hâlâ kapalı kabul edilmesi yeterli bir gerekçe değildir.
H2 geliştirme öncesinde görülmüş olarak işaretlenir. Dört kartın tamamı için kapalı test iddiası geri çekilir. Görülmediği doğrulanan H1, H3, H4 alt kümesinde sonuç 2/3’tür; bu küçük ve sonradan ayrılmış kapsam açıkça belirtilir. Tercih edilen sonraki kanıt, yeni bağımsız setle önceden tanımlı değerlendirmedir.
Ekip içinde bu kaydı bir suçlama aracı olarak kullanmayın. Amaç, iyileştirme döngüsünü engellemek değil hangi geri bildirimin hangi sürümü etkilediğini görünür kılmaktır. Teslimatınız sürüm dosyası, kart erişim kaydı, sonuç tablosu ve karar sınırından oluşsun. Böylece sonraki toplantıda aynı başarı sayısına farklı anlamlar yüklemek yerine ortak bir kanıt üzerinden konuşabilirsiniz.
Kaynaklar ve doğrulama
- Google — Datasets: Dividing the original dataset
Geliştirme doğrulaması ile son testin ayrılması ve tekrar kullanımla testin aşınması; prompt örneğine uyarlama özgündür.
Erişim ve kontrol:
Yöneticiler İçin Yapay Zekâ
Yöneticiler İçin Yapay Zekâ programı, pilot sonuçlarının hangi karara yeterli olduğunu tartışmak için uygundur. Eğitim talebinizde geliştirme sırasında görülen örneklerle son değerlendirmeyi nasıl ayırdığınızı anlatabilirsiniz.
- Kuruma özel planlanır