Tensör Değişken İsimlendirmede Oyun Değiştiren Bir Alışkanlık

Makine öğrenmesi kodlarıyla uğraşırken en büyük sıkıntılardan biri, değişkenlerin neyi temsil ettiğini anlamak oluyor. outputs diye bir şey görüyorsunuz, sonra kafa karışıyor: batch önce mi geliyor, sonra mı? Sequence boyutu var mıydı? Ya da daha kötüsü, bir yerlerde reshape edilmiş mi?

İşin ilginç tarafı, çözüm sandığınızdan çok daha basit.

Boyut Son Ekleri Nedir?

Basitçe ifade edecek olursak, tensör değişkenlerinin sonuna boyut bilgisini gösteren küçük harfler ekliyorsunuz. outputs yerine outputs_bc, activations yerine activations_bcn yazıyorsunuz.

İlk başta gereksiz bir angarya gibi durabilir. Ama tam tersine, makine öğrenmesi projelerinde uygulayabileceğiniz en verimli kodlama alışkanlıklarından biri bu.

Standart Boyut Alfabesi

Her boyutun karşılık geldiği harfler şöyle:

• b — batch (parti) boyutu
• p — pozisyon veya sıra indeksi
• n — nöron boyutu (ağırlık matrisi çarpımından gelen sonuç)
• c — kanal boyutu
• h — yükseklik (görüntü tensörleri için)
• w — genişlik (görüntü tensörleri için)
• d — derinlik (3D veriler için)
• k — kernel boyutu

Örneğin logits_bc dediğinizde, batch boyutunda ve kanal boyutunda logitler olduğunu anlıyorsunuz — sınıflandırma işleri için ideal. positional_embeddings_bpn ise batch, pozisyon ve nöron boyutlarının sıralandığını gösteriyor.

Neden Bu Kadar İşe Yarıyor?

Anında okunabilirlik. probs_bc gördüğünüzde, batch ve sınıf bazında organize edilmiş olasılıklar olduğunu hemen anlıyorsunuz. Araştırma yapmaya, doküman karıştırmaya gerek yok.

Doğal hata yakalama. İşin güzel yanı burası. outputs_bc = torch.matmul(activations_bcn, weights_bcn) yazdığınızda, uyumsuzluk gözünüze çarpıyor. Ağırlık matrisiniz weights_nc olmalıydı, activations_bcn ile doğru çarpım için. Değişken isimleri sanki bir tür kontrol mekanizması gibi çalışıyor.

Kendiliğinden güncel kalan dokümantasyon. Yorumlar zamanla eskiyor, kimse refactor ederken güncellemiyor. Ama embeddings_bpn konvansiyonu koruduğunuz sürece doğru kalıyor — çünkü değişken ismi zaten dokümantasyonun kendisi.

Kod incelemeleri hızlanıyor. Pull request'lerde boyut uyumsuzluklarını kodu çalıştırmadan veya fonksiyon çağrılarını takip etmeden görebiliyorsunuz. Bu, hem zaman kazanıyor hem de hataları erken aşamada yakalıyor.

Günlük Hayatta Kullanım Kalıpları

Birleştirme ve stack işlemleri: Tensörleri birleştirdiğinizde, son eki yeni yapıya göre güncelleyin. İki features_bc tensörünü yeni bir boyut üzerinden stack'lediğinizde, artık features_bck veya seçtiğiniz eksene bağlı olarak features_bkc olur.

Azaltma işlemleri: Pozisyon boyutu üzerinden toplama yaparsanız inputs_bp → inputs_b olur. Kanallar üzerinden argmax alırsanız logits_bc → logits_b olur. Son ek, gerçek durumu yansıtacak şekilde küçülür.

Karmaşık tensörler: Birden fazla boyut kodunu yan yana kullanabilirsiniz. Pozisyon çiftleri arasındaki attention skorları için attention_bpp, batch, pozisyon ve nöron bazında organize edilmiş gradyanlar için gradients_bpn gibi.

Alışkanlık Haline Nasıl Getirilir?

Tek kelime: tutarlılık. Konvansiyonu belirlediniz, her yerde uygulayın — girdilerde, çıktılarda, her ara tensörde. Hatta debug için oluşturduğunuz tek satırlık değişkenlerde bile.

İleride kendiniz teşekkür edeceksiniz. Ekibiniz de edecek.

Makine öğrenmesi uygulamaları geliştiriyorsanız ve ekiple birlikte ölçeklenebilir, bakımı kolay kod istiyorsanız, bu küçük alışkanlıklar birleştiğinde büyük verimlilik artışları sağlıyor. Yazılım geliştirmede iyi isimlendirmenin arkasındaki mantıkla aynı — kodu dokümantasyon gibi okunabilir hale getirmek.

Bir sonraki projenizde bir hafta deneyin. Sanırım sonra "nasıl olmuş da bunu yapmadan kod yazmışım" diyeceksiniz.