Većina neuspjeha AI-ja nisu neuspjesi modela. To su neuspjesi u dizajnu softvera.

Sposoban model može sažimati, klasificirati, zaključivati na temelju uputa i stvarati korisne nacrte. Ali ne može pouzdano djelovati na temelju informacija koje su raspršene po nečitljivim dokumentima, skrivene iza nedosljednih API-ja ili pomiješane s podacima koje nikada ne bi smio vidjeti. Pravi je posao arhitektonski: odlučiti što sustav treba znati, kada to treba znati i što smije učiniti s tim znanjem.

To je razlika između dodavanja okvira za chat i izgradnje proizvoda s omogućenom AI funkcionalnošću. Prvo izlaže model. Drugo modelu daje pažljivo osmišljeno radno okruženje.

Počnite od posla, a ne od modela

„Dodajte AI” nije zahtjev. Koristan zahtjev opisuje odluku, tijek rada ili ishod koji se može poboljšati uz pomoć. Na primjer: pomoći osoblju korisničke podrške da prepozna ispravnu politiku, pomoći inženjeru da istraži neuspjeh implementacije ili pomoći financijskim timovima da izdvoje polja iz predanih dokumenata.

Svaki od tih poslova ima drukčiji profil rizika. Pomoćnik za podršku možda treba navesti odobreni tekst politike. Pomoćnik za implementaciju možda treba trenutačno stanje sustava, ali ne i mogućnost promjene produkcije. Tijek rada s dokumentima možda treba strukturirano izdvajanje nakon kojeg slijedi ljudski pregled.

Prije odabira modela ili izrade upita definirajte četiri stvari:

• Korisnik: tko prima rezultat i kakvu stručnost ima?
• Odluka: što će učiniti drukčije nakon što ga vidi?
• Dokazi: koji su izvori dovoljno mjerodavni da potkrijepe rezultat?
• Granica: što sustav mora odbiti, eskalirati ili prepustiti čovjeku?

Ovaj okvir sprječava tim da tečan izlaz tretira kao proizvod. Proizvod je poboljšani tijek rada oko tog izlaza.

Učinite znanje dostupnim u slojevima

AI sustavi trebaju kontekst, ali „dajte mu sve podatke” gotovo je uvijek pogrešan dizajn. Povećava trošak, stvara probleme s privatnošću i kontrolom pristupa te modelu otežava razlikovanje relevantnih informacija od šuma.

Snažniji je obrazac postupno otkrivanje. Modelu najprije dajte stabilne upute, zatim dohvatite samo dokumente relevantne za trenutačni zahtjev, a potom pozivajte alate uskog opsega samo kada je to potrebno.

Odvojite upute, činjenice i dozvole

Te tri kategorije ne bi trebalo spojiti u jedan veliki upit.

• Upute definiraju ponašanje: ton, granice zadatka, obavezne provjere i pravila eskalacije.
• Činjenice dolaze iz dokumentacije proizvoda, zapisa, prijava, baza znanja ili drugih izvora koji se mogu mijenjati.
• Dozvole određuju kojim činjenicama i alatima određeni korisnik ili tijek rada može pristupiti.

Ovo razdvajanje olakšava ažuriranje i reviziju sustava. Promjena politike trebala bi ažurirati izvor politike, a ne zahtijevati uređivanje skrivenog odlomka u aplikacijskom kodu. Dozvole korisnika trebale bi filtrirati dohvat prije nego što kontekst dosegne model, a ne samo tražiti od modela da zanemari povjerljive zapise.

Dohvat također zahtijeva produktno promišljanje. Dijeljenje dokumenta na odlomke nije dovoljno. Sačuvajte naslove, poveznice na izvore, datume stupanja na snagu, vlasništvo i metapodatke o pristupu. Ako je odgovor važan, korisnici bi trebali moći pregledati dokaze koji su ga oblikovali.

Dajte agentima alate s uskim ugovorima

AI agent postaje korisniji kada može upitivati sustave, stvarati zapise ili pokretati tijekove rada. Također postaje opasniji. Rješenje nije izbjegavanje alata; rješenje je dizajnirati ih jednako pažljivo kao javne API-je.

Dobar alat ima malu svrhu, eksplicitne ulaze, predvidljive izlaze i jasan model autorizacije. „Pretraži narudžbe kupaca” sigurnije je i lakše evaluirati od općeg sučelja za upite nad bazom podataka. „Izradi nacrt zahtjeva za povrat novca” sigurnije je od „izvrši povrat novca”.

Za radnje s posljedicama odvojite planiranje od izvršavanja. Dopustite modelu da sastavi predloženu radnju, prikaže važne parametre i zahtijeva potvrdu ili korak odobravanja prije provođenja promjene.

{
  "action": "create_refund_request",
  "order_id": "ORD-1042",
  "amount": 49.00,
  "reason": "duplicate_charge",
  "requires_approval": true
}

Aplikacija, a ne model, trebala bi provoditi taj zahtjev za odobrenjem. Modeli mogu predlagati i objašnjavati; deterministički softver trebao bi validirati sheme, primjenjivati autorizaciju, rukovati ponovnim pokušajima i bilježiti rezultat.

Dizajnirajte za neizvjesnost i neuspjeh

Izlaz AI-ja je probabilistički. Vanjski sustavi nisu uvijek dostupni. Dohvaćeni dokumenti mogu biti nepotpuni ili zastarjeli. Produkcijski dizajn pretpostavlja da će se dogoditi sva tri uvjeta.

Izgradite eksplicitne putove za neizvjesnost. Ako sustav nema dovoljno dokaza, trebao bi to reći i navesti što mu sljedeće treba. Ako poziv alata ne uspije, trebao bi prijaviti neuspjeh bez pretvaranja da je radnja uspjela. Ako radnja istekne zbog vremenskog ograničenja, sustav bi trebao provjeriti njezino konačno stanje prije ponovnog pokušaja, osobito ondje gdje bi ponovni pokušaj mogao stvoriti duplicirani rad.

Idempotentnost je važna kad god agenti pokreću operacije. Identifikator zahtjeva može omogućiti nizvodnoj usluzi da prepozna kako ponovni pokušaj predstavlja istu namjeravanu radnju, a ne novu. To je uobičajena disciplina distribuiranih sustava i jednako je važna kada je uključen AI.

Također razlikujte koristan nacrt od provjerenog rezultata. Model može izraditi nacrt sažetka promjena; skup testova provjerava ponašanje. Može predložiti dijagnozu incidenta; telemetrija i zapisnici utvrđuju je li ta dijagnoza potkrijepljena. Sustav bi korisnicima trebao učiniti tu razliku vidljivom.

Evaluirajte tijek rada, a ne samo odgovor

Timovi često evaluiraju AI s nekoliko dojmljivih primjera. To je korisno za istraživanje, ali nedostatno za implementaciju. Pouzdan skup za evaluaciju uključuje uobičajene zahtjeve, dvosmislene zahtjeve, nepotpune podatke, neprijateljske upute, granice dozvola i scenarije neuspjeha.

Mjerite ono što je za posao doista važno. Za pomoćnika korisničke podrške to može uključivati je li odabrao odobrene smjernice, naveo relevantni izvor, izbjegao nepotkrijepljene tvrdnje i preusmjerio osjetljive slučajeve. Za pomoćnika za programiranje to može uključivati prolaze li predložene promjene testove, poštuju li konvencije repozitorija i izbjegavaju li mijenjanje nepovezanog ponašanja.

Zadržite reprezentativne primjere kao regresijske testove. Kada se promijene upiti, logika dohvata, alati ili modeli, ponovno ih pokrenite. Time se kvaliteta AI-ja iz subjektivne rasprave u demonstracijskoj sobi pretvara u inženjersku praksu s vidljivim kompromisima.

Ljudski nadzor treba biti namjeran

Ljudski pregled nije jedan prekidač. Pripada ondje gdje trošak pogreške premašuje trošak pauziranja: nepovratne radnje, financijske obveze, regulirane odluke, osjetljiva komunikacija i slučajevi niske razine pouzdanosti.

Suprotno tome, prisiljavanje odobrenja za bezopasan, reverzibilan rad može izbrisati vrijednost automatizacije. Cilj je kalibrirana autonomija: dopustite sustavu da široko priprema, razvrstava, sažima i izrađuje nacrte; zahtijevajte snažnije kontrole kako potencijalni učinak raste.

Dobra sučelja pomažu recenzentima da djeluju brzo. Prikažite predloženu radnju, dokaze, zahvaćene zapise i razlog zbog kojeg je odabrana. Ne tjerajte recenzenta da obrnutim inženjeringom lanca poruka modela shvati što će se dogoditi.

Podučavajte sustav putem arhitekture

Softver podučava AI sustav što je važno. Modeli podataka govore mu koji entiteti postoje. Dohvat mu govori koji su dokazi relevantni. Ugovori alata govore mu koje su radnje moguće. Dozvole mu govore gdje su granice. Evaluacija timu govori što znači „dobro”.

Model je važan, ali je samo jedna komponenta tog nastavnog plana. Najtrajnije AI sustave izgradit će timovi koji kontekst, kontrole i povratne informacije tretiraju kao prvoklasnu produktnu arhitekturu. Kada sustav zna prave stvari, može provjeriti ono što tvrdi i djeluje samo unutar dobro osmišljenih granica, inteligencija postaje korisna umjesto tek dojmljiva.