Latar belakang saya di bidang teknik mesin, jadi tolong maafkan ketidaktahuan saya untuk bidang ini.
Saya sangat menikmati pemrograman dan pengembangan perangkat lunak. Juga, saya baru-baru ini mengambil kelas Machine Learning (ML) online gratis, yang saya sangat rekomendasikan, diajarkan oleh profesor Stanford Andrew Ng. Tautkan di sini .
Saya pernah mendengar profesor ini mengatakan bahwa sulit untuk menemukan area yang tidak akan pernah terpengaruh oleh ML.
Pertanyaan
Jadi pertanyaan saya adalah, penelitian apa yang telah dilakukan sejauh ini dalam menerapkan pembelajaran mesin untuk pengembangan kode? Bagaimana dengan debugging?
Harap sertakan sumber daya / sumber / makalah ilmiah jika memungkinkan.
Saya belum beruntung mencari ini karena sering mencari ML dan pengembangan perangkat lunak (atau pemrograman) akhirnya mengarah ke hasil dalam pengembangan perangkat lunak (atau pemrograman) aplikasi ML.
Jawaban:
Fuzzing adalah metode pengujian di mana pembelajaran mesin dapat & telah diterapkan. Fuzzing adalah metode pengujian di bidang pengujian eksplorasi otomatis. Mencoba untuk menemukan cacat dalam perangkat lunak dengan menjalankan sejumlah besar input dan mencari kesalahan. Pengecualian yang tidak ditangani adalah kategori paling sederhana, tetapi implementasi yang cerdas dapat menggunakan ML untuk menemukan output yang dicurigai. ML sebagian besar digunakan dalam domain ini untuk membuat proses lebih efisien. Ini berfungsi dengan menggunakan ML untuk menghindari pengujian setiap input yang mungkin dengan melatih input "menarik". (Dis-input serupa yang cenderung menyebabkan kegagalan.)
sumber
Iya. Daerah ini sedang panas sekarang. Ini disebut "kode besar," dan DARPA memasukkan $ 40 juta ke dalamnya: http://www.darpa.mil/program/mining-and-understanding-software-enclaves . Beberapa hasil yang mengesankan telah keluar dari hibah ini, seperti sistem Nabi dan Genesis dari Fan Long, yang secara otomatis dapat memperbaiki bug dalam program dengan menggunakan model patch yang benar yang dipelajari. Martin Vechev dan muridnya Veselin Raychev juga telah menjadi perintis di bidang ini. Mungkin hasil mereka yang paling mengesankan adalah JSNice ( http://jsnice.org/ ), yang dapat " menonaktifkan kode JavaScript.
Secara keseluruhan, gagasan kode besar belum memenuhi janjinya: data terlalu jarang untuk mempelajari sesuatu yang jauh lebih menarik daripada nama variabel. Sementara saya masih didanai sebagian oleh program DARPA ini, lab saya sebagian besar berhenti mengerjakannya. Pada catatan itu, hal terakhir yang saya dengar tentang DeepCoder adalah mendapatkan hasil yang cukup menyedihkan dibandingkan dengan keadaan canggih dalam sintesis program.
Sebagian besar alat yang berhasil untuk pemrograman otomatis masih mengandalkan metode non-ML seperti pemecah SMT. Lihatlah proses konferensi PL apa pun (misalnya: PLDI, POPL, OOPSLA) atau konferensi rekayasa perangkat lunak akademik apa pun (misalnya: ICSE, FSE, ISSTA, ASE), dan Anda akan melihat banyak contoh.
sumber
Microsoft telah mengembangkan DeepCoder untuk menggunakan pembelajaran mendalam untuk memprediksi tubuh metode dari input dan output yang diberikan. Itulah satu-satunya contoh yang saya tahu begitu saja.
Saya dapat memberitahu Anda bahwa Pemrograman Meta-Genetik adalah bidang studi dengan ambisi yang sama, tetapi saya tidak bisa mengatakan bahwa saya cukup tahu tentang hal itu agar dapat diketahui.
Pemrograman Genetik menjadi berita pada tahun 2015 ketika muScalpel mengembangkan solusi untuk mentransplantasikan fitur dari satu program ke program lain, menggunakan unit test untuk keduanya sebagai semacam rangkaian pelatihan.
sumber
Sebuah pertanyaan terkait adalah tentang teknik pembelajaran mesin untuk pembuatan dan kompilasi kode (karena Anda dapat membayangkan transpiler dan kompiler sebagai cara untuk secara otomatis "mengembangkan kode" - secara aktual menulis kode - dari beberapa bahasa tingkat yang lebih tinggi).
Ada beberapa makalah tentang itu, misalnya MILEPOST GCC .
Anda juga dapat mencari makalah tentang teknik pembelajaran mesin untuk debugging atau untuk analisis kode sumber statis (atau segala jenis analisis program statis ).
Lihat juga blog J.Pitrat tentang kecerdasan buatan bootstrap yang terkait dengan pertanyaan Anda.
sumber
Dalam sebuah artikel baru-baru ini di Komunikasi ACM tentang Menghasilkan uang menggunakan matematika, Erik Meijer mengutip Jeff Dean, Senior Fellow Google, Grup Sistem dan Infrastruktur:
Artikel ini memberikan ikhtisar tentang kegiatan terbaru di bidang penelitian. Itu di balik dinding bayar tetapi mungkin layak dibaca jika Anda tertarik dengan persamaan teoretis antara pengkodean dan pembelajaran mesin / statistik. Mungkin daftar referensi di akhir artikel mungkin bermanfaat juga.
Sebagai contoh, artikel ini mengacu pada WebPPL, pemrograman probabilistik untuk web .
sumber
Berikut ini adalah satu kasus penggunaan menggunakan pembelajaran mesin untuk men-debug layanan mikro. Saya mendokumentasikan beberapa upaya dalam menganalisis data kinerja layanan mikro dengan pembelajaran mesin di mana saya melatih pohon keputusan dari data kinerja yang dikumpulkan dari pengujian beban, layanan mikro lalu mempelajari pohon yang memberi saya wawasan tentang masalah lingkungan dan membantu saya mendiagnosis dan memperbaiki bug kinerja.
sumber
Saya menemukan daftar bacaan yang cukup luas pada semua topik pembelajaran mesin yang berhubungan dengan pengkodean .
Seperti yang Anda lihat, orang telah mencoba menerapkan pembelajaran mesin ke pengkodean, tetapi selalu di bidang yang sangat sempit, bukan hanya mesin yang dapat menangani segala macam pengkodean atau debugging.
Sisa dari jawaban ini berfokus pada mesin "debugging" lingkup yang relatif luas dan mengapa ini belum benar-benar dicoba (sejauh penelitian saya menunjukkan topik).
Saya membuat ulang sebagian jawaban yang panjang. Untuk meringkas (penting untuk bagian selanjutnya): mengikuti metodologi pembelajaran mesin saat ini, apa pun yang dapat dipelajari manusia, mesin juga bisa. Kami hanya dibatasi oleh ranah fisik (kecepatan CPU, ukuran mesin, ...), bukan penerapan yang seharusnya terbatas dari algoritma pembelajaran itu sendiri.
Masalahnya di sini bukanlah bahwa itu tidak mungkin, tetapi itu adalah topik yang sangat kompleks.
Manusia bahkan belum mendekati mendefinisikan standar pengkodean universal yang disetujui semua orang. Bahkan prinsip-prinsip yang paling banyak disepakati seperti SOLID masih menjadi sumber diskusi tentang seberapa dalam itu harus dilaksanakan. Untuk semua tujuan praktis, tidak mungkin untuk sepenuhnya mematuhi SOLID kecuali Anda tidak memiliki kendala keuangan (atau waktu) apa pun; yang tidak mungkin dilakukan di sektor swasta di mana sebagian besar pembangunan terjadi. SOLID adalah pedoman, bukan batas keras.
Dengan tidak adanya ukuran obyektif tentang benar dan salah, bagaimana kita bisa memberikan mesin umpan balik positif / negatif untuk membuatnya belajar?
Paling-paling, kita dapat meminta banyak orang untuk memberikan pendapat mereka sendiri kepada mesin ("ini adalah kode yang baik / buruk"), dan hasil mesin tersebut kemudian akan menjadi "opini rata-rata". Tapi itu belum tentu sama dengan solusi yang benar . Bisa saja, tetapi tidak dijamin.
Kedua, untuk debugging secara khusus, penting untuk mengakui bahwa pengembang spesifik cenderung memperkenalkan jenis bug / kesalahan tertentu. Sifat kesalahan dalam beberapa kasus dapat dipengaruhi oleh pengembang yang memperkenalkannya.
Misalnya, karena saya sering terlibat dalam memperbaiki bug kode orang lain di tempat kerja, saya memiliki semacam harapan tentang kesalahan macam apa yang cenderung dilakukan oleh setiap pengembang. Diberikan masalah tertentu, saya tahu bahwa dev A cenderung lupa memperbarui file konfigurasi, sedangkan dev B sering menulis kueri LINQ yang buruk. Berdasarkan pengembang, saya mungkin melihat ke arah file konfigurasi atau LINQ terlebih dahulu.
Demikian pula, saya telah bekerja di beberapa perusahaan sebagai konsultan sekarang, dan saya dapat dengan jelas melihat bahwa jenis bug dapat bias terhadap jenis perusahaan tertentu. Ini bukan aturan yang keras dan cepat yang bisa saya tunjukkan, tapi ada tren yang pasti.
Bisakah mesin mempelajari ini? Dapatkah ia menyadari bahwa dev A lebih cenderung mengacaukan konfigurasi dan dev B lebih cenderung mengacaukan kueri LINQ? Tentu saja bisa. Seperti yang saya katakan sebelumnya, apa pun yang bisa dipelajari manusia, mesin juga bisa.
Namun, bagaimana Anda tahu bahwa Anda telah mengajarkan mesin berbagai kemungkinan? Bagaimana Anda bisa menyediakannya dengan set data kecil (yaitu bukan global) dan mengetahui fakta bahwa ia mewakili seluruh spektrum bug? Atau, apakah Anda akan membuat debugger khusus untuk membantu pengembang / perusahaan tertentu, daripada membuat debugger yang dapat digunakan secara universal?
Meminta debugger yang dipelajari dengan mesin sama seperti meminta Sherlock Holmes yang dipelajari dengan mesin. Bukan tidak mungkin untuk membuatnya, tetapi seringkali alasan utama untuk menjadi debugger / Sherlock bergantung pada penilaian subyektif yang bervariasi dari satu subjek ke subjek lainnya dan menyentuh pada variasi pengetahuan / kemungkinan kelemahan yang sangat luas.
Kurangnya hasil yang benar / salah yang dapat dibuktikan dengan cepat membuat sulit untuk dengan mudah mengajarkan mesin dan memverifikasi bahwa itu membuat kemajuan yang baik.
sumber