Perluasan alat agen dan pengendalian sistem

Situasi yang umum adalah mengevaluasi sistem Agen. Hal pertama yang Anda lihat adalah “berapa banyak alat yang dapat diterima”.

Itu dapat memeriksa database, mengirim pesan, mengubah perintah kerja, menerbitkan skrip, dan mengoperasikan browser. Ini tentu saja lebih terlihat seperti sistem yang benar-benar berfungsi daripada model hanya obrolan. Jadi mudah bagi tim untuk mengambil arah ini: jika kita menghubungkan beberapa alat lagi, memberikan lebih banyak izin, dan membuat tautan lebih otomatis, sistem akan menjadi lebih kuat.

Masalahnya, menjadi kuat bukan berarti bisa dikendalikan.

Penilaian saya adalah: **Kemampuan pengendalian sistem Agen tidak bergantung pada jumlah alat, namun pada konvergensi status, batasan izin, dan fallback kegagalan. Ketika semakin banyak alat yang digunakan, konteks yang semakin panjang, dan semakin banyak efek samping dari tindakan, tanpa batasan dan mekanisme konvergensi yang jelas, sistem secara umum akan menjadi lebih sulit untuk diprediksi. **

Ada banyak alat, solusinya adalah jangkauan yang bisa dioperasikan; terkendali, solusinya adalah apakah hasilnya dapat ditahan

Solusi dari “adjustable tools” adalah Agen tidak lagi hanya memberikan saran, tetapi dapat mempengaruhi sistem sebenarnya secara langsung.

Ini adalah perluasan kapasitas, bukan isu palsu.

Namun begitu sistem ditingkatkan dari “menjawab pertanyaan” menjadi “melakukan tindakan”, fokus teknisnya pun berubah. Tidak perlu lagi menilai apakah konten keluaran terdengar seperti ucapan manusia, tetapi menilai:

• Apa sebenarnya yang dilakukannya kali ini;
• Lakukan gerakan ini dibandingkan gerakan lain yang lebih aman;
• Seberapa luas dampaknya jika melakukan kesalahan;
• Jika gagal di tengah, apakah sistem akan berhenti, mencoba lagi, atau meninggalkan setengah rangkaian efek samping?
• Jika permintaan serupa datang lagi, apakah akan mengambil jalur yang sama sekali berbeda?

Dengan kata lain, seiring bertambahnya jumlah alat, kompleksitasnya bergeser dari “masalah kebenaran teks” menjadi “masalah prediktabilitas perilaku sistem”.

Kedua jenis masalah ini besarnya tidak sama.

Model yang hanya bisa menjawab pertanyaan biasanya menimbulkan gangguan kognitif jika membuat kesalahan; jika Agen dapat menyesuaikan lebih dari selusin alat, sekali tidak ada batasan, jika membuat kesalahan maka akan terjadi gangguan tindakan, dan jika membuat kesalahan maka akan terjadi gangguan sistem.

Yang pertama kali lepas kendali sering kali adalah negara.

Banyak tim yang mengacaukan Agen, dan reaksi pertama adalah modelnya tidak stabil. Faktanya, banyak masalah yang berada di luar model.

Misalnya, proses yang umum:

• Agen terlebih dahulu memeriksa sistem perintah kerja dan mendapatkan tugas untuk diproses;
• Cari lagi basis pengetahuan untuk menemukan metode pembuangan historis;
• Kemudian panggil query database;
• Kirim pesan lain ke kelompok tugas;
• Tambahkan catatan pembuangan akhir.

Setiap langkah dalam tautan ini “masuk akal”, tetapi selama keadaan perantara tidak ditentukan dengan jelas, sistem akan segera menghadapi masalah berikut:

• Status perintah kerja berubah menjadi Sedang Diproses, namun pemberitahuan belum terkirim;
• Query database telah dijalankan, namun hasilnya belum dicatat dalam catatan akhir;
• Pesan telah terkirim ke grup, namun langkah selanjutnya gagal, namun dunia luar mengira masalah tersebut telah ditangani;
• Setelah jendela konteks terpotong, tidak diketahui tindakan mana yang telah dilakukan sebelumnya ketika eksekusi putaran kedua dilanjutkan.

Ini adalah sistem tidak memiliki mekanisme konvergensi negara.

Agen yang dapat melakukan tindakan tanpa mesin status tugas yang jelas pada dasarnya hanya merangkai efek samping multi-langkah pada inferensi bahasa alami.

Ini terlihat bagus dalam demo, namun sulit diterapkan dalam produksi.

Batasan izin tidak jelas, dan Agen dapat dengan mudah berubah dari “mampu melakukan sesuatu” menjadi “melakukan terlalu banyak hal”

Kesalahpahaman umum lainnya adalah menganggap akses alat sebagai inventaris kemampuan.

Hubungkan ke browser dan berikan akses ke latar belakang apa pun; Saat terhubung ke Shell, sebagian besar perintah dapat dijalankan secara default; Saat terhubung ke sistem pesan, Anda dapat secara proaktif memberi tahu grup mana pun secara default; Hubungkan ke database dan berikan izin baca dan tulis campuran.

Di permukaan, hal ini membuat Agen lebih fleksibel, namun pada kenyataannya ia mengandalkan pengendalian sistem untuk menghindari kesalahan dalam satu inferensi.

Hal ini berbahaya karena risiko agen adalah bahwa ia akan memanggil alat dengan efek samping yang tinggi dalam konteks yang wajar secara lokal namun salah secara global.

Misalnya:

• Saya seharusnya memeriksa statusnya, tetapi malah menjalankan skrip perbaikan;
• Seharusnya hanya membalas pengguna saat ini, tetapi pemberitahuan dikirim ke grup;
• Seharusnya hanya membaca data, tetapi antarmuka pembaruan dipanggil;
• Tindakan ini seharusnya hanya dilanjutkan setelah peninjauan oleh manusia, namun “tindakan yang disarankan” langsung diubah menjadi “tindakan yang dijalankan”.

Oleh karena itu, fokus desain batas izin adalah untuk memisahkan tindakan dengan efek samping tinggi dari alasan ketidakpastian tinggi.

Jika suatu tindakan akan menyebabkan kerusakan nyata jika salah satu kali, tindakan tersebut tidak boleh ditempatkan di lapisan otomatisasi yang sama dengan tindakan kueri biasa.

Dengan lebih banyak alat yang terorganisir, kegagalan bukan lagi sekedar “kesalahan”, tetapi keadaan setengah selesai.

Tentu saja, sistem perangkat lunak biasa juga gagal, namun kegagalan sistem Agen mempunyai masalah tambahan: seringkali merupakan kegagalan setengah total di seluruh alat, sistem, dan batasan semantik.

Misalnya:

1. Pertama buat tugas pemrosesan di Jira;
2. Buka Slack untuk mengirim notifikasi;
3. Sesuaikan API internal untuk menarik log lagi;
4. Terakhir tulis ringkasannya kembali ke basis pengetahuan.

Apa yang harus dilakukan sistem jika langkah ketiga gagal?

• Kembalikan tugas Jira? -Hapus notifikasi yang baru saja dikirim?
• Tugas dipertahankan tetapi pemrosesan tanda terganggu?
• Biarkan Agen lain mengambil alih?

Pendekatan yang paling tabu di sini adalah memahami “penanganan kegagalan” sebagai menanyakan model lagi.

Karena banyak kegagalan yang sudah merupakan efek samping. Yang sebenarnya dibutuhkan adalah:

• Langkah mana yang dapat dicoba ulang;
• Langkah mana yang harus idempoten;
• Langkah mana yang hanya dapat dilanjutkan setelah konfirmasi manual;
• Tindakan eksternal manakah yang harus meninggalkan jejak audit;
• Setelah suatu tautan terputus, di manakah tautan tersebut akan disambungkan kembali saat tautan tersebut dipulihkan lagi?

Jika ini tidak ditentukan, Agen tampaknya melakukan otomatisasi, namun sebenarnya membuat pekerjaan manual setelahnya.

Inti dari pengendalian terletak pada “akankah ia bertemu?”

Saya semakin cenderung menganggap sistem Agen sebagai sistem alur kerja dengan kemampuan penalaran, daripada portal serba bisa yang dapat mengobrol.

Artinya saat mendesainnya, hal pertama yang harus dijawab adalah:

• Apakah tugas sudah jelas dimulai, diproses, menunggu konfirmasi, selesai, atau berstatus gagal;
• Alat mana yang boleh dipanggil di setiap negara bagian;
• Hasil mana yang bisa disampaikan langsung dan mana yang harus dikaji ulang;
• Setelah konteksnya hilang, dapatkah sistem pulih dari keadaan eksternal alih-alih mengandalkan penarikan kembali model;
• Apakah terdapat catatan input, output, dan eksekusi yang dapat dipertanggungjawabkan untuk setiap tindakan.

Hal-hal ini kedengarannya tidak seksi, tetapi menentukan apakah Agen adalah sistem yang dapat ditingkatkan secara bertahap, atau mainan yang hanya dapat didemonstrasikan di sudut-sudut berisiko rendah.

Standar penilaian yang sangat sederhana adalah: **Jika Anda mengubah model untuk sementara ke tingkat yang lebih lemah, efisiensi sistem hanya akan menurun; jika mesin negara, batasan izin, dan mekanisme rollback dihilangkan, sistem tidak akan dapat langsung online. **

Hal ini menunjukkan bahwa landasan sebenarnya adalah kemampuan konvergensi sistem.

Contoh balasan yang umum: memperlakukan Agen sebagai koordinator universal

Banyak platform internal yang pada akhirnya akan tumbuh menjadi sesuatu yang sangat mirip dengan “platform tengah AI”:

• Hubungkan ke sistem apa pun;
• Saya ingin menerima permintaan apa pun;
• Cobalah untuk menyelesaikan semua tindakan secara otomatis; – Saya pikir selama saya membuat kata-kata cepatnya sedikit lebih detail, saya bisa menekan risikonya.

Masalah terbesar dengan rute ini adalah kompleksitas marjinalnya yang sangat buruk.

Karena semakin banyak jenis permintaan, semakin kompleks semantik alatnya, dan semakin besar jumlah kombinasi jalur keberhasilan dan jalur kegagalan. Awalnya saya hanya perlu “memeriksa catatan rilis”, tapi kemudian menjadi:

• Periksa catatan;
• Penilaian kelainan;
• Putuskan apakah akan memutar kembali;
• Kirim pemberitahuan;
• Ubah status;
• Hasilkan ulasan;
• Basis pengetahuan yang diperbarui.

Sepertinya loop tertutup otomatis yang lengkap. Faktanya, dengan setiap langkah tambahan, sistem menambahkan lapisan konsistensi efek samping dan biaya interpretasi izin.

Pada akhirnya, yang sering menyita waktu tim adalah:

• Langkah ini akan dijalankan dengan sendirinya;
• Masalah yang sama mengambil jalan yang berbeda hari ini dan kemarin;
• Sistem eksternal telah diubah, tetapi catatan internal tidak dipertahankan;
• Setelah kecelakaan, sulit untuk memulihkan apa yang diandalkan Agen saat itu.

Hal ini berarti menyerahkan terlalu banyak tindakan dengan ketidakpastian tinggi ke dalam proses penalaran yang tidak memiliki batasan. **

Pendekatan yang lebih stabil adalah dengan otomatisasi lapisan daripada menumpuk alat secara datar.

Jika Anda benar-benar ingin membuat sistem Agen dapat dikontrol, saya sarankan untuk melapisinya berdasarkan risiko dan efek samping:

1. Lapisan risiko rendah: kueri dan ringkasan

Pertama-tama biarkan Agen melakukan pembacaan, pengambilan, ringkasan, dan penyusunan.

Sekalipun penilaian tindakan ini tidak sempurna, biasanya tidak secara langsung mengubah keadaan eksternal, dan lebih cocok untuk menambah jumlahnya terlebih dahulu.

2. Lapisan risiko menengah: tindakan satu langkah dengan batasan

Misalnya, Anda hanya bisa mengubah bidang dalam status perintah kerja tertentu, Anda hanya bisa membalas sesi saat ini, dan Anda hanya bisa melakukan operasi dalam daftar yang diizinkan secara eksplisit.

Kuncinya di sini adalah memampatkan ruang tindakan menjadi cukup sempit agar biaya kesalahan dapat diterima.

3. Lapisan risiko tinggi: persetujuan eksplisit dan eksekusi rollback

Setiap kali penghapusan data, operasi batch, penulisan lintas sistem, pemberitahuan keluar, dan eksekusi skrip lingkungan produksi terlibat, mekanisme peninjauan manusia, audit, dan rollback harus diutamakan, daripada dibiarkan begitu saja.

Agen yang benar-benar matang tahu apa yang harus dilakukan secara otomatis, apa yang hanya bisa disarankan, dan apa yang tidak boleh dilakukan secara langsung.

Batasan yang berlaku

Artikel ini terutama membahas:

• Agen internal yang terhubung ke beberapa alat;
• Agen berbasis proses dengan efek samping eksternal yang nyata;
• Skenario orkestrasi yang melibatkan operasi lintas sistem seperti pesan, perintah kerja, database, skrip, browser, dll.

Jika Agen masih terjebak dalam tugas-tugas dengan efek samping rendah seperti “membantu pengguna meringkas halaman web” dan “membantu merancang respons layanan pelanggan”, memiliki lebih banyak alat belum tentu langsung menyebabkan hilangnya kendali, karena sebagian besar kesalahan masih berada di lapisan teks.

Masalah sebenarnya muncul ketika sistem mulai mengubah keadaan eksternal secara langsung. Pada saat itu, kami sudah menghadapi desain terbatas bergaya sistem terdistribusi.

Ringkasan

Agen dapat memanggil lebih banyak alat, yang tentunya akan membuat sistem lebih berguna.

Namun “lebih bermanfaat” dan “lebih terkendali” bukanlah kata-kata yang memiliki arah yang sama.

Ketika kompleksitas tindakan, efek samping, dan konteks meningkat secara bersamaan, yang benar-benar menentukan batas atas sistem sering kali adalah apakah status aktivasi dapat dikonvergensi, apakah batasan izin jelas, dan apakah aktivasi dapat dihentikan dan dipulihkan secara stabil setelah kegagalan.

Jika tidak, semakin banyak alat yang terhubung, sistem akan semakin menjadi seperti seorang eksekutif dengan kemampuan yang kuat namun sulit diprediksi.