AI Agen

Sistem AI agen terdiri dari komponen berikut:

• Komponen Orkestrasi Agen mengelola, dan mengoordinasikan tindakan sekumpulan Agen. Komponen Agen Orkestrasi dapat menggunakan LLM untuk memecah dan secara dinamis menghasilkan alur kerja untuk menyelesaikan tugas-tugas yang kompleks, atau mungkin hanya menggunakan alur kerja yang ditentukan secara statis yang didefinisikan menggunakan teknologi seperti Business Process Modeling Notation (BPMN), Business Process Execution Language (BPEL), atau teknologi alur kerja lainnya.
  
  
• Satu atau beberapa Agen, perangkat lunak yang dapat menentukan sendiri dan menjalankan tindakan untuk memenuhi tujuan yang ditentukan. Agen biasanya menggunakan LLM untuk secara dinamis menghasilkan rencana untuk menyelesaikan tugas. Agen juga dapat menggunakan Alat untuk berinteraksi dengan sistem eksternal, misalnya. API aplikasi perusahaan, toko pengetahuan pencarian, misalnya. kueri Wikipedia, atau untuk melakukan perhitungan, misalnya. operasi matematika, yang tidak dapat dilakukan secara akurat atau efektif menggunakan LLM saja.
  
  
• Akhirnya, alat berinteraksi dengan sumber dan sistem perusahaan dan eksternal untuk mengambil informasi, dan memperbarui sistem catatan.

Agen memiliki arsitektur konseptual mereka sendiri, diilustrasikan pada gambar di bawah ini.

Agen terdiri dari komponen inti berikut:

• Komponen Input adalah satu atau lebih sumber input yang memicu agen untuk mengambil tindakan. Biasanya ini adalah kueri bahasa alami atau tugas dari pengguna tetapi juga bisa berupa peristiwa sistem, seperti pembuatan file, pesan pada antrean Kafka, atau panggilan API terstruktur.
  
  
• Komponen Eksekusi mengoordinasikan aktivitas agen untuk melaksanakan tugas yang diperlukan. Umumnya, tugas pertama yang dijalankan oleh komponen Eksekusi adalah (i) menyusun daftar alat dan sumber daya yang tersedia untuk agen, dan (ii) memanggil komponen Perencanaan dan Refleksi untuk menghasilkan rencana aktivitas untuk melaksanakan tugas. Komponen Eksekusi kemudian mengeksekusi rencana yang dihasilkan, memanggil alat dan sumber daya yang diperlukan untuk mengumpulkan informasi atau mengubah lingkungan eksternal agen; dan dapat secara berkala memanggil kembali komponen Perencanaan dan Refleksi untuk menyesuaikan rencana aktivitas tergantung pada tanggapan/kegagalan alat.
  
  
• Komponen Perencanaan dan Refleksi, yang umumnya berupa LLM, memungkinkan agen untuk membuat rencana tindakan langkah demi langkah untuk menyelesaikan suatu tugas sebagai respons terhadap input, serta untuk merefleksikan hasil tindakan dan menyesuaikan rencana mereka sebagai respons terhadap hasil.
  
  
• Komponen Integrasi Alat memungkinkan agen menggunakan 'alat' untuk memanggil API dan mengakses sumber daya untuk menyelesaikan tindakan dan mengumpulkan informasi untuk berkontribusi pada penyelesaian tugas keseluruhan.
  
  
• Komponen Memori mengelola pengetahuan jangka pendek, dalam tugas, konteks, serta pengetahuan jangka panjang yang memungkinkan agen untuk mempertahankan konteks di seluruh panggilan tugas (misalnya, "Membalikkan pesanan pembelian terakhir") dan untuk memberikan dasar bagi analisis tindakan masa lalu dan optimalisasi tindakan di masa depan.
  

Komponen tambahan, tidak ditunjukkan pada gambar, dapat ditambahkan untuk menyediakan manajemen agen operasional, pemantauan kinerja, dan kontrol keamanan seperti propagasi identitas dan pencegahan kebocoran data.

Diagram di bawah ini menggambarkan alur kontrol dan informasi melalui arsitektur konseptual.

1. Pengguna mengirim kueri ke aplikasi AI generatif (misalnya, chatbot, atau antarmuka kueri dalam aplikasi)
   
   
2. Aplikasi AI generatif meneruskan kueri pengguna ke Agen Orchestrator dalam bentuk kueri mentah, misalnya. aplikasi AI adalah antarmuka obrolan, atau pemicu alur kerja yang telah ditentukan sebelumnya, misalnya. inisiasi permintaan pembelian. Kueri mentah akan diasumsikan untuk penelusuran.
   
   
3. Router menggunakan LLM yang disetel untuk memecah permintaan pengguna menjadi serangkaian tindakan, atau langkah, yang diperlukan untuk sampai pada jawaban. Misalnya, untuk menjawab pertanyaan "Berapa suhu saat ini di Winnipeg, Manitoba, Kanada? Bagaimana jika dibandingkan dengan rata-rata historis untuk sepanjang tahun ini?" LLM dapat merespons dengan daftar tindakan konseptual berikut:
   
   
   • Cari suhu saat ini untuk Winnipeg menggunakan agen Cuaca
   • Cari tanggal saat ini menggunakan agen Kalender
   • Cari suhu rata-rata di Winnipeg pada tanggal ini menggunakan agen Pencarian
   • Temukan perbedaan antara suhu saat ini dan rata-rata historis menggunakan agen Kalkulator
   • Merumuskan respons bahasa alami menggunakan agen Bahasa
     
     
4. Orchestrator kemudian memanggil agen yang sesuai untuk setiap tindakan dalam daftar. Melanjutkan dengan contoh dari Langkah 3:
   
   
   • Orchestrator memanggil agen Cuaca untuk mengambil suhu saat ini untuk Winnipeg, -1° C.
   • Orchestrator memanggil agen Kalender untuk mendapatkan tanggal saat ini, 9 November 2023.
   • Orchestrator menggunakan agen Pencarian untuk menemukan suhu normal di Winnipeg pada 9 November, 1,4° C.
   • Orchestrator memanggil agen Kalkulator untuk menemukan perbedaan antara dua suhu, -1 - 1,4 = -2,4
   • Orchestrator menggunakan agen Bahasa untuk merumuskan respons terhadap kueri awal menggunakan data yang dikumpulkan
      
5. Ketika dipanggil, agen mungkin, seperti Orchestrator, menggunakan LLM untuk merencanakan tindakannya. Melanjutkan dengan contoh sebelumnya, agen Cuaca akan menerima permintaan "Berapa suhu saat ini di Winnipeg?", yang akan menghasilkan rencana berikut:
   
   
   • Cari tahu di negara mana Winnipeg berada
   • Cari layanan cuaca nasional otoritatif untuk negara Winnipeg
   • Gunakan API Cuaca untuk menanyakan layanan cuaca untuk suhu saat ini di Winnipeg.
   • Agen kemudian akan mencari negara di mana Winnipeg berada (Kanada) menggunakan LLM atau layanan eksternal, menggunakan nilai itu untuk mencari layanan cuaca nasional untuk Kanada (Environment Canada), dan menggunakan API Cuaca untuk mendapatkan suhu saat ini untuk Winnipeg.
      
6. Respons yang dihasilkan kemudian diteruskan kembali ke aplikasi AI generatif; dalam contoh kami "Suhu saat ini di Winnipeg adalah -1°C. Itu 2,4° C lebih dingin dari norma historis 1,4° C".
   
   
7. Respons yang dirumuskan diteruskan kembali ke pengguna.

Diagram di atas menggambarkan pemetaan produk IBM ke arsitektur AI agen.

watsonx Orchestrate adalah solusi AI agen multi-fungsi yang menggabungkan:

• publikasi dan pengelolaan alat (disebut keterampilan dalam watsonx Orchestrate);
• komposisi keterampilan ke dalam proses multi-langkah yang kompleks menggunakan alur kerja deklaratif; dan
• agen khusus domain yang dibangun sebelumnya untuk area bisnis horizontal seperti SDM dan Pembelian.

watsonx.ai Agent Builder adalah alat low-code/no-code yang memungkinkan pengembang untuk membangun agen, dan menentukan serta mengelola alat menggunakan alur yang dibangun sebelumnya.

Strategi Orkestrasi

Orkestrasi agen dapat diimplementasikan dengan menggunakan berbagai pendekatan. Pendekatan orkestrasi terpusat menggunakan satu komponen orkestrasi utama untuk mengelola tindakan semua agen lain dalam sistem. Memiliki satu titik konfigurasi dan manajemen membuat keseluruhan sistem mudah dikelola dan dikendalikan, mudah untuk memecahkan masalah. Kelemahannya adalah bahwa satu titik kontrol dapat menjadi hambatan dan menyebabkan tantangan skalabilitas karena volume permintaan dan/atau jumlah agen meningkat.

Pendekatan orkestrasi terdesentralisasi menerapkan antrean tugas di mana agen mengambil tugas dan memposting hasil, serta mengarahkan tugas multi-bagian di antara mereka sendiri; mirip dengan sistem papan tulis. Solusi orkestrasi terdesentralisasi sangat kuat dan toleran terhadap kesalahan tetapi sulit untuk dirancang dan dipecahkan karena sistem menjadi lebih besar dengan kemampuan yang lebih besar.

Akhirnya, pendekatan orkestrasi hierarkis menggabungkan unsur-unsur pendekatan terpusat dan terdesentralisasi. Dalam orkestrasi hierarkis, orkestrator master digunakan untuk mengoordinasikan tindakan agen tingkat tinggi yang pada gilirannya dapat memanggil agen lain untuk menyelesaikan tugas-tugas kompleks. Ini mempertahankan banyak kemudahan manajemen dan kontrol dari pendekatan terpusat tetapi mengurangi potensi komponen kontrol pusat untuk menjadi hambatan pada volume permintaan tinggi dan/atau sejumlah besar agen.

Granularitas Agen

Granularitas agen AI mengacu pada kompleksitas tugas yang dapat dilakukan agen. Agen granularitas tinggi mungkin mampu melakukan banyak tugas atau sejumlah kecil tugas dengan detail yang sangat tinggi, sedangkan agen granularitas rendah mungkin hanya mampu menyelesaikan sejumlah kecil atau bahkan hanya satu tugas dengan tingkat detail yang rendah. Untuk memperjelas hal ini, pertimbangkan agen layanan pelanggan. Agen granularitas rendah mungkin hanya dapat menjawab pertanyaan sederhana tentang suatu produk (misalnya, “Apakah itu berwarna hitam?”) , sedangkan agen granularitas tinggi mungkin dapat memeriksa persediaan lokal dan mengatur untuk mengirimkan produk ke rumah pelanggan.

Perancang solusi agen harus memutuskan seberapa granular untuk membuat agen individu dalam sistem, misalnya, memiliki sejumlah kecil agen granularitas tinggi atau sejumlah besar agen granularitas rendah. Kemampuan luas agen granularitas tinggi datang dengan biaya kebutuhan sumber daya komputasi yang lebih besar dan waktu penyelesaian tugas yang lebih lama. Meskipun kurang mampu, fokus sempit agen granularitas rendah berarti mereka membutuhkan lebih sedikit sumber daya komputasi dan umumnya akan menyelesaikan tugas lebih cepat.

Sementara tingkat perincian yang 'tepat' masih belum diketahui, pengalaman awal menunjukkan pembuatan agen granularitas rendah yang selaras dengan proses bisnis yang terfokus, misalnya, Purchase_Order_Processing_Agent, menghasilkan keseimbangan yang baik antara persyaratan sumber daya, kecepatan pemrosesan, dan kompleksitas solusi. Agen granularitas rendah kemudian dapat dimasukkan ke dalam alur kerja statis, atau dipanggil oleh agen granularitas tinggi sebagai bagian dari proses yang lebih besar.

Alur Kerja Statis vs Dinamis

Perancang solusi AI agen harus mencapai keseimbangan antara agen yang mengikuti proses dan alur kerja statis yang telah ditentukan sebelumnya, dan memiliki alur kerja yang dihasilkan secara dinamis sebagai respons terhadap prompt pengguna. Meskipun tidak ada jawaban yang benar atau salah, arsitek disarankan untuk mempertimbangkan rekomendasi dan pertimbangan berikut:

• Alur kerja statis harus digunakan untuk proses bisnis yang terdiri dari beberapa langkah kompleks yang melintasi domain pengetahuan (mis. hukum dan akuntansi), atau yang tunduk pada pengawasan peraturan. Menggunakan alur kerja statis dalam hal ini memberikan beberapa manfaat bagi arsitek:

  • Alur kerja statis (relatif) mudah untuk diukur, dipantau, dan diaudit, dan alur kerja itu sendiri dapat digunakan sebagai bukti kepatuhan terhadap peraturan. Alur kerja yang dihasilkan secara dinamis lebih sulit untuk dipantau karena dieksekusi dan eksekusi proses individual harus direkonstruksi dari log agen individu. Alur kerja dinamis juga memiliki potensi untuk memvariasikan urutan tugas yang makin mempersulit pemantauan audit dan kepatuhan.
    
    
  • Memiliki proses serah terima yang jelas antara bidang keahlian yang berbeda memastikan pemisahan tanggung jawab yang jelas dan memudahkan untuk memastikan bahwa informasi yang diserahkan lengkap dan akurat. Meskipun hal yang sama dapat dicapai dengan alur kerja yang dihasilkan secara dinamis, hal ini membutuhkan lebih banyak perhatian dalam desain dan implementasi untuk mencapainya
    
    
• Alur kerja dinamis harus digunakan untuk aktivitas atau fungsi 'satu langkah' yang dilakukan dalam waktu yang berdekatan dan tidak melintasi domain pengetahuan serta pelaksanaannya tidak tunduk pada pengawasan atau kontrol regulasi.