Large Language Model telah mengubah pengembangan perangkat lunak, namun mereka kesulitan dengan tantangan mendasar yang dapat ditangani programmer manusia secara alami: menulis kode yang perlu dibangun dari kanan ke kiri atau tidak berurutan. Keterbatasan ini menjadi sangat jelas dengan bahasa pemrograman khusus seperti q/kdb+ dan APL, yang menggunakan evaluasi kanan-ke-kiri, tetapi masalah ini meluas jauh melampaui bahasa-bahasa niche tersebut.
Masalah inti berasal dari cara LLM saat ini menghasilkan teks. Mereka memproduksi token secara berurutan dari kiri ke kanan, sehingga sulit untuk menulis ekspresi di mana hasil akhir bergantung pada operasi yang seharusnya ditulis di bagian akhir terlebih dahulu. Ini menciptakan masalah tidak hanya dengan bahasa kanan-ke-kiri, tetapi juga ketika melakukan refactoring panggilan fungsi bersarang atau bekerja dengan struktur kode apa pun yang mendapat manfaat dari komposisi non-linear.
Bahasa Pemrograman Right-to-Left:
- q/kdb+: Bahasa pemrosesan data keuangan dengan evaluasi dari kanan ke kiri
- APL: Bahasa pemrograman array yang diciptakan oleh pemenang Turing Award Ken Iverson
- K: Penerus APL dengan prinsip evaluasi yang serupa
- Gaya Evaluasi: Right-to-Left tanpa Operator Precedence (RL/NOP)
Masalah Generasi Berurutan
Model berbasis transformer saat ini unggul dalam memprediksi token berikutnya berdasarkan konteks sebelumnya, tetapi pendekatan ini gagal ketika alur logis konstruksi kode tidak sesuai dengan pola penulisan kiri-ke-kanan. Developer manusia sering memulai dengan hasil yang diinginkan dan bekerja mundur, atau melompat ke bagian yang berbeda dari suatu ekspresi saat mereka membangunnya. LLM tidak dapat mereplikasi perilaku coding alami ini.
Komunitas telah mengidentifikasi ini sebagai keterbatasan arsitektur yang lebih luas. Ketika developer menulis ekspresi kompleks, mereka sering perlu mempertimbangkan hasil akhir terlebih dahulu, kemudian mengisi langkah-langkah perantara. Pendekatan top-down untuk konstruksi kode ini adalah sesuatu yang tidak dapat dilakukan model saat ini secara efektif.
Keterbatasan LLM Saat Ini dalam Pembuatan Kode:
- Generasi token berurutan mencegah konstruksi kode dari kanan ke kiri
- Kesulitan dengan bahasa yang menggunakan evaluasi kanan ke kiri ( q/kdb+ , APL , K )
- Kesulitan dengan komposisi kode non-linear dan refactoring
- Masalah dengan manajemen state implisit yang kompleks ( Ruby on Rails )
- Kecenderungan menambahkan import yang tidak perlu sebagai perilaku hedging
Mengapa Data Training Bukan Satu-satunya Jawaban
Meskipun beberapa orang menyarankan bahwa lebih banyak data training untuk bahasa khusus dapat menyelesaikan masalah, isu ini lebih dalam dari sekadar eksposur sederhana. Sifat berurutan dari arsitektur model saat ini berarti mereka kesulitan dengan paradigma pemrograman apa pun yang memerlukan pemikiran non-linear, terlepas dari seberapa banyak data training yang tersedia.
Bahkan bahasa populer menunjukkan kelemahan ini. Aplikasi Ruby on Rails, dengan manajemen state implisit yang kompleks, sering membingungkan LLM meskipun memiliki data training yang melimpah. Model juga cenderung menambahkan import yang tidak perlu dalam Python, melindungi diri dengan menyertakan modul yang mungkin mereka perlukan nanti dalam proses generasi.
Model Diffusion sebagai Solusi Potensial
Solusi paling menjanjikan yang sedang dibahas melibatkan model bahasa berbasis diffusion. Tidak seperti generator berurutan tradisional, model diffusion dimulai dengan teks acak dan secara bertahap memperbaikinya menjadi output yang koheren. Pendekatan ini secara teoritis dapat memungkinkan model untuk bekerja pada bagian kode yang berbeda secara bersamaan, menyelesaikan dependensi dalam urutan apa pun yang paling masuk akal.
Beberapa model coding berbasis diffusion sudah mulai bermunculan, meskipun mereka belum secara khusus dilatih untuk menangani evaluasi kanan-ke-kiri atau konstruksi kode non-linear. Arsitektur secara teoritis mendukung fokus pada wilayah kode yang berbeda pada waktu yang berbeda, berpotensi menyelesaikan masalah penulisan mundur.
Pendekatan Alternatif dan Solusi Sementara
Beberapa developer sedang mengeksplorasi solusi perantara, seperti membuat sintaks mirip Python yang dikompilasi ke bahasa khusus. Pendekatan ini memanfaatkan kekuatan LLM dengan sintaks yang familiar sambil menangani urutan evaluasi yang kompleks melalui terjemahan otomatis.
Terkadang saya mulai dengan data dan bekerja mundur melalui fungsi-fungsi luar, membuka nesting saat saya melakukannya. Terkadang saya mulai dengan return akhir dan bekerja mundur ke input. Saya perhatikan terkadang LLM seharusnya bekerja dengan cara ini, tetapi tidak bisa.
Solusi lain yang diusulkan termasuk melatih model untuk menghasilkan Abstract Syntax Tree secara langsung, atau menggunakan pendekatan training bidirectional. Namun, metode ini menghadapi tantangan praktis mengingat sifat berbasis teks dari sebagian besar data training pemrograman.
Solusi yang Diusulkan:
- Model Difusi: Dimulai dengan teks acak dan diperbaiki secara bertahap, memungkinkan generasi non-sekuensial
- Pendekatan Transpilasi: Sintaks mirip Python yang dikompilasi ke bahasa khusus
- Generasi AST: Generasi langsung Abstract Syntax Trees alih-alih teks
- Pelatihan Bidireksional: Melatih model baik maju maupun mundur pada kode
- Prompting yang Ditingkatkan: Menggunakan langkah-langkah penalaran eksplisit dan komentar yang verbose
Melihat ke Depan
Keterbatasan ini menyoroti kesenjangan mendasar antara cara manusia berpikir tentang konstruksi kode dan cara model AI saat ini beroperasi. Meskipun solusi sementara ada untuk kasus penggunaan tertentu, mengatasi masalah inti mungkin memerlukan arsitektur model baru yang dapat menangani generasi non-berurutan secara lebih alami.
Seiring model diffusion terus berkembang dan berpotensi menggabungkan dukungan yang lebih baik untuk output terstruktur seperti kode, kita mungkin melihat peningkatan signifikan dalam kemampuan LLM untuk menangani tugas pemrograman kompleks yang memerlukan pemikiran non-linear. Sampai saat itu, developer yang bekerja dengan bahasa khusus atau tugas refactoring kompleks perlu mengandalkan strategi prompting yang hati-hati dan alat terjemahan perantara.
Referensi: Why LLMs Can't Write q/kdb+: Writing code Right-to-Left