Većina softverskih timova već zna kako umjetnoj inteligenciji zadati zadatak: sažeti ovaj dokument, napisati test, objasniti pogrešku, sastaviti upit. Vrjedniji je pomak postaviti drugačije pitanje: kako sustav umjetne inteligencije može istaknuti posao koji zaslužuje pozornost prije nego što ga netko izričito zatraži?

To je razlika između izvršitelja zadataka i generatora uvida. Izvršitelj zadataka čeka upit. Generator uvida promatra odobrene signale, povezuje relevantan kontekst i daje preporuku koju osoba može provjeriti i prema njoj djelovati.

Za programere i tehnološke lidere to nije obećanje autonomnih softverskih odjela. To je disciplina dizajna za olakšavanje pronalaženja, procjene i korištenja operativnog znanja.

Krenite od odluka, a ne od osobnosti agenata

„Izgradite agenta” samo po sebi nije koristan zahtjev. Počnite s ponavljajućom odlukom koja je trenutačno spora, opterećena šumom ili ovisna o raspršenim informacijama.

Razmotrite tim za održavanje usluge koji istražuje porast neuspjelih pozadinskih poslova. Pomoćnik usmjeren na zadatke može odgovoriti: „Kako mogu pregledati red čekanja?” Sustav usmjeren na uvide može povezati metapodatke nedavne implementacije, kategorije pogrešaka, dubinu reda čekanja i smjernice iz priručnika za postupanje, a zatim iznijeti sažet nalaz: obrazac neuspjeha počeo je nakon promjene konfiguracije, utječe na jednu vrstu posla i ima dvije predložene sljedeće provjere.

Rezultat nije „agent je popravio produkciju”. To je ograniženo izvješće povezano s dokazima koje smanjuje vrijeme utrošeno na prikupljanje konteksta.

• Odluka: O čemu bi netko trebao odlučiti ili što bi trebao istražiti ranije?
• Signali: Koji odobreni sustavi pružaju potrebne dokaze?
• Publika: Tko može potvrditi rezultat i poduzeti radnju?
• Radnja: Koji siguran sljedeći korak slijedi iz uvida?
• Mjera: Kako će tim znati da je sustav koristan?

Ovo uokviravanje izbjegava čest način neuspjeha: izgradnju razgovornog omotača oko podataka koji ne poboljšava nijedan stvarni tijek rada.

Dajte agentu usku operativnu granicu

Agent postaje koristan kada može kombinirati dohvaćanje, zaključivanje i pažljivo ograničene radnje. Postaje rizičan kada su njegove dozvole, upute i uvjeti za zaustavljanje nejasni.

Definirajte njegovu operativnu granicu jednako promišljeno kao što biste definirali API ugovor. Agent treba znati koje izvore smije čitati, koje alate smije pozivati, što mora citirati u izlazu i kada mora stati i zatražiti ljudski pregled.

Odvojite promatranje od intervencije

Rane integracije agenata obično bi trebale biti samo za čitanje. Dopustite sustavu da analizira zapise o incidentima, dohvaća relevantnu dokumentaciju, uspoređuje bilješke o izdanjima ili označava praznine u zahtjevu za promjenu. To stvara vrijednost, a posljedice ostaju reverzibilne.

Tek kasnije trebali biste razmotriti radnje poput otvaranja tiketa, ažuriranja polja statusa ili pripreme zahtjeva za povlačenje. Čak i tada koristite izričite točke odobrenja. Agent može pripremiti radnju, ali odgovorni vlasnik trebao bi odobriti značajne promjene.

agent:
  allowed_reads:
    - service_metrics
    - deployment_records
    - approved_runbooks
  allowed_writes:
    - draft_incident_note
  requires_human_approval:
    - create_ticket
    - modify_configuration
    - deploy_service
  stop_conditions:
    - missing_evidence
    - conflicting_sources
    - permission_error

To nije birokracija. Jasne granice olakšavaju testiranje, reviziju i poboljšavanje ponašanja.

Oblikujte izlaze za provjeru

Proza koju generira umjetna inteligencija može zvučati samouvjereno čak i kada joj je temelj slab. Tečan odgovor tretirajte kao sučelje, a ne kao dokaz. Koristan operativni uvid trebao bi učiniti svoju osnovu vidljivom.

Snažan je obrazac zahtijevati od agenta da razlikuje činjenice, zaključke i preporuke. Činjenice dolaze iz imenovanih izvornih zapisa. Zaključci objašnjavaju vjerojatan odnos i navode neizvjesnost. Preporuke utvrđuju sljedeću provjeru ili radnju niskog rizika.

• Uočeno: „Broj događaja s pogreškom povećao se za ovu vrstu posla nakon zabilježene promjene konfiguracije.”
• Zaključak: „Vrijeme upućuje na to da bi promjena mogla biti povezana, ali dostupni zapisi ne utvrđuju uzročnost.”
• Sljedeći korak: „Usporedite učinkovitu konfiguraciju na radniku s neuspjehom s radnikom za kojeg je poznato da radi ispravno.”

Ta struktura pomaže recenzentima osporiti pravi dio rezultata. Mogu ispraviti činjenicu koja nedostaje bez rasprave o stilu proze ili odbaciti zaključak bez odbacivanja cijelog izvješća.

Namjerno oblikujte dohvaćanje konteksta

Mnogi razočaravajući projekti agenata zapravo su problemi s kontekstom. Model možda jest sposoban, ali prima zastarjelu dokumentaciju, duplicirane zapise, dvosmislenu terminologiju ili previše nerelevantnog materijala.

Izgradite sloj za dohvaćanje oko pitanja na koja agent mora odgovoriti. Dajte prednost autoritativnim, održavanim izvorima. Uključite identifikatore, vremenske oznake, vlasništvo i pravila pristupa. Dohvaćeni kontekst zadržite dovoljno usmjerenim da recenzent može razumjeti zašto je odabran.

Na primjer, pomoćniku za pregled koda ne treba svaki dokument na inženjerskom wikiju. Možda će mu trebati izmijenjene datoteke, konvencije repozitorija, relevantni testovi, ugovor sučelja usluge i povezani problem. Više konteksta nije automatski bolji kontekst.

Kada se izvori ne slažu, agent bi trebao prijaviti sukob umjesto da tiho odabere najprikladniju verziju. U produkcijskom radu neizvjesnost je često najvažniji uvid.

Gradite za neuspjeh prije gradnje za razmjer

Agenti komuniciraju sa sustavima kojima istječe vrijeme, vraćaju nepotpune podatke, mijenjaju formate i provode dozvole. Njihovi tijekovi rada trebaju uobičajene inženjerske zaštite: ponovne pokušaje ondje gdje je ponovno pokušavanje sigurno, vremenska ograničenja, idempotentne radnje, strukturirane zapisnike i vidljiva stanja neuspjeha.

Ne dopustite da neuspjelo dohvaćanje postane izmišljen odgovor. Ako potreban izvor nije dostupan, agent treba navesti što nije bilo moguće provjeriti i izbjegavati zaključke koji o tome ovise. Ako bi poziv alata mogao izazvati vanjski učinak, dodijelite ključ idempotentnosti ili zahtijevajte potvrdu prije ponovnog pokušaja.

Evaluacija bi trebala uključivati nepovoljne putanje. Testirajte nepotpun kontekst, proturječne zapise, zastarjele dokumente, odbijanja dozvola, neispravno oblikovane odgovore alata i zahtjeve izvan opsega agenta. Sustav koji se sigurno ponaša u uvjetima neizvjesnosti vrjedniji je od sustava koji daje dojmljive demonstracije u idealnim uvjetima.

Mjerite kvalitetu tijeka rada

Ne mjerite uspjeh samo prema tome koliko često ljudi koriste sučelje za razgovor. Mjerite poboljšava li se tijek rada. Je li trijaža incidenata brže došla do vjerodostojnog sljedećeg koraka? Jesu li recenzenti prije odobrenja uočili više nedostajućeg konteksta? Jesu li timovi podrške potrošili manje vremena na pronalaženje trenutačne politike?

Kombinirajte kvantitativne signale tijeka rada s kvalitativnim pregledom. Zadržite mali skup reprezentativnih slučajeva i ponovno ih pregledajte nakon promjena u upitu, modelu, alatu ili izvoru podataka. Time nastaje praktičan skup regresijskih testova za ponašanje agenta.

Pratite i obrasce ispravaka. Ako korisnici redovito uklanjaju istu preporuku, problem bi mogao biti ograničenje koje nedostaje, a ne problem s modelom. Ako više puta traže dokaze, poboljšajte citate i odabir izvora. Povratne informacije najkorisnije su kada su povezane s određenom točkom odluke u tijeku rada.

Stvarna nadogradnja jest organizacijska pozornost

AI agenti često se opisuju kao način za obavljanje više zadataka s manje klikova. To može biti korisno, ali dublja je prilika poboljšati kamo ide ljudska pozornost. Dobro oblikovan agent okuplja slabe signale, relevantnu povijest i jasno sljedeće pitanje, a prosudbu ostavlja ljudima odgovornima za ishod.

Počnite malim koracima: jednom ponavljajućom odlukom, pouzdanim izvorima, pristupom samo za čitanje, vidljivim dokazima i granicom ljudskog odobrenja. Kada sustav pouzdano proizvodi uvide koje ljudi mogu provjeriti, proširivanje njegove uloge postaje inženjerska odluka, a ne skok vjere.

Cilj nije softver koji zvuči zauzeto. Cilj je softverski rad u kojem važan kontekst stiže ranije, neizvjesnost je izričito navedena, a stručni ljudi mogu više vremena provesti donoseći odluke koje su važne.