Penting untuk mempertimbangkan dengan cermat bagaimana dan di mana keputusan dibuat dalam sistem berbasis agen Anda.
Menyerahkan lebih banyak keputusan kepada LLM memungkinkan sistem menangani lebih banyak jenis tugas, tetapi berpotensi mengorbankan kecepatan, keandalan, dan ketangguhan.
Jika memungkinkan, pindahkan sebanyak mungkin proses pengambilan keputusan dari LLM ke kode perangkat lunak yang eksplisit. Hal ini terutama berlaku untuk alur kerja berisiko tinggi dan/atau produksi.
Saat merancang sistem berbasis agen dengan LLM, salah satu pilihan terpenting adalah menentukan sejauh mana pengambilan keputusan ditempatkan dalam model LLM, alih-alih dalam perangkat lunak eksplisit.
Agar lebih mudah dipahami, pilihan ini dapat dipandang sebagai spektrum di antara pendekatan berikut:
Arsitektur berbasis router menetapkan urutan dan logika secara eksplisit dalam kode sehingga tugas dengan cakupan sempit dapat diuji serta berjalan secara terprediksi dan tangguh (disebut juga “agen alur kerja”).
Agen orkestrator mengandalkan model bahasa besar (LLM) untuk menentukan alur tugas secara dinamis melalui perintah berbahasa alami. Pendekatan ini ideal bagi interaksi terbuka ketika logika yang ditetapkan sebelumnya tidak memadai atau mustahil dibuat.
Untuk alur kerja produksi yang berisiko tinggi, kami biasanya menyarankan lebih banyak fitur berbasis router dan membatasi orkestrator pada aplikasi yang memerlukan percakapan fleksibel untuk berbagai tujuan.
Arsitektur Berbasis Router
Sistem berbasis agen dengan router:
Menetapkan alur pengambilan keputusan secara eksplisit melalui kode atau perangkat lunak, lalu menggunakan LLM untuk menentukan rute yang ditempuh perangkat lunak tersebut.
Lebih menyerupai sistem perangkat lunak tradisional karena memiliki jalur yang jelas dan terprediksi sehingga memberikan hasil yang lebih konsisten.
Ideal untuk tugas yang dapat didefinisikan secara ketat.
Berikut adalah contoh sederhana agen Chatbot Pemesanan Maskapai yang menggunakan “pendekatan Router”. LLM membantu mengklasifikasikan maksud pertanyaan ke dalam tiga pilihan, tetapi perangkat lunak kitalah yang memetakan maksud tersebut ke respons teks berbasis templat. Karena LLM sangat dibatasi, pengguna akan merasakan perilaku yang lebih konsisten.
Arsitektur Orkestrator
Berbeda dengan sistem router, sistem berbasis agen dengan orkestrator:
Menetapkan alur logika melalui perintah berbahasa alami, bukan perangkat lunak. Catatan: dibandingkan bahasa pemrograman, bahasa alami pada dasarnya ambigu dan fleksibel (keduanya dapat menjadi kelebihan sekaligus kekurangan, seperti akan dibahas nanti). Kami menyebutnya “maksud, bukan instruksi”.
Dapat menyediakan beberapa opsi pemrosesan, sementara LLM menentukan urutan dan metode pelaksanaannya.
Dapat secara dinamis membuat jalur logika baru yang sulit ditetapkan secara eksplisit dalam perangkat lunak.
Ambiguitas ini dapat menghasilkan keluaran yang tidak konsisten, tetapi ketika berhasil, hasilnya bisa terasa “ajaib”.
Contoh berikut menerapkan pendekatan orkestrator pada simulasi masalah maskapai yang sama. Alih-alih membiarkan perangkat lunak menentukan respons yang tepat, pengambilan keputusan diserahkan kepada lapisan LLM. Di sini terdapat sistem multiagen. Agen orkestrator “utama” memilah kueri pengguna dan meneruskannya kepada agen yang dirancang khusus untuk mengubah penerbangan, lalu agen tersebut memberikan respons kepada pengguna.
Dalam contoh ini, lapisan LLM berperan sebagai pengklasifikasi, router, dan penulis respons. Dalam contoh Router, LLM hanya berperan sebagai pengklasifikasi (selebihnya ditangani perangkat lunak).
Jika memungkinkan, kami menyarankan pendekatan berbasis router karena menawarkan keunggulan berikut:
Kecepatan dan efisiensi: Komputasi lokal lebih cepat daripada orkestrator yang bergantung pada API eksternal. Memproses logika “IF/ELSE” dengan Python juga jauh lebih murah daripada membayar penyedia LLM untuk memprosesnya melalui model dengan 400 miliar parameter.
Kemudahan pengujian dan keterprediksian: Jauh lebih mudah di-debug, diuji, dan dipelihara dengan praktik perangkat lunak yang sudah mapan.
Transparansi dan keandalan: Perilaku yang lebih seragam memudahkan pemecahan masalah. Sebagian besar alur aplikasi juga dinyatakan dalam perangkat lunak transparan yang dikelola dengan kontrol versi, bukan dalam bobot LLM yang buram dan sulit ditafsirkan.
Kekurangan pendekatan router adalah sifatnya yang dapat menjadi kaku, tidak fleksibel, dan kesulitan menangani masalah yang lebih terbuka. Chatbot yang selalu memberikan respons persis sama mungkin dianggap membosankan atau stagnan oleh penggunanya.
Desain orkestrator memiliki kemampuan yang andal:
Perencanaan: Dapat merencanakan respons secara dinamis.
Pemilihan Alat/Alih Tugas Antaragen: Memilih alat yang sesuai atau mendelegasikan tugas kepada agen.
Penggabungan Keluaran secara Iteratif: Mengolah dan menggabungkan kembali keluaran secara kreatif.
Menentukan Penyelesaian: Menentukan kapan informasi yang dikumpulkan sudah cukup untuk menyelesaikan respons.
Kerangka kerja seperti Pydantic-AI atau Agents SDK dari OpenAI membuat orkestrasi mudah dan cepat diterapkan. Karena itu, pendekatan ini sangat cocok untuk demo atau pembuktian konsep.
Kekurangan pendekatan ini adalah:
Tidak ada jaminan bahwa langkah perencanaan LLM dan tindakan selanjutnya akan benar atau sesuai. Sistem router memiliki masalah yang sama, tetapi karena lebih dibatasi, perilakunya lebih mudah diprediksi.
Untuk tugas sederhana yang didefinisikan dengan baik, kemungkinan besar kita tidak memerlukan seluruh kemampuan sistem multiagen. Misalnya, dalam contoh Agen Maskapai, kemungkinan hanya ada beberapa jenis kueri yang benar-benar ingin diajukan seseorang saat berinteraksi dengan sistem dukungan maskapai.
Karena lebih banyak logika ditempatkan dalam LLM, sistem menjadi jauh lebih rentan terhadap jailbreak atau eksploitasi oleh pelaku jahat.
Pendekatan ini mengabstraksikan pengambilan keputusan ke dalam LLM sehingga sistem lebih sulit dipahami (meski alat pemantauan seperti Langfuse atau Braintrust mungkin sedikit membantu).
Catatan untuk pembaca: meskipun kemampuan model berubah dengan cepat, poin-poin berikut kemungkinan tidak akan berubah dalam waktu dekat.
Tentukan cakupan masalah Anda.
Dapatkah Anda dengan mudah menggambarkan logika keputusan yang diinginkan dalam sebuah diagram?
Apakah aplikasi Anda tidak boleh mengalami kegagalan atau perilaku yang tidak terduga?
Jawaban “ya” untuk salah satu pertanyaan di atas menunjukkan bahwa fitur router lebih sesuai.
Jika memungkinkan, kami menyarankan penggunaan pendekatan router selama masih memadai. Sebagai prinsip umum, jika suatu bagian sistem dapat dinyatakan dalam kode, nyatakanlah dalam kode (yaitu, jangan menggunakan LLM secara berlebihan jika tidak diperlukan).
Ketika pendekatan ini mencapai batasnya, beberapa keunggulan orkestrator untuk tugas terbuka dapat diterapkan kembali secara terbatas. Contohnya:
Pemilihan Alat/Alih Tugas Antaragen: Mudah diterapkan melalui percabangan bersyarat atau pengklasifikasi LLM.
Menentukan Penyelesaian: Pengklasifikasi LLM sederhana dapat memeriksa kelengkapan respons sebelum mengembalikannya kepada pengguna.
Namun, “Perencanaan” dan “Penggabungan Keluaran secara Iteratif” jelas jauh lebih sulit diwujudkan dalam sistem router yang kaku. Jadi, ketika tugas memerlukan kemampuan tersebut—sebagaimana ditentukan oleh pengklasifikasi LLM atau logika lainnya—kami menyarankan pembuatan cabang orkestrator yang lebih bebas dalam sistem Anda.
Pilihan antara arsitektur router dan orkestrator harus mencerminkan kejelasan, kompleksitas, serta gaya interaksi aplikasi Anda. Saat ini, pendekatan berbasis router menawarkan keandalan, efisiensi, dan kemudahan pengujian untuk tugas yang didefinisikan dengan jelas. Orkestrator menawarkan fleksibilitas lebih tinggi untuk interaksi percakapan dengan cakupan lebih luas.
Seiring kemajuan LLM, keseimbangan antara kedua pendekatan ini dapat berubah. Untuk beban kerja produksi, kami cenderung memilih arsitektur berbasis router atau hibrida dan menggunakan orkestrator untuk masalah terbuka yang memerlukan interaksi dinamis layaknya manusia.