Naš je sustav učinio jednu stvar, i to dobro: pretvorio je pitanja na prirodnom jeziku u API pozive.
Korisnici su bili analitičari, voditelji računa i voditelji operacija. Znali su koji im podaci trebaju, ali njihovo ručno sastavljanje značilo je korištenje četiri nadzorne ploče, dva BI alata i alata za izradu izvješća Salesforce. U našem su sustavu zahtjev upisali na čistom engleskom. Zahtjev poput "Sastavite izvješće o obujmu prodaje od siječnja do ožujka 2026. za sjeveroistočnu regiju, raščlanjeno po gradovima" je preveden u API poziv na koji sustav može djelovati:
json
"opis": "Korisnik je zatražio obujam prodaje za navedeni datumski raspon, ovdje je API poziv za dobivanje odgovora",
"api_poziv": "/api/sales_volume",
"post_tijelo":
"početni_datum": "2026-01-01",
"završni_datum": "2026-03-31",
"regija": "sjeveroistočno"
Ostatak cjevovoda bio je konvencionalni inženjering. Sustav je poslao poziv u pravu pozadinu – imali smo integracije s internim portalima za izvješćivanje, Salesforceom i nekoliko domaćih servisa – primijenio veliki jezični model (LLM)(generirani JSON upit za filtriranje i oblikovanje odgovora, i isporučio ga putem e-pošte, kao Drive dokument ili prikazan kao grafikon u pregledniku.
Do sredine 2025. godine sustav je generirao nekoliko stotina izvještaja mjesečno. Vodstvo i analitičari koristili su ta izvješća i proslijeđivali ih vanjskim dionicima. To je postao zadani način na koji većina timova izvlači ad-hoc podatke.
Ugovor između LLM-a i ostatka sustava bio je strukturirani JSON objekt kao što je opisano u gornjem primjeru.
json
"opis": "Korisnik je zatražio obujam prodaje za navedeni datumski raspon, ovdje je API poziv za dobivanje odgovora",
"api_poziv": "/api/sales_volume",
"post_tijelo":
"početni_datum": "2026-01-01",
"završni_datum": "2026-03-31",
"regija": "sjeveroistočno"
Izgradili smo ga na Claude Sonnetu 3.5 početkom 2025. Nadogradili smo na 3.7 bez incidenata i na 4.0 bez incidenata. U vrijeme kada je Sonnet 4.5 isporučen, postali smo zadovoljni stabilnošću i predvidljivošću LLM-ova u rješavanju onoga za što smo vjerovali da je jednostavan problem. Nadogradnje modela postale su rutina, poput sudara s manjom verzijom knjižnice koja se dobro ponaša.
Zatim smo izbacili 4.5. Za značajan postotak zahtjeva, model je počeo savijati sadržaj post_body u polje opisa. Uslijedila su dva načina neuspjeha.
Prvo, parametri filtra nikad nisu stigli do API-ja. Naš sustav čita post_tijelo kao izvor istine za korisni teret zahtjeva, a to se polje vratilo prazno. API poziv je napravljen bez filtra datumskog raspona ili regije. Ovisno o specifičnom API-ju koji se poziva, pozadina je vratila obujam prodaje za sva vremena ili sve regije ili je vratila pogrešku 500.
Drugo, model je u svom odgovoru počeo postavljati razjašnjavajuća pitanja. Ovo je bilo novo. Ranije verzije uvijek su uzimale najbolji pristup dvosmislenom zahtjevu i vraćale strukturirani objekt. Sonet 4.5, budući da je bio oprezniji, ponekad bi umjesto toga odgovorio pitanjem. Naš sustav nije imao put za to. Izgrađen je na pretpostavci da će svako pozivanje modela rezultirati API pozivom. Nije bilo komponente čovjeka u petlji niti stanja za zadržavanje djelomično dovršenog zahtjeva. To je uzrokovalo kvarove nizvodnih sustava na više načina.
Vratili smo se na 4.0. To je bilo teže nego što je trebalo biti: između postavljanja 4.0 i 4.5, naš je tim dodao nove integracije API-ja, a sve su bile kvalificirane za 4.5. Vraćanje modela značilo je ponovno kvalificiranje svakog od njih u odnosu na 4.0 pod vremenskim pritiskom.
Sadržaj objave
Zašto tradicionalna inženjerska disciplina ovdje ne uspijeva
Softversko inženjerstvo počiva na sposobnosti vezanja učinka promjene. Kada nadogradite upravljački program ili biblioteku, pročitajte napomene o izdanju da biste vidjeli možete li očekivati prijelomne promjene. Jedinični testovi opisuju što bi se moglo pomaknuti. Možete iskoristiti sljedeće svojstvo: Sustav koji se mijenja dovoljno je determinističan da se njegovo ponašanje može predvidjeti ili barem uzorkovati dovoljno gusto da vam ulije povjerenje. Radijus miniranja omeđen je konstrukcijom.
Sustavi podržani LLM-om ruše ovu pretpostavku. Komponenta koja proizvodi vaš izlaz nije pod vašom kontrolom. Ne možete razlikovati verziju modela s 4.0 na 4.5. To je veleprodajna zamjena funkcionalnosti o kojoj vaš sustav ovisi.
To je ono što mislimo pod an beskonačni radijus eksplozije: promjena čiji se silazni učinci ne mogu unaprijed nabrojati jer su ulazni prostor (prirodni jezik) i načini neuspjeha (sve što bi model mogao učiniti drugačije) neograničeni.
Anatomija neuspjeha
Obdukcija je otkrila da je naš upit uvijek bio nedovoljno specificiran. Rekli smo modelu da vrati JSON objekt s tri polja. Opisali smo čemu služi svako polje. Nismo izričito naveli da opis mora biti niz na prirodnom jeziku i da ne smije sadržavati serijalizirane prikaze drugih polja.
Ranije verzije modela izvele su ovo ograničenje iz konteksta. Sonet 4.5, očito bolji u biti "od pomoći" u svojim izborima oblikovanja odlučio je da traženje pojašnjenja ili navođenje tijela zahtjeva u opisu čini odgovor korisnijim. Iz perspektive modela, ovo je bila razumna interpretacija dvosmislene upute. Međutim, to je prekršilo pretpostavke pod kojima je naš sustav izgrađen.
Greška nije bila u modelu. Greška je bila u našoj pretpostavci da će model nastaviti popunjavati nedostatke u našim specifikacijama kao što je uvijek bio. Tri uspješne nadogradnje naučile su nas da vjerujemo da su te praznine sigurne.
Strukturirani izlazni načini i API-ji za korištenje alata uhvatili bi ovaj specifični kvar na razini sheme. Nismo ih koristili iz inženjerskih razloga izvan opsega ovog članka. Ali sheme samo ograničavaju sintaksu, a ne semantiku. Shema ne može specificirati da se pitanje za pojašnjenje ne bi trebalo pojaviti u sustavu bez staze za pojašnjenje ili da raspon datuma nikada ne bi trebao tiho postaviti na zadano sve vrijeme. Sheme rješavaju lakšu polovicu problema.
Evals-prva arhitektura
Disciplina koja zatvara ovu prazninu je tretiranje paketa za procjenu – ne upita – kao formalne specifikacije sustava. Upit je implementacija od spec. Model je an prevoditelj. Procjene su same specifikacije, a svaka promjena modela ili brze promjene valjana je ako i samo ako ih prođe.
U praksi, eval je trostruko: ulaz, svojstvo koje mora zadovoljiti izlaz i funkcija bodovanja. Za naš sustav, procjena koja bi uhvatila regresiju 4,5 izgleda otprilike ovako:
piton
def test_description_contains_no_serialized_payload(response):
desc = odgovor["description"].donji()
zabranjeno = ["curl", "post_body", "{", "http://", "https://"]
assert not any(token in desc for token in forbidled), \
f"opis procurio strukturirani sadržaj: odgovor['description']"
Nekoliko stotina takvih svojstava, neka napisana rukom za poznate važne invarijante, neka generirana kao regresijski testovi iz stvarnog proizvodnog prometa, neka ocijenjena od strane LLM-a kao suca za nejasnije kvalitete poput tona, postaju vrata. Nadogradnje modela i brze promjene trebaju se tretirati kao zahtjevi za povlačenje koji moraju ozeleniti paket prije spajanja.
Evali su skupi za izgradnju i održavanje. Oni se mijenjaju kako se vaš proizvod mijenja. LLM-as-judge bodovanje uvodi vlastitu varijaciju u ishodima. A paket može uhvatiti samo načine kvarova koje ste mislili navesti — ne možete procijeniti svoj put do sigurnosti prema kategoriji kvara koju niste ni zamislili. Ovu smo lekciju naučili na teži način: nitko u našem timu nikada nije napisao tvrdnju koja kaže "polje za opis ne smije sadržavati naredbu curl," jer nitko nije mislio da će ga model tamo staviti.
Ocjene nisu srebrni metak. Oni vam daju mogućnost ograničiti radijus eksplozije promjene na jedini dostupan način kada je temeljna funkcija crna kutija: gustim uzorkovanjem ulazno-izlaznog odgovora do kojeg vam je zapravo stalo i odbijanjem implementacije kada se to ponašanje pomakne.
Putokaz
Inženjerska zajednica tek treba razviti tijelo znanja za pisanje učinkovitih procjena. Ne postoje široko prihvaćeni standardi o tome što ‘pokrivenost’ znači u prostorima unosa prirodnog jezika. CI/CD sustavi nisu izgrađeni za provjeru ishoda probabilističkih testova. Kako agenti preuzimaju autonomniji posao – pisanje koda, premještanje novca, planiranje promjena infrastrukture – jaz između "model je prošao naše testove dima" i "znamo što će ovaj sustav učiniti u proizvodnji" postaje središnji inženjerski problem sljedećih nekoliko godina.
Timovi koji će zatvoriti taj jaz bit će oni koji će prestati tretirati ocjene kao naknadnu misao o osiguranju kvalitete i početi ih tretirati kao stvarnu specifikaciju onoga što njihov sustav jest.
Vijay Sagar Gullapalli osnivač je inženjer umjetne inteligencije u tvrtki Adopt AI i patentirani izumitelj USPTO-a.
Sarat Mahavratayajula je viši softverski inženjer u Sherwin-Williamsu.