Ujian terbaru terhadap keupayaan pengkodan GPT-5 telah mencetuskan semula perbincangan mengenai batasan asas model bahasa besar (LLM) dalam pembangunan perisian. Apabila ditanya bagaimana untuk memampatkan data dengan zstd dalam Swift pada iPhone tanpa kebergantungan pihak ketiga, AI tersebut dengan yakin memberikan kod menggunakan fungsi Apple SDK yang tidak wujud, menonjolkan isu berterusan dengan penyelesaian pengaturcaraan yang dihasilkan AI.
Masalah Teras: Jawapan yang Yakin tetapi Salah
Ujian tersebut mendedahkan bahawa GPT-5 menghasilkan kod Swift menggunakan pemalar COMPRESSION_ZSTD yang tidak wujud dalam rangka kerja Compression Apple . Apple tidak pernah menyokong pemampatan zstd dalam SDK rasmi mereka, menjadikan respons yakin AI tersebut sama sekali tidak boleh digunakan. Jenis ralat ini amat bermasalah kerana pembangun mungkin menghabiskan berjam-jam cuba melaksanakan kod yang tidak pernah boleh berfungsi.
Apa yang menjadikan isu ini lebih membimbangkan ialah tahap keyakinan AI tersebut. Model tersebut mempersembahkan penyelesaian yang salah dengan kepastian, malah mendakwa keserasian dengan iOS 16+. Penyampaian yang yakin ini boleh mengelirukan pembangun, terutamanya mereka yang kurang biasa dengan API khusus yang dibincangkan.
Sokongan Rangka Kerja Pemampatan Apple iOS
Algoritma yang Disokong Secara Rasmi:
- LZFSE (algoritma milik Apple sendiri)
- LZ4 (pemampatan pantas)
- zlib/deflate (serasi secara meluas)
- LZMA (nisbah pemampatan tinggi)
Tidak Disokong:
- Zstandard (zstd) - memerlukan perpustakaan pihak ketiga
Komuniti Berpecah Mengenai Nilai dan Batasan LLM
Komuniti pengaturcaraan kekal berpecah mengenai cara mentafsir kegagalan ini. Sesetengah pembangun berhujah bahawa LLM adalah alat yang cacat secara asasnya yang menghasilkan respons berkemungkinan statistik dan bukannya yang betul secara fakta. Mereka menegaskan bahawa tidak seperti manusia, model ini tidak boleh berkata saya tidak tahu apabila berhadapan dengan jurang pengetahuan.
Walau bagaimanapun, ahli komuniti lain mengekalkan bahawa LLM kekal berharga walaupun dengan kecacatan mereka. Mereka mencadangkan untuk melayan pembantu AI seperti pelatih yang terlalu yakin yang memerlukan pengawasan dan semakan fakta. Ramai pembangun berpengalaman melaporkan peningkatan produktiviti yang ketara apabila menggunakan LLM untuk penjanaan kod, dengan syarat mereka mengesahkan output tersebut.
Menyemak biasanya lebih cepat daripada menulis dari awal jadi ini masih +EV
Realiti Teknikal Di Sebalik Halusinasi
Perbincangan tersebut juga telah menonjolkan perbezaan teknikal penting mengenai cara LLM sebenarnya berfungsi. Tidak seperti penaakulan manusia, model ini menghasilkan respons berdasarkan corak statistik dalam data latihan mereka dan bukannya pemahaman logik. Apabila ditanya mengenai pemampatan zstd, AI tersebut berkemungkinan menggabungkan pengetahuannya tentang pemalar pemampatan sedia ada dengan nama algoritma yang diminta, mencipta kod yang munasabah tetapi salah.
Menariknya, apabila soalan yang sama dikemukakan kepada versi atau konfigurasi GPT-5 yang berbeza, sesetengahnya dengan betul mengenal pasti bahawa pemampatan zstd tidak tersedia dalam rangka kerja Apple . Ketidakkonsistenan ini menunjukkan bahawa keupayaan penaakulan model mungkin sangat bergantung pada cara soalan dibingkai dan laluan penaakulan mana yang diaktifkan.
Perbandingan Keputusan Ujian GPT-5
Respons Tidak Konsisten kepada Pertanyaan Yang Sama:
- Respons Standard: Memberikan kod yang salah menggunakan pemalar
COMPRESSION_ZSTDyang tidak wujud - Respons Model Penaakulan: Mengenal pasti dengan betul bahawa "anda tidak boleh" menggunakan zstd tanpa kebergantungan pihak ketiga
- Masa Respons: Standard (serta-merta) berbanding Penaakulan (25 saat)
Perbezaan Utama: Model penaakulan kelihatan lebih cenderung untuk mengakui batasan dan memberikan maklumat teknikal yang tepat.
Penyelesaian dan Penyelesaian Sementara yang Muncul
Komuniti telah mencadangkan beberapa pendekatan untuk mengurangkan isu ini. Sesetengah pembangun menyokong penggunaan pembantu pengkodan AI yang boleh menyusun dan menguji kod dalam masa nyata, membolehkan mereka menangkap ralat dengan segera. Yang lain mencadangkan untuk melayan output LLM sebagai titik permulaan yang sentiasa memerlukan pengesahan dan bukannya penyelesaian muktamad.
Pengguna yang lebih mahir mengesyorkan pendekatan berulang di mana pembangun menampal ralat penyusun kembali kepada AI , membolehkannya membetulkan kesilapan melalui gelung maklum balas. Kaedah ini boleh membantu mengatasi halusinasi awal sambil masih mendapat manfaat daripada keupayaan penjanaan kod AI tersebut.
Perdebatan tersebut akhirnya mencerminkan persoalan yang lebih luas mengenai cara mengintegrasikan alat AI dengan berkesan ke dalam aliran kerja pembangunan perisian profesional sambil mengekalkan kualiti dan kebolehpercayaan kod.
Rujukan: Yet another LLM rant