Penting kanggo nimbang kanthi tliti kepriye lan ing ngendi keputusan digawe ing sistem agen sampeyan.
Masrahake luwih akeh keputusan marang LLM bisa ndadekake sistem bisa digeneralisasi kanggo luwih akeh tugas, nanging bisa ngorbanake kacepetan, linuwih, lan kakuwatan sistem.
Yen bisa, coba pindhahake sabisa-bisane proses nggawe keputusan saka LLM menyang kode piranti lunak sing eksplisit. Iki mligi ditrapake kanggo alur kerja produksi lan/utawa sing berisiko dhuwur.
Nalika ngrancang sistem agen adhedhasar LLM, salah siji pilihan sing paling penting yaiku nemtokake sepira akehe proses nggawe keputusan sing dilebokake ing model LLM tinimbang ing piranti lunak eksplisit.
Supaya luwih gampang dimangerteni, pilihan iki bisa dianggep minangka spektrum antarane pendekatan ing ngisor iki:
Arsitektur adhedhasar router nemtokake urutan lan logika kanthi eksplisit ing kode, saengga tugas ing ranah winates bisa diuji, dipredhiksi, lan luwih kukuh (iki uga diarani “agen alur kerja”).
Agen orkestrator ngendelake LLM kanggo nemtokake alur tugas kanthi dinamis nggunakake pituduh basa alami. Pendekatan iki cocog kanggo interaksi tanpa watesan nalika logika sing wis ditemtokake ora cukup utawa ora bisa digawe.
Kanggo alur kerja produksi sing berisiko dhuwur, biasane disaranake nggunakake luwih akeh fitur adhedhasar router lan nggunakake orkestrator mung kanggo aplikasi sing mbutuhake pacelathon fleksibel lan serbaguna.
Arsitektur Adhedhasar Router
Sistem agen router:
Nemtokake alur nggawe keputusan kanthi eksplisit liwat kode utawa piranti lunak, banjur nggunakake LLM kanggo milih rute sing kudu ditindakake piranti lunak kasebut.
Luwih cedhak karo sistem piranti lunak tradhisional amarga nduweni jalur sing cetha lan bisa dipredhiksi, saengga asile luwih konsisten.
Cocog kanggo tugas sing bisa ditemtokake kanthi ketat.
Ing ngisor iki ana conto prasaja agen Chatbot Pemesanan Maskapai sing nggunakake “pendekatan Router”. LLM mbantu nggolongake maksud pitakon menyang salah siji saka telung pilihan, nanging pungkasane piranti lunak kita sing masangake maksud kasebut karo cithakan wangsulan teks. Amarga LLM diwatesi kanthi ketat, pangguna bakal ngrasakake prilaku sing luwih konsisten.
Arsitektur Orkestrator
Beda karo sistem router, sistem agen orkestrator:
Nemtokake alur logika liwat pituduh basa alami, dudu piranti lunak. Cathetan: dibandhingake karo basa pamrograman, basa alami pancen nduweni teges sing ora mesthi lan fleksibel (iki bisa dadi sipat positif utawa negatif, kaya sing bakal dirembug mengko). Iki dianggep minangka “maksud, dudu instruksi”.
Bisa nyedhiyakake pirang-pirang pilihan pangolahan, kanthi LLM sing nemtokake urutan lan cara eksekusi.
Bisa nggawe jalur logika anyar kanthi dinamis sing angel ditemtokake kanthi eksplisit ing piranti lunak.
Kahanan sing ora mesthi iki bisa ngasilake output sing ora konsisten, nanging yen kasil, bisa krasa “nggumunake”.
Conto ing ngisor iki ngetrapake pendekatan orkestrator kanggo masalah maskapai prasaja sing padha. Tinimbang ngidini piranti lunak nemtokake wangsulan sing cocog, proses nggawe keputusan dipasrahake menyang lapisan LLM. Ing kene ana sistem multiagen. Agen orkestrator “utama” milah panjaluk pangguna lan masrahake menyang agen sing dirancang khusus kanggo ngganti penerbangan, banjur agen kasebut menehi wangsulan marang pangguna.
Ing conto iki, lapisan LLM nindakake peran minangka panggolong, router, lan panyusun wangsulan. Ing conto Router, LLM mung nindakake peran minangka panggolong (dene liyane ditangani piranti lunak).
Yen bisa, disaranake nggunakake pendekatan adhedhasar router amarga nduweni kaluwihan iki:
Kacepetan lan efisiensi: Komputasi lokal luwih cepet tinimbang orkestrator sing gumantung marang API eksternal. Ngolah logika “IF/ELSE” nganggo Python uga luwih murah tinimbang mbayar panyedhiya LLM kanggo ngolah logika kasebut nganggo model 400 milyar parameter.
Bisa diuji lan dipredhiksi: Luwih gampang didandani, diuji, lan dirumat nganggo praktik piranti lunak sing wis mapan.
Transparansi lan linuwih: Prilaku sing ora akeh variasine nggampangake panlusuran masalah. Bagean luwih gedhe saka alur aplikasi uga diwujudake minangka piranti lunak transparan sing dikontrol versine, dudu minangka bobot LLM sing peteng lan ora bisa ditafsirake.
Kakurangan pendekatan router yaiku bisa kaku, ora fleksibel, lan kangelan nalika ngadhepi masalah sing luwih tanpa watesan. Chatbot sing tansah menehi wangsulan persis padha bisa dianggep mboseni utawa mandheg berkembang dening panggunane.
Rancangan orkestrator nduweni kabisan sing kuwat:
Perencanaan: Bisa ngrancang wangsulan kanthi dinamis.
Pamilihan Piranti/Pasrah Tugas menyang Agen: Milih piranti sing cocog utawa masrahake tugas marang agen.
Gabungan Output kanthi Iteratif: Ngolah lan nggabungake maneh output kanthi kreatif.
Nemtokake Rampunge Proses: Nemtokake kapan informasi sing diklumpukake wis cukup kanggo ngrampungake wangsulan.
Framework kaya Pydantic-AI utawa Agents SDK saka OpenAI nggampangake orkestrasi lan nyepetake implementasine. Mula, pendekatan iki cocog kanggo demo utawa bukti konsep.
Kakurangan pendekatan iki yaiku:
Ora ana jaminan yen langkah perencanaan LLM lan tumindak sabanjure bakal bener utawa cocog. Sistem router nduweni masalah sing padha, nanging amarga luwih diwatesi, prilakune luwih bisa dipredhiksi.
Kanggo tugas prasaja sing wis ditemtokake kanthi cetha, kemungkinan kita ora mbutuhake kabeh kabisan sistem multiagen. Contone, ing conto Agen Maskapai, mesthine mung ana sawetara jinis panjaluk sing pancen dikarepake wong nalika sesambungan karo sistem dhukungan maskapai.
Amarga luwih akeh logika disimpen ing LLM, sistem dadi luwih rentan dijebol utawa dieksploitasi dening pihak sing nduweni niat ala.
Pendekatan iki mindhah proses nggawe keputusan menyang LLM, mula sistem sampeyan luwih angel dimangerteni (sanajan piranti pamantauan kaya Langfuse utawa Braintrust bisa rada mbantu).
Cathetan kanggo pamaca: senajan kabisan model owah kanthi cepet, bab-bab ing ngisor iki kemungkinan ora bakal owah ing wektu cedhak.
Temtokake cakupan masalah sampeyan.
Apa logika keputusan sing dikarepake bisa ditetepake kanthi gampang ing diagram?
Apa aplikasi sampeyan ora bisa nampa kegagalan utawa prilaku sing ora dikarepake?
Yen wangsulan kanggo salah siji pitakon ing ndhuwur “ya”, fitur router kemungkinan luwih cocog.
Yen bisa, disaranake nggunakake pendekatan router nganti tekan watese. Minangka prinsip umum, yen bagean sistem bisa diwujudake nganggo kode, tulisen nganggo kode (tegese, aja nggunakake LLM kanthi keladuk yen ora dibutuhake).
Nalika wis tekan wates kasebut, sawetara kaluwihan orkestrator tanpa watesan bisa ditiru kanthi cara sing diwatesi. Contone:
Pamilihan Piranti/Pasrah Tugas menyang Agen: Gampang ditrapake liwat percabangan kondisional utawa panggolong LLM.
Nemtokake Rampunge Proses: Panggolong LLM sing prasaja bisa mriksa apa wangsulan wis jangkep sadurunge diwenehake marang pangguna.
Nanging, “Perencanaan” lan “Gabungan Output kanthi Iteratif” pancen luwih angel ditindakake ing sistem router sing kaku. Mula, nalika tugas mbutuhake kabisan kasebut (adhedhasar asil panggolong LLM utawa logika liyane), disaranake nggawe cabang orkestrator sing luwih longgar ing sistem sampeyan.
Pilihan antarane arsitektur router lan orkestrator kudu nggambarake kajelasan, kerumitan, lan gaya interaksi aplikasi sampeyan. Saiki, pendekatan adhedhasar router nyedhiyakake linuwih, efisiensi, lan gampang diuji kanggo tugas sing ditemtokake kanthi cetha. Orkestrator nawakake fleksibilitas luwih apik kanggo interaksi pacelathon sing luwih amba.
Kanthi kabisan LLM sing terus maju, imbangan antarane pendekatan kasebut bisa owah. Kita luwih milih arsitektur adhedhasar router utawa hibrida kanggo beban kerja produksi, lan nggunakake orkestrator mung kanggo masalah tanpa watesan sing mbutuhake interaksi dinamis kaya manungsa.