Model Bahasa Besar telah mengubah pembangunan perisian, tetapi mereka bergelut dengan cabaran asas yang dikendalikan secara semula jadi oleh pengaturcara manusia: menulis kod yang perlu dibina dari kanan ke kiri atau tidak mengikut urutan. Batasan ini menjadi sangat ketara dengan bahasa pengaturcaraan khusus seperti q/kdb+ dan APL, yang menggunakan penilaian kanan ke kiri, tetapi masalah ini melangkaui bahasa-bahasa niche tersebut.
Isu teras berpunca daripada cara LLM semasa menjana teks. Mereka menghasilkan token secara berurutan dari kiri ke kanan, menjadikannya sukar untuk menulis ungkapan di mana hasil akhir bergantung kepada operasi yang sepatutnya ditulis di hujung terlebih dahulu. Ini mewujudkan masalah bukan sahaja dengan bahasa kanan ke kiri, tetapi juga semasa memfaktor semula panggilan fungsi bersarang atau bekerja dengan mana-mana struktur kod yang mendapat manfaat daripada komposisi bukan linear.
Bahasa Pengaturcaraan Kanan-ke-Kiri:
- q/kdb+: Bahasa pemprosesan data kewangan dengan penilaian kanan-ke-kiri
- APL: Bahasa pengaturcaraan tatasusunan yang dicipta oleh pemenang Anugerah Turing Ken Iverson
- K: Pengganti kepada APL dengan prinsip penilaian yang serupa
- Gaya Penilaian: Kanan-ke-Kiri tanpa Keutamaan Operator (RL/NOP)
Masalah Penjanaan Berurutan
Model berasaskan transformer semasa cemerlang dalam meramalkan token seterusnya berdasarkan konteks sebelumnya, tetapi pendekatan ini rosak apabila aliran logik pembinaan kod tidak sepadan dengan corak penulisan kiri ke kanan. Pembangun manusia sering bermula dengan hasil yang diingini dan bekerja ke belakang, atau melompat ke bahagian berbeza ungkapan semasa mereka membinanya. LLM tidak dapat meniru tingkah laku pengkodan semula jadi ini.
Komuniti telah mengenal pasti ini sebagai batasan seni bina yang lebih luas. Apabila pembangun menulis ungkapan kompleks, mereka kerap perlu mempertimbangkan hasil akhir terlebih dahulu, kemudian mengisi langkah-langkah perantaraan. Pendekatan atas ke bawah untuk pembinaan kod ini adalah sesuatu yang model semasa tidak dapat lakukan dengan berkesan.
Batasan Semasa LLM dengan Penjanaan Kod:
- Penjanaan token berurutan menghalang pembinaan kod dari kanan ke kiri
- Bergelut dengan bahasa yang menggunakan penilaian kanan ke kiri ( q/kdb+ , APL , K )
- Kesukaran dengan komposisi kod bukan linear dan pemfaktoran semula
- Masalah dengan pengurusan keadaan tersirat yang kompleks ( Ruby on Rails )
- Kecenderungan untuk menambah import yang tidak perlu sebagai tingkah laku lindung nilai
Mengapa Data Latihan Bukan Satu-satunya Jawapan
Walaupun ada yang mencadangkan bahawa lebih banyak data latihan untuk bahasa khusus boleh menyelesaikan masalah, isu ini lebih mendalam daripada pendedahan mudah. Sifat berurutan seni bina model semasa bermakna mereka bergelut dengan mana-mana paradigma pengaturcaraan yang memerlukan pemikiran bukan linear, tanpa mengira berapa banyak data latihan yang tersedia.
Malah bahasa popular menunjukkan kelemahan ini. Aplikasi Ruby on Rails, dengan pengurusan keadaan tersirat yang kompleks, sering mengelirukan LLM walaupun mempunyai data latihan yang banyak. Model-model juga cenderung menambah import yang tidak perlu dalam Python, melindung nilai taruhan mereka dengan memasukkan modul yang mungkin mereka perlukan kemudian dalam proses penjanaan.
Model Difusi sebagai Penyelesaian Berpotensi
Penyelesaian paling menjanjikan yang sedang dibincangkan melibatkan model bahasa berasaskan difusi. Tidak seperti penjana berurutan tradisional, model difusi bermula dengan teks rawak dan secara beransur-ansur memperhaluskannya menjadi output yang koheren. Pendekatan ini secara teorinya boleh membenarkan model bekerja pada bahagian kod yang berbeza secara serentak, menyelesaikan kebergantungan dalam apa jua urutan yang paling masuk akal.
Beberapa model pengkodan berasaskan difusi sudah muncul, walaupun mereka belum dilatih secara khusus untuk mengendalikan penilaian kanan ke kiri atau pembinaan kod bukan linear. Seni bina secara teorinya menyokong tumpuan pada kawasan kod yang berbeza pada masa yang berbeza, berpotensi menyelesaikan masalah penulisan terbalik.
Pendekatan Alternatif dan Penyelesaian Sementara
Sesetengah pembangun sedang meneroka penyelesaian perantaraan, seperti mencipta sintaks seperti Python yang dikompil kepada bahasa khusus. Pendekatan ini memanfaatkan kekuatan LLM dengan sintaks yang biasa sambil mengendalikan urutan penilaian yang kompleks melalui terjemahan automatik.
Kadang-kadang saya bermula dengan data dan bekerja kembali melalui fungsi luar, membuka sarang semasa saya pergi. Kadang-kadang saya bermula dengan pulangan akhir dan bekerja kembali ke input. Saya perasan kadang-kadang LLM sepatutnya bekerja dengan cara ini, tetapi tidak boleh.
Penyelesaian lain yang dicadangkan termasuk melatih model untuk menjana Pokok Sintaks Abstrak secara langsung, atau menggunakan pendekatan latihan dua hala. Walau bagaimanapun, kaedah-kaedah ini menghadapi cabaran praktikal memandangkan sifat berasaskan teks kebanyakan data latihan pengaturcaraan.
Penyelesaian yang Dicadangkan:
- Model Difusi: Bermula dengan teks rawak dan diperhalusi secara beransur-ansur, membenarkan penjanaan bukan berurutan
- Pendekatan Transpilasi: Sintaks seperti Python yang dikompil kepada bahasa khusus
- Penjanaan AST: Penjanaan langsung Pokok Sintaks Abstrak dan bukannya teks
- Latihan Dua Arah: Melatih model ke hadapan dan ke belakang pada kod
- Pemproman Dipertingkat: Menggunakan langkah penaakulan eksplisit dan komen yang terperinci
Memandang ke Hadapan
Batasan ini menyerlahkan jurang asas antara cara manusia berfikir tentang pembinaan kod dan cara model AI semasa beroperasi. Walaupun penyelesaian sementara wujud untuk kes penggunaan tertentu, menangani isu teras mungkin memerlukan seni bina model baharu yang boleh mengendalikan penjanaan bukan berurutan dengan lebih semula jadi.
Memandangkan model difusi terus berkembang dan berpotensi menggabungkan sokongan yang lebih baik untuk output berstruktur seperti kod, kita mungkin melihat peningkatan ketara dalam keupayaan LLM untuk mengendalikan tugas pengaturcaraan kompleks yang memerlukan pemikiran bukan linear. Sehingga itu, pembangun yang bekerja dengan bahasa khusus atau tugas pemfaktoran semula yang kompleks perlu bergantung pada strategi prompting yang teliti dan alat terjemahan perantaraan.
Rujukan: Why LLMs Can't Write q/kdb+: Writing code Right-to-Left