Mnoge AI značajke ne uspijevaju iz iznenađujuće običnog razloga: model je dobio tekst, ali nitko nije preuzeo odgovornost za značenje tog teksta.

Proizvod je nakupio jezik posvuda: u zahtjevima za podršku, specifikacijama, izvornom kodu, prodajnim bilješkama, dokumentima za uvođenje novih korisnika, analitičkim događajima i kraticama koje koriste ljudi koji ga razvijaju. AI asistent može dohvatiti sve to, a ipak dati odgovor koji je tehnički tečan, samouvjereno pogrešan ili opasno nepotpun.

Razlika između impresivne demonstracije i pouzdane mogućnosti proizvoda jest vlasništvo nad kontekstom. Netko mora odlučiti što bi sustav trebao znati, odakle to znanje dolazi, koliko mora biti svježe, što nikada ne smije zaključivati i tko je odgovoran kada je odgovor pogrešan.

Kontekst je imovina proizvoda, a ne prompt

Primamljivo je AI rad svesti na pisanje promptova. Promptovi su važni, ali oni su samo vidljivi rub većeg sustava. Koristan odgovor ovisi o tome jesu li pravi korisnik, račun, stanje tijeka rada, pravila, dozvole, terminologija i trenutačno ponašanje proizvoda dostupni u trenutku donošenja odluke.

Razmotrite asistenta za podršku kojem je postavljeno pitanje: „Zašto ne mogu izvesti ovo izvješće?” Generički model može objasniti nekoliko vjerojatnih uzroka. Asistent koji poznaje proizvod trebao bi najprije znati jesu li izvozi omogućeni za plan tog korisnika, sadrži li izvješće ograničene podatke, izvršava li se već zadatak izvoza i je li relevantna integracija ispravna.

To nije samo bolje sročeno. To je kontekst proizvoda povezan s radnjom ili objašnjenjem.

Tehnički voditelji trebali bi ovaj kontekst tretirati kao i svaku drugu ključnu imovinu proizvoda. Potreban mu je jasan vlasnik, izričite granice, provjere kvalitete, upravljanje životnim ciklusom i način za ispravke.

Dodijelite vlasništvo na izvoru

„AI tim posjeduje kontekst” zvuči razumno, ali često stvara usko grlo i lažan osjećaj odgovornosti. AI tim može izgraditi sustave za dohvat, evaluaciju i promatranje. Ne može biti autoritet za svaku iznimku u određivanju cijena, pravilo tijeka rada, sigurnosnu politiku ili konfiguraciju specifičnu za korisnika.

Vlasništvo bi trebalo ostati blizu ljudima koji već posjeduju temeljno područje.

• Produktni timovi posjeduju trenutačno ponašanje, podržane tijekove rada i terminologiju vidljivu korisnicima.
• Timovi za podršku i operacije posjeduju dokumentirane putove rješavanja, kriterije za eskalaciju i poznata ograničenja.
• Timovi za sigurnost i usklađenost posjeduju pravila pristupa, klasifikacije podataka i zabranjena otkrivanja.
• Inženjerski timovi posjeduju stanje sustava, ugovore o integraciji i pouzdanost isporuke konteksta.
• AI ili platformni timovi posjeduju mehanizme koji odabiru, sastavljaju, evaluiraju i nadziru kontekst.

To nije birokracija radi birokracije. Sprječava čest način neuspjeha: zastarjeli dokument postane modelova prividna istina jer nitko nije bio odgovoran za njegovo povlačenje ili ispravljanje.

Modelirajte razliku između znanja i stanja

Ne bi se svakim kontekstom trebalo postupati jednako. Trajno znanje i aktualno stanje imaju različite načine neuspjeha.

Trajno znanje obuhvaća dokumentaciju proizvoda, politike, definicije i odobrene upute za otklanjanje poteškoća. Koriste mu pažljivo uređivanje, verzioniranje, pregled i dohvat. Aktualno stanje obuhvaća dozvole računa, status narudžbe, zastavice značajki, trenutačne incidente i napredak tijeka rada. Ono obično mora dolaziti iz autoritativnih sustava u trenutku zahtjeva.

Njihovo nemarno miješanje uzrokuje suptilne probleme. Dokument može navesti da korisnik može promijeniti postavku, dok trenutačna konfiguracija računa kaže da ne može. U tom slučaju živi sustav trebao bi ograničiti odgovor. Asistent ne bi trebao „zaobilaziti” granice dozvola zato što opći članak pomoći zvuči optimističnije.

Praktično pitanje pri dizajnu glasi: Koja bi informacija učinila ovaj odgovor nesigurnim ili obmanjujućim kada bi bila zastarjela? Sve u toj kategoriji zaslužuje izričitu strategiju svježine.

Učinite neizvjesnost vidljivom u dizajnu

Sustavima konteksta trebalo bi dopustiti da kažu „Nemam dovoljno informacija.” To nije neuspjeh inteligencije; to je značajka pouzdanosti.

Za tijek rada s velikim utjecajem definirajte što se događa kada nedostaje potreban kontekst:

1. Utvrdite koje polje ili izvor nedostaje.
2. Postavite usmjereno dodatno pitanje kada ga korisnik može pružiti.
3. Dohvatite podatke iz autoritativnog sustava kada proizvod to može učiniti sigurno.
4. Eskalirajte ili odbijte kada bi odgovor inače zahtijevao nagađanje.

Cilj nije ukloniti svaki nepotpun odgovor. Cilj je ukloniti samouvjereno izmišljanje na mjestima gdje korisnici trebaju da proizvod bude pouzdan.

Izgradite ugovor o kontekstu

Ugovor o kontekstu sažet je dogovor između proizvoda, vlasnika područja i implementacijskog tima. Opisuje ulaze koje AI mogućnost smije koristiti i pravila koja njima upravljaju.

Za svaki značajan izvor konteksta dokumentirajte vlasnika, svrhu, zahtjeve pristupa, očekivanja svježine, ponašanje pri neuspjehu i postupak pregleda. Neka bude dovoljno lagan da ostane aktualan. Savršen dokument koji nitko ne ažurira manje je koristan od kratkog, vidljivog dogovora koji se održava uz proizvod.

Ugovor za internog inženjerskog asistenta, na primjer, mogao bi navesti da smjernice za arhitekturu dolaze iz odobrenih zapisa tehničkih odluka, status usluga dolazi iz prikaza promatranja uživo, a tajne ili podaci korisnika nikada nisu uključeni u dohvat. Ako se status usluge ne može dohvatiti, asistent može objasniti opće dijagnostičke korake, ali ne smije tvrditi da je usluga ispravna.

Takva preciznost udaljenim timovima daje zajednički jezik. Umjesto rasprave o tome je li model „dovoljno pametan”, mogu ispitati je li mogućnost primila ispravne informacije uz ispravna ograničenja.

Evaluirajte cijeli put, a ne samo odgovor

Timovi često evaluiraju AI izlaz kao da je izoliran tekst. U proizvodu je odgovor završna faza lanca: namjera korisnika, identitet, dozvole, dohvat, rangiranje izvora, rezultati alata, upute, generiranje odgovora i svaka posljedična radnja.

Testirajte reprezentativne scenarije kroz taj lanac. Uključite sretne putove, dvosmislene zahtjeve, zastarjele dokumente, sukobljene izvore, odbijene dozvole, nedostupne ovisnosti i protivničko formuliranje. Najvrjedniji slučajevi obično proizlaze iz stvarne dvosmislenosti proizvoda: pojmova koje korisnici preopterećuju, postavki koje ljudi pogrešno razumiju i tijekova rada sa skupim rubnim slučajevima.

Kada je odgovor loš, klasificirajte neuspjeh prije promjene prompta. Je li izvor bio pogrešan? Je li izvor nedostajao? Je li dohvat odabrao pogrešan materijal? Je li sustavu nedostajalo trenutačno stanje? Je li model zanemario valjano ograničenje? Različiti uzroci zahtijevaju različite popravke.

Dajte programerima prostor da preuzmu odgovornost za ishode

Vlasništvo nad kontekstom mijenja i način na koji programeri napreduju. Inženjere koji grade AI značajke ne bi trebalo svesti na povezivanje modela sa sučeljem. Potreban im je dovoljan pristup proizvodu da razumiju odluke koje korisnici pokušavaju donijeti i dovoljna operativna vidljivost da vide gdje sustav ne uspijeva.

To ne znači da svaki programer preko noći postaje stručnjak za područje. To znači da timovi stvaraju redovit kontakt s produktnim menadžerima, kolegama iz podrške i stručnjacima za područje; zajedno pregledavaju stvarne slučajeve neuspjeha; i ispravke čine dijelom uobičajene isporuke, umjesto hitnom mjerom nakon pokretanja.

Održiva AI isporuka manje se odnosi na dramatična pokretanja, a više na održavanje živog razumijevanja proizvoda. Nove značajke mijenjaju terminologiju. Politike se razvijaju. Integracije otkazuju. Korisnici otkrivaju putove koje nitko nije predvidio. Kontekst se mora revidirati s istom disciplinom koja se primjenjuje na kod.

Proizvod pamti što organizacija cijeni

AI sustav odražavat će kontekst koji prima, uključujući njegove praznine, proturječja i zanemarena područja. Ako nitko ne posjeduje taj kontekst, sustav i dalje može zvučati korisno. Jednostavno neće dosljedno razumjeti proizvod koji predstavlja.

Trajna prednost nije imati najveću hrpu dokumenata ni najdomišljatiji prompt. To je stvaranje jasne odgovornosti za značenje: tko ga definira, tko ga održava, kako dolazi do sustava i što se događa kada je neizvjesno.

Kada kontekst ima vlasnike, AI postaje manje razgovorni sloj postavljen na vrh proizvoda. Postaje pažljiv sudionik u samom proizvodu.