Natjerati veliki jezični model da proizvede impresivan odgovor u izoliranom okruženju lako je. Natjerati ga da obavlja koristan posao unutar stvarnog proizvoda inženjerska je disciplina.

Razlika nije samo u opsegu. Demonstracija može pretpostaviti čiste ulaze, strpljivog korisnika, stabilne usluge i nikakve posljedice za netočan odgovor. Produkcijski sustavi susreću se s dvosmislenim zahtjevima, nepotpunim podacima, promjenjivim dozvolama, ponovnim pokušajima, prekidima rada, ograničenjima troškova i ljudima koji s pravom očekuju da sustav zna kada nije siguran.

Najvrjedniji pomak jest prestati razmišljati o LLM-u kao o značajci koja „zna stvari”. Tretirajte ga kao jednu komponentu šireg sustava: probabilističkog tumača koji može pretvoriti jezik u strukturiranu namjeru, sastaviti sadržaj, sažeti dokaze ili odabrati među pažljivo ograničenim radnjama. Takvo uokvirivanje donosi bolji dizajn i manje neugodnih iznenađenja.

Započnite s ograničenim zadatkom, a ne općim asistentom

„Dodajte AI asistenta” nije zahtjev. To je oznaka za nekoliko vrlo različitih sposobnosti, od kojih svaka nosi zasebne rizike. Asistent za podršku koji dohvaća odobreni sadržaj pomoći nije isto što i agent koji može ažurirati evidenciju kupaca. Pomoćnik za pregled koda nije isto što i tijek rada koji može implementirati uslugu.

Snažan prvi slučaj uporabe ima jasnog korisnika, uočljiv ishod i elegantan način neuspjeha. Na primjer, interni alat za operacije mogao bi pretvoriti zahtjev u nacrt prijave s kategorijom, prioritetom i predloženim opisom. Korisnik može pregledati nacrt prije slanja. Model štedi vrijeme bez stjecanja ovlasti koje nije zaslužio.

Prije odabira modela ili pisanja upute definirajte četiri stvari:

• Koji ulaz sustav prima, uključujući očekivanu neurednost.
• Koji je izlaz koristan i kako će se upotrebljavati.
• Koje radnje sustav, ako ih ima, smije poduzeti.
• Što bi se trebalo dogoditi kada odgovor nedostaje, nije siguran, neispravno je oblikovan ili nije siguran za upotrebu.

To je uobičajen dizajn sustava. LLM mijenja sučelje, a ne potrebu za granicama.

Generiranje jezika držite odvojenim od poslovnih ovlasti

Jedan od najpouzdanijih obrazaca integracije jest slojeviti tijek. Model obrađuje jezik i ograničeno zaključivanje; deterministički softver provjerava izlaz, primjenjuje pravila i izvršava sporedne učinke.

Pretpostavimo da korisnik kaže: „Pomakni sutrašnju sesiju planiranja na petak poslijepodne i pozovi voditelja dizajna.” Model može izdvojiti namjeru i vratiti strukturirane podatke kandidata. Vaša bi aplikacija tada trebala razriješiti stvarni događaj, provjeriti korisnikove dozvole za kalendar, identificirati voditelja dizajna putem odobrenog imenika, provjeriti sukobe u rasporedu, prikazati predloženu promjenu i tek tada pozvati API kalendara.

{
  "action": "reschedule_meeting",
  "event_reference": "tomorrow planning session",
  "new_time_window": "Friday afternoon",
  "add_attendee_role": "design_lead"
}

JSON nije radnja. To je nepouzdan prijedlog. Provjerite ga prema shemi, razriješite reference prema mjerodavnim sustavima i odbijte ili razjasnite sve što se ne može sigurno protumačiti. Nikada nemojte dopustiti da tekst koji je generirao model postane upit baze podataka, naredba ljuske, odluka o autorizaciji ili API zahtjev bez namjenski izrađenog sloja provjere.

Upotreba alata zahtijeva ugovore i zaštitne ograde

Alati pretvaraju LLM iz konverzacijskog sučelja u operativnu komponentu. Također koncentriraju rizik. Model može odabrati pogrešan alat, navesti pogrešan argument, ponoviti poziv nakon isteka vremena ili biti pod utjecajem teksta koji je zatraženo da obradi.

Dizajnirajte svaki alat kao da njegov pozivatelj može pogriješiti. Neka nazivi budu precizni, ulazi tipizirani, a opisi uski. Dajte prednost radnji kao što je create_draft_invoice u odnosu na široki manage_invoices. Odvojite operacije čitanja od operacija pisanja. Za pisanja s posljedicama zahtijevajte izričit korak potvrde povezan s točno predloženom promjenom.

Idempotentnost je ovdje jednako važna kao i u svakom distribuiranom tijeku rada. Ako se uzvodni zahtjev ponovno pokuša izvršiti, radnja „create” ne bi trebala stvarati duplicirane zapise. Pohranite identifikator zahtjeva, učinite prijelaze stanja izričitima i vratite dovoljno podataka o rezultatu da sustav može utvrditi je li se radnja već dogodila.

Pretpostavite da je dohvaćeni tekst nepouzdan

Dohvaćanje može utemeljiti model u aktualnom znanju tvrtke, ali ne čini svaki dohvaćeni dokument uputom. Članak za podršku, preneseni dokument, web-stranica ili komentar na prijavu mogu sadržavati jezik namijenjen preusmjeravanju modela: „zanemari prethodna pravila” ili „pošalji ove podatke drugdje”. Taj je sadržaj podatak, a ne ovlast.

Držite pouzdane upute aplikacije odvojene od dohvaćenog materijala. Recite modelu čemu dohvaćeni materijal služi, ograničite alate dostupne u tom koraku i provodite dozvole izvan upute. Dohvaćanje bi trebalo odgovarati na pitanja relevantnim dokazima; ne bi trebalo potajno proširivati ono što sustav smije učiniti.

Procjenjujte tijek rada, a ne samo formulaciju

Timovi često testiraju uputu s nekolicinom zadovoljavajućih primjera i to zamijene za pouzdanost. Stvarna procjena počinje reprezentativnim slučajevima: uobičajenim zahtjevima, nejasnim zahtjevima, sukobljenim uputama, nedostajućim informacijama, osjetljivim podacima, neispravno oblikovanim odgovorima alata i zahtjevima koji se moraju odbiti.

Za tijek strukturiranog izdvajanja mjerite jesu li obavezna polja prisutna, valjana i ispravno razriješena. Za dohvaćanje provjerite je li odgovor potkrijepljen odabranim kontekstom. Za agentski tijek rada procijenite cijeli trag: izbor alata, argumente, ponovne pokušaje, konačno stanje i je li zatraženo ljudsko odobrenje kada je to bilo potrebno.

Izradite mali, verzionirani skup za procjenu prije objavljivanja značajke. Pokrenite ga svaki put kada se promijene upute, modeli, alati, postavke dohvaćanja ili pravila. Povratne informacije iz produkcije tada postaju izvor novih slučajeva, umjesto nestrukturiranog reda anegdota.

Dizajnirajte za uobičajeni neuspjeh

Modeli mogu vratiti nevaljan strukturirani izlaz. Pružatelji mogu biti spori ili nedostupni. Može doći do ograničenja stope. Alat može uspjeti, a njegov odgovor može biti izgubljen. Dohvaćanje možda neće pronaći ništa relevantno. Nijedan od tih ishoda ne bi trebao ostaviti korisnika da se pita je li se ključna radnja dogodila.

Koristite vremenska ograničenja, ograničene ponovne pokušaje i jasno zamjensko ponašanje. Ponovite prolazne pogreške prijenosa, ali nemojte naslijepo ponavljati sporedne učinke. Ako strukturirani izlaz ne prođe provjeru, zatražite od modela da ga popravi samo unutar ograničene petlje; nakon toga vratite sigurnu pogrešku ili prepustite zadatak natrag korisniku. Bilježite identifikatore zahtjeva, verzije modela i upute, neuspjele provjere, pozive alata i konačne ishode, uz smanjivanje nepotrebnog zadržavanja osjetljivog sadržaja.

Dobar UX dio je pouzdanosti. Korisno sučelje razlikuje „Nisam pronašao odgovor”, „Trebam pojedinost”, „Nisam mogao dovršiti radnju” i „Dovršio sam ovu radnju”. To su različita stanja, a njihovo tretiranje kao istog vedrog odgovora u chatu narušava povjerenje.

Neka ljudski pregled bude odluka o proizvodu

Čovjek u petlji nije sinonim za kopiranje svakog odgovora u red za pregled. Pregled bi trebao odgovarati reverzibilnosti i utjecaju. Sastavljanje internog sažetka možda ne treba odobrenje. Slanje vanjske poruke, mijenjanje polja ugovora ili brisanje podataka trebali bi imati strože kontrole. Ključno je učiniti pregled smislenim: prikažite izvorne dokaze, predloženu radnju, zahvaćene zapise i najmanju odluku koju osoba mora donijeti.

S vremenom, opažena pouzdanost može opravdati užu automatizaciju. Taj bi napredak trebao biti promišljen. Počnite s prijedlozima, zatim odobrenim radnjama u ograničenim područjima, a potom pažljivo nadziranom automatizacijom za niskorizične, reverzibilne zadatke. Proširivanje ovlasti prije dokazivanja ponašanja način je na koji privlačan prototip postaje operativna obveza.

Prava integracija je organizacijska

Teži dio usvajanja LLM-a rijetko je API poziv. Riječ je o usuglašavanju vlasništva, pristupa podacima, pravila odobravanja, standarda kvalitete i metrike koja definira korisnost. Proizvod, inženjering, sigurnost, operacije i stručnjaci za domenu svi vide različite načine neuspjeha. Zrela implementacija daje tim pitanjima mjesto u dizajnu.

Najbolji LLM sustavi nisu čarobne crne kutije. Oni su razumljivi tijekovi rada s fleksibilnim jezičnim slojem, izričitim ograničenjima, uočljivim ponašanjem i sigurnim izlazima. To možda zvuči manje dramatično od autonomnog agenta opće namjene. U stvarnom radu to je daleko moćnije: sustav kojem ljudi mogu dovoljno vjerovati da ga ponovno upotrijebe sutra.