Pouzdanost AI agenata: Zašto konačni odgovor nije dovoljan

Tačan izlaz ne dokazuje ispravno rasuđivanje, bezbedno izvršavanje ili pouzdan sistem.

Godinama je evaluacija veštačke inteligencije bila dominirana naizgled jednostavnim pitanjem: Da li je odgovor bio tačan? Za ćaskbot to ponekad može biti dovoljno. Za agenta sposobnog da pretražuje sisteme, čita podatke, poziva alate, menja stanje, izvršava tokove posla, piše datoteke, komunicira sa API-jima ili donosi odluke, to nije.

Agent može proizvesti tačan konačni odgovor dok na putu do njega čini više stvari pogrešno. Može koristiti pogrešan izvor, pogrešno razumeti instrukciju i kasnije nadoknaditi grešku, pristupiti nepotrebnim informacijama, izvršiti neovlašćenu međukorak, tiho se oporaviti od greške koja je trebala da pokrene eskalaciju, ili ostaviti iza sebe sporedne efekte koje niko nije primetio.

To stvara jedan od centralnih problema agentske veštačke inteligencije: tačan ishod ne dokazuje tačnu putanju.

Iluzija ishoda

Tradicionalni softver nam daje intuitivni model ispravnosti. Ulaz ulazi u deterministički ili uglavnom deterministički sistem, logika se izvršava, izlaz se proizvodi, a testovi proveravaju očekivano ponašanje. Sistemi zasnovani na LLM-u slabe ovu pretpostavku. Agentski sistemi idu i dalje.

• interpretacija modela
• preuzeti kontekst
• izbor alata
• međuopažanja
• spoljašnje stanje
• prethodne radnje
• planovi koje generiše model
• granice dozvola
• ponovni pokušaji i rezervno ponašanje
• interakcija sa ljudima

Dva izvršavanja koja počinju od gotovo identičnih ulaza mogu doći do istog rezultata kroz veoma različite puteve. Ako evaluacija posmatra samo konačni izlaz, veći deo sistema ostaje nevidljiv.

Zamislite da agent veštačke inteligencije dobije instrukciju: Ažuriraj adresu za naplatu kupca. Adresa se na kraju ispravno ažurira. Konvencionalna evaluacija bi mogla klasifikovati zadatak kao uspešan.

1. Agent pretražuje nekoliko nepovezanih evidencija kupaca.
2. Preuzima više ličnih podataka nego što je potrebno.
3. U početku menja pogrešan nalog.
4. Primećuje grešku.
5. Poništava promenu.
6. Ažurira ispravan nalog.
7. Prijavljuje uspeh.

Konačno stanje: ispravno. Ponašanje sistema: neprihvatljivo. Benchmark koji se zasniva samo na ishodu daje ovom izvršavanju prolaz. Sistem za osiguranje proizvodnje ne bi trebalo.

Putanja je deo proizvoda

Zato putanja agenta veštačke inteligencije mora postati prvoklasni inženjerski objekat. Putanja je niz relevantnih stanja i radnji između originalnog zahteva i konačnog rezultata.

Namera → Kontekst → Odluka → Alat → Radnja → Opažanje → Odluka → Promena stanja → Rezultat

Zachary J. Stevens razvija ovu ideju u Putanja je sistem, tvrdeći da agentska evaluacija mora prevazići konačni odgovor i ispitati kompletan put radnji kroz promenljivo okruženje.

Tačan ishod ne opravdava neprihvatljivu putanju.— Zachary J. Stevens, Putanja je sistem

Razlika je izuzetno važna. Pouzdanost stoga nije jednostavno tačan izlaz. Ona je bliža prihvatljivom ishodu + prihvatljivoj putanji + mogućnosti oporavka + dokazima.

Tačan odgovor može sakriti pokvaren sistem

Većina evaluacija zasnovanih na merilima snažno nagrađuje A i B, a kažnjava C i D. Operativno, međutim, B može biti opasniji od C. Agent C može prepoznati neizvesnost, zaustaviti izvršenje i zatražiti ljudski pregled. Agent B može sa samopouzdanjem proizvesti tačne rezultate dok krši pretpostavke koje niko ne nadgleda.

uspešan izlaz → povećano poverenje → šire dozvole → više automatizacije → veći radijus eksplozije

Potrebni su nam dokazi, ne samopouzdanje

Jedna od najvećih grešaka u usvajanju veštačke inteligencije je tretiranje samopouzdanja modela, zadovoljstva korisnika ili istorijske stope uspeha kao dokaza pouzdanosti sistema. Oni nisu ekvivalentni.

• Šta je agent primio?
• Koji kontekst je preuzeo?
• Koje alate je pozvao?
• Zašto je radnja bila dozvoljena?
• Koje stanje je postojalo pre radnje?
• Šta se promenilo?
• Koji su međuotkazi nastali?
• Da li je nešto ponovljeno?
• Da li je bilo potrebno ljudsko odobrenje?
• Da li je izvršenje moglo biti zaustavljeno?
• Može li se radnja poništiti?
• Koji model, prompt i verzije alata su bili uključeni?

Bez ovih odgovora, ne postoji ozbiljno operativno osiguranje. Postoji samo izlaz. Opservabilnost i dokazi stoga moraju biti projektovani u arhitekturu agenta, a ne dodati nakon implementacije.

Vođenje evidencije nije isto što i kontrola

Organizacije često odgovore: Sve se evidentira. Dobro. Ali samo evidentiranje ne kontroliše ništa. Evidencija vam govori šta se dogodilo. Kontrola određuje da li nešto može da se dogodi.

Agent zahteva DELETE /customer/123 ↓
Radnja evidentirana ↓
DELETE izvršen

To pruža opservabilnost. Uporedite to sa:

Agent zahteva DELETE /customer/123 ↓
Procena politike ↓
Trenutni identitet verifikovan ↓
Trenutni parametri radnje provereni ↓
Prag rizika procenjen ↓
Ljudsko odobrenje ako je potrebno ↓
Radnja izvršena ↓
Rezultat verifikovan ↓
Dokazi sačuvani

Sada se približavamo kontrolnom sistemu. Razlika je arhitektonska, a ne kozmetička.

Dozvola je neophodna — ali nije osiguranje

Pretpostavimo da agent ima dozvolu da šalje e-poštu. Kontrola pristupa odgovara: Može li ovaj agent slati e-poštu? Ne odgovara: Da li ovaj konkretan e-mail treba poslati ovoj konkretnoj osobi sa ovim konkretnim prilogom upravo sada?

KONTROLA SPOSOBNOSTI
Šta je agentu tehnički dozvoljeno da uradi? + OSIGURANJE RADNJE
Da li je ova konkretna radnja prikladna u trenutnom stanju?

RBAC, OAuth opsezi, API dozvole i identiteti agenata definišu prostor mogućih radnji. Oni ne dokazuju da je radnja unutar tog prostora prikladna. Snažna arhitektura agenta zahteva oba sloja.

Prvi pogrešan korak je važan

Kada agent ne uspe, konačna netačna radnja često nije mesto gde je neuspeh počeo. Pravi neuspeh se možda dogodio mnogo ranije.

Pogrešno pretraživanje ↓
Pogrešna pretpostavka ↓
Uverljivo zaključivanje ↓
Važeći poziv alata ↓
Pogrešna radnja

Ako istražujemo samo konačnu radnju, popravljamo simptom. Ako pregledamo putanju, možemo identifikovati prvi pogrešan korak. To pretvara nepripisiv neuspeh u konkretan inženjerski problem.

Testiranje agenata mora prevazići testiranje promptova

Promptovi su važni, ali ponašanje agenta u produkciji proizilazi iz celog sistema.

MODEL
+
SISTEMSKI PROMPT
+
KONTEKST
+
MEMORIJA
+
PRETRAŽIVANJE
+
ALATI
+
DOZVOLE
+
RADNI TOK
+
SPOLJNO STANJE
+
KONTROLNA LOGIKA

Promena bilo kojeg od ovih može promeniti putanju. Stoga, verzionisanje samo prompta nije dovoljno.

model_version
prompt_version
tool_version
policy_version
retrieval_version
workflow_version
environment_state
execution_id

Kriterijumi prihvatanja za agente moraju uključivati ponašanje

Tradicionalni kriterijumi prihvatanja često izgledaju ovako: Dato X, sistem proizvodi Y. Za agentske sisteme, to je nepotpuno. Kriterijumi prihvatanja treba da definišu i ograničenja na putanji.

Ishod

Adresa kupca je ispravno ažurirana.

Autorizacija

Agent menja samo eksplicitno izabranog kupca.

Pristup podacima

Nijedan nepovezan zapis o kupcu nije pristupljen.

Alati

Koriste se samo odobrene CRM operacije.

Verifikacija

Nova adresa se čita i poredi sa traženom vrednošću.

Neuspeh

Dvosmisleno razrešavanje identiteta zaustavlja izvršenje.

Ljudski autoritet

Čovek može odbiti modifikaciju pre izvršenja kada pragovi rizika zahtevaju odobrenje.

Dokaz

Izvršenje ostavlja trag dovoljan za rekonstrukciju odluke i prelaza stanja.

Oporavak

Prethodna vrednost ostaje povratna.

Čovek-u-petlji nije dovoljan

Dodavanje polja za ljudsko odobrenje ne rešava problem automatski. Čovek može kontrolisati agenta samo ako ima vidljivost, autoritet, vreme, kontekst i mogućnost oporavka.

• Vidljivost: dovoljno informacija da se razume šta se dešava.
• Autoritet: stvarna sposobnost da se zaustavi ili izmeni akcija.
• Vreme: intervencija pre nego što se posledica dogodi.
• Kontekst: dovoljno dokaza za donošenje odluke.
• Mogućnost oporavka: sposobnost da se akcija poništi ili popravi.

Korisnik koji klikne Odobri na nešto što ne može smisleno da pregleda nije snažno upravljanje. To je pozorište odobravanja.

Povratak mora postati izvorna AI sposobnost

Tradicionalno uvođenje softvera nas je naučilo nečemu vrednom: Nikada ne uvodi ono što ne možeš vratiti. Trebalo bi da primenimo isti princip na agentske akcije.

REVERZIBILNO
Može se automatski poništiti. KOMPENZABILNO
Ne može se direktno poništiti, ali se može izvršiti kompenzaciona akcija. NEOPOZIVO
Ne može se pouzdano vratiti prethodno stanje.

Što je veća nepovratnost, to bi zahtev za kontrolom trebalo da bude jači.

Čitanje javnog dokumenta → niska posledica
Kreiranje nacrta → povratno
Izmena CRM zapisa → povratno ali sa posledicama
Slanje spoljnog imejla → praktično nepovratno
Prenos novca → visoka posledica
Brisanje podataka iz produkcije → potencijalno katastrofalno

Agentu je potrebna kontrolna ravan

KORISNIK / SISTEMSKA NAMERA │ ▼ AI AGENT │ predložena akcija │ ▼ ┌───────────────────┐ │ KONTROLNA RAVAN │ ├───────────────────┤ │ Identitet │ │ Autorizacija │ │ Politika │ │ Rizik │ │ Stanje │ │ Dokazi │ │ Ljudski autoritet │ │ Povratak │ └───────────────────┘ │ odobreno? / \ NE DA │ │ STOP ▼ ALAT │ ▼ PROMENA STANJA │ ▼ VERIFIKACIJA

LLM treba da predlaže. Kontrolna ravan treba da upravlja. Ta podela je ključna. Model ne bi trebalo da bude krajnji autoritet koji određuje da li je njegova sopstvena predložena akcija sa visokim uticajem bezbedna.

Od benčmarka do operativnog poverenja

Benčmarkovi ostaju korisni. Oni nam govore o sposobnosti, porede modele, otkrivaju regresije i pomažu u proceni očekivanih performansi. Ali procena sposobnosti i operativno poverenje odgovaraju na različita pitanja.

Benčmark pita: Da li sistem može ovo da uradi? Operativno osiguranje pita: Da li možemo da dozvolimo sistemu da ovo uradi ovde, pod ovim uslovima, sa ovim dozvolama i posledicama?

Pouzdanost treba meriti kao svojstvo sistema

1. Ispravnost ishoda: Da li je sistem proizveo očekivani rezultat?
2. Ispravnost putanje: Da li je pratio prihvatljiv put?
3. Integritet kontrole: Da li su poštovane granice autorizacije, politike i intervencije?
4. Oporavljivost: Da li se kvarovi mogu ograničiti, preokrenuti ili popraviti?
5. Kompletnost dokaza: Da li se izvršenje može rekonstruisati i revidirati?

Operativna pouzdanost
=
Ishod × Putanja × Kontrola × Oporavljivost × Dokazi

Množenje je namerno. Ako jedna kritična dimenzija teži nuli, visok rezultat na drugom mestu ne bi trebalo da to sakrije. Savršeno ispravan izlaz sa nultim integritetom autorizacije nije sistem sa 80% pouzdanosti. To je neprihvatljivo izvršenje koje je slučajno proizvelo tačan odgovor.

Uspeh je ponekad najopasniji neuspeh

Neuspesi privlače pažnju. Uspeh često ne. Zato su uspešne ali nekontrolisane putanje agenta posebno opasne. Očigledan neuspeh stvara incident. Skriveni defekt putanje stvara poverenje. A poverenje proširuje autonomiju.

Organizacije stoga ne bi trebalo samo da istražuju Zašto je agent zakazao? One bi trebalo periodično da se pitaju: Zašto je agent uspeo? Da li je uspeo zato što je arhitektura pouzdano ograničila i verifikovala izvršenje, ili zato što ovaj put ništa nije pošlo naopako?

Zaključak

Industrija se brzo kreće od AI koji odgovara ka AI koji deluje. Ta tranzicija menja značenje pouzdanosti. Za sistem odgovora, procena odgovora često može biti dovoljna. Za sistem akcije, moramo proceniti putanju.

Prompt ↓
Odgovor postaje namera ↓
Putanja ↓
Akcije ↓
Promene stanja ↓
Dokazi ↓
Ishod

Konačan odgovor ostaje važan, ali on je samo vidljivi kraj mnogo većeg sistema. Kada se AI-u dozvoli da utiče na stvarni svet, put do odgovora postaje deo odgovora.