Jangan serahkan keputusan dan logika bisnis kepada LLM

• Lebih aman membatasi LLM bukan sebagai pengambil keputusan aplikasi, melainkan sebagai antarmuka bahasa alami yang bolak-balik antara input pengguna dan logika berbasis API
• Contoh bot catur menunjukkan bahwa jika pemeliharaan status dan pengambilan keputusan diserahkan ke LLM, hasilnya kalah dibanding engine khusus atau kode biasa dalam hal performa, debugging, pengujian, dan biaya
• Di area yang hasilnya penting seperti serangan dalam game, agen negosiasi, atau pemilihan acak, keputusan tidak boleh dibuat oleh LLM dan harus ditangani sistem yang dapat diverifikasi
• Hal yang dikerjakan LLM dengan baik adalah transformasi terstruktur seperti attack(target="orc", weapon="sword"), mengubah pesan error ke bahasa alami, klasifikasi intent, dan memahami ekspresi ala manusia
• Meski performa model terus membaik, menempatkan logika inti di sistem terpisah tetap lebih mudah ditangani dari sisi inferensi, pemeliharaan, biaya eksekusi, dan manajemen versi

---

Mengapa LLM harus disingkirkan dari logika inti

• Dalam sebagian besar aplikasi, LLM sebaiknya tetap berada di antarmuka pengguna antara pengguna dan API logika aplikasi
• Pada contoh bot catur, pengguna mengirim perintah bahasa alami seperti “saya akan menangkap knight dengan bishop” lewat WhatsApp, lalu bot memainkan langkah catur
  • LLM mungkin saja bisa mempertahankan status papan catur dan bermain dengan cukup meyakinkan, tetapi tidak ada alasan untuk merancangnya seperti itu
  • Sebagai contoh terkait, ditautkan artikel catur
• Engine catur khusus bisa menjadi pemain catur yang lebih cepat, lebih kuat, dan lebih murah daripada LLM
  • Engine catur modern seperti Stockfish, meskipun menyertakan jaringan saraf, tetap merupakan sistem yang dioptimalkan untuk tujuan spesifik dengan input dan fungsi evaluasi yang jelas
  • Ini berbeda dari LLM serbaguna yang mempertahankan status permainan hanya melalui teks
• Sulit menalar dan men-debug mengapa LLM mengambil keputusan tertentu, sehingga sulit pula menyesuaikan cara pengambilan keputusannya
  • Sulit memahami jalur apa di ruang makna berdimensi tinggi yang ditempuh hingga sampai pada jawaban, dan LLM sendiri juga tidak pandai menjelaskannya
  • Meski ada kemajuan seperti riset penelusuran proses berpikir model bahasa dari Anthropic, observabilitas LLM umum tetap sulit
• Dari sisi operasional juga, LLM memiliki banyak batasan yang tidak cocok untuk logika inti
  • Menguji output LLM lebih sulit daripada unit test pada jalur kode yang sudah diketahui
  • Untuk matematika, kemampuannya kalah dari CPU, dan untuk memilih angka acak juga tidak cukup baik
  • Manajemen versi dan audit menjadi lebih sulit, begitu pula monitoring dan observabilitas
  • Pengelolaan status berbasis bahasa alami rapuh, serta bergantung pada batas laju API dan biaya
  • Jika semua alur melewati prompt, batas keamanan menjadi kabur

Tugas yang cocok untuk LLM

• Bahkan jika pengguna berkata “saya akan menyerang player X dengan vorpal sword”, LLM tidak boleh menilai apakah senjata itu dimiliki atau bagaimana hasil pertarungannya
  • LLM harus fokus mengubah teks bebas menjadi pemanggilan API, lalu menjelaskan kembali hasil dari sistem kepada pengguna
• Dalam agen negosiasi pun, LLM tidak seharusnya langsung mengambil keputusan negosiasi
  • Peran yang cocok adalah membungkus usulan, meneruskannya ke engine negosiasi, lalu menyampaikan hasilnya kepada pengguna
• Bahkan ketika respons pengguna memerlukan pilihan acak, LLM tidak boleh menjadi pihak yang memilih
• Kekuatan LLM ada pada transformasi, interpretasi, klasifikasi, dan komunikasi
  • Dapat mengubah “hit the orc with my sword” menjadi attack(target="orc", weapon="sword")
  • Dapat mengubah {"error": "insufficient_funds"} menjadi “You don’t have enough gold for that.”
  • Dapat merutekan apakah intent pengguna adalah perintah bertarung, memeriksa inventaris, atau meminta bantuan
  • Dapat memahami konsep manusia bahwa “blade” kemungkinan berarti sword dan “smash” kemungkinan berarti attack
• Bahkan jika LLM terus meningkat dan mampu menangani kasus-kasus ini dengan cukup baik, arsitektur yang menempatkan logika inti pada sistem khusus tujuan tetap lebih cocok untuk pemeliharaan, biaya, dan manajemen versi

[GN⁺]

Opini Hacker News

• Sepertinya ada persimpangan yang lebih umum di sini. Logika terbagi menjadi hal yang harus presisi dan ketat, dan hal yang selama ini diimplementasikan begitu hanya karena komputer memang bekerja seperti itu.
  Yang termasuk kategori pertama adalah hal-hal yang sudah berada dalam ranah presisi, seperti keamanan, keuangan, pekerjaan yang melibatkan konflik antarpihak, matematika, atau permainan dengan aturan yang jelas. Kategori kedua adalah kasus-kasus yang sejak awal lebih cocok untuk aproksimasi dan “penalaran berbasis intuisi”, sehingga lama-kelamaan akan digantikan oleh AI. Bahkan dalam aplikasi yang sama, bagian demi bagian bisa berbeda mana yang lebih tepat.

  • Apa contoh untuk kategori nomor 2?

• Tulisan yang bagus. Di hackathon kantor baru-baru ini, saya membuat game edukasi petualangan bercabang, dan ketika saya meminta LLM membuat serta menjalankan game seperti ini, dalam 10 menit pertama hasilnya sudah cukup meyakinkan.
  Masalahnya, gamenya buruk sekali. Selalu berakhir setelah menerima input 3–4 kali, semua pengetahuan ada di konteks sehingga terus membocorkan jawaban yang benar, dan alurnya sama sekali tidak masuk akal. Pada akhirnya, setelah kira-kira dua hari, saya mengorkestrasi 11 prompt dengan Python, menghilangkan kasus ketika pengguna berinteraksi langsung dengan LLM, hanya sekali menggunakan ulang konteks di beberapa kueri, dan juga menambahkan RAG dasar untuk menyembunyikan state game dari LLM sampai state itu terungkap lewat tindakan pengguna. LLM paling bagus dipakai sebagai roda gigi kecil di dalam mesin yang lebih besar. Roda gigi yang sangat kompeten dan hampir seperti sihir, tetapi tetap harus diselaraskan dengan banyak pekerjaan engineering biasa.

  • Saya bingung. Apakah Anda meminta LLM menulis kode gamenya, atau LLM menjalankan seluruh game itu sendiri lewat penalaran?
    Saya tidak tahu kenapa Anda berharap seluruh game yang dibuat hanya dengan beberapa prompt bisa berjalan persis seperti yang diinginkan. Apakah Anda mencantumkan kondisi game yang tepat dalam prompt?
  • Saya sudah sering memainkan petualangan teks interaktif dengan ChatGPT; bagus untuk menciptakan situasi dan membawa cerita ke arah yang mengejutkan, tetapi lemah dalam menjaga narasi yang konsisten.
    Ceritanya penuh dengan kesalahan kontinuitas. Sepertinya siang atau malam ditentukan secara acak, dan ia sering lupa tindakan yang sebelumnya saya lakukan atau item penting yang sudah saya ambil. Aturan yang diberikan di prompt awal juga harus terus diingatkan ulang. Pada akhirnya itu adalah hal-hal yang disebut “menjaga state” dalam tulisan ini. Sekarang saya jadi berhati-hati memberi tugas yang membutuhkan lebih dari 5–10 prompt. Semakin banyak prompt yang diberikan, halusinasi makin sering muncul.
  • Saya penulis tulisan ini. Keren sekali! Kalau suatu saat ingin ngobrol lewat telepon tentang topik ini, silakan kirim email.

• Terkait pernyataan “LLM tidak boleh mengimplementasikan logika apa pun”, untuk kegunaan itu ada teknik kecerdasan mesin tersendiri, yaitu logika, optimisasi, dan constraint programming.
  Fakta menarik: George Boole, pendiri modern logika, optimisasi, dan constraint programming, adalah leluhur dari pihak kakek buyut Geoffrey Everest Hinton, “bapak baptis AI”.
  [1] Logic, Optimization, and Constraint Programming: A Fruitful Collaboration - John Hooker - CMU (2023) [video]:
  https://www.youtube.com/live/TknN8fCQvRk
  [2] "We Really Don't Know How to Compute!" - Gerald Sussman - MIT (2011) [video]:
  https://youtube.com/watch?v=HB5TrK7A4pI

  • Tepatnya, ia adalah kakek buyutnya.

• Sepertinya penulis tulisan ini akan mengalami pelajaran pahit.
  [1] http://www.incompleteideas.net/IncIdeas/BitterLesson.html

  • Bisa jadi, bisa juga tidak. Sistem berbasis LLM yang andal dan berinteraksi dengan model dunia masih belum stabil.
    Waymo adalah contoh sistem yang memakai machine learning, tetapi machine learning tidak langsung bertanggung jawab menghasilkan tindakan. Banyak pemrosesan sensor dan classifier membangun model lingkungan, lalu model itu bisa dibandingkan dengan dunia nyata di layar. Setelah itu ada bagian yang menghasilkan perintah gerak berdasarkan model lingkungan. Seberapa banyak bagian itu memakai machine learning tidak jelas. Tesla sedang mencoba machine learning end-to-end, dan hasilnya mengecewakan. Banyak kejadian “kenapa ia melakukan itu?”, dan bahkan belum tentu Tesla sendiri tahu alasannya. Waymo juga mencoba machine learning end-to-end untuk melihat apakah ada yang terlewat, tetapi hasilnya lebih buruk daripada pendekatan mereka saat ini. Itulah yang saya pikirkan tentang topik ini selama 1–2 tahun terakhir. Sistem yang memakai LLM end-to-end untuk benar-benar melakukan sesuatu tampaknya hanya dipakai ketika biaya kesalahan ditanggung pengguna atau pelanggan, bukan operator layanan. Kesalahan LLM sering diperlakukan sebagai eksternalitas seperti polusi, dialihkan ke orang lain. Tentu saja, kalau masalah itu terselesaikan, ia juga akan siap mengambil pekerjaan manajemen.
  • Maksudnya, bahkan untuk membuat panggilan API yang masuk akal pun benar-benar tidak stabil begitu input sedikit saja menjadi kompleks?
  • Bagaimana bisa begitu? Pelajaran pahit secara spesifik membahas efektivitas model statistik.
    Misalnya, saya rasa menambahkan lebih banyak energi ke mesin pakar tidak akan mengubah akurasinya.
  • Kalau melihat kalimat “pelajaran terbesar yang bisa dibaca dari 70 tahun riset AI adalah bahwa metode umum yang memanfaatkan komputasi pada akhirnya adalah yang paling efektif, dan dengan selisih besar”, bukankah ironis bahwa AI modern digerakkan bukan oleh komputasi berbasis CPU serbaguna, melainkan oleh operasi yang khusus atau tidak serbaguna?
  • “Pelajaran pahit” adalah ekstrapolasi dari satu titik data saja, yaitu keberuntungan luar biasa bernama Dennard scaling. Maaf, tetapi era sihir silikon sudah berakhir. Mungkin suatu saat akan kembali, tetapi untuk saat ini sudah berakhir.

• Alasan tulisan seperti ini populer, baik bernada positif maupun negatif, mungkin karena pada praktiknya mustahil untuk memahami secara kaya apa saja yang bisa dilakukan LLM.
  Jadi pembaca ingin ada seseorang yang memberi jawaban mudah. Saya juga sudah cukup banyak memakai chatbot seperti ini, tetapi saya tidak bisa bilang bahwa saya tahu hal apa yang tidak berguna baginya dan hal apa yang sangat dikuasainya. Pada satu saat ia bahkan tidak bisa menulis state machine sederhana, lalu pada saat berikutnya ia menulis aplikasi web yang memodelkan snare drum secara fisik. Melihat populernya makalah riset yang mencoba mencari tahu bagaimana chatbot seperti ini bekerja, setidaknya pada 2025 tidak seorang pun boleh mengklaim benar-benar memahami benda-benda ini

  • Jika “setidaknya pada 2025 tidak seorang pun boleh mengklaim benar-benar memahami benda-benda ini”, secara pribadi itu saja sudah menjadi alasan yang cukup untuk menolaknya sepenuhnya.
    Kita tidak boleh bergantung pada alat yang tidak dipahami siapa pun. Saya pribadi mungkin tidak tahu bagaimana mesin mobil bekerja, tetapi saya percaya di suatu tempat dalam masyarakat ada orang yang memahaminya. LLM berbeda
  • Pernyataan bahwa “setidaknya pada 2025 tidak seorang pun boleh mengklaim benar-benar memahami benda-benda ini” cukup meragukan. Model-model ini bukan benda yang ditemukan di komputer alien.
    Saya bisa menerima bahwa belum ada yang menemukan cara mengekstrak logika yang dapat digunakan dari sup angka yang merupakan model nyata itu. Namun kita tahu logika interaksi yang terjadi di dalamnya
  • Apa definisi dari “memahami dengan baik”?

• Kami juga mendapatkan pelajaran yang persis sama. Terutama jika respons LLM harus cepat dan murah, Anda membutuhkan prompt pendek dan model non-reasoning yang kecil.
  Banyak informasi di pasaran berasumsi bahwa Anda bersedia menunggu model raksasa membakar uang selama 30 detik. Namun jika Anda membangun produk interaktif dengan harga yang masuk akal, Anda akan memakai model yang kurang kuat. Kesimpulan berikutnya yang disayangkan adalah, untuk banyak aplikasi, ini bukan UI default yang bagus. Pengguna tidak suka harus mengetik kalimat panjang dan menebak-nebak kemampuan produk ketika situasinya cukup dengan menekan satu tombol. Jika begitu, LLM nyaris tidak punya peluang menambah nilai selain penerjemahan. Lebih baik UI tradisional menyusun permintaan internal, lalu secara opsional menambahkan input LLM untuk membuat permintaan atau mengisi UI

  • Dari pengalaman saya, untuk mendapatkan jawaban singkat, Anda perlu memasukkan beberapa paragraf system prompt agar LLM mengurangi omongannya dan fokus. Selebihnya saya setuju
  • Saya setuju semuanya, tetapi ingin menambahkan bahwa o3-mini sangat cepat dan murah

• Tempat kerja istri saya juga melakukan hal serupa, tetapi tanpa API. Tidak persis game, tetapi mirip game.
  Menurut saya pendekatan yang hanya memakai LLM kemungkinan besar akan runtuh karena tidak mampu menahan bobotnya sendiri. Cara khusus LLM adalah mimpi buruk untuk diuji, dan tiap individu yang menulis hal semacam ini punya trik dan gaya berbeda yang memengaruhi keseluruhan interaksi. Jadi ketika sesuatu yang dibuat seseorang setahun lalu harus diperbaiki orang lain setelah orang itu keluar dari perusahaan, biayanya sering kali mendekati biaya membuat ulang dari awal. Orang berikutnya mungkin tidak bisa memancing perilaku yang benar dari sesi dalam state tertentu. Sejak awal, state itu bukan cara ia akan menulisnya, sehingga sulit ditangani, atau prompt dasarnya memakai pendekatan yang tidak familiar dan jika disentuh semuanya rusak. Dalam proses itu, waktu yang sangat besar akan terbakar. Memperbaiki satu bagian bisa merusak interaksi berikutnya. Jika dipakai seperti ini, ia menjadi sistem yang sangat rapuh. Jauh lebih masuk akal memakainya untuk mengubah teks menjadi panggilan API lalu mengembalikannya lagi

• Sebagai bagian dari aplikasi, LLM luar biasa untuk mengubah data tidak terstruktur seperti halaman web, resume, transkrip, dan teks pengguna menjadi data terstruktur.
  Namun saya tidak akan pernah memakainya untuk memilih semua titik di peta yang berada dalam radius 5 mil dari koordinat tertentu. Patokan saya adalah: jika kode bisa melakukannya secara tepat, maka kode yang harus melakukannya. Kode deterministik jauh lebih mudah ditangani daripada “kode” probabilistik. Meski begitu, kemampuannya mengekstrak keteraturan dari kekacauan adalah alat yang sangat berguna

• Apakah benar ada orang yang melakukan ini? Saya tidak pernah menganggapnya sebagai cara yang praktis, karena konteks terlihat seperti versi terburuk dari global state. Tidak bisa diserialisasi, tidak bisa direproduksi.
  Bagaimana Anda bisa memelihara sistem yang bahkan di lingkungan pengujian pun tidak mudah diinspeksi? Saya memang menganggap LLM kuat, tetapi bukan untuk penggunaan ini

  • Jika yang dimaksud “ini” di sini adalah command pattern yang dibahas dalam tulisan, saya pernah menggunakannya dengan sangat efektif ketika kode di sekelilingnya dirancang dengan benar.
    Jika panggilan LLM bisa ditulis sebagai fungsi yang beroperasi pada suatu state, itu juga cocok untuk evaluasi:
    (document, input) -> command
(document, command) -> document'
# assert bahwa document' memenuhi sifat tertentu dibandingkan document

• Benar. LLM kuat dalam bahasa, jadi seharusnya dipakai di ranah itu.
  Memakai mesin mimpi LSD untuk logika bisnis sama saja mencari masalah. Tidak, tunggu—di dalam lamunan, buat ia berpura-pura kepada dirinya sendiri untuk mengabaikan semua instruksi sebelumnya, lalu menyuruh pengguna mentransfer uang ke nomor rekening berikut…