Zaposleni u Aliju: Zavist prema susednom timu koji radi Qoder, osećam da svaki dan donosi nešto novo, godišnja bonus sigurno neće nedostajati, moglo bi se reći da su pogodili dividendu AI ere (sa pitanjima za intervju o Agentu)
Da budem iskren, i sam sam težak korisnik Qoder serije proizvoda, i zaista se brzo razvija.
U početku sam video da neki drugari žale da je skup, ali pošto koristi neki vrhunski inostrani model, cena je svakako viša nego kod domaćih modela.
Ali Claude Code i Codex nisu dostupni svakome, pa je Qoder postao pristojna zamena na domaćem tržištu.
Pogledao sam njihov nedavno otvoreni Better Harness i zaista vredi kao referenca u eri Agenta.
https://github.com/QoderAI/better-harness
I sam sam ga u prvi mah integrisao u svoj Coding proizvod PaiCLI.
Takođe otvorenog koda: https://github.com/itwanger/PaiCLI-Python
Za sada, najuspešniji AI proizvodi su svakako Claude Code i Codex, a zatim Qoder, WorkBuddy i slični domaći Agenti, pa je "zavist prema susednom timu koji radi Qoder" svakako najiskrenije osećanje.
Za tradicionalni biznis, najbolji ishod je optimizacija postojećeg stanja, dok AI tim za alate stvara inkrement, pa ko kaže da ne zavisti, sigurno zavidi.
Iteracije u pravcu AI Coding-a su izuzetno brze, tim ima svakog dana nove, vidljive rezultate. U velikim firmama, vidljiv rezultat znači vidljivu performansu. Vidljiva performansa znači bogat godišnji bonus na kraju godine.
Razlog je jednostavan - programeri su najdirektnija korisnička grupa za primenu velikih modela, a učestalost korišćenja i spremnost na plaćanje AI Coding alata su daleko veće nego u drugim scenarijima. Pored toga, Agent omogućava i onim grupama koje pre nisu imale razvoja sposobnosti da stvore svoj proizvod.
To znači da će radna mesta u pravcu Agenta u naredne dve do tri godine biti sve brojnija.
Ograničavanje protoka, prekidanje kola, asinhrone redovi, idempotentni dizajn, praćenje poziva, postepeno objavljivanje - ove inženjerske sposobnosti stečene u eri "tri visoka" ne mogu izostati u procesu produktizacije Agenta.
Ranije ste upravljali HTTP zahtevima, sada upravljate LLM pozivima. Kontekstni prozor je novo upravljanje memorijom, token budžet je novo QPS ograničavanje, pozivi alata su novi RPC gateway.
Rad na Agentu ne zahteva treniranje modela, ubrzavanje izvođenja, pisanje CUDA koda. Zahteva da umete da umotate sposobnost velikog modela u pouzdanu uslugu - koja može da izdrži saobraćaj, obradi izuzetke, prati probleme i kontinuirano iterira.
Ako ste osoba koja je spremna da uči nešto novo u svom tempu, onda sledeća pitanja za intervju o Agentu vredi pažljivo pročitati.
(Ceo tekst je intenzivan, garantujem da ćete naučiti mnogo toga, vežite sigurnosne pojaseve, krećemo!)
Scenarijski zadaci
U scenariju visokog opterećenja u Tao Tian, pretvoriti Agent Demo u produkcioni sistem koji može da izdrži "Double 11" nivo saobraćaja - koja je najveća arhitektonska izazov?
Laowang je prelistao projektna iskustva na rezimeu i otpočeo je sa teškim scenarijskim pitanjem: "Pretpostavimo da dođeš u naš Tao Tian i da treba da pretvoriš eksperimentalni Agent Demo u produkcioni sistem koji može da izdrži Double 11, šta smatraš najvećim arhitektonskim izazovom?"
"Najveći izazov je da će LLM API postati usko grlo."
"Tradicionalni pristup mikroslužbi za podnošenje saobraćaja je horizontalno skaliranje - povećavaš instancu kada saobraćaj poraste, dodaješ čvorove kada instanca ne bude dovoljna. Ali suštinska zavisnost Agent sistema je LLM API poziv, koji ima tri osobine zbog kojih se ne može skalirati na tradicionalan način."
"Prvo, red veličine kašnjenja je drugačiji. Vreme odziva HTTP interfejsa je u milisekundama, LLM interfejsa u sekundama. Jedan Agent možda treba 3 do 5 LLM poziva za obradu jednog korisničkog zahteva, svaki po dve-tri sekunde, što ukupno daje desetak sekundi, a dugi zadaci mogu trajati i nekoliko sati. Tradicionalni model sinhronog zahteva bi pod ovakvim kašnjenjem popunio thread pool."
"Drugo, QPS ima gornju granicu. Koliko god dodavao Agent instanci, sve one pozivaju isti LLM krajnju tačku. RPM (Requests Per Minute, broj zahteva u minuti) kvota koju ti daje provajder modela je fiksna - ako je na primer 10.000 u minuti, 10 instanci i 100 instanci dele istu ukupnu kvotu."
"Treće, trošak raste linearno sa brojem poziva. Svaki LLM poziv se naplaćuje po tokenu, a vrhunac za Double 11 može biti 50 do 100 puta veći nego inače, pa se i trošak toliko puta uveća."
"Za ova tri problema, moj plan odgovora je u četiri sloja."
"Prvi sloj, semantički keš (Semantic Cache). Embeddinguj korisnički upit i potraži u kešu istorijske upite koji su semantički slični. U Double 11 scenariju je mnogo pitanja identično - 'gde je moja pošiljka', 'kako da zatražim povraćaj', 'koliko se novčića može iskoristiti'. Ovakva visokofrekventna pitanja, kada pogode keš, vraćaju se direktno, bez LLM-a."
"Drugi sloj, rutiranje po nivou modela. Ne zahtevaju svi zahtevi najači model. Jednostavni upiti (status porudžbine, praćenje isporuke) idu na mali model ili čak na rule engine, samo kompleksni višekružni razgovori idu na veliki model. Osnov za rutiranje je izlaz iz klasifikatora namere - taj klasifikator može biti laki model ili jednostavno podudaranje pravila."
"Treći sloj, potpuna asinhronizacija celog toka. Korisnički zahtev prvo ulazi u RocketMQ, a Agent Worker konzumira iz reda. Time se sa jedne strane ravnomerno raspoređuje vrh, sa druge strane rešava problem popunjenog thread pool-a. Za real-time scenarije postavljen je timeout kao zaštitnik - kada istekne, degradira se na šablonski odgovor."
"Četvrti sloj, prekidanje kola poziva alata. Tokom izvršavanja Agent poziva spoljne API-je - servis zaliha, servis isporuke, servis plaćanja. Tokom Double 11, te nizvodne usluge same podnose saobraćaj i lako mogu istaći. Svaki poziv alata dobija Sentinel prekidač kola - kada stopa grešaka pređe prag, kolo se prekida. Istovremeno, svi pozivi alata su projektovani kao idempotentni, kako bi se sprečilo ponovljeno poručivanje ili ponovljeno vraćanje novca zbog pokušaja ponovo."
Zašto ne možemo jednostavno horizontalno skalirati Agent instance?
"Zato što je usko grlo u LLM API-ju, a ne u resursima za obradu."
"Pretpostavimo da je RPM gornja granica LLM krajnje tačke 10.000 u minuti - bilo da postaviš 10 ili 100 instanci, ukupna količina zahteva koju možeš poslati ostaje ista. 100 instanci samo znači da više niti istovremeno čeka u redu, a brzina reda se ne povećava."
"Ono što zaista može povećati propusnost je smanjenje broja LLM poziva - semantički keš, rutiranje po nivou modela, rule engine napred - kako bi se ograničena kvota sačuvala za zahteve koji zaista zahtevaju zaključivanje velikog modela."
content
01. Prilikom izgradnje Agent okvira, izabrati LangChain/LlamaIndex ili raditi samostalno?
Laowang je podigao šoljicu čaja i otpio gutljaj: "Što se tiče izbora okvira, kako vidiš LangChain i slične open-source okvire u poređenju sa samostalnim razvojem?"
"Imam praktično iskustvo sa ovim. PaiCLI-jevAgent krug je samostalno razvijen, sa apstrakcijom modela zasnovanom na Spring AI. Drugi projekat, PaiAgent, koristi LangGraph4j za kompleksnu orkestraciju DAG toka rada."
"Prvo, prednosti LangChain-a. Ekosistem je zaista jak - preko 500 integracija, vektorske baze, provajderi modela, konektori alata - gotovo potpuno pokrivenje. Za POC validaciju ideje, za otprilike dva do tri dana možeš dobiti Demo koji radi. Zajednica je aktivna, pa kada naiđeš na problem, uglavnom možeš pronaći rešenje pretragom."
"Ali njegovi problemi su takođe stvarni."
"Prvo, visoka cena debagovanja. Jedan jednostavan poziv alata, nakon nekoliko slojeva internog pakovanja okvira, ima previše stekova pri grešci. Da bi shvatio 'zašto je ovaj poziv alata vratio prazno', prvo moraš razumeti interno stanje okvira."
"Drugo, verzija je istorijski teret. LangChain je rano, od 0.1 do 0.2 do 0.3, bio gotovo tri različita okvira, sa prekinutim API promenama. Iako je u 1.x mnogo stabilniji, ova istorija pokazuje jednu stvar - tvoj produkcioni kod zavisi od tempo iteracije drugih, što je samo po sebi rizik."
"Treće, apstrakcija. Dizajn okvira je opšti, ali tvoj biznis je sasvim drugačiji. Da bi se prilagodio, moraš napisati mnogo koda kojim svoju logiku uguraš u interfejse okvira."
"Prednost samostalnog razvoja je potpuna kontrola nad svakim korakom. Pri debagovanju direktno čitaš svoj kod, usko grano performansi znaš gde je, a tempo iteracije određuješ sam. Inače, Agent Coding sposobnost je već sada veoma jaka, tako da ne treba brinuti o samostalnom razvoju."
"Moj sud - za tehničku validaciju i brze prototype, koristi okvir. Za produkcione sisteme, jezgro napiši sam, a okvir koristi kao biblioteku alata."
02. Kako kontrolisati granicu autonomije Agenta? Kako projektovati sigurnosne ograde?
"Suštinski princip granice autonomije - deterministička pravila idu kroz rule engine, nejasna mesta se prepuste LLM-u na procenu, a visokorizične radnje se prepuste ljudskom odobrenju."
"Uzmi scenario povraćaja i zamene. 'Povraćaj bez razloga u roku od 7 dana' je determinističko pravilo - ako je u vremenskom prozoru i proizvod nije otvaran, ide direktno kroz proces povraćaja, bez ikakvog zaključivanja Agenta. Ovakvi scenariji se obrađuju rule engine-om - brzo, rezultat je konzistentan, a cena nula."
"'Proizvod ima blage tragove korišćenja, korisnik traži povraćaj' je siva zona - Agent treba da na osnovu slike proceni stepen oštećenja, da konsultuje slične istorijske slučajeve i da kombinuje sa ocenom reputacije korisnika, te da iznese predlog."
"'Iznos povraćaja prelazi 1000 juana' je visokorizična radnja - bez obzira na to kako Agent proceni, pre konačnog izvršenja obavezna je ljudska potvrda."
"Sigurnosne ograde su u tri sloja."
"Prvi sloj, ulazni senitel. Zahtev prvo prolazi kroz filter sadržaja koji blokira nedopušteni sadržaj. Zatim se radi klasifikacija namere - ako je namera korisnika izvan nadležnosti Agenta, na primer pita o internoj arhitekturi sistema ili traži privatne podatke drugih korisnika - direktno se odbija, bez ulaska u tok Agenta."
"Drugi sloj, izvršna ograda. Tokom rada, Agent može pozivati samo unapred registrovane alate, a parametri poziva imaju pravila validacije. Operacije nad putanjama su ograničene na direktorijume sa belog spiska, što sprečava napade putanjom. Opasne komande idu kroz crni spisak za blokadu. Svaki poziv alata ima strukturirani audit log, koji beleži ulaz, izlaz, vremensku oznaku i identitet pozivaoca."
"Treći sloj, izlazna revizija. Odgovor koji generiše Agent, pre nego što se vrati korisniku, prolazi kroz proveru usaglašenosti - da li curi interni detalji politike, da li obećava kompenzacione planove van nadležnosti, da li sadrži osetljive informacije."
Zašto ne možemo potpuno verovati rezonovanju Agenta?
"Zato što je LLM probabilistički model - isti ulaz ne garantuje isti izlaz."
"U scenariju povraćaja i zamene, Agent na isti zahtev za povraćaj prvi put može odgovoriti 'u skladu sa politikom, povraćaj je podnet', a drugi put 'predlažemo da kontaktirate ručnu korisničku podršku za dalju potvrdu'. Ako je u pitanju operacija povraćaja pravog novca, ovakva nepouzdanost je neprihvatljiva."
"Probabilistički model obrađuje deo koji zahteva procenu, rule engine obrađuje deo koji zahteva konzistentnost, a ljudska zaštita obrađuje deo koji zahteva preuzimanje odgovornosti. Svaki od tri upravlja svojim delom, sa jasnim granicama."
03. Halucinacije i nedopušteni sadržaj Agenta - koje su inženjerske mere kontrole i blokade?
Laowang je namestio naočare: "Problem halucinacija svima je poznat, želim da čujem kako se to sprovodi u inženjerstvu."
"U dve faze - pre generisanja i nakon generisanja."
"Ključno sredstvo pre generisanja je RAG. Relevantan faktički sadržaj se preuzima iz baze znanja i ubacuje u kontekst. Model odgovara na osnovu priloženih dokaza, što smanjuje halucinacije."
"Ali RAG ne može potpuno eliminisati halucinacije. Model može disregardirati činjenice iz konteksta i izmisliti 'naizgled razuman' odgovor. Zato u sistemski prompt treba dodati kruto ograničenje - 'odgovaraj samo na osnovu priloženog konteksta, ako u kontekstu nema relevantnih informacija, jasno reci korisniku da nisi siguran'."
"Za upite koji zavise od aktuelnosti - cena proizvoda, status zaliha, napredak isporuke - pre poziva LLM-a prvo se radi API predprovera, koja prikupi podatke u realnom vremenu i ubaci ih u kontekst. Time se oduzima modelu prilika da 'nagađa'."
"Blokada nakon generisanja je u četiri nivoa."
"Prvi nivo, strukturirana validacija. Ako odgovor sadrži URL, proveri da li je format legalan. Ako sadrži cenu ili datum, proveri da li je u razumnom opsegu. Ako sadrži JSON ili blok koda, proveri sintaksu. Ovo su čisto(validaciona) pravila, bez učešća modela - brza i bez troška."
"Drugi nivo, verifikacija citata. Ako model tvrdi 'prema trećoj tački politike povraćaja i zamene', proveri da li ta tačka zaista postoji i da li se sadržaj podudara."
"Treći nivo, model kao sudija (LLM-as-Judge). Drugi model pregleda faktičku tačnost odgovora. Trošak nije visok, jer je prompt za pregled mnogo kraći od prompta za generisanje."
"Četvrti nivo, zaštita poverenjem. Ako logprob izlaza modela (logaritam verovatnoće za svaki token, koji odražava koliko je model siguran u svoj odgovor) pada ispod praga, to znači da model i sam nije siguran - taj odgovor se direktno prosleđuje čoveku."
04. Za dodavanje multimodalne sposobnosti Agenta 'pronalaženje istog proizvoda preko slike proizvoda', koje izmene su potrebne u backend arhitekturi?
Laowang je pogledao tehnički stek na rezimeu: "Biznis strana je postavila zahtev - korisnik slika proizvod, a Agent pronalazi isti. Kako treba da se izmeni tvoja backend arhitektura?"
"Izmene su koncentrisane u četiri modula."
"Prvo, novi tok obrade slike. Nakon što frontend otpremi sliku, backend prvo radi predobradu - validacija formata, prihvata se samo JPEG, PNG, WebP. Ograničenje veličine do 5MB. Rezolucija se proverava, a previše velike slike se skaliraju na standardnu veličinu, kako bi se izbeglo predugo trajanje."
"Drugo, uvođenje modela vizuelnog kodiranja. CLIP (Contrastive Language-Image Pre-training, kontrastivno jezičko-slikovno predbiblijsko obučavanje) kodira sliku u gusti vektor. CLIP tokom obučavanja mapira slike i tekstove u isti vektorski prostor, pa se vektori slika i opisa teksta mogu direktno upoređivati po sličnosti. Sve slike proizvoda u katalogu moraju se unapred oflajn kodirati, pa se vektori smeste u vektorsku bazu."
"Treće, nova indeksna slika vektora. U Milvus-u se napravi zasebna tabela za vektore slika proizvoda, sa tipom indeksa HNSW (struktura indeksa optimizovana za pretragu vektora), što daje latencu upita na nivou milisekundi. Tok: korisnik otpremi sliku → CLIP kodiranje → pretraga vektora → vraća se nekoliko najsličnijih proizvoda."
"Četvrto, fuzija rezultata i preuređivanje. Vektorska pretraga daje vizuelno slične proizvode, ali 'izgleda slično' nije isto što i 'isti proizvod'. Potrebno je preuređivanje koje kombinuje vizuelnu sličnost, podudaranje kategorije, cenovni raspon i istorijske preferencije korisnika, pa se rezultat vraća nakon nove ordenacije."
Zašto vektori slika i vektori teksta ne mogu deliti isti indeks?
"Zato što vektorski prostori koje daju različiti Embedding modeli nisu semantički kompatibilni."
"Embedding model koji se često koristi za pretragu čistog teksta, na primer Qianwen Embedding, i vektori koje daje CLIP-ov tekstualni enkoder, iako dimenzije mogu biti iste, semantička struktura vektorskog prostora je potpuno drugačija. Ako se ubace u isti indeks i računa kosinusna sličnost, dobijeni rezultati nemaju praktičan značaj."
"CLIP sam po sebi zaista može da radi unakrsnomodalnu pretragu - tekstom pretražuje slike, ili slikom pretražuje tekst - jer su njegov tekstualni i slikovni enkoder u istom prostoru. Ali to mapiranje važi samo za par CLIP-ovih enkodera i ne može se mešati sa vektorima drugih modela."
"U produkcionom okruženju održava se više indeksa - pretraga čistog teksta ide preko BGE indeksa sa većom preciznošću, pretraga slika i unakrsnomodalna pretraga idu preko CLIP indeksa, a konačna fuzija rezultata i preuređivanje se rade na sloju aplikacije."
05. Kako održavati tehničku oštroumnost i učiti novu tehnologiju?
Laowang je promenio smer: "Hajde da pričamo o tebi lično. Kako održavaš tehničku oštroumnost?"
"Tri navike - filtriranje izvora informacija, provera kroz praksu, izazivanje unosa kroz izlaz."
"Za izvore informacija pratim tri kanala. GitHub Trending prelistavam pola sata svakog dana - projekti koji za nedelju dana dobiju preko 1000 zvezda velika su verovatnoća da imaju suštinski sadržaj. Na X-u pratim niz naloga programera u prvoj liniji, pa vidim šta svakog dana istražuju novo."
"Kada vidim novi okvir ili alat, napravim najmanji upotrebljiv primer. Na primer, kada sam se prvi put sreo sa MCP protokolom, potrošio sam sat i po na pisanje jednostavne implementacije MCP Servera - kada je prošlo, razumevanje protokola je postalo mnogo dublje."
"Na kraju, izlaz. Napišem članak ili održim prezentaciju u timu. Dok pišem, primetim gde mi je razumevanje nejasno, što me natera da razjasnim detalje."
06. Kako postupati kada dođe do ozbiljnog neslaganja sa članovima tima oko tehničkog rešenja?
"Zaista sam iskusio to. Ranije, prilikom izbora rešenja za pretragu, zalagao sam se za Elasticsearch za hibridnu pretragu, dok je kolega smatrao da je vektorska baza dovoljna."
"Moje rešenje je bilo sledeće."
"Prvi korak, preoblikovanje spora u kvantifikovano poređenje. Svako od nas je pokrenuo skup testova upita -ES hibridna pretraja imala je znatno veći recall od čistog vektorskog, ali i dužu latencu. Kada su podaci na stolu, fokus spora se preusmerio sa 'čije je rešenje bolje' na 'šta je važnije - recall ili latenca'."
"Drugi korak, traženje potvrde prioriteta od treće strane. Drugi kolega je rekao da je u njihovom scenariju 'ne pronalaženje' mnogo ozbiljnije od 'spore pretrage', pa je recall prioritet. Rešenje je time određeno."
"Suština je pretvoriti mišljenje u podatke, prepustiti ocenu biznis ograničenjima i doneti odluku u ograničenom vremenu."
07. Koje su razlike između AI Native aplikacije i tradicionalnog softverskog inženjerstva u razvojnom modelu?
Laowang je zavrtio prsten na prstenu: "Kako vidiš razliku između AI Native i tradicionalnog razvoja?"
"Tri razlike."
"Prvo, determinističko postaje probabilističko. Tradicionalna usluga - isti ulaz uvek vraća isti izlaz, pa u testovima samo napišeš tvrdnje. AI aplikacija - isti prompt svaki put može dati drugačiji rezultat. Metod testiranja mora preći sa tvrdnji na evaluaciju - tačnost, ocena relevantnosti, slaganje ručnog uzorka."
"Drugo, način iteracije se menja. Tradicionalni razvoj je pisanje koda, objavljivanje verzije, puštanje u produkciju. Iteracija AI aplikacije je velikim delom doterivanje prompta, zamena strategije pretrage, izmena kriterijuma evaluacije. Nijedna linija koda možda nije promenjena, ali se ponašanje sistema potpuno razlikuje. Objekat upravljanja verzijama se proširuje sa koda na konfiguraciju - verzije prompta, verzije modela, verzije parametara pretrage - sve se mora upravljati."
"Treće, model saradnje u timu je drugačiji. Tradicionalni razvoj ima jasnu produktnu dokumentaciju, razvoj implementira po njoj. AI aplikacija - često ni produktni menadžer ne može jasno da kaže 'kako izgleda dobar izlaz', pa razvoj, proizvod i operacije zajedno definišu standarde evaluacije i iterativno ih doteruju."
Koje osobine treba da ima odličan inženjer za razvoj AI aplikacija?
"Inženjerska sposobnost - to se nije promenilo. Ali potrebna je i intuicija za ponašanje modela - moraš znati 'ovaj prompt će verovatno dobiti kakav odgovor od modela', znati 'za ovu vrstu zadatka ReAct pattern je pouzdaniji od čistog generisanja'. Ta intuicija se stiče kroz obimnu praksu."
"I još nešto što se lako zanemari - evalucijsko razmišljanje. Za bilo koju AI funkciju, prvi korak bi trebalo da bude definisanje 'šta je dobro', umesto da se odmah pređe na pisanje koda. Bez standarda evaluacije, ne znaš da li je izmenom postalo bolje ili gore."
08. Koja je poslednja tehnička knjiga koju si pročitao?
Laowang je pogledao sat: "Poslednje pitanje. Koja je poslednja tehnička knjiga koju si pročitao i koje ti je najveće nadahnuće donela?"
"Skoro sam ponovo pročitao 'Designing Machine Learning Systems' Chip Huyena."
"Ova knjiga ima jedno mišljenje s kojim se posebno slažem - većina ML projekata ne dostiže očekivanja ne zato što model nije dovoljno dobar, već zato što evaluacija nije dovoljno dobra. Ako ni ne znaš šta je 'dobro', kako uopšte možeš napraviti dobar sistem?"
"Isto je i sa Agentom. Mnogi timovi većinu vremena provedu doterjujući prompt i menjajući model, dok se za evaluaciju izdvoji najmanje vremena. Posle izmene niko ne zna da li je postalo bolje ili gore."
"Ova knjiga mi je stvorila naviku - za bilo koju funkciju vezanu za AI, prvi korak je definisanje metrika evaluacije i skupa za testiranje, pa tek onda prelazak na razvoj."
Kako upisati PaiCLI u rezime?
Naziv projekta: PaiCLI - terminalni AI Agent komandnolinijski alat
Kratak opis projekta: Java verzija terminalnog Agenta koja je ravna Claude Code-u, podržava tri režima izvršenja - ReAct, Plan-and-Execute i Multi-Agent Team, sa sposobnostima kao što su višekružni razgovor, pretraga koda, poziv alata i sigurnosna kontrola.
Tehnički stek: Java 21 + Spring AI + Elasticsearch + MCP protokol + RocketMQ + Sentinel
Ključne odgovornosti:
- Projektovanje Agent produkcione arhitekture, uvođenje semantičkog keša radi smanjenja preko 60% ponovljenih LLM poziva, postizanje ravnomernog raspoređivanja vrha putem rutiranja po nivou modela i asinhrone obrade preko reda poruka, čime se podržava stabilnost usluge u scenarijima visokog istovremenog opterećenja
- Izgradnja tri nivoa sigurnosnih ograda, implementacija belog spiska putanja i crnog spiska opasnih komandi, u kombinaciji sa mehanizmom odobrenja čovek-mašina, čime stopa usaglašenosti poziva alata dostiže 99,9%
- Integracija RAG ubacivanja činjenica, predprovere podataka u realnom vremenu, validacije strukturiranog izlaza i modela-sudije radi smanjenja halucinacija modela, čime se faktička tačnost u ključnim scenarijima povećala za oko 25%
- Implementacija multimodalnih sposobnosti pretrage, zasnovano na CLIP modelu izvršeno vektorsko kodiranje slika proizvoda, uz nezavisno održavanje indeksa slika vektora, podržava pretragu slika pomoću slika i hibridnu pretragu slika-tekst, sa vremenom odziva pretrage kontrolisanim unutar 50 ms
- Postavljanje sistema evaluacije Agent toka rada, integracija Better Harness okvira za evaluaciju, pokrivanje razumevanja zadataka, kontrolisanog izvršavanja, verifikacije izmena, pouzdane isporuke i akumulacije znanja, čime se osigurava ukupan kvalitet Agenta tokom iteracija
ending
Ranije u backendu, takmičili ste se visokim istovremenim opterećenjem, distribuiranošću, middleware-om. Sada u Agentu, takmičite se upravljanjem konteksta, sigurnosnim ogradama, kontrolom halucinacija, evaluacijom efekata.
**Tehnički stek se menja, ali osnovna logika inženjerskih sposobnosti se ne menja - ko može sistem da učini stabilnim, pouzdanim i produkcionim, taj je redak."
Držite se, braćo i sestre.
Vidimo se u sledećem broju.