Mengapa LLM Dalam Pengembangan Perangkat Lunak Mungkin Jalan Buntu

Sementara judulnya Apakah AI saat ini menunjukkan jalan buntu? jelas dibuat untuk mendorong perdebatan, ada kasus dalam artikel akademis ini yang khususnya berkaitan dengan pengembang perangkat lunak:

“Sistem AI saat ini tidak memiliki struktur internal yang berhubungan dengan fungsinya. Bahan-bahan tersebut tidak dapat dikembangkan, atau digunakan kembali, sebagai komponen. Tidak ada pemisahan kepentingan atau pembangunan sedikit demi sedikit.”

Postingan saya hari ini hanya tentang penggunaan Model Bahasa Besar (LLM) sebagai bagian dari solusi produk Anda, bukan menggunakan AI sebagai alat selama pengembangan (misalnya, alat pengkodean AI seperti Cursor dan Zed AI). Menggunakan LLM untuk melakukan Aktivitas Siklus Hidup Pengembangan Perangkat Lunak (SDLA) tertentu memiliki masalah, namun cara kami membuat sesuatu biasanya berbeda dari apa yang kami jual kepada pelanggan. Jadi, pada grafik di bawah, kita melihat dua bagian teratas:

Masalahnya saat ini dengan LLM adalah bahwa mereka disediakan seperti mobil. Anda membayar semuanya, dan tidak ada harapan untuk melihatnya sebagai kumpulan karya yang dapat disusun. Kurangnya penguraian pada mobil tidak menjadi masalah karena mengemudi adalah aktivitas yang sangat dikontrol. Sekalipun Anda dapat membuat mobil dari komponen seperti Lego, hal itu tidak akan ditoleransi di jalan umum.

Ini mungkin yang diinginkan oleh perusahaan teknologi besar — ​​​​mereka ingin menjual produk atau layanan dalam jumlah besar kepada Anda, bukan sekumpulan produk yang dapat dibuat lebih mudah oleh orang lain. Dengan cara ini, hanya sekelompok kecil produsen besar yang dapat bertahan dalam industri ini. Menjaga LLM tetap misterius membuat nilainya tetap tinggi.

LLM bertentangan dengan konsep umum komputasi, di mana tugas dapat dipecah.

Namun hal ini bertentangan dengan konsep umum komputasi, yang mengharuskan tugas-tugas dipecah. Komponen perangkat lunak yang berfungsi, baik dibangun secara internal atau tidak, terdiri dari kode yang dapat diuji unit. Mereka harus bekerja sama dengan komponen lain secara andal.

Bahkan jika suatu produk menggunakan database Oracle, kita semua memahami bahwa persistensi ada pada tingkat desain nosional. Pada titik tertentu, keputusan teknis dibuat mengenai jenis penyimpanan mana yang akan digunakan. Pada saat itu, sistem pengujian mungkin sudah ada. Sementara itu, inovasi dalam database terus berlanjut, namun tidak pernah terpikir oleh pelanggan bahwa penyedia penyimpanan mengendalikan perangkat lunak tersebut.

Di kalangan akademis, masalah kurangnya kemampuan dekomposisi biasanya dibarengi dengan kurangnya kemampuan menjelaskan. Kami dapat merangkum alasan bisnis terkait lainnya yang mendukung LLM dalam perangkat lunak yang dikirimkan.

Kami tidak dapat memisahkan pengoperasian LLM dari data pelatihannya.

Saat ini, kami tidak dapat memisahkan pengoperasian LLM dari data pelatihannya. Kita tahu bahwa LLM adalah sebuah pelatihan, namun prosesnya biasanya tidak terbuka dan hasilnya tetap diharapkan untuk diterima apa adanya. Cara mengharapkan komponen untuk “direndam” seperti ini baik untuk rebusan tetapi tidak benar-benar berlaku untuk pengembangan komponen.

Keamanan dan privasi akhirnya menjadi perhatian karena tidak ada benang baja atau cara yang dapat dibuktikan untuk menghentikan LLM membedakan bagian mana yang harus disembunyikan. Kami tidak dapat mencegat jaringan saraf dengan cara apa pun dari luar dan menjelaskan bahwa informasi tertentu bersifat pribadi dan tidak boleh diungkapkan.

Kepemilikan legal masih bermasalah. Kita dapat membuktikan bahwa hasil operasi yang dilakukan dengan perhitungan dingin dapat diulang, dan akan keluar jawaban yang sama setiap saat dengan masukan yang sama. Karena LLM membawa bagasi pelatihan yang tidak dapat mereka lepaskan, kami tidak dapat membuktikan bahwa mereka tidak mencuri karya seni sebelumnya. Dan mereka mungkin punya.

Perusahaan-perusahaan yang berupaya mengendalikan jejak karbon mereka bergerak ke arah yang berlawanan dengan para pencipta LLM, yang membutuhkan sejumlah besar daya komputasi untuk menghasilkan peningkatan yang semakin berkurang.

Sekarang, sama seperti artikel ini bukan tentang menggunakan LLM untuk membantu pengembangan, ini bukan tentang hanya memberikan pengguna akhir akses mentah ke utilitas LLM dan hanya mengangkat bahu dengan sinis dan berkata “ini dia”. Editor teks yang saya gunakan memiliki beberapa bentuk AI yang ditambahkan, dan tidak ada jaminan mengenai fungsinya. Kita semua tahu bahwa ini umumnya merupakan latihan kotak centang — fitur yang harus muncul namun tidak melekat pada penawaran.

Saya rasa tidak ada banyak masa depan bagi LLM untuk diperkenalkan sebagai layanan dalam produk, kecuali sebagai produk itu sendiri.

Untuk alasan yang telah saya kemukakan, menurut saya tidak ada banyak masa depan bagi LLM untuk diperkenalkan sebagai layanan dalam produk, kecuali sebagai produk itu sendiri. Namun hal ini pun merupakan jebakan serius bagi bisnis apa pun. Saat Eric Yuan, pendiri Zoom, menyampaikan idenya Klon AI menghadiri pertemuan di Zoom dia memang pantas diejek karena mengharapkan kemampuan ini muncul entah bagaimana secara “turun”. Dengan mengalihdayakan inovasi besar ke vendor LLM, dia hanya menyerahkan kendali peta jalannya ke perusahaan lain.

Bagaimana Seharusnya Pengembang Perangkat Lunak Menanggapi

Semuanya baik-baik saja, tetapi bagaimana seharusnya pengembangan perangkat lunak menanggapi hal ini saat ini? Kita semua memahami bahwa suatu komponen harus mempunyai pekerjaan, atau peran yang disepakati, sehingga dapat diganti dan dapat diuji dengan komponen sejenis lainnya. Kami juga memahami bahwa jika bersifat eksternal, maka seharusnya dibangun dengan standar komputasi yang sama — dan kami dapat membangunnya kembali menggunakan standar ini.

Kita tidak boleh mencoba mengubah aturan main untuk perhatian jangka pendek. Intinya adalah merancang proses yang memberikan fungsionalitas yang kami perlukan untuk usaha kami dan kemudian mengembangkan platform yang memungkinkan pengembang membangunnya secara berkelanjutan.

Sebagai pengembang, kita harus tetap membuka pintu bagi Kecerdasan Buatan yang benar-benar dapat dijelaskan dengan komponen yang dapat diuji.

Sebagai pengembang, kita harus tetap membuka pintu bagi Kecerdasan Buatan yang benar-benar dapat dijelaskan dengan komponen yang dapat diuji. Jika pelatihan diperlukan, pelatihan tersebut harus dipantau, dapat dilaporkan, dapat diulang, dapat dijelaskan, dan dapat dibatalkan. Jika kami menemukan bahwa LLM meyakini sesuatu itu benar padahal tidak, maka hal ini harus segera diperbaiki dalam serangkaian langkah yang ditentukan. Jika uraian ini tidak masuk akal, maka komputasi dengan LLM juga tidak ada saat ini. Namun secara teori, saya tidak melihat alasan mengapa hal ini tidak dapat diubah di masa depan.

Ketakutan saya, perbedaan itu bisa seperti membandingkan metode ilmiah dengan keimanan terhadap peninggalan suci. Kita tahu kita bisa melakukan serangkaian eksperimen yang tidak bisa dilakukan (jika saya memotong relik ini, apakah semua bagiannya sama-sama disucikan?), tapi kita juga tahu bahwa kita tidak boleh berharap kedua wilayah tersebut akan berdamai.

David pernah menjadi pengembang perangkat lunak profesional yang berbasis di London bersama Oracle Corp. dan British Telecom, dan seorang konsultan yang membantu tim bekerja dengan cara yang lebih tangkas. Dia menulis buku tentang desain UI dan telah menulis artikel teknis sejak saat itu….

Baca lebih lanjut dari David Eastman