Keşif Yazılımı: Keşifte Dengeyi Sağlamak

Hayatım boyunca araştırmada çalıştım, bu yüzden araştırmacıların çirkin kod yazdığına dair bir stereotip biliyorum (örneğin buraya , buraya veya buraya bakın). Ama düşündüm: Bunu düzeltebiliriz, değil mi? Bu yüzden birçok kez güzel araştırma çerçeveleri tasarlamaya çalıştım. Okumayı sevdiğim yazılım mühendisliği kitaplarını ve bloglarını kullanarak arayüzler oluşturmaya ve güzel soyutlamalar oluşturmaya çalıştım.

Ancak tekrar tekrar tüm bu çabalar boşa çıktı. Üzerinde çalıştığım araştırma yazılımlarının çoğunluğu hiçbir zaman üretime geçmedi (bazıları üretime geçmiş olsa da). Birisi bana basit bir gerçeği söyleseydi akıl sağlığım için harika olurdu: aslında olması gereken şey araştırma kodunun ölmesidir . Araştırmacılar ilk etapta bunun mühendisliğine fazla zaman harcamamalıdır.

Profesyonel yazılım mühendisleri, en iyi yazılım uygulamalarını kullanmayan araştırmacıları her zaman küçümserler. Araştırma kodu çıtasını yükseltmeye çalışan birkaç gönderi var (örneğin bu harika gönderi ve bir araştırma kodu el kitabı ). Ancak bu yazı bunun tam tersini söylüyor: En iyi yazılım uygulamalarını abartmamayı ve bunun yerine yalnızca hızlı keşfetmeye nasıl yatırım yapılacağını tartışıyor. Amacının birçok fikri hızlı bir şekilde denemek olduğu araştırma odaklı şirketlere yöneliktir.

1. Stratejik teknoloji borcunu üstlenin

Bir şirketteki başarılı bir araştırma projesinin iki aşaması vardır: keşif ve kullanım. "Keşifte" mümkün olduğunca çok sayıda farklı çözümü denemek istersiniz. “Kullanım” sırasında en iyi çözümü sağlamlaştırmanız ve onu kullanışlı bir ürüne dönüştürmeniz gerekir.

Optimal yazılım uygulamaları ikisi arasında oldukça farklıdır. Bu nedenle şirketlerin sıklıkla ayrı araştırma ve ürün bölümleri vardır. Yazılım tasarımıyla ilgili olarak okuyabileceğiniz kitapların tümü esas olarak ikinci "kullanım" aşamasıyla ilgilidir. Bu aşamada ölçeklenebilir bir ürünün temellerini oluşturuyorsunuz. Tüm tasarım modellerinin devreye girdiği yer burasıdır: güzel API'ler, günlük kaydı, hata yönetimi vb.

Ancak ilk "keşif" aşamasında sonsuza kadar yaşayacak temeller atmıyorsunuz . Aslında, çabalarınızın çoğunluğu hayatta kalıyorsa, o zaman (tanım gereği) yeterince araştırmamışsınız demektir.

Bu yazıdaki birçok uygulama, normalde "teknoloji borcu" haline gelecek olanın örnekleridir. Temiz, yeniden kullanılabilir, iyi özetlenmiş kod yazmayarak elde ettiğiniz şey budur. Borç her zaman kötü müdür? Asla kredi veya ipotek almamayı tercih ederiz, ancak borç para almak genellikle hayatta iyi bir stratejidir. Hızlı hareket etmek ve daha sonra kâr etmek için borca girmekte sorun yoktur.

Benzer şekilde, teknik borç almayarak araştırmanızı yavaşlatıyor olabilirsiniz. İyi haber şu ki çoğu zaman geri ödemek zorunda kalmıyorsunuz. Araştırma kodunuzun çoğunun zaten ölmesi muhtemeldir. Yani ortalama olarak aldığınız tüm teknik borcun acısını çekmeyeceksiniz.

Kodun yeniden kullanımına karşı dava

Birçok yazılım mimarisi ve yeniden düzenleme tekniği, özellikle kodun yeniden kullanılabilirliğini iyileştirmeye yöneliktir. Kodun yeniden kullanımının genel dezavantajları vardır. Ancak üretimde, iyi bilinen faydalar nedeniyle bunlar daha ağır basmaktadır (örneğin, bu tipik gönderiye bakın). Araştırma projelerinde kodun çoğunluğunun unutulmaya mahkum olması kaçınılmazdır. Kodu yeniden kullanmak için çabalamak aslında sizi yavaşlatabilir.

Kodun yeniden kullanımını sınırlamak, araştırmada alınması uygun olan teknik borç türüdür. Tartışmak istediğim birkaç kod yeniden kullanım modeli var: gereksiz bir bağımlılık eklemek, kodu kopyalayıp yapıştırmak, çok sayıda paylaşılan araştırma kodunu sürdürmek, erken tasarım yatırımları.

Yeni bir şey ithal etmeden önce iki kez düşünün

Sizi hızlandıracak, bakımlı ve sürümlü bir kitaplık biliyorsanız - devam edin! Ancak yeni bir bağımlılığa başlamadan önce buna değip değmeyeceğine karar vermeye çalışın. Her ilave, sizi bağımlılık cehennemine daha da yaklaştırır. Öğrenmeye ve sorun gidermeye zaman ayırmanızı sağlar. Bu kısa gönderide bağımlılığın diğer tuzaklarını görün.

Aşağıdaki durumlarda bir şeye bağlı olmak muhtemelen iyidir:

• zaten kullandınız, öğrenecek pek bir şey yok, geniş bir topluluğu var, iyi dokümanlar ve testler var
• versiyonlanmıştır, kurulumu kolaydır
• ve son olarak, bunu kendi başınıza uygulayabilmenizin hiçbir yolu yok.

• 
  

Ancak aşağıdaki durumlarda bağımlılığa karşı dikkatli olun:

• onu nasıl hızlı bir şekilde kullanacağınızı çözemiyorsunuz, çok yeni (ya da çok eski) ya da hiç kimse onu bilmiyor gibi görünüyor; belge veya test yok

• monorepo'nuzdan geliyor ve diğer ekipler tarafından sürekli değiştiriliyor

• diğer birçok bağımlılığı ve aracı da kendine çeker; veya kurulumu zor

• ve son olarak, kendinizin (veya bazı LLM'lerin) bu kodu birkaç saat içinde yazabileceğini hissediyorsunuz.

  
  

Açık bir bağımlılık yerine güzel bir Go atasözünü takip edebilirsiniz: Bir sonraki konumuz olan “ biraz kopyalamak, biraz bağımlılıktan iyidir ”.

Copypaste size deneme özgürlüğü verir

Bazıları “ kopyala-yapıştırın yasa dışı olması gerektiğini ” söylüyor. Ama şaşırtıcı bir şekilde kendimi sık sık bunun lehine tartışırken buldum. Kopya macunu, keşif aşamasında en uygun seçim olabilir.

Kod tabanının başka bir bölümünden yoğun olarak kullanılan bir işleve bağlıysanız, onu kolayca değiştirmeyi unutabilirsiniz. Muhtemelen birisi için bir şeyleri bozarsınız ve kod incelemeleri ve düzeltmeleri için değerli zaman harcamak zorunda kalırsınız. Ancak gerekli kodu kopyalayıp klasörünüze yapıştırırsanız, onunla istediğiniz her şeyi yapmakta özgürsünüz. Bu, deney yapmanın bir istisna olmaktan çok bir norm olduğu araştırma projelerinde büyük bir sorundur. Özellikle değişikliklerin herkes için yararlı olup olmayacağından emin değilseniz.

Derin öğrenme kod tabanlarının kopyalayıp yapıştırmaya en uygun olduğunu düşünüyorum. Genellikle bir modeli ve onun eğitimini tanımlamak için gereken kod miktarı o kadar da büyük değildir. Ancak aynı zamanda çok incelikli olabilir ve genelleştirilmesi zor olabilir. Paylaşılabilir eğitim komut dosyaları yönetilemez bir boyuta ulaşma eğilimindedir: örneğin Hugging Face transformers Trainer'ın +4k satırı vardır. İlginçtir ki, transformatörler model düzeyinde kopyala yapıştırmayı tercih etti. Lütfen "tek dosya modeli" politikalarının ardındaki gerekçeleri içeren gönderilerine göz atın. Sonunda kopyala macunun güzelliği hakkında daha fazla kaynak görün.

Kopyala yapıştırmanın bir alternatifi dalda kalmaktır. Ancak bunun ekip çalışmasına çok fazla yük getirdiğini düşünüyorum. Ayrıca, kopya macunun güzelliği hakkında birkaç gönderi daha buldum - daha fazla gönderiyi sonuç bölümünde görebilirsiniz.

Paylaşılan araştırma kodunu sürdürmek zordur

Yoğun olarak kullanılan paylaşılan kodun bakımı çok fazla çalışma gerektirir. Pytorch sürümüne göre çizilen torch.nn.Module dosya satırı sayısına bir göz atın. En gelişmiş araştırma ekiplerinin bile karmaşıklığı kontrol altında tutmakta zorlandığını görebilirsiniz.

Büyük bir paylaşılan araştırma kodunu sürdürmek için gereken zamanı ve kaynakları küçümsemeyin. Bir araştırma kütüphanesi ne kadar çok kullanılırsa o kadar karmaşık hale gelir. Bu, tipik bir kütüphaneye göre daha hızlı gerçekleşir çünkü her araştırma yönünün biraz farklı bir kullanım durumu vardır. Neyin geri bağışlanabileceği konusunda çok katı kurallar belirleyin. Aksi takdirde, paylaşılan kod çok sayıda seçenek, hatalı optimizasyonlar ve uç durumlarla kırılgan hale gelir ve büyümüş olur. Araştırma kodlarının çoğunluğu ortadan kalktığı için, bu ekstra karmaşıklığın tümü bir daha asla kullanılamayacak. Paylaşılan kodunuzun bir kısmını bırakmak, gerçek araştırma yapmak için biraz zaman kazandıracaktır.

Kodun yeniden kullanımı için değil, keşif için tasarım

Üretim aşamasında bile kodunuzu gelecekte de kullanıma hazır hale getirmek istemeyeceğiniz bir bakıma doğrudur. Gereksinimleri karşılayan mümkün olan en basit çözümü uygulamaya çalışın. Ancak üretim kodunda her zaman sürdürülebilirliğin dikkate alınması gereken yönleri vardır. Örneğin, hata işleme, hız, kayıt tutma, modülerleştirme genellikle düşünmeniz gereken şeylerdir.

Araştırma kodunda bunların hiçbiri önemli değil. Bir fikrin iyi ya da kötü olduğunu mümkün olan en hızlı şekilde kanıtlamak ve devam etmek istiyorsunuz. Yani herhangi bir modül veya API olmadan bunu başaran kirli basitlik kesinlikle sorun değil!

Değerli zamanınızı aşağıdaki gibi erken yazılım yatırımlarıyla boşa harcamayın:

• bileşen arayüzlerinin projenin çok erken aşamasında oluşturulması. Kendi yarattığınız yapay kısıtlamalara uyum sağlamak için çok fazla zaman harcayacaksınız
• derin öğrenme çözümüne geçmeden önce derin öğrenme eğitim altyapısını optimize etme
• üretim yapılandırması/fabrikalar/serileştirme sistemleri veya temel sınıfları kullanma. Çoğu zaman prototipleme sırasında bunların işlevlerine ihtiyacınız olmaz.
• aşırı katı astarlama ve tip kontrol sistemleri. Hızla değişen, atılan araştırma kodunu yavaşlatmanın bir anlamı yok.

2. Hızlı keşfe yatırım yapın

Bir araştırma projesinin amacı yeni bir çözüm bulmaktır. Hiç kimse (tanım gereği) neye benzediğini bilmiyor. Bu, sınırlı bilgiye sahip karmaşık bir araştırma ortamındaki optimizasyon sürecine benzer. İyi bir minimum bulmak için birçok yolu denemeniz, iyi ve kötü yolları tanımanız ve yerel minimumlara takılıp kalmamanız gerekir. Tüm bunları hızlı bir şekilde yapabilmek için bazen teknoloji borcu almak yerine yazılım yatırımları yapmanız gerekebilir.

Ortak yolları hızlandırın

Denemek istediğiniz birkaç farklı araştırma yolu vardır. Yolların çoğundan zaman kazandıracak bir tasarım, kitaplık veya optimizasyon var mı? Hiçbir şeye aşırı mühendislik yapmamaya dikkat etmelisiniz çünkü denemek üzere olduğunuz fikirlerin tamamını her zaman bilemezsiniz. Bu her proje için çok özeldir, ancak işte bazı örnekler:

• Derin ağları eğitiyorsanız eğitim altyapısına yatırım yapın. Egzersiz sırasında hızlı ve güvenilir bir şekilde birleşmenizi sağlayan hiperparametreleri belirleyin
• her deney farklı bir model kullanmanızı gerektiriyorsa, bunları hızlı bir şekilde nasıl değiştirebileceğinizi öğrenin (örneğin, basit bir fabrika sistemi kullanarak veya yalnızca kopyala yapıştır yaparak)
• Her deneyde çok fazla parametre varsa ve yönetilmesi zorsa güzel bir yapılandırma kitaplığına yatırım yapın.

Hızla şubeleşin

Araştırmacılar yeni ve çeşitli fikirleri hızlı bir şekilde başlatabilmelidir. Projenin başlangıcında kolay görünüyor. Ancak daha sonra insanlar en sevdikleri araştırma yollarına yerleştikçe bu durum giderek daha da zorlaşıyor. Bunu ele almak için kültürel ve organizasyonel değişiklikler şarttır. Gelecek vaat etmeyen araştırmaları, çok fazla para ve duygu harcamadan önce durduran bir süreç olmalıdır. Düzenli demo günleri ve teknik emsal incelemeleri bu amaç için etkili stratejiler olarak hizmet edebilir. İnsanların yeni ve parlak bir fikre atlaması ile mevcut projeleri düzgün bir şekilde kapatması arasında bir denge bulmak da önemlidir.

Ancak bu bir yazılım gönderisi olduğundan, yeni projeleri dallara ayırmayı kolaylaştıracak bazı uygulamaları burada bulabilirsiniz:

• değerlendirme kodunu algoritmalardan uzak tutun. Değerlendirmeler genellikle araştırma yönergelerinden daha istikrarlıdır
• Boş bir sayfadan yeni bir projeye başlamayı benimseyin, ancak ardından hangi bileşenlerin yeniden kullanıldığına dikkat edin. Bunları modüler hale getirmek ve temizlemek iyi bir yatırımdır
• Yeni bir araştırma projesinde önce en yenilikçi ve riskli bileşeni uygulayın. Bunu yapmak, gelecekteki yazılım tasarımına yön veren darboğazların çoğunu tanımlar.

Sinyal-gürültü oranını artırın

Gürültülü ve hatalı kod, sonuçları o kadar belirsiz ve sonuçsuz hale getirir ki tüm proje zaman kaybı olur. İşleri gereğinden fazla tasarlamamanız gerekirken, karmaşık kodlardan kaçınmak için bu basit temel kuralları kolayca takip edebilirsiniz:

• 
  

• yan etkileri olan kodlardan kaçının

• varsayılan olarak sınıflar yerine işlevler; ve sınıflarda, kalıtıma karşı kapsüllemeyi tercih edin

• fonksiyonların/sınıfların/modüllerin uzunluğunu en aza indirin; if ifadelerinin sayısını en aza indirin

• Python'u iyi biliyorum ama basit teknikler kullanıyorum. Metasınıfların, dekoratörlerin ve işlevsel programlamanın entelektüel yabani otlarına girmenin cazibesine karşı koyun.

  
  

Farklı çalıştırmalar sırasında farklı sonuçlar üreten yazılımlarla çalışmak zordur. Şanssız bir tohuma dayanarak önemli ama yanlış bir karar verdiyseniz, iyileşmek için çok zaman kaybedersiniz. Deterministik olmayan yazılımlarla çalışırken bazı ipuçları:

• Gürültünün algoritmadan mı yoksa değerlendirmeden mi geldiğini anlayın. Gürültü kaynakları birleşir ve tamamen deterministik bir değerlendirme için çabalamalısınız.
• Gerçekten tekrarlanabilir bir senaryo elde edene kadar rastgelelik kaynakları bulmayı bırakmayın. Tüm rastgele tohumları bulduktan sonra gürültünün verilerden veya yan etkileri olan genel işlevlerden gelebileceğini unutmayın.
• tohumları çeşitlendirin ve sonuçlarınızın temel değişkenliğini belirleyin. İstatistiksel olarak anlamlı olmayan sonuçlar hakkında karar almayın.

Çözüm

Can alıcı nokta, araştırma koduyla ilgili bu yazıdan geliyor:

“[İyi yazılım tasarımı] ile uğraşmıyorsunuz çünkü amaç kod değil. Kod, size ihtiyacınız olan cevabı sağlayan bir araçtır” .

Harika kodlama temellerine sahip olmak son derece önemlidir. Ancak günün sonunda önemli olan keşfedilmiş ve gerçekten faydalı üründür. Araştırmada çok fazla üretim yazılımı kullanırsanız, yeni bir şey keşfetmek için gereken zamanı boşa harcarsınız. Bunun yerine keşif sürecinizi neyin yavaşlattığını bulun. Hızlı dallanmaya, sonuçlara ulaşma süresine ve temiz, gürültüsüz koda yatırım yaparak araştırma yollarını hızlandırın.

Kodun yeniden kullanımına tamamen karşı çıkmak çılgınlık olurdu. Sadece kodun yeniden kullanımının dengeli bir etkinlik olması gerektiğini belirtmek istiyorum. Araştırmada, atılan kodların oranı üretimdekinden daha fazladır. Denge yeniden kullanıma karşı daha da eğilir. Kodun yeniden kullanılmasıyla ilgili tuzakları içeren birkaç harika gönderi daha:

• Yeniden Kullanılabilir Kod: İyi, Kötü ve Çirkin

• Kendinizi Tekrarlamak Mantıklı Olduğunda

• Yeniden kullanımın artıları ve eksileri ile Dengeli StackExchange

  
  

Ve işte kopya yapıştırma uygulamalarını savunan birkaç gönderi daha:

• Kopyala yapıştır gerçekten bir sorun mu?

• Kodu Ne Zaman Kopyala-Yapıştır Yapmalısınız?

• Kopyala-Yapıştır Programlamanın İyisi ve Kötüsü

• "5 YOE'li bir son sınıf öğrencisi olarak, maaşımın bir kısmının hangi kodu kopyalayacağımı bilmek olduğunu hissediyorum, hahaha"

  
  

Okuduğunuz için teşekkürler! Bazı kısımların biraz tartışmalı olduğunu düşünüyorum, lütfen yorumlarda bana bildirin!