Pola desain sistem agen

Membangun sistem agen melibatkan mengatur bagaimana panggilan LLM, pengambilan data, dan tindakan eksternal berkoordinasi. Anda dapat memikirkan pola desain untuk sistem agen pada kontinum kompleksitas danotonomi: dari rantai deterministik, melalui sistem agen tunggal yang dapat membuat keputusan dinamis (dan dapat melibatkan beberapa panggilan LLM di bawah kap), hingga arsitektur multi-agen yang mengoordinasikan beberapa agen khusus.

Panggilan alat

Sebelum menyelami pola desain, penting untuk memahami panggilan alat sebagai kemampuan mendasar yang dapat digunakan dalam sistem agen apa pun, dari yang sederhana hingga kompleks. Panggilan alat adalah mekanisme yang memungkinkan sistem agen berinteraksi dengan fungsi eksternal, sumber data, atau layanan. Ini dapat mengaktifkan:

• Pencarian data waktu nyata seperti kueri SQL, pengambilan CRM, atau pengambilan indeks vektor.
• Tindakan seperti mengirim email atau memperbarui catatan.
• Logika atau transformasi arbitrer melalui fungsi atau API Python.

Panggilan alat dengan demikian menyediakan mekanisme yang kuat untuk membuat LLM "mengetahui" data eksternal atau API apa pun pola desain yang Anda pilih.

Untuk mempelajari selengkapnya tentang alat agen, lihat alat agen AI.

Bagian di bawah ini membahas tiga pola desain sistem agen, yang masing-masing dapat memanfaatkan panggilan alat ke tingkat yang berbeda-beda.

Membandingkan pola desain aplikasi AI generatif

Pola desain aplikasi Gen AI (agen) disajikan dalam urutan kompleksitas.

Pola Desain	Kapan Harus Digunakan	Keuntungan	Kontra
rantai deterministik	Tugas yang terdefinisi dengan baik Alur statis seperti RAG dasar Tidak perlu keputusan secara seketika	Sangat sederhana Mudah diaudit	Tidak fleksibel Memerlukan perubahan kode untuk beradaptasi
sistem agen tunggal	Kueri tingkat sedang hingga kompleks dalam domain yang sama Beberapa keputusan dinamis tanpa beban tambahan dari berbagai agen khusus.	Flexibel Lebih sederhana dari multi-agen Pengaturan bawaan yang baik	Kurang dapat diprediksi Harus waspada terhadap panggilan alat yang berulang atau salah
sistem multi-agen	Domain besar atau lintas fungsi; beberapa agen "ahli"; konteks logika atau percakapan yang berbeda; pola refleksi tingkat lanjut.	Sangat modular Menskalakan ke domain besar	Kompleks untuk mengorkestrasi Lebih sulit dilacak dan di-debug

Sistem agen tunggal

Sistem agen-tunggal memiliki satu alur logika yang terkoordinasi - sering mengoordinasikan beberapa panggilan LLM - untuk menangani permintaan yang masuk. Agen dapat:

1. Terima permintaan seperti kueri pengguna dan konteks yang relevan seperti riwayat percakapan.
2. Pertimbangkan cara terbaik untuk merespons, secara opsional memutuskan apakah akan memanggil alat untuk data eksternal atau tindakan.
3. Iterasi jika diperlukan, memanggil LLM (dan/atau alat yang sama) berulang kali hingga tujuan tercapai atau kondisi tertentu terpenuhi (seperti menerima data yang valid atau menyelesaikan kesalahan).
4. Integrasikan output alat ke dalam percakapan.
5. Menghasilkan respons yang kohesif sebagai keluaran.

Dalam banyak kasus penggunaan, satu putaran penalaran LLM (seringkali dengan pemanggilan alat) sudah cukup. Namun, agen yang lebih canggih dapat mengulang beberapa langkah sampai mereka tiba pada hasil yang diinginkan.

Meskipun hanya ada agen "satu", Anda masih dapat memiliki beberapa LLM dan panggilan alat di balik layar (untuk perencanaan, pembuatan, verifikasi, dan sebagainya), semuanya dikelola oleh alur terintegrasi tunggal ini.

Contoh : Asisten staf bantuan

• Jika pengguna mengajukan pertanyaan sederhana ("Apa kebijakan pengembalian kami?"), agen dapat merespons langsung dari pengetahuan LLM.
• Jika pengguna menginginkan status pesanan mereka, agen memanggil fungsi lookup_order(customer_id, order_id). Jika alat tersebut merespons dengan "nomor pesanan yang tidak valid", agen dapat mencoba kembali atau meminta ID yang benar kepada pengguna, melanjutkan hingga dapat memberikan jawaban akhir.

Kapan menggunakan:

• Anda mengharapkan kueri pengguna yang bervariasi tetapi masih berada dalam domain atau area produk yang kohesif.
• Kueri atau kondisi tertentu dapat menjamin penggunaan alat seperti memutuskan kapan harus mengambil data pelanggan.
• Anda menginginkan lebih banyak fleksibilitas daripada rantai deterministik tetapi tidak memerlukan agen khusus terpisah untuk tugas yang berbeda.

Keunggulan :

• Agen dapat beradaptasi dengan kueri baru atau tidak terduga dengan memilih alat (jika ada) mana yang akan dipanggil.
• Agen dapat mengulangi panggilan LLM atau pemanggilan alat berulang kali untuk menyempurnakan hasil - tanpa perlu pengaturan multi-agen yang lengkap.
• Pola desain ini sering kali menjadi solusi tepat untuk kasus penggunaan perusahaan - lebih sederhana untuk memperbaiki kesalahan daripada pengaturan multi-agen sambil tetap memungkinkan logika dinamis dan otonomi yang terbatas.

Pertimbangan :

• Dibandingkan dengan rantai kode tetap, Anda harus berjaga-jaga terhadap panggilan alat yang berulang atau tidak valid. (Perulangan tak terbatas dapat terjadi dalam skenario panggilan alat apa pun, jadi atur batas perulangan atau batas waktu.)
• Jika aplikasi Anda mencakup sub-domain yang berbeda secara radikal (keuangan, devops, pemasaran, dll.), satu agen mungkin menjadi sulit diatur atau dibebani oleh persyaratan fungsionalitas.
• Anda masih memerlukan perintah dan batasan yang dirancang dengan hati-hati untuk menjaga agen tetap fokus dan relevan.

Rantai deterministik (langkah-langkah berkode keras)

Dalam pola ini, pengembang menentukan komponen mana yang dipanggil, dalam urutan apa, dan dengan parameter mana. Tidak ada pengambilan keputusan dinamis tentang alat mana yang untuk dihubungi atau dalam urutan apa . Sistem mengikuti alur kerja yang telah ditentukan sebelumnya untuk semua permintaan, membuatnya sangat dapat diprediksi.

Umumnya disebut "Rantai", aliran pada dasarnya adalah rantai langkah tetap, seperti:

1. Selalu ambil permintaan pengguna dan ambil dari indeks vektor untuk konteks yang relevan.
2. Gabungkan konteks tersebut dengan permintaan pengguna ke dalam prompt LLM akhir.
3. Panggil LLM dan kembalikan jawabannya.

Contoh: Rantai RAG Dasar

Rantai RAG deterministik mungkin selalu:

1. Ambil hasil top-k dari indeks vektor menggunakan permintaan pengguna masuk (ambil).
2. Memformat potongan yang sudah diambil ke dalam templat prompt (perluas).
3. Sampaikan permintaan yang telah ditingkatkan tersebut ke LLM (menghasilkan).
4. Mengembalikan respons LLM.

Kapan menggunakan:

• Untuk tugas yang ditentukan dengan baik dengan alur kerja yang dapat diprediksi.
• Ketika konsistensi dan audit adalah prioritas utama.
• Untuk meminimalkan latensi atau waktu respons, hindari melakukan beberapa panggilan LLM untuk keputusan orkestrasi.

Keunggulan :

• Tingkat prediktabilitas dan auditabilitas tertinggi.
• Biasanya latensi lebih rendah (panggilan LLM lebih sedikit untuk orkestrasi).
• Lebih mudah diuji dan divalidasi.

Pertimbangan :

• Fleksibilitas terbatas untuk menangani permintaan yang beragam atau tidak terduga.
• Dapat menjadi kompleks dan sulit untuk dipertahankan saat cabang logika tumbuh.
• Mungkin memerlukan pemfaktoran ulang yang signifikan untuk mengakomodasi kemampuan baru.

Sistem multi-agen

Sistem multi-agen melibatkan dua atau beberapa agen khusus yang bertukar pesan dan/atau berkolaborasi dalam tugas. Setiap agen memiliki domain atau keahlian tugas, konteks, dan set alat yang berpotensi berbeda. Koordinator terpisah - yang mungkin merupakan LLM lain atau router berbasis aturan - mengarahkan permintaan ke agen yang sesuai, atau memutuskan kapan harus memindahkan tugas dari satu agen ke agen lain.

Contoh : Asisten perusahaan dengan agen khusus

• Agen dukungan pelanggan: Menangani pencarian, pengembalian, dan pengiriman CRM.
• agen Analytics: Fokus pada kueri SQL dan ringkasan data.
• Supervisor/router: Memilih agen mana yang terbaik untuk kueri pengguna tertentu, atau kapan harus beralih.

Setiap sub-agen dapat melakukan panggilan alat dalam domainnya sendiri (seperti lookup_customer_account atau run_sql_query) sering membutuhkan permintaan unik atau riwayat percakapan.

Kapan menggunakan:

• Anda memiliki area masalah atau set keterampilan yang berbeda seperti agen pengkodian atau agen keuangan.
• Setiap agen memerlukan akses ke riwayat percakapan atau perintah khusus domain.
• Anda memiliki begitu banyak alat sehingga memasukkan semuanya ke dalam skema satu agen menjadi tidak praktis; setiap agen dapat memiliki bagian dari alat-alat tersebut.
• Anda ingin menerapkan refleksi, kritik, atau kolaborasi bolak-balik di antara agen khusus.

Keunggulan :

• Pendekatan modular ini berarti setiap agen dapat dikembangkan atau dikelola oleh tim terpisah, yang mengkhususkan diri dalam domain sempit.
• Dapat menangani alur kerja perusahaan yang besar dan kompleks yang mungkin sulit dikelola oleh satu agen secara kohesif.
• Memfasilitasi penalaran multi-langkah atau multi-perspektif lanjutan - misalnya, satu agen menghasilkan jawaban, yang lain memverifikasinya.

Pertimbangan :

• Memerlukan strategi untuk perutean antar agen, ditambah biaya tambahan untuk pencatatan log, pelacakan, dan penelusuran kesalahan di beberapa titik akhir.
• Jika Anda memiliki banyak sub-agen dan alat, itu bisa menjadi rumit untuk memutuskan agen mana yang memiliki akses ke data atau API mana.
• Agen dapat bertukar-tukar tugas selamanya di antara mereka sendiri tanpa resolusi jika tidak dibatasi dengan hati-hati.
  • Risiko loop tak terbatas juga ada dalam pemanggilan alat oleh agen tunggal, tetapi pengaturan multi-agen menambahkan lapisan kompleksitas tambahan pada debugging.

Saran praktis

Terlepas dari pola desain mana yang Anda pilih, pertimbangkan praktik terbaik berikut untuk mengembangkan sistem agen yang stabil dan dapat dipertahankan.

1. Mulai sederhana: Jika Anda hanya membutuhkan rantai yang mudah, rantai deterministik akan cepat dibangun.
2. Secara bertahap menambahkan kompleksitas: Saat Anda membutuhkan kueri yang lebih dinamis atau sumber data fleksibel, pindah ke sistem agen tunggal dengan panggilan alat.
3. Gunakan multi-agen: Hanya jika Anda memiliki domain atau tugas yang jelas berbeda, beberapa konteks percakapan, atau sekumpulan alat yang terlalu besar untuk satu agen saja.

Jika kasus penggunaan Anda dimulai dari kecil - seperti rantai RAG sederhana - mulailah dengan rantai yang diprogram secara statis. Seiring berkembangnya persyaratan, Anda dapat menambahkan logika panggilan alat untuk pengambilan keputusan dinamis atau bahkan membagi tugas menjadi beberapa agen khusus. Dalam praktiknya, banyak sistem agen dunia nyata menggabungkan pola. Misalnya, gunakan rantai yang sebagian besar deterministik tetapi memungkinkan LLM untuk secara dinamis memanggil API tertentu dalam satu langkah jika diperlukan.

Mosaic AI Agent Framework adalah agnostik dari pola apa pun yang Anda pilih, sehingga mudah untuk mengembangkan pola desain saat aplikasi Anda tumbuh.

Panduan pengembangan

• Perintah
  • Jaga agar permintaan tetap jelas dan minimal untuk menghindari instruksi yang bertentangan, informasi yang mengalihkan perhatian, dan mengurangi halusinasi.
  • Berikan hanya alat dan konteks yang diperlukan agen Anda, bukan sekumpulan API yang tidak terbatas atau konteks besar yang tidak relevan.
• Pengelogan & Observabilitas
  • Terapkan pencatatan terperinci untuk setiap permintaan pengguna, rencana agen, dan panggilan alat. Pelacakan MLflow dapat membantu menangkap log terstruktur untuk debugging.
  • Simpan log dengan aman dan perhatikan informasi identitas pribadi (PII) dalam data percakapan.
• Memperbarui model & Penyematan versi
  • Perilaku LLM dapat bergeser saat penyedia memperbarui model di belakang layar. Gunakan penyematan versi dan pengujian regresi yang sering untuk memastikan logika agen Anda tetap kuat dan stabil.
  • Menggabungkan MLflow dengan Evaluasi Agen Mosaic AI menyediakan cara yang disederhanakan untuk membuat versi agen dan secara teratur mengevaluasi kualitas serta performanya.

Panduan pengujian dan perulangan

• Penanganan kesalahan & logika cadangan
  • Persiapkan diri untuk kegagalan alat atau LLM. Waktu habis, respons cacat, atau hasil kosong dapat merusak alur kerja. Sertakan strategi ulang, logika pemulihan, atau rantai pemulihan yang lebih sederhana saat fitur canggih gagal.
• rekayasa pemicu berulang
  • Diharapkan untuk menyempurnakan petunjuk dan logika berantai seiring waktu. Versi setiap perubahan (menggunakan Git dan MLflow) supaya Anda bisa mengembalikan atau membandingkan performa antar versi.
  • Pertimbangkan kerangka kerja seperti DSPy untuk mengoptimalkan perintah dan komponen lain dalam sistem agen Anda secara terprogram.

Panduan produksi

• Latensi vs. pengoptimalan biaya
  • Setiap LLM atau panggilan alat tambahan meningkatkan penggunaan token dan waktu respons. Jika memungkinkan, gabungkan langkah-langkah atau simpan kueri berulang dalam cache untuk menjaga performa dan biaya tetap terkelola.
• Keamanan dan sandboxing
  • Jika agen Anda dapat memperbarui rekaman atau menjalankan kode, isolasi tindakan tersebut atau berlakukan persetujuan manusia jika diperlukan. Ini sangat penting di perusahaan atau lingkungan yang diatur untuk menghindari bahaya yang tidak diinginkan.
  • Databricks merekomendasikan alat Unity Catalog untuk eksekusi dalam lingkungan terisolasi. Lihat fungsi alat Katalog Unity vs. alat kode agen. Katalog Unity memungkinkan isolasi eksekusi kode arbitrer dan mencegah aktor jahat menipu agen untuk menghasilkan dan menjalankan kode yang mengganggu atau menguping permintaan lain.

Dengan mengikuti panduan ini, Anda dapat mengurangi banyak mode kegagalan paling umum seperti kesalahan pemanggilan alat, penurunan performa LLM, atau lonjakan biaya yang tidak terduga, dan membangun sistem agen yang lebih andal dan dapat diskalakan.