Kodlamayla ilgili tüm makine öğrenimi konularında oldukça kapsamlı bir okuma listesi buldum .
Gördüğünüz gibi, insanlar kodlama için makine öğrenmesini uygulamaya çalışıyorlar, ama sadece her türlü kodlama veya hata ayıklamayı kaldırabilecek bir makine değil, her zaman çok dar alanlarda çalışıyorlar.
Bu yanıtın geri kalanı, nispeten geniş kapsamlı "hata ayıklama" makinenize ve bunun neden henüz gerçekten denenmediğine (konu hakkındaki araştırmamın gösterdiği gibi) odaklanıyor.
Cevabın uzun bir kısmını düzelttim. Özetlemek gerekirse (bir sonraki bölüm için önemlidir): mevcut makine öğrenme metodolojisine, bir insanın öğrenebileceği her şeye, bir makineye de gidebilirsiniz. Biz sadece öğrenme alanı algoritmasının kendisi için sınırlı bir uygulanabilirlik değil, fiziksel bölge (CPU hızı, bir makinenin boyutu, ...) ile sınırlıyız.
kod geliştirmeye makine öğrenmesini uygulamak için şimdiye kadar hangi araştırmalar yapıldı? Hata ayıklamaya ne dersiniz?
Buradaki mesele imkansız değil, aksine oldukça karmaşık bir konu.
İnsanlar herkesin hemfikir olduğu evrensel bir kodlama standardı tanımlamaya bile yaklaşmadılar. SOLID gibi en yaygın olarak üzerinde anlaşılan ilkeler bile, ne kadar derinlemesine uygulanması gerektiği konusunda hala bir tartışma kaynağıdır . Tüm pratik amaçlar için, herhangi bir mali (veya zaman) kısıtlamanız olmadığı sürece SOLID'e mükemmel bir şekilde uymak imkansızdır; bu da çoğu gelişmenin gerçekleştiği özel sektörde mümkün değil. SOLID zor bir sınır değil bir kılavuzdur.
Doğru ve yanlış için nesnel bir ölçüt olmadığında, öğrenmesi için bir makineye nasıl olumlu / olumsuz geribildirim verebiliriz?
En iyi ihtimalle, birçok kişinin makineye kendi fikirlerini vermesini sağlayabiliriz ("bu iyi / kötü kod") ve makinenin sonucu daha sonra "ortalama bir görüş" olacaktır. Ancak bu doğru bir çözümle aynı olmak zorunda değildir . Olabilir, ancak olması garanti edilmez.
İkincisi, özellikle hata ayıklama için, belirli geliştiricilerin belirli bir hata / hata türünü uygulamaya eğilimli olduklarını kabul etmek önemlidir. Hatanın doğası, bazı durumlarda, onu tanıtan geliştiriciden etkilenebilir.
Örneğin, sık sık işyerinde başkalarının kodunu düzeltmekle meşgul olduğum için, her geliştiricinin ne tür bir hata yapmaya eğilimli olduğuna dair bir beklentim var. Belirli bir sorun göz önüne alındığında, dev A'nın yapılandırma dosyasını güncellemeyi unutmasının muhtemel olduğunu biliyorum, oysa dev B genellikle kötü LINQ sorguları yazıyor. Geliştiriciye dayanarak, önce config dosyasına veya LINQ'ya bakabilirim.
Benzer şekilde, şu anda birkaç şirkette danışman olarak çalıştım ve hata türlerinin belirli şirket türlerine karşı önyargılı olabileceğini açıkça görebiliyorum. Kesin olarak işaret edebileceğim zor ve hızlı bir kural değil, ama kesin bir eğilim var.
Bir makine bunu öğrenebilir mi? Dev A'nın yapılandırmayı bozma ve dev B'nin LINQ sorgusunu bozma olasılığının daha yüksek olduğunu fark edebilir misiniz? Tabii ki yapabilir. Daha önce söylediğim gibi, bir insanın öğrenebileceği her şey, bir makine de yapabilir.
Ancak, makineye tüm olasılıkları öğrettiğinizi nasıl anlarsınız? Nasıl küçük (küresel değil) bir veri kümesi sağlayabilir ve hataların tüm spektrumunu temsil ettiği gerçeğini nasıl bilebilirsiniz? Veya evrensel olarak kullanılabilen bir hata ayıklayıcı oluşturmak yerine belirli geliştiricilere / şirketlere yardımcı olmak için belirli hata ayıklayıcılar oluşturmak ister misiniz?
Makine öğrenimli bir hata ayıklayıcı istemek, makine öğrenimli bir Sherlock Holmes istemek gibidir. Bir tane oluşturmak muhtemelen imkansız değildir, ancak genellikle bir hata ayıklayıcı / Sherlock olmanın temel mantığı, konudan özneye değişen ve inanılmaz derecede geniş bir bilgi / olası kusurlara dokunan öznel değerlendirmelere dayanır.
Hızla kanıtlanabilir doğru / yanlış sonuçların olmaması, bir makineye kolayca öğretmeyi ve iyi ilerleme kaydettiğini doğrulamayı zorlaştırır.