AI se često uvodi u softversku arhitekturu kao značajka: dodajte okvir za razgovor, pozovite model, isporučite asistenta. Takvo je uokvirivanje preusko. Kad AI sustav može tumačiti zahtjeve, birati alate, dohvaćati informacije tvrtke ili pokretati radne tokove, postaje dio površine arhitekture za donošenje odluka.

Važno pitanje nije „Koji model bismo trebali koristiti?” nego „Kakvu vrstu sustava stvaramo i što mora ostati pouzdano kad je model nesiguran, spor, nedostupan ili pogrešan?” Dobri odgovori vode do korisnih AI proizvoda. Slabi odgovori stvaraju dojmljive demonstracije s nejasnim granicama.

Počnite s odlukom, a ne s modelom

AI sposobnost trebala bi postojati kako bi poboljšala određenu odluku ili smanjila određenu vrstu posla. „Sažmi zahtjeve za podršku” zadatak je. „Pomozite voditeljima podrške prepoznati ponavljajuće probleme prije nego što postanu incidenti” ishod je. Druga izjava arhitektima daje nešto za što mogu dizajnirati: ulaze, korisnike, točke pregleda, očekivanja latencije i mjere korisnosti.

Odvojite rad koji zahtijeva jezičnu prosudbu od rada koji zahtijeva točna pravila. Model može klasificirati nejasnu poruku korisnika, sastaviti odgovor ili izdvojiti vjerojatne teme iz dokumenata. Ne bi trebao biti jedini autoritet za primjenu politike popusta, promjenu dozvola računa ili izračun financijskog iznosa.

Ta je razlika temeljna. Koristite deterministički softver za determinističke obveze. Koristite AI ondje gdje dvosmislenost, varijacije ili nestrukturirane informacije čine tradicionalno programiranje skupim ili krhkim.

Dizajnirajte AI kao nepouzdanog suradnika

Jezični modeli produktivni su jer mogu stvarati uvjerljiv izlaz iz nepotpunog konteksta. To je ujedno i njihov središnji inženjerski rizik. Mogu pogrešno razumjeti uputu, izmisliti pojedinost, odabrati pogrešan alat ili izraziti nesigurnost s neopravdanim samopouzdanjem.

Arhitektura bi stoga trebala tretirati izlaz modela kao nepouzdan dok ga okolni sustav ne provjeri. To ne znači da je AI neupotrebljiv. Znači da sustav treba slojeve koji korisne prijedloge pretvaraju u sigurne radnje.

• Ograničite ulaze. Jasno definirajte zadatak, dostupan kontekst i dopuštene radnje.
• Provjerite izlaze. Provjeravajte formate, obavezna polja, raspone, identifikatore i dozvole u uobičajenom aplikacijskom kodu.
• Ograničite ovlasti. Agentu dajte najmanji skup alata i podataka potreban za njegov posao.
• Zahtijevajte potvrdu. Uvedite korak ljudskog odobrenja prije značajnih vanjskih radnji.
• Zabilježite odluke. Sačuvajte relevantne ulaze, pozive alata, izlaze i ishode radi otklanjanja pogrešaka i pregleda.

Na primjer, AI asistent može zahtjev na prirodnom jeziku pretvoriti u predloženi upit baze podataka. Aplikacija bi i dalje trebala provoditi pristup samo za čitanje, dopuštati samo odobrene tablice, ograničiti broj vraćenih redaka i odbaciti nesigurne strukture upita. Model može pomoći prevesti namjeru; aplikacija ostaje odgovorna za provedbu.

Poslovna pravila držite izvan upita

Upiti su korisna sučelja, ali su loša zamjena za pravila proizvoda. Ako je politika dovoljno važna da utječe na novac, pristup, usklađenost ili postupanje s korisnicima, kodirajte je ondje gdje je softver može testirati i provoditi.

Upit može reći asistentu da izbjegava otkrivanje povjerljivih informacija. Sloj dozvola trebao bi odrediti koje informacije trenutačni korisnik smije dohvatiti. Upit može zatražiti od agenta da izdaje povrate novca samo u okviru politike. Usluga bi trebala provjeriti iznos povrata, razlog, stanje računa i zahtjev za odobrenjem prije izvršavanja transakcije.

Ovo razdvajanje poboljšava više od sigurnosti. Olakšava pregled, testiranje i implementaciju promjena politike bez pokušaja zaključivanja hoće li izmijenjena rečenica promijeniti ponašanje modela u svakom rubnom slučaju.

Koristite strukturirane granice

Kada AI sustav prosljeđuje informacije drugom sustavu, prednost dajte shemi u odnosu na slobodno oblikovani tekst. Zatražite od modela ograničenu strukturu, provjerite je i izričito obradite neuspjele provjere. Odgovor modela koji ne može zadovoljiti shemu nije razlog za nagađanje; razlog je za ponovni pokušaj s jasnijom uputom, traženje ljudskog unosa ili zaustavljanje radnog toka.

{
  "action": "create_draft",
  "customer_id": "string",
  "summary": "string",
  "requires_review": true
}

Shema ne čini izlaz istinitim. Čini ugovor provjerljivim. Vaša usluga i dalje mora potvrditi da korisnik postoji i da je pozivatelj ovlašten izraditi nacrt.

Dohvaćanje je problem proizvoda i podataka

Mnoge AI aplikacije trebaju aktualno, organizaciji specifično znanje. Dohvaćanje može pružiti relevantne dokumente u trenutku zahtjeva, ali nije jednostavno „povezivanje vektorske baze podataka”. Kvaliteta odgovora ovisi o kvaliteti dokumenata, dijeljenju na segmente, metapodacima, kontrolama pristupa, ponašanju pretraživanja i načinu na koji se dohvaćeni materijal predstavlja modelu.

Arhitekti bi rano trebali postaviti praktična pitanja. Koji su izvori mjerodavni? Koliko brzo ažuriranja moraju postati dostupna? Što se događa kad dokument nedostaje ili je proturječan? Može li korisnik dohvatiti materijal koji inače ne bi smio vidjeti?

Metapodaci su posebno važni. Dokument politike bez vlasnika, datuma stupanja na snagu, područja proizvoda ili klasifikacije pristupa teško je pouzdano dohvatiti i opasno ga je slijepo koristiti. Izgradite radne tokove unosa koji čuvaju podrijetlo. Odgovor bi trebao moći uputiti natrag na materijal upotrijebljen kao njegova potpora, čak i ako proizvod odabere drukčiji prikaz od formalnog citata.

Planirajte kvar kao normalno stanje

AI sustavi dodaju načine kvara uz uobičajene kvarove aplikacija: ograničenja broja zahtjeva, vremenska ograničenja, neispravno oblikovan izlaz, nedostupne alate, zastarjeli dohvaćeni sadržaj i ponašanje modela koje se mijenja kako pružatelji ažuriraju sustave. Otporan dizajn pretpostavlja da će se to događati.

Postavite vremenske proračune i zamjensko ponašanje. Ako asistent ne može generirati koristan sažetak unutar prozora interakcije, prikažite izvorni sadržaj ili ponudite rezultat u redu čekanja. Ako poziv alata ne uspije, nemojte tiho tvrditi da je radnja uspjela. Ako dohvaćanje vrati slabe dokaze, dopustite sustavu da kaže da nema dovoljno informacija.

Ponovni pokušaji zahtijevaju oprez. Ponovni pokušaj zahtjeva za generiranje teksta može biti razuman. Ponovni pokušaj radnje koja je stvorila zahtjev ili poslala poruku može udvostručiti rad ako operacija nije idempotentna. Pridružite stabilan identifikator zahtjeva operacijama sa sporednim učincima i omogućite usluzi primatelju da prepozna duplikate.

Procijenite cijeli radni tok

Testovi tradicionalnog softvera često pitaju vraća li funkcija očekivanu vrijednost. Evaluacija AI-ja također treba pitati je li radni tok koristan, utemeljen, siguran i primjereno oprezan u realističnim varijacijama.

Izradite mali, reprezentativni skup za evaluaciju prije široke implementacije. Uključite jednostavne zahtjeve, dvosmislene zahtjeve, nedostajuće informacije, sukobljene dokumente, protivničke upute i zahtjeve koje treba odbiti ili eskalirati. Pregledajte ne samo konačne odgovore nego i izbore alata, dohvaćeni kontekst te je li sustav slijedio obavezne kontrole.

Povratne informacije iz produkcije također su važne. Pratite stope neuspjeha, odbijanja provjere, napuštene interakcije, eskalacije, latenciju i obrasce ispravaka. Velik broj tečnih odgovora nije dokaz vrijednosti ako ih korisnici nakon toga redovito popravljaju.

Dajte ljudima smislen nadzor

Ljudski nadzor funkcionira samo kad je ugrađen u radni tok. Tražiti od nekoga da odobri stotine neprozirnih AI odluka nije zaštitna mjera; to je stroj za zamor od upozorenja. Preglednici trebaju sažet kontekst: što sustav predlaže, dokaze koje je upotrijebio, dostupne signale pouzdanosti ili nesigurnosti te točnu posljedicu odobrenja.

Odaberite točke pregleda prema mogućnosti poništavanja. Izrada nacrta sažetka sastanka može zahtijevati laganu ispravku. Slanje izmjene ugovora namijenjene korisniku zaslužuje snažniji pregled. Brisanje podataka, mijenjanje dozvola ili pokretanje plaćanja trebali bi imati izričito ovlaštenje i jasne zapise revizije.

Arhitektura je mjesto gdje povjerenje postaje stvarno

Najtrajniji AI sustavi neće biti oni koji modelima daju najviše slobode. Bit će to oni koji sposobne modele uparuju s jasnim granicama, pouzdanim podacima, vidljivim radnim tokovima i promišljenom ljudskom kontrolom.

O modelu razmišljajte kao o moćnoj komponenti, a ne o samoj aplikaciji. Dopustite mu da tumači, generira, rangira i pomaže. Neka okolna arhitektura definira istinu, dozvole, politiku i odgovornost. Tako AI postaje više od uvjerljivog sučelja: postaje sustav na koji se ljudi mogu osloniti.