Evaluați un agent AI după instrumentele pe care le poate apela
Înainte să dați unui agent AI acces la datele firmei, verificați permisiunile, validarea cererilor, repetarea operațiilor și aprobarea acțiunilor exacte.
De 
Paul. AI și programare cu agenți
Cea mai relevantă parte a unei propuneri pentru un agent AI este lista instrumentelor disponibile. O demonstrație arată ce a făcut modelul o dată. Lista arată ce îi permite aplicația să încerce din nou, inclusiv când înțelege greșit cererea sau întâlnește informații externe care îl induc în eroare.
O integrare pentru firmă ar trebui să trateze fiecare apel propus ca pe o cerere venită de la un apelant în care nu poate avea încredere. Permisiunile și regulile afacerii se verifică în afara modelului. Acțiunile se delimitează clar, iar cele ireversibile care pot afecta firma cer aprobare umană. Un model mai bun poate fi mai util, fără să înlocuiască aceste limite.
Capacitatea modelului și dreptul de a acționa
Anthropic a anunțat disponibilitatea generală a utilizării instrumentelor în Claude la 30 mai 2024. Interacțiunea cu instrumente externe, dirijată de model, devenea o funcție oferită oficial. Acest moment istoric nu dovedește că o anumită integrare de afaceri era pregătită să funcționeze fără supraveghere.
Pentru instrumentele executate de aplicația client, documentația actuală separă cererea modelului de execuție. Modelul propune apelul, iar codul aplicației execută operația și transmite rezultatul. Firma are, așadar, un loc în care poate aplica regulile înainte să se schimbe ceva.
Acela este punctul în care trebuie impuse permisiunile. Instrucțiunea „rambursați doar comenzile aprobate” îi spune modelului ce să facă. Verificarea dreptului utilizatorului de a rambursa și a stării curente a comenzii impune efectiv regula în server. Ambele pot fi utile, dar îndeplinesc roluri diferite.
Instrumente numite după acțiunile firmei
Luați drept exemplu ipotetic un asistent pentru comenzi. Un instrument care acceptă instrucțiuni arbitrare pentru baza de date lasă modelului multă libertate. Operații separate pentru găsirea unei comenzi, pregătirea unei rambursări și executarea rambursării aprobate fac activitatea mai ușor de verificat.
Denumirea precisă nu ajunge. Implementarea trebuie să stabilească firma și identitatea persoanei din contextul autentificat, fără să creadă un identificator de firmă furnizat de model. Trebuie să verifice și că acea comandă aparține firmei. Un număr de comandă cu format corect nu dovedește dreptul de acces.
Și instrumentele de citire cer limite. Întregul istoric al unui client poate dezvălui mult mai mult decât cere o întrebare despre starea comenzii. Limitați câmpurile și înregistrările la sarcina respectivă. Stabiliți ce conținut poate fi transmis furnizorului modelului. Accesul doar pentru citire reduce unele consecințe, fără să transforme datele confidențiale în informații publice.
Textul extern trebuie tratat tot ca informație în care nu aveți încredere. O notă dintr-o comandă poate conține instrucțiuni adresate asistentului. Ea trebuie să rămână o informație despre comandă. Permisiunile aplicației trebuie să se aplice și dacă modelul interpretează acea notă drept instrucțiune.
Repetarea cererii nu trebuie să dubleze tranzacția
Expirarea timpului de așteptare lasă o incertitudine: operația poate să fi reușit, deși agentul nu a primit rezultatul. Repetarea unei rambursări sau a unui e-mail către client poate dubla acțiunea.
Pentru modificări, definiți un identificator stabil al operației și păstrați rezultatul. Repetarea aceleiași cereri ar trebui să întoarcă rezultatul existent, dacă integrarea permite această garanție. Identificatorul trebuie păstrat la reîncercare. Unul nou la fiecare apel anulează mecanismul.
Nu promiteți că o acțiune se execută exact o dată în sisteme independente doar fiindcă o funcție locală memorează un identificator. Serviciul extern poate confirma modificarea înainte ca aplicația locală să înregistreze succesul. Proiectul are nevoie de o metodă de clarificare a rezultatului incert sau de oprirea operației și solicitarea intervenției unui om.
Acesta este un scenariu util de acceptare: cereți furnizorului să descrie ce se întâmplă dacă legătura cade după ce sistemul extern a acceptat acțiunea. Un răspuns credibil precizează ce sistem stabilește rezultatul oficial și cum se verifică starea. Un nou mesaj de succes nu dovedește că acțiunea a avut loc o singură dată.
Aprobarea trebuie legată de detalii exacte
„Cereți acordul înainte de trimitere” lasă detalii importante neprecizate. Persoana care aprobă trebuie să vadă destinatarul, conținutul și consecința relevantă pentru firmă. Aplicația trebuie să lege acordul de aceste detalii exacte.
Dacă modelul schimbă ulterior destinatarul sau suma, aprobarea anterioară nu ar trebui să permită execuția. Dacă se modifică între timp comanda, verificați din nou dacă acordul mai este valabil. Expirarea aprobării și verificarea stării curente reduc riscul executării unei instrucțiuni depășite.
Nu orice modificare cere aceeași procedură. Salvarea unei ciorne interne, ușor de anulat, poate urma o cale mai simplă decât transferul banilor sau trimiterea datelor confidențiale în afara firmei. Regula trebuie să țină cont de consecință și de posibilitatea recuperării. Și anularea are limite: ștergerea unui mesaj trimis nu șterge ce a citit destinatarul.
Dovezi utile, fără o nouă expunere a datelor
Păstrați suficiente informații pentru a reconstitui cine a cerut acțiunea, ce instrument a fost apelat, ce decizie de autorizare s-a luat și ce rezultat s-a confirmat. Legați aprobarea de identificatorul operației. Distingeți cererile propuse, cele respinse și modificările reușite, astfel încât persoana responsabilă să le poată deosebi.
Evitați copierea tuturor documentelor sau secretelor în jurnal. Limitați accesul și perioada de păstrare după sensibilitatea și scopul înregistrării. Un jurnal care expune aceleași date mai multor persoane creează încă o problemă de administrat.
Cel mai puternic contraargument este viteza livrării. Un prototip poate arăta valoare înainte să existe toate permisiunile, iar un asistent pentru ciorne interne poate fi util cu măsuri limitate. Păstrați-l într-un mediu restrâns, cu drepturi restrânse. Extindeți drepturile când aplicația poate explica eșecurile la fel de clar ca reușitele.
Când evaluați o propunere de agenți AI, cereți catalogul instrumentelor. Parcurgeți o cerere respinsă, una repetată și o acțiune ireversibilă aprobată. Sunt cerințe de proiectare care trebuie verificate în proiect. Ele arată dacă în spatele conversației există un sistem prin care firma controlează acțiunile.