Intervjuista namršteno: „Zadužiš se za Agent-a produkcionog nivoa, kako bi ga dizajnirao?” Ja odmah krenuh da nabacujem ReAct, Function Calling, Skills. Intervjuista posle toga odmahahuje glavom.

„Zadužiš se za Agent-a produkcionog nivoa, kako bi ga dizajnirao?”

Ako bi ti odgovarao, kako bi odgovorio, ako odmah kreneš da nabacuješ ReAct, Function Calling, Skills i slično, intervjuista će sigurno odmahati glavom.

Ako on ne odmahne, ja ću njemu odmaheti (zaštita glavom psa).

Hajde, ovo pitanje je tek vrh ledenog brega.

U nastavku su stvarna pitanja sa intervjua čitalaca, ko ima potrebe može sačuvati za kasnije polako učenje, oh ne, polako razumevanje, polako učenje.

(Ceo tekst je prilično intenzivan, garantujem da ćete naučiti mnogo toga, vežite sigurnosne pojaseve, idemoooo.)

content

PS: Projekat koristi PaiCLI, otvorenog koda na GitHub-u, to je terminal Agent sličan Claude Code-u, zainteresovani mogu da uče.

https://github.com/itwanger/PaiCLI-Python

I izvorni kod i pitanja sa intervjua su tu za vas, bez skrivanja.

Tako iskreno radimo.

01. Koji je najveći izazov na koji si naišao u PaiCLI projektu?

Stari Wang otvoreno: „Koji je najveći izazov na koji si naišao u PaiCLI projektu?”

„PaiCLI ima tri režima rada — ReAct glavna petlja, Plan-and-Execute prvo planiranje pa izvršenje, Multi-Agent kolaboracija više uloga. Tri režima moraju da dele isti skup registracije alatki, sistem memorije, bezbednosnu odobrenje, audit log itd.”

„Na primer, ista operacija pisanja datoteke u ReAct režimu zahteva iskakanje odobrenja, a i u Multi-Agent režimu. Mehanizam memorije isto tako, ako korisničke preference sačuvane u ReAct režimu ne mogu da se pročitaju pri prebacivanju u Plan režim, onda Harness nije dobro urađen.”

02. Ako prvih 10 rundi razgovora postanu rezime, da li je originalni kontekst još uvek potreban?

Stari Wang klimnu glavom. „Pričajmo o kompresiji konteksta. Ako prvih 10 rundi razgovora postanu rezime, da li je originalni kontekst još uvek potreban?”

„Nije potreban. Nakon završetka kompresije, originalne stare poruke se brišu, zadržava se samo rezime i nekoliko poslednjih rundi kompletnih zapisa.”

Strategija kompresije PaiCLI-ja je Map-Reduce sumiranje po segmentima, u tri koraka.

• Sečenje. Stare poruke se iseku na više segmenata po 5 poruka u grupi
• Map sumiranje. Svaki segment nezavisno generiše po jedan rezime, zadržavajući korisničke zahteve i namere, izvršene operacije i rezultate, donete odluke i zaključke
• Reduce spajanje. Više rezimea segmenata se spaja u jedan ukupni rezime

„Nakon završetka kompresije, stare poruke se brišu, rezime se upisuje kao novi zapis u istoriju razgovora, a zatim se poslednje 3 runde kompletnog razgovora vraćaju originalno. Model u sledećoj rundi vidi 'rezime + nekoliko poslednjih rundi kompletnog razgovora', i ne prelazi prozor i zadržava najnoviji operativni kontekst.”

03. Korisnik je pre mesec dana rekao da voli ljuto, pre nedelju dana rekao da ne može ljuto, kako proceniti?

„Vremenski ponderisano. Obema sečama memorije se čuva, bez prisilnog spajanja, bez prisilnog brisanja starih.”

„Pri pretrazi se boduje po vremenskom opadanju, što je novija memorija to je teža.”

„Krivulja opadanja PaiCLI-ja je da za 24 sata opadne sa pune ocene na polovinu. 'Ne može ljuto' od pre nedelju dana u rangiranju pretrage prirodno stoji ispred 'voli ljuto' od pre mesec dana, model dobija prvu stavku kao najnovije stanje.”

„Stari zapisi se ne brišu direktno zato što je brisanje nepovratno. Šta ako je 'ne može ljuto' privremena alergija, pa za dve nedelje opet bude u redu? Zadržavanjem starih zapisa, model može videti putanju promena i doneti tačniju procenu.”

04. Ako se memorija čuva u vektorskoj bazi, kako ažurirati postojeću memoriju?

„Ako se memorija čuva u vektorskoj bazi, proces ažuriranja je prvo semantički pronaći stari zapis, obrisati stari vektor, novi sadržaj ponovo vektorizovati (embedding), generisati novi vektor i upisati nazad u bazu. U međuvremenu treba obratiti pažnju na konflikte verzija — kada dve sesije istovremeno menjaju isti zapis memorije, potrebno je dodati optimističku bravu ili proveru vremenske oznake.”

„Memorijski sistem PaiCLI-ja ne koristi vektorsku bazu.”

„U memoriji se čuvaju činjenice kao što su korisničke preference, informacije o projektu, ukupno možda nekoliko stotina do hiljadu stavki. Za ovaj obim je dovoljno podudaranje ključnih reči — rezultat u milisekundama, objašnjivo, debagovano, koja je stavka pronađena i zašto, sve se vodi na prvi pogled.”

„Vektorska baza je pogodna za RAG bazu znanja, sa desetinama gigabajta dokumenata, samo semantička pretraga može da ih obradi.”

05. Da li kompresija konteksta gubi ključne informacije?

Stari Wang se namršti. „Da li kompresija konteksta gubi ključne informacije?”

„Gubi, to je cena kompresije, ne postoji besgatno kompresovanje.”

„Ali se mogu napraviti tri sloja zaštite, gubitak se drži u prihvatljivim granicama.”

„Prvi sloj, ekstrakcija činjenica. Pre kompresije, iz starog razgovora izvuci stabilne činjenice koje i dalje imaju vrednost van sesije, sačuvaj u dugoročnu memoriju.”

„Te činjenice ne učestvuju u kompresiji, neće nestati.”

„Drugi sloj, instrukcija za rezime. Prompt kompresije će jasno tražiti da se zadrže korisnički zahtevi i namere, izvršene operacije i rezultati, donete odluke i zaključci, važni tehnički detalji.”

„Model pri generisanju rezimea ima oslonac, jedan rezime se drži ispod 200 znakova, spojeni rezime ispod 300 znakova.”

„Treći sloj, nedavni bafer. Poslednje runde kompletnog razgovora se zadržavaju originalno, bez kompresije.”

„Najnoviji operativni koraci i kontekst su tu.”

Korisnik je potrošio 500 juana na kupovinu proizvoda, šta ako kompresija izgubi 500?

„Budimo konkretni. Korisnik je potrošio 500 juana na kupovinu proizvoda, šta ako kompresija izgubi 500?”

„Vrati se na prvi sloj, ekstrakciju činjenica.”

„Pre kompresije, sistem iz razgovora izvlači stabilne činjenice. 'Korisnik je potrošio 500 juana na kupovinu određenog proizvoda' ovakva transakciona informacija sa iznosom se prepoznaje kao trajna činjenica i upisuje u dugoročnu memoriju.”

„Dugoročna memorija nije pogođena kompresijom konteksta, model je uvek može naći.”

„Da odmaknemo korak, čak i ako ekstrakcija činjenica ne uhvati ovu stavku, pravilo podmetanja 'donetih odluka i zaključaka' u promptu za rezime će takođe navesti model da zadrži iznos transakcije u rezimeu. Dvostruka zaštita, iako ne može da garantuje savršeno, mnogo je pouzdanije od direktne kompresije.”

06. Kako definisati šta spada u važne informacije?

„Jednom rečenicom — stabilne činjenice koje i dalje važe van sesije i imaju vrednost ponovnog korišćenja u budućnosti.”

PaiCLI koristi tri sloja filtriranja da sprovede ovu definiciju.

• Isključi privremene zadatke. Sadržaj čije rečenice počinju sa „korisnik želi”, „pomozi mi”, „kreiraj”, „obriši”, „ovaj zadatak” spada u jednokratne instrukcije trenutne sesije, filtriraj
• Isključi nagađanja. Sadržaj koji sadrži reči kao što su „možda”, „trebalo bi”, „pogodi”, „nagađam” nije utvrđena činjenica, filtriraj
• Zadrži trajne signale. Sadržaj koji sadrži ključne reči kao što su „preferencija”, „navika”, „projekat”, „repozitorijum”, „konfiguracija”, „verzija”, „tehnički stek”, „dogovor”, „pravilo” je verovatno činjenica vredna van sesije, zadrži

07. Kako rešiti API tajm-aut i greške?

„Core mehanizam je eksponencijalni backoff pokušaj sa slučajnim tremom.”

„Podrazumevano maksimalno 3 pokušaja. Prvi put sačekaj 500 milisekundi, drugi put udvostruči na 1 sekundu, treći put 2 sekunde, gornja granica 30 sekundi.”

„Svako vreme čekanja se doda 20% slučajnog trema, izbegavajući da više klijenata u istom trenutku koncentrisano pokušava i ponovo sruši server.”

„Pokušaji imaju opseg primene, treba razlikovati tipove grešaka koje se mogu pokušati i onih koje ne mogu.”

Pokušavajuće situacije:

• HTTP statusni kod 408 (tajm-aut zahteva), 429 (ograničenje protoka), 500/502/503/504 (kvar servera)
• Izuzeci na mrežnom sloju, tajm-aut veze, veza resetovana, DNS rezolucija neuspešna, prekid strimovanja

Nepokušavajuće situacije:

• SSL greška sertifikata, pokušaj sigurnosnog problema ne pomaže
• JSON greška u analizi, problem sa formatom odgovora, pokušaj vraća istu grešku
• Prekid niti, ukazuje na to da je korisnik aktivno otkazao zadatak

„Još jedan inženjerski detalj. Ako server vrati Retry-After zaglavlje, interval pokušaja uzima veću vrednost između izračunate backoff vrednosti i vrednosti koju je naveo server.”

„Server kaže čekaj 5 sekundi, čekaj 5 sekundi, ne pokušavaj prerano.”

08. Kako otkriti prebrzu potrošnju Token-a?

„Prvo pogledaj podatke. PaiCLI nakon svake runde poziva ispisuje Token statistiku, koja sadrži broj poziva, ukupne ulazne tokene, ukupne izlazne tokene, tokene pogotka keša, prosečne ulazne tokene po pozivu i dostupan budžet.”

„Pristup pronalaženju je traženje anomalnih peak-ova iz statistike. Tri su uobičajena uzroka.”

• Pre dug izlaz alatke. Jedan shell izlaz sa desetinama hiljada znakova ubačen u kontekst, Token odmah ode gore.
• Prekasno okidanje kompresije. Podrazumevano se okida na 90% dostupnog budžeta, ako jedna runda alatki ima previše poziva, možda je već prešlo pre okidanja. Spuštanje praga okidanja na 80% može pomoći
• Širenje konteksta. Ista informacija se više puta pretražuje i ubacuje. Tada treba proveriti da li je mehanizam deduplikacije rezultata pretrage memorije na mestu

09. Šta je mehanizam progresivnog otkrivanja Skill-a?

„Progresivno otkrivanje je učitavanje po potrebi — Skill koji se ne koristi ne ulazi u kontekst, kada zatreba se proširi.”

Konkretno u tri faze.

• Pri pokretanju se ubacuje indeks. Kada se Agent pokrene, imena i opisi u jednoj rečenici svih omogućenih Skill-ova se ubacuju u system prompt. Samo ime i kratak opis, jedan opis ispod 500 znakova, maksimalno 20 Skill-ova
• Učitavanje po potrebi. Model tokom razgovora procenjuje koji Skill odgovara trenutnom zadatku, aktivno poziva load_skill alatku da učita kompletno uputstvo
• Bafer ubacivanja. Kompletno uputstvo se upisuje u bafer, pri sledećoj rundi razgovora se automatski dodaje ispred korisničke poruke. Bafer istovremeno zadržava najviše 3 Skill uputstva, višak se izbacuje po najmanje korišćenom

Zašto ne ubaciti sva kompletna uputstva Skill-ova direktno u kontekst?

„Pretpostavimo 20 Skill-ova, svako kompletno uputstvo u proseku 2000 tokena, svi stalno u system prompt-u je 40.000 tokena.”

„Svaka runda razgovora mora da učita tih 40.000 tokena, a stvarno korišćeno je možda jedan do dva. Progresivno otkrivanje učitava samo Skill koji se koristi.”

10. Dizajn pametnog korisničkog servisa Agent, kako dizajnirati?

Stari Wang odahnu i baci scenario. „Sada treba dizajnirati pametan korisnički Agent, prema pitanjima korisnika odgovarati što tačnije, kako dizajnirati?”

„U četiri sloja.”

„Prvi sloj, prepoznavanje namere. Prva rečenica korisnika kad uđe, prvo razjasni da li je konsultacija o proizvodu, žalba nakon prodaje, povraćaj robe ili praćenje isporuke.”

„Klasifikacija određuje koje alatke kasnije poziva, koje baze znanja pretražuje.”

„Drugi sloj, pretraga znanja. RAG povezuje baze znanja kao što su dokumentacija proizvoda, FAQ, politika povraćaja.”

„Korisnik pita 'da li ovaj telefon podržava NFC', pretraga pronalazi stranicu sa parametrima proizvoda, model odgovara na osnovu rezultata pretrage. Ako se ne pronađe, model mora odgovoriti 'nisam siguran u ovo pitanje, prebacujem vas na operatera', ne izmišljati.”

„Treći sloj, izvršenje alatki. Provera narudžbina, praćenje isporuke, pokretanje povraćaja novca, Agent poziva odgovarajuće back-end interfejse.”

„Rezultat poziva alatke se vraća modelu, model ga organizuje u odgovor razumljiv korisniku.”

„Četvrti sloj, podmetanje i eskalacija. Ako model dve runde zaredom ne da važeći odgovor, ili korisnik jasno traži operatera, odmah prebacuje na operatera.”

Šta još treba uzeti u obzir?

„Četiri aspekta.”

① Tačnost. Strategija sečenja na komade (chunk) mora biti razumna, previše veliko znači da semantička pretraga postaje nejasna, previše malo gubi kontekst. Obično 512 do 1024 tokena po chunk-u, sa 20% preklapanja. Dodaj još jedan sloj rerank modela (Reranker) za sekundarno sortiranje, rezultat vektorske pretrage nije nužno optimalan, semantička sličnost nije isto što i relevantnost pitanja

② Latencija. Strimovani izlaz je osnovni zahtev, korisnik ne može čekati. Odgovori na česta pitanja se mogu keširati, sledeći put direktno pogodak bez prolaska kroz model

③ Bezbednost. Zaštita od ubrizgavanja prompt-a — sadržaj koji alatke vraćaju tretira se kao nepoverljivi podaci, ne može se izvršiti kao instrukcija. Osetljive informacije korisnika kao što su broj telefona, adresa se maskiraju

④ Podmetanje. Neprepoznata namena, nepronađeno u bazi znanja, model nesiguran — sve ide na operatera. Bolje više puta prebaciti na operatera nego dozvoliti modelu da izmišlja odgovore

11. Kako rešiti šiljke saobraćaja pri e-commerce promocijama?

„Za ovakav Agent servis, kada je saobraćaj velik pri e-commerce promocijama, sa šiljcima, kako rešiti?”

„Ključni pristup je ravnanje peak-ova, preusmeravanje, podmetanje, pet linija odbrane.”

① Asinhronizovan red zahteva. Korisnički zahtevi prvo idu u red poruka, Worker troši prema kapacitetu. LLM poziv je sam po sebi spor, sinhrono procesiranje ne može da izdrži šiljke. Nakon dekupling reda, front-end odgovara u sekundama „obrada u toku”, back-end zove model po ritmu

② Model slojevit. Jednostavna pitanja idu na mali model ili mašinu pravila, složena pitanja tek idu na veliki model. „Gde je moja pošiljka” ne zahteva prolazak kroz veliki model, jedan API poziv rešava

③ Keširanje hot-spotova. Najčešće postavljana pitanja tokom promocija, kao što su vreme isporuke, politika povraćaja, pravila popusta, unapred generišu standardne odgovore i keširaju. Pogodak keša vraća direktno, ne troši računsku snagu modela

④ Zaštita ograničavanja protoka. Broj zahteva po korisniku u minuti ima gornju granicu. Višak vraća „trenutno veliki obim konsultacija, pokušajte kasnije”, bolje nego da sistem padne

⑤ Prekidač degradacije. Kada kašnjenje odgovora LLM servera pređe prag ili stopa greške skoči, automatski prekida, prebacuje na šablonske odgovore ili direktno preusmerava na operatera

„Jedna stvar na koju treba obratiti pažnju, u scenariju promocija rok trajanja keša ne sme biti predug. Pravila aktivnosti se mogu usput promeniti, keš mora podržati ručno brisanje.”

ending

Ranije su intervjui pitali o CRUD i parametrima midlver-a, sada pitaju kako komprimovati kontekst, kako upravljati memorijom, kako uštedeti Token, kako izdržati saobraćaj.

[Svi znaju da nabacuju koncepte, ali pretvoriti koncepte u inženjerske detalje koji rade u produkciji, to je ono što intervjuista zaista želi da čuje.]

Agent inženjering je tek počeo, mnoga pitanja još uvek nemaju standardne odgovore. Ko prvi pregazi zamke, ima samopouzdanje koje drugi nemaju.

Držite se, braćo i sestre.

Vidimo se u sledećem.