Nikola Trifunović je 15 godina gradio Bing. Sada gradi infrastrukturu Perplexityja — i radi u timu koji ne koristi mejlove za poslovnu komunikaciju.
Prošlog utorka smo imali peti AI Hub meetup u Beogradu. Sala je bila dupke puna — 105 ljudi, od čega više od polovine inženjeri, a skoro trećina menadžment.
Gost večeri bio je Nikola Trifunović, search engineer u Perplexityju. Pre toga je proveo 15 godina u Microsoftu radeći na Bingu — od klasifikatora za adult content do runtime search sistema. Sada gradi infrastrukturu koja stoji iza jednog od prvih AI proizvoda koji je citiranje izvora stavio u centar korisničkog iskustva.
Ako nisi koristio Perplexity: to je search engine koji umesto liste linkova daje strukturiran odgovor sa citatima. Svaka tvrdnja ima izvor. Ova arhitektonska odluka — razdvajanje pretrage od rezonovanja — provlačila se kroz dobar deo razgovora.
Ako gradiš RAG sistem, radiš sa pretraživačima, ili te jednostavno zanima kako AI kompanija zaista funkcioniše iznutra — ovo je za tebe.
Razdvajanje rezonovanja i pretrage
Jedno od pitanja iz publike bilo je direktno: zašto bi neko koristio Perplexity umesto ChatGPTja?
Nikola je objasnio:
Perplexity je bio prva kompanija koja je prepoznala da moramo razdvojiti rezonovanje i znanje.
Sve druge kompanije — GPT i svi ostali — stavile su sve u LLM i svi odgovori su dolazili iz memorije LLM-a.
Perplexity je prvi napravio infrastrukturu gde postoji jasna separacija između rezonovanja i informacija.
Drugim rečima: LLM rezonuje, ali ne pretražuje. Pretragu radi zaseban sistem — search engine — koji vraća konkretne dokumente sa izvorima. LLM ih samo sintetiše u odgovor.
Ova arhitektonska odluka ima jednu veliku posledicu: halucinacije se mogu kontrolisati na mestu gde nastaju, umesto da se naknadno love u tekstu koji je LLM generisao.
Retrieval funnel — arhitektura koja je stara 30 godina i još uvek radi
Da bi objasnio kako ta separacija izgleda iznutra, Nikola nas je proveo kroz arhitekturu koju koriste bukvalno svi — Perplexity, Google, Bing, LinkedIn, Netflix, Uber.
Ova arhitektura postoji skoro 30 godina. Problem je sledeći: imaš milijarde dokumenata, 100 milisekundi latency budžeta pre nego što korisnik ode, i modele koji su preskupi da obrade sve. Rešenje je retrieval funnel — levak sa tri nivoa.
Prvi nivo je candidate generation: od milijardi dokumenata dođeš do 10.000. Cilj je da ne propustiš ništa (recall). Koriste se jeftine, brze metode — inverted index, BM25, ili dense embeddings.
Drugi nivo je pre-ranking: od 10.000 dođeš do 500. Cilj je da očistiš smeće (precision). Koriste se malo skuplje modele, ali i dalje brze.
Treći nivo je ranking: od 500 dođeš do 10. Cilj je da poređaš tačno (NDCG). Ovde se koriste najskuplji modeli — cross-encoderi bazirani na LLM dekoderima.
Svaki nivo ima svoju metriku. Na primer, za prvi nivo se meri recall — da li su svi dobri rezultati u listi. Nikola je posebno naglasio prednosti ovog pristupa:
I ovo radi zato što je modularno. Možeš zameniti L1 sa nekim novim vector store-om bez da diraš L2 ili L3.
Ova modularnost ima još jednu prednost: ako nešto pođe po zlu, lako je locirati problem. Greška na L1 neće kaskadirati kroz ceo sistem na nepredvidiv način.
Da bi dočarao skalu, pomenuo je i šta Microsoft radi interno:
Microsoft je napravio novu platformu za vektorsku pretragu koja se zove Taze. Cilj im je da servira 100 milijardi dokumenata sa 512 dimenzija u par milisekundi.
Zašto u funelu nema halucinacija
Ako su svi zabrinuti zbog halucinacija — kako to da ih u ovom sistemu nema?
U funelu nema halucinacija. Koristimo klasifikatore ili rankere. To su deterministički ili statistički modeli — ne generativni.
Ovo je ključna razlika. Halucinacije nastaju kada LLM generiše tekst. Ali u retrieval funnelu ništa se ne generiše — samo se pretražuje, filtrira i rangira. Dokumenti koji izlaze iz L3 su pravi dokumenti koji zaista postoje u indeksu.
Naravno, LLM na kraju sintetiše odgovor i tu halucinacije mogu da nastanu. Ali razlika je u tome što sada LLM ima izvor istine — konkretne dokumente — umesto da se oslanja samo na svoju memoriju.
Kako merimo groundedness: svaka tvrdnja mora imati izvor — link ili dokument. Ako nema, ocena pada.
"The dream" — zašto end-to-end training ne radi
Ako je funnel tako dobar, zašto ga ne bismo trenirali kao jedan sistem? Zašto L3 ne bi mogao da kaže L1: "Daješ mi pogrešne kandidate"?
Nikola nas je proveo kroz ono što u industriji zovu "the dream" — i zašto taj san ne uspeva.
San je: da li možemo eliminisati ovu konstantnu serijalizaciju i deserijalizaciju? Da li L1, L2 i L3 modeli mogu zajedno da rade na rešavanju problema?
To može samo kroz end-to-end training. Istraživači pokušavaju decenijama.
Problem je strukturalan.
Kada dokumente serijalizuješ u indeks — bio to inverted index ili vector graph — gradienti ne mogu da teku unazad kroz tu operaciju. To je diskretna operacija. Nema derivata.
Bilo je pokušaja u istraživanju, ali ništa veliko nije izašlo iz toga — barem ne praktično primenjivo.
Dodatni problem je što u eri AI odgovora nemaš dovoljno signala za treniranje:
Postoji thumbs up dugme, ali niko ga ne koristi. Ljudi ga koriste, ali... malo.
Poenta je bila jasna: kada korisnik dobije savršen odgovor, jednostavno ode — nema klikova, nema povratne informacije na kojoj bi se model trenirao.
Agents — reframe umesto rešenja
Agenti ne zamenjuju funnel — oni ga orkestriraju. Nikola je objasnio kako to funkcioniše:
Možeš imati više funnela, ali su fiksirani. Agent odlučuje koji funnel da koristi.
Pokušavamo da razdvojimo stvari — šta dobijamo kroz dense retrieval, šta kroz sparse retrieval, šta kroz filtere i SQL-like upite, šta kroz knowledge graphs.
Nikola je pravio paralelu sa istorijom pretraživanja:
Pre Googla, imao si 20 različitih polja za unos — autor, datum, kategorija. Google je sve to spojio u jedan text box.
Sada se vraćamo na strukturirane upite — ali agent radi dekompoziciju umesto korisnika.
Schema over embeddings
Najbitniji deo vašeg search sistema nije model — nego schema.
Volimo da sve strpamo u jedan document embedding. Mislim da to nije dobra ideja.
Nikola je dao konkretan primer iz sopstvenog iskustva:
Document embeddings sami po sebi ne mogu da rade dobro. Ako treba da nađeš nešto po broju — dok sam radio na Bingu za lokacije, kada neko traži ulicu sa specifičnim brojem, embedding to nikada neće naći.
Brojevi ne nose dovoljno semantičke informacije.
Ulična adresa je jedan od najčešćih search slučajeva, a embeddings ga jednostavno ne podržavaju.
Treba da razumeš svoje podatke. Ako radiš sa patentima ili lokacijama — analiziraj kako ljudi pretražuju. Ako traže po gradu, državi, koordinatama — izdvoji to. Stavi u zasebne indekse.
Kategorije i opisi mogu da idu u embeddings. Ali imaj tu granularnost — i onda će agent popuniti ta polja i dobićeš mnogo efikasniju pretragu.
Patent search — kako to izgleda u praksi
Nikola je pokazao konkretan sistem na kojem je radio: pretragu patenata.
Primer upita: "Koji Samsung patenti su najsličniji Apple patentima za touchscreen scrolling iz 2008?"
Funnel nikada ne bi mogao da reši ovaj problem.
Ali agent koji razume koje alate ima na raspolaganju može da napravi plan.
Tri koraka: prvo semantička pretraga naslova i apstrakata uz filter po godini, koja pronalazi konkretni Apple patent. Zatim čitanje claims sekcije tog patenta i izvlačenje ključnih koncepata (kapacitivni dodir, overscroll gest, navigacija liste). I na kraju, pretraga patenata gde je assignee Samsung Electronics i claims su semantički slični izvučenim konceptima.
Tri koraka, tri različita tipa pretrage. Klasičan search box nikada ne bi mogao da podrži ovakav upit.
Naravno, ovo ima cenu:
Da li i ovo uvek dobijamo za 100 milisekundi? Ne. Imaš dva poziva, znači 200 milisekundi. Plus razmišljanje agenta između. Ovo obično ide u više sekundi.
Korisnici su OK sa tim jer alternativa ne postoji — ne takmičiš se sa drugim proizvodom, već sa nepostojanjem proizvoda. Ili korisnik mora da bude ekstremno specifičan u upitu, ili uopšte ne može da dobije odgovor.
Kako se meri uspeh agentic sistema
Ako agenti rade kompleksne multi-hop upite, kako znaš da li rade ispravno?
Nikola je upozorio da tradicionalne metrike nisu dovoljne za evaluaciju agentic sistema. Ponekad model halucinira samouvereno i na sreću dobije dobre rezultate — retrieval score je odličan, ali orchestration i groundedness su loši.
Rešenje je evaluacija na tri nivoa: kvalitet pretrage (NDCG, precision, recall — po svakom pozivu pretrage), kvalitet orkestracije agenta (logička konzistentnost plana, efikasnost), i end-to-end evaluacija kroz RAG trijadu — relevantnost konteksta, relevantnost odgovora, groundedness.
AI-first kompanija — kako to izgleda iznutra
Druga polovina večeri bila je posvećena iskustvu rada u Perplexityju.
Nisam napisao liniju koda poslednjih par meseci. Naša kompanija je usvojila AI-first pristup.
Čak i kada ne radi savršeno, i dalje insistiramo da naučimo kako da radimo sa tim. Ali većinom radi odlično. Koristimo Claude Code većinu vremena.
Na pitanje da li mogu da koriste šta hoće ili imaju mandate:
Možemo da koristimo šta hoćemo. I mislim da su mi API troškovi veći od plate.
Tok rada izgleda ovako: Nikola napiše specifikaciju zadatka u Linearu sa referencama na dokumentaciju, poveže se na tu specifikaciju kroz MCP i kaže agentu da krene.
Većinu vremena radi odlično.
Za code review isto koriste agente — agent prolazi kroz promene i daje feedback pre nego što kolege uopšte pogledaju PR.
Intervjui — AI je dozvoljen, a ako ga ne koristiš, to je problem
Kada sam se ja intervjuisao u septembru, AI je bio dozvoljen. Agenti tada nisu bili toliko dobri kao sada, i verovatno nisam znao da ih koristim kako treba.
Ali generalno — AI je dozvoljen. I ako ne koristiš AI na intervjuu, to je red flag.
Kulturni šok — startap posle korporacije
Nikola je bio otvoren o tranziciji iz Microsofta u Perplexity.
Razlike nisu samo u tome kako se radi — nego i kako se komunicira, ko učestvuje, i koliko brzo moraš da se snađeš.
Kada sam poslao svoj prvi mejl — izveštaj šta sam radio te nedelje — kolege su mi se smejale. U Perplexityju ne čitamo mejlove.
Ovde je samo Slack — i to sa celim vertikalama gde se CTO ili CEO priključe ako žele da prate projekat. I to nije formalnost:
Na jednom projektu na kojem radim, Aravind [CEO] je bio u kanalu. Postaviš update i velika je verovatnoća da će on odgovoriti.
Na pitanje o jezičkoj barijeri — većina tima su bivši Yandex inženjeri:
Kako se nosim sa tim? Prilično dobro, za sada. Logično je — većina ljudi dolazi iz Yandexa, a Yandex je imao odličan track record u search prostoru. Imali su najbolji pretraživač u Evropi.
Ali definitivno mislim da nam treba više srpske krvi i pozivam vas da nam se pridružite.
A onboarding? Ne postoji — bar ne u korporativnom smislu:
U poređenju sa Microsoftom — kada dođeš u Microsoft, postoji neko ko će te voditi prvih par meseci. To se neće desiti u Perplexityju. To je startap.
Moraš da pokažeš inicijativu. Meni su rekli: imamo problem ovde. Ti ideš tamo, i sam smisli šta ne radi dobro i popravi.
Šta dalje
Perplexity ima kancelariju u Ušće Tower 2 u Beogradu.
Dva tima su tamo: Core Search tim (ono što je Nikola opisao večeras) i Search Infrastructure tim (održavanje podova, modela, vektorskih baza).
Agent tim nije u Srbiji, on je u San Francisku, a ovde je i tim za Comet browser — Perplexityjev AI-native pretraživač.
Imamo mesta za 100 inženjera, ali samo 50 je popunjeno. Tako da tražimo još ljudi.
Slajdove sa ovog događaja možete preuzeti ovde (PDF).
