> Kelihatannya akan sangat cocok jika memimpin, tetapi dia menolak peran tambahan seperti itu.
> Saat penulis mengusulkan tantangan baru untuk pertumbuhan ...
Dari sudut pandang teknisi, bukankah pertumbuhan berarti menjadi semakin baik dalam hal yang memang sudah dikuasai?
Di buku atau kutipan mana pun,
tentang poin nomor 3 selalu ditulis seperti itu,
namun dalam kenyataannya
kenapa menanyakan hal seperti ini
kenapa baru sekarang menyinggungnya
masa hal beginian juga ditanyakan
kombinasi tiga tingkat yang bisa membuat kita dianggap sebagai partner berkualitas rendah
Karena itu, saya setuju dengan sebagian besar isi tulisan ini.
Tulisan ini lebih membahas gambaran besarnya daripada tips yang benar-benar praktis, jadi kalau menambahkan beberapa tips lagi saat mengembangkan agentic/agent berbasis LLM, pada akhirnya LLM itu berbasis transformer (yaitu penalaran berbasis probabilistik; berdasarkan token/state saat ini, ia bukan memahami konteks/semantik lalu mengucapkan kata berikutnya, melainkan menghasilkan output secara probabilistik). Karena itu, sebaik apa pun sys prompt yang kita berikan, cukup sering ia tidak memberikan jawaban yang kita inginkan (misalnya diminta menjawab dalam output JSON, tetapi kadang lupa menutup } dan sebagainya). Jadi, menambahkan beberapa fallback fn berbasis regex selalu merupakan hal yang wajib.
Lalu, kalau menulis sys prompt yang meminta structured output, biasanya lebih baik memakai non-reasoning model, dan semakin panjang context, semakin sering halusinasi muncul, jadi lebih baik membuat beberapa sys prompt lalu meng-chain-nya.
Saat mengembangkan layanan, karena berbagai error bisa terjadi, kuncinya adalah merancang arsitektur layanan yang modular dan fault tolerant (misalnya supervisor agent dibuat async dan agent lainnya sync), terutama untuk agentic/agent yang sering menghasilkan unexpected output.
Karena itu, sejak awal sebaiknya menulis kode sambil menjaga SRP dan menulisnya secara declarative; saya ingin mengatakan bahwa pendekatan fungsional itu baik (= tidak ada side effect, dan flow-nya intuitif).
Lalu, tergantung apakah LLM dipakai lewat API atau kita akan melakukan model serving sendiri, tetapi jika Anda akan langsung men-serving SLM atau LLM, jangan lakukan model serving di server yang sama dengan backend hosting; akan lebih baik dan lebih fault tolerant jika IO bound task dan CPU bound tasks (yaitu task yang membutuhkan GPU, perkalian matriks, dan semacamnya) ditempatkan di server yang berbeda (misalnya hosting CPU bound task di runpod).
Masih ada banyak tips pengembangan lainnya, tetapi karena takut jadi terlalu panjang, saya tulis sampai di sini saja.
Mereka dulu menyisipkan terjemahan otomatis yang kacau untuk terjemahan bahasa Korea, dan sekarang rupanya sudah berevolusi lagi. Terjemahan otomatis saja tidak bisa dibendung, sekarang kita juga dipaksa mencicipi AI kacau yang sama buruknya!
Kalau soal cgi sih masih bisa dimaklumi, tapi reaksi terhadap jsp cukup mengejutkan ya wkwk.
Apakah jsp memang sudah jadi peninggalan kuno sampai sejauh itu.
Saya benar-benar tidak suka fitur AI, terutama layanan yang siaga di latar belakang lalu menawarkan bantuan.
Jika dijalankan dari jarak jauh, ada masalah karena informasi saya bisa diberikan; jika dijalankan secara lokal, ada masalah karena itu menghabiskan sumber daya komputer saya (CPU, memori, baterai, ...).
Ini benar banget wkwk
Rasanya seperti membandingkan mobil dengan maraton..
wkwkwk "harusnya ada fiturnya"
Saya sangat setuju dengan Anda!
Wkwkwkwk
Pengembangan yang dipandu halusinasi... begitu ya sebutannya;;
> Kelihatannya akan sangat cocok jika memimpin, tetapi dia menolak peran tambahan seperti itu.
> Saat penulis mengusulkan tantangan baru untuk pertumbuhan ...
Dari sudut pandang teknisi, bukankah pertumbuhan berarti menjadi semakin baik dalam hal yang memang sudah dikuasai?
Terima kasih atas kata-katanya yang baik!!
Mungkin yang terpikir adalah bahwa dibanding tanggung jawab dan beban kerja yang semakin besar, tingkat gaji dan perlakuannya tidak ikut berkembang.
Kemungkinan besar begitu.
Tentu saja, jika pemimpinnya baik, mereka akan mendengarkan dengan ramah
dan menyelesaikan masalah dengan tepat.
Di buku atau kutipan mana pun,
tentang poin nomor 3 selalu ditulis seperti itu,
namun dalam kenyataannya
kenapa menanyakan hal seperti ini
kenapa baru sekarang menyinggungnya
masa hal beginian juga ditanyakan
kombinasi tiga tingkat yang bisa membuat kita dianggap sebagai partner berkualitas rendah
Saya juga saat ini sedang membuat Computer-use Agent bernama UseDesktop.
https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq
usedesktop.com
Karena itu, saya setuju dengan sebagian besar isi tulisan ini.
Tulisan ini lebih membahas gambaran besarnya daripada tips yang benar-benar praktis, jadi kalau menambahkan beberapa tips lagi saat mengembangkan agentic/agent berbasis LLM, pada akhirnya LLM itu berbasis transformer (yaitu penalaran berbasis probabilistik; berdasarkan token/state saat ini, ia bukan memahami konteks/semantik lalu mengucapkan kata berikutnya, melainkan menghasilkan output secara probabilistik). Karena itu, sebaik apa pun
sys promptyang kita berikan, cukup sering ia tidak memberikan jawaban yang kita inginkan (misalnya diminta menjawab dalam output JSON, tetapi kadang lupa menutup}dan sebagainya). Jadi, menambahkan beberapafallback fnberbasis regex selalu merupakan hal yang wajib.Lalu, kalau menulis
sys promptyang meminta structured output, biasanya lebih baik memakai non-reasoning model, dan semakin panjang context, semakin sering halusinasi muncul, jadi lebih baik membuat beberapasys promptlalu meng-chain-nya.Saat mengembangkan layanan, karena berbagai error bisa terjadi, kuncinya adalah merancang arsitektur layanan yang modular dan fault tolerant (misalnya
supervisor agentdibuat async dan agent lainnya sync), terutama untuk agentic/agent yang sering menghasilkan unexpected output.Karena itu, sejak awal sebaiknya menulis kode sambil menjaga SRP dan menulisnya secara declarative; saya ingin mengatakan bahwa pendekatan fungsional itu baik (= tidak ada side effect, dan flow-nya intuitif).
Lalu, tergantung apakah LLM dipakai lewat API atau kita akan melakukan model serving sendiri, tetapi jika Anda akan langsung men-serving SLM atau LLM, jangan lakukan model serving di server yang sama dengan backend hosting; akan lebih baik dan lebih fault tolerant jika IO bound task dan CPU bound tasks (yaitu task yang membutuhkan GPU, perkalian matriks, dan semacamnya) ditempatkan di server yang berbeda (misalnya hosting CPU bound task di runpod).
Masih ada banyak tips pengembangan lainnya, tetapi karena takut jadi terlalu panjang, saya tulis sampai di sini saja.
Semoga ini bisa membantu seseorang.
Bagaimana kalau layanan yang dipasang di server jarak jauh private?
Mereka dulu menyisipkan terjemahan otomatis yang kacau untuk terjemahan bahasa Korea, dan sekarang rupanya sudah berevolusi lagi. Terjemahan otomatis saja tidak bisa dibendung, sekarang kita juga dipaksa mencicipi AI kacau yang sama buruknya!
Kalau soal cgi sih masih bisa dimaklumi, tapi reaksi terhadap jsp cukup mengejutkan ya wkwk.
Apakah jsp memang sudah jadi peninggalan kuno sampai sejauh itu.
Saya benar-benar tidak suka fitur AI, terutama layanan yang siaga di latar belakang lalu menawarkan bantuan.
Jika dijalankan dari jarak jauh, ada masalah karena informasi saya bisa diberikan; jika dijalankan secara lokal, ada masalah karena itu menghabiskan sumber daya komputer saya (CPU, memori, baterai, ...).
Sepertinya ini bisa menjadi referensi yang bagus.
Seorang developer asal Rusia; pernah dari Yandex ke Riot, dan sekarang pindah kerja ke JPMorganChase.
Wkwkwkwk, lucu banget
Terasa sekali seperti cuma ganti nama.