Jangan biarkan LLM mengambil keputusan atau menjalankan logika bisnis

Argumen inti: keluar dari LLM secepat mungkin dan jangan terlalu lama berada di dalamnya

• Jangan serahkan pengambilan keputusan atau logika bisnis kepada LLM → akurasi dan stabilitasnya kurang memadai
• Dalam kebanyakan kasus, LLM seharusnya hanya berperan sebagai antarmuka antara pengguna dan API aplikasi
• Logika inti harus dijalankan oleh sistem atau engine khusus, dan LLM hanya bertugas mengubah permintaan pengguna menjadi pemanggilan API lalu mengubah hasilnya kembali menjadi bahasa alami

Mengapa demikian?

• Contoh bot catur: pengguna mengirim lewat WhatsApp "ambil knight dengan bishop saya" → LLM memang bisa sekaligus menjaga status papan catur dan memainkan permainan, tetapi itu menimbulkan banyak masalah dari sisi keandalan, performa, dan pemeliharaan

• Performa: kemampuan LLM bermain catur memang mengesankan, tetapi tetap lebih lambat dan kurang akurat dibanding engine catur khusus (misalnya Stockfish)

• Sulit di-debug dan disetel: sulit mengetahui mengapa keputusan itu diambil, sehingga sukar memperbaikinya agar bekerja sesuai maksud

• Masalah lainnya:

  • Output LLM sulit diuji
  • Kinerjanya buruk untuk matematika atau pembuatan angka acak
  • Versioning dan audit sulit dilakukan
  • Menjaga state dalam bahasa alami itu rapuh
  • Muncul masalah seperti biaya API dan batas kecepatan
  • Batas keamanan menjadi kabur

Pemisahan peran yang benar dilihat dari berbagai contoh

• Dalam game, "saya ingin menyerang pemain X dengan vorpal sword" → LLM seharusnya hanya mengubah ini menjadi bentuk attack(player=X, weapon="vorpal_sword") lalu meneruskannya ke logika game
• Agen negosiasi → LLM tidak membuat keputusan negosiasi, melainkan membungkus input pengguna, mengirimkannya ke engine negosiasi, lalu menyampaikan hasilnya
• Pembuatan respons acak → jangan dipilih oleh LLM, melainkan harus ditangani oleh fungsi acak eksternal

Hal yang dikerjakan LLM dengan baik

• LLM unggul dalam transformasi, interpretasi, dan komunikasi
• Contoh:
  • "pukul orc dengan pedang" → diubah menjadi attack(target="orc", weapon="sword")
  • { "error": "insufficient_funds" } → dijelaskan secara alami menjadi "Gold Anda tidak cukup"
  • Dapat mengklasifikasikan apakah input pengguna adalah perintah bertarung, pemeriksaan inventaris, atau permintaan bantuan
  • Sangat baik dalam memahami konsep manusia (misalnya blade = sword, smash = attack)
• Intinya bukan untuk penilaian kompleks atau pengelolaan state → hanya berperan sebagai jembatan yang menghubungkan niat pengguna ke sistem

Prospek masa depan dan prinsip yang tetap berlaku

• Teknologi berkembang sangat cepat, sehingga hal yang sekarang tidak mungkin bisa segera menjadi mungkin
• Namun, masalah struktural yang tidak bisa diselesaikan oleh LLM kemungkinan besar akan tetap ada:
  • Logika yang tidak menggunakan LLM lebih mudah dipahami, serta lebih mudah dipelihara dan dikelola versinya
  • Biaya eksekusinya juga lebih murah
• Bahkan di masa depan pun, LLM sebaiknya tetap fokus pada peran antarmuka, sementara logika inti diserahkan kepada sistem khusus

[GN⁺]

Komentar Hacker News

• Ada dua jenis logika

  • 1. Logika yang secara inheren harus akurat dan ketat
  • 2. Logika yang terbentuk seperti itu karena sifat komputer

• Jenis nomor 1 mencakup bidang seperti keamanan, keuangan, dan matematika

• Jenis nomor 2 sangat mungkin digantikan oleh AI

• Bagian lain dari aplikasi yang sama bisa cocok untuk nomor 1 atau nomor 2

• Baru-baru ini membuat game edukasi di sebuah hackathon

  • Menggunakan LLM untuk membuat dan menjalankan game, tetapi alur permainannya kurang baik
  • Pada akhirnya, menggunakan banyak kode Python dan beberapa prompt untuk mengelola status game
  • LLM paling baik digunakan sebagai komponen kecil dalam sistem yang besar

• LLM tidak seharusnya mengimplementasikan logika

  • Logika, optimisasi, dan constraint programming adalah teknik yang terpisah
  • Pendiri logika modern adalah George Boole, dan dia adalah kakek Geoffrey Everest Hinton

• Sulit untuk memahami kemampuan LLM

  • Pembaca menginginkan jawaban yang sederhana
  • LLM bisa kesulitan menulis state machine yang sederhana
  • Makalah penelitian sedang populer, dan bahkan hingga 2025 tidak akan ada orang yang sepenuhnya memahami LLM

• Jika respons LLM harus cepat dan murah, gunakan prompt pendek dan model kecil

  • Banyak informasi berasumsi penggunaan model besar
  • UI tradisional mungkin menjadi pilihan yang lebih baik

• Sulit melakukan pengujian hanya dengan LLM

  • Gaya tiap orang memengaruhi interaksi
  • Biaya pemeliharaan bisa tinggi
  • Mengubahnya menjadi pemanggilan API lebih masuk akal

• Menggunakan LLM dalam business logic itu berisiko

  • Cocok untuk pemrosesan bahasa

• Dapat merangkum artikel dengan menggunakan gambar yang dihasilkan AI