Posle intervjua, uzvratio sam pitanjem: "Zar je za praksu toliko teško?" Intervjuer: "Dobro razumeš RAG, Agent, MCP, Skill, zato su zahtevi viši."

Stari Wang danas nosi crnu majicu, na grudima beli natpis "My code does compile", brada mu je pomalo čekinjasta — verovatno nije brijao nekoliko dana.

Na stolu mu je ledeni americano, čini se tek spremljen, ali do sada nije stigao ni gutljaj.

"Prema tebi imam visoke zahteve." Stari Wang otvoreno kaže. "Nemoj da se nerviraš."

(Inner monolog: Drug, video sam ja i veće oluje, uopšte se ne plašim, samo napred.)

Ali iskreno, ovaj intervju je zaista bio jak, skoro do izdisaja. (osmeh)

Braćo i sestre, pogledajte ova pitanja — zaista, prosečan čovek to ne izdrži.

Vezite sigurnosni pojas, idemo.

content

01. U tvom RAG projektu, kako si dizajnirao sečenje? Zatim, kako si radio parsiranje sadržaja, vektorizaciju, i kako se radi pretraga i priziv?

Rekoh: "Podeliću u četiri bloka — sečenje, parsiranje, vektorizacija, priziv."

Stari Wang klima glavom, nasloni se u stolici — spreman za moje dugotrajno izlaganje.

Sečenje: PaiSmart koristi višenivovno semantičko sečenje, po progresiji pasus → rečenica → reč → znak. Podrazumevana veličina chunk-a je 512 bajtova, bez overlap-a.

Stari Wang ovde ubaci: "Nema overlap-a, ne plašiš se cepanja semantike?"

Kažem: "I o tome smo razmišljali. Kasnije smo otkrili da overlap u kineskom scenariju daje prosečne rezultate — čak znači da isti sadržaj u ES-u stoji duplo, pa priziv onda na vrhu ima nekoliko isečaka iz istog pasusa, što zapravo troši topK kvotu. Naš pristup je da pored chunk-a održavamo roditeljski blok od 1MB koji se učitava strimovanjem da se izbegne OOM, a chunk služi samo za vektorski priziv — kad se pogodi, vraćamo se na roditeljski blok kao kontekst za veliki model."

Stari Wang-ove oči se malo rasvetliše, ništa ne reče, samo mi dade znak da nastavim.

Parsiranje: koristimo Apache Tika 2.9.1, automatsko prepoznavanje formata, podržava PDF, Word, Excel, PPT, Markdown, HTML. PDF obrađujemo posebno preko PDFBox-a, sečemo po stranicama i istovremeno uklanjamo duplicirane header/footer znakove. Dugačke kineske rečenice se tokenizuju pomoću HanLP StandardTokenizer.

Vektorizacija: ide preko Alibaba Qwen text-embedding-v4, dimenzija 2048, poziva se preko API-ja kompatibilnog sa OpenAI protokolom, najviše 10 u batch-u.

Priziv: ovo je glavna tačka. Koristimo ElasticSearch, indeks knowledge_base, vektorsko polje dense_vector, sličnost preko kosinusne mere. Radimo hibridni priziv KNN + BM25 — KNN prvo grubo priziva topK × 30, a zatim BM25 u tom prozoru radi rescore, konačno vraća topK.

Stari Wang posle slušanja kaže: "U redu, jasno si izložio, dobro."

Ova prosta rečenica mi je dala mnogo podrške, iskreno.

02. Zašto Qwen, i zašto vektor sa 2048 dimenzija?

Kažem: "O ovome sam zaista istraživao."

Qwen v4 embedding model u kineskom scenariju daje jako dobre rezultate, posebno za tehničku dokumentaciju sa mešavinom koda, engleskog i kineskog objašnjenja.

Upoređivali smo — za isti Spring Boot tutorijal, tačnost priziva Qwen-a bila je za više od deset procenata viša nego kod jednog drugog vektorskog modela.

Stari Wang nastavlja: "A 2048 dimenzija? Qwen v4 podržava 1024, 1536, 2048 — tri nivoa. Zašto najveći?"

Glavno dva razloga.

Prvo, preciznost — što veća dimenzija, to jača izražajna moć vektorskog prostora i bolja diferencijacija za dugačke tekstove i stručne termine.

Drugo, na strani ES-a smo izmerili trošak skladištenja i računanja — 2048 u odnosu na 1024 daje oko 8KB više po vektoru, indeks knowledge_base trenutno ima na stotine hiljada zapisa, tako da povećani pritisak na skladište prihvatljiv.

Pretraga, pošto ima BM25 kao podupiruće preuređivanje, povećanje vremena KNN-a je u okviru prihvatljivog.

Stari Wang prstima lagano kucnu po stolu: "To što si cenu računao — dobro. Nastavi."

Inner monolog: hehe, ovo pitanje me je jednom zapelo, pa sam se vratio i onda učio.

03. Kako radi taj KNN vektorski priziv i BM25 preuređivanje?

KNN koristi ES 8.x ugrađeni _knn_search interfejs.

Konkretno, parametar recallK = topK × 30 — na primer ako treba vratiti 10, KNN prvo grubo priziva 300.

BM25 ide preko ES rescore mehanizma — u prozoru od 300 koje je KNN prizvao još jednom se rangira.

Težine su KNN 0.2, BM25 1.0 — BM25 je dominantan.

Stari Wang podiže obrve: "Zašto BM25 dominantan, a ne KNN? Zar danas mainstream nije vektorski priziv?"

Pravili smo A/B test — čist KNN u scenariju sa dugačkim dokumentima zna da da "semantički blizu, ali odgovor na pogrešnom mestu". Na primer, korisnik pita "kolika je veličina chunk-a PaiSmart-a", čist KNN prizove gomilu pasusa o strategijama sečenja, ali konkretan broj 512 se ne nađe visoko.

BM25 je osetljiv na pogotke ključnih reči — zna da podigne pasuse koji sadrže '512', 'chunk-size'. Zato BM25 donosi konačnu odluku, a KWN obezbeđuje skup kandidata.

Stari Wang se nasmeši, delujući zadovoljno ovim odgovorom.

04. Šta je BM25?

BM25 je klasičan algoritam za bodovanje relevantnosti teksta, pun naziv Best Matching 25, u istoj je lozi sa TF-IDF.

Jezgro se sastoji od tri tačke: učestalost reči (TF), inverzna dokumentna frekvencija (IDF), normalizacija dužine dokumenta.

Što se reč više pojavljuje u trenutnom dokumentu, to je značajnija za njega; što je reč češća u svim dokumentima (na primer "i", "je"), to je njena težina niža; što je dokument duži, to je težina pojedinačne reči nešto niža, jer dugi dokumenti prirodno imaju prednost.

ES podrazumevano koristi BM25 kao mernik sličnosti, sa dva parametra — k1 kontroliše brzinu zasićenja učestalosti reči, podrazumevano 1.2; b kontroliše jačinu normalizacije dužine, podrazumevano 0.75. Mi ta dva parametra nismo menjali.

Stari Wang nastavlja: "U čemu je BM25 jači od TF-IDF?"

Najvažnije, parametar k1 uvodi zasićenje učestalosti reči.

U TF-IDF-u učestalost raste linearno — dokument u kom se reč pojavljuje 100 puta ima deset puta veći rezultat od onog sa 10 puta, što je očigledno nelogično.

BM25 formulom (k1+1)*tf / (k1+tf) čini rast učestalosti ograničenim gornjom granicom, što je u skladu sa ljudskom intuicijom.

05. Tokom izrade ovog projekta, koja ti je iskustva ostavila i koliko je ljudi radilo na njemu?

Jezgro razvoja tima su 3 osobe — ja i još dva cimera, plus naš mentor Erge.

Ako je reč o spoznajama, najdublja je: RAG — da li radi dobro, 70% zavisi od podataka, 20% od priziva, 10% od modela.

Na početku smo udarali glavom o model, doterivali prompt, rezultati nisu išli gore. Onda smo se vratili sečenju — smanjili sa 1024 na 512 i dodali semantičko granicu sečenja — tačnost priziva je drastično skočila.

Stari Wang klima glavom: "I ja imam to iskustvo. Ima još?"

Još jedna — produkcioni RAG i demo RAG su dve različite stvari.

Demo sa vektorizacijom + prizivom + LLM-om u tri koraka može da se radi za nedelju dana, ali kad se dodaju izolacija prava, multi-tenancy, deduplikacija fajlova, streaming upload, postepeno ažuriranje — obim posla se uveća deset puta.

Samo prava smo radili u tri sloja filtriranja — userId, orgTag, isPublic.

06. Koliko je AI uzeo udela u ovom projektu?

Što se tiče generisanja koda, oko 60% koda je napisao Codex, uključujući mapper, CRUD servisa, ES mapping konfiguraciju, omotač oko Qwen API-ja.

Stari Wang pita još: "A preostalih 40%?"

Preostalih 40% je ključna poslovna logika — na primer strategija sečenja, podešavanje težina hibridnog priziva, prompt inženjering, optimizacija performansi.

Prva verzija koju AI napiše uglavnom ne može da se koristi direktno, zahteva da mi kombinujemo sa stvarnim podacima i iterativno doterujemo.

07. Koliko je vreme odziva ElasticSearch KNN vektorskog priziva?

Nismo radili poseban SLA test, ali po logovima instrumentacije, ukupno vreme KNN + BM25 rescore-a je između 50ms i 120ms, u proseku oko 80ms.

Stari Wang nastavlja: "Šta na to vreme najviše utiče?"

Glavno tri faktora.

Prvo, količina podataka — u indeksu knowledge_base prelazak sa 100 hiljada na 500 hiljada zapisa usporava jedan upit.

Drugo, podešavanje recallK — probali smo topK × 50, kvalitet priziva se nije primetno popravio, ali vreme je poraslo, pa smo se zaustavili na × 30.

Treće, opseg pogođenih dokumenata — ako su ključne reči korisnikovog upita previše široke, prozor BM25 rescore-a postaje veći i vreme raste.

08. Zašto ste za ovo koristili ES?

Zato što jedan indeks istovremeno podržava i pretragu teksta i vektorsku pretragu.

Da smo koristili namensku vektorsku bazu kao Milvus ili Qdrant, pa posebno podigli jedan sustav za pretragu ključnih reči, troškovi održavanja i sinhronizacije podataka bi porasli. ES 8.x dense_vector je dovoljno dobar, nema potrebe za uvođenjem nove komponente.

Stari Wang nastavlja: "Da li poznaješ ES podatkovnu strukturu ispod?"

Pretraga teksta ide preko klasičnog Lucene inverted indeksa — posle tokenizacije dokumenata gradi se mapiranje reč → dokument, a pri upitu se direktno traži reč.

Vektorska pretraga u ES 8.x koristi HNSW (Hierarchical Navigable Small World) algoritam — ukratko, struktura sa više slojeva grafova, od retkog gornjeg sloja se ulazi i sloj po sloju pretražuje sve detaljnije, u O(log n) složenosti pronalazi približne najbliže susede.

Stari Wang očigledno ima duboko istraživanje u ovom području — na pomen HNSW-a klimnuo je glavom.

U uobičajenim tipovima upita ES uglavnom ima: term za tačno podudaranje, match za podudaranje sa tokenizacijom, bool za kombinovane upite, range za opseg, aggregation za agregaciju.

U našem projektu najčešće koristimo kombinaciju bool + match + filter — bool uključuje must/should/filter, should služi za filtriranje prava, filter za tvrda ograničenja bez učešća u bodovanju.

Stari Wang se nasmeši: "Ovo je jasno shvaćeno."

09. Koji AI model se koristi?

U projektu koristimo dva AI modela — jedan za embedding, drugi LLM.

Embedding koristi Alibaba Qwen text-embedding-v4, 2048 dimenzija.

LLM je DeepSeek-chat, preko zvaničnog API-ja (api.deepseek.com/v1).

Stari Wang nastavlja: "Zašto za LLM DeepSeek, a ne Qwen ili GLM?"

Pre svega, odnos cena/kvalitet.

Izlazni kvalitet DeepSeek-a je u top ligi, a cena API-ja samo je nekoliko desetina puta manja od GPT-ove — što nam posebno odgovara.

10. Kako u svakodnevnom radu koristiš AI za programiranje?

Claude Code uglavnom koristim za obradu teksta, Codex za kodiranje.

Radi lakšeg korišćenja, u IntelliJ IDEA-u sam takođe priključio Codex — za čitanje koda je izuzetno zgodan; za Claude Code sam napravio PaiSwitch konzolu, koja može da prebacuje model ispod haube — Kimi i GLM takođe koristim.

Stari Wang pita još: "Koje Skill u Claude Code-u koristiš?"

Frontend-design (frontend dizajn), Skill-creator, web-access itd. — ovaj poslednji je najkorisniji, može Agent-u da podigne sposobnost interneta do maksimuma, a ako neki sadržaj zahteva prijavu, ovaj Skill preko cdp-a direktno povezuje karticu Chrome-a koja je već prijavljjena.

11. Kako znaš da li je AI dobro odradio?

Trenutni pristup mi je u tri sloja.

Prvi sloj, neka AI sam ponudi plan verifikacije. Na primer, kad završi interfejs, tražim od njega da ponovo pokrene jedinične testove ili da napiše curl komandu za proveru.

Drugi sloj, ključne putanje mora da pregleda više Agenata. Na primer, kad Codex završi kod, ja pokrenem Qoder-ov ekspertski tim za testiranje.

Treći sloj, lično testiranje. Iako Codex može preko computer use da kontroliše pregledač za testove, neke tvrdoglave probleme Agent još uvek ne može da dosegne — i dalje moraš lično da testiraš.

12. Da li pratiš tehniološke novosti? Na koji način?

Pre svega preko X-a, GitHub trending-a, Hacker News-a — ta tri kanala.

Na X-u pratim grupu aktivnih developera i zvaničnih naloga, uključujući velike kompanije kao Anthropic, OpenAI, DeepMind i pojedinačne developere poput swyx-a, karpathy-ja.

Pratim i nalog pod imenom "Ergeovi pomoćnici", koji svakog dana deli hardcore AI znanje — mnogo sam naučio.

Hacker News preko OpenClaw-a sam podesio zakazani zadatak koji mi svakog jutra šalje email sa top 30 postova i sažetkom komentara prethodnog dana — čovek se lepo obavesti.

13. Ako bismo ovaj RAK želeli da unapredimo u agenta, šta bismo radili?

Tri ključne izmene.

• Prvo, promeniti pretragu iz "jednokratnog upita" u "petljani upit" — model na osnovu međurezultata odlučuje da li da pita još i šta da pita.
• Drugo, uvesti pozive alata — pored pretrage baze znanja, dodati pretragu interneta, SQL upite, čitanje/pisanje fajlova i druge atomske sposobnosti.
• Treće, dodati planer (Planner) — model prvo razbija korisničko pitanje na podzadatke, a zatim ih redom izvršava.

Stari Wang nastavlja: "Konkretno za PaiCLI Agent, kako bi menjao?"

Najjednostavnije rešenje je uvesti ReAct petlju.

Model prvo razmišlja, zatim deluje, pa posmatra rezultat, pa ponovo razmišlja — i tako u krug.

Poziva ES pretragu, posmatra šta je ElasticSearch vratio. Sve dok model ne izbaci Final Answer, petlja se ne završava. Taj mehanizam LangChain, LangGraph već imaju gotov, prebacite i koristite.

Ali za produkciju, morate dodati još nekoliko stvari:

timeout i maksimalan broj tura (da se izbegne beskonačna petlja), perzistencija međustanja (da jedan neuspeh ne baci sve iz početka), interfejs za ljudsku intervenciju (ključne odluke zahtevaju potvrdu).

14. Kako razumeš skills, mcp i tool?

Ove tri stvari u Claude Code-u često idu zajedno, ali im je pozicija različita.

Tool je atomična sposobnost na najnižem nivou — čitanje fajla, pokretanje komandne linije, upit nad bazom. Svaki Tool je potpis funkcije + deo logike izvršenja. Model poziva Tool preko Function Calling-a, parametri i povratne vrednosti su strukturirani JSON.

MCP je standardizovani protokol za Tool. MCP definiše ujednačen protokol, tako da se Tool može zapakovati kao nezavisan Server i biti pozvan od bilo kog klijenta koji podržava MCP. Claude Code, Codex i slični alati podržavaju MCP.

Skill je pakovanje toka rada. To je kompletna metodologija "kako se nešto radi", obuhvata prompt šablone, redosled poziva, logiku odlučivanja, čak i pozive pod-Skill-ova. Anthropic Skill stavlja u direktorijum .claude/skills/, gde je svaki Skill jedna fascikla koja sadrži SKILL.md (opis), references (referentni materijali), scripts (pomoćne skripte).

Stari Wang nastavlja: "Da li su ovo tri u odnosu sadržanja?"

Ne potpuno.

Tool je atomska sposobnost, MCP je transportni protokol za Tool, Skill je napredna sposobnost orkestrirana preko Tool-a i prompt-a.

Možemo ovako uporediti: Tool je kao komanda cat, grep, awk u Linuxu; MCP je kao shell — taj unifikovani interfejs; Skill je kao gotova shell skripta.

Stari Wang na ovu poredbu ne izdrža da se nasmeje: "Poređenje je prilično tačno."

15. U stvarnoj upotrebi, šta tokom AI programiranja koristiš najviše?

Skill najviše, MCP drugi, izvorni Tool najmanje.

Tool je na niskom nivou, Agent ga već zatvara.

MCP — trenutno najviše koristim Chrome Devtools MCP i IntelliJ IDEA, koji se priključuju Agent-u.

Skill — trenutno koristim mnogo. Ako na GitHub-u postoji gotov, dobar, uzimam ga direktno. Ako nema odgovarajućeg, ostavljam Agent da ga generiše prema mog tokovima rada.

Stari Wang pita još: "Ima li Skill neku zamku?"

Najveća zamka je što ako opis Skill-a nije dobro napisan, model ga neće aktivno okinuti.

Polje description u Skill-u je zapravo klasifikator — kad model vidi korisnički zahtev, ocenjuje da li da učita taj Skill. Ako je description previše širok, zna da bude lažno okinut.

16. Da li si sam pisao skills? Ako ne, da li si bar video konkretnu implementaciju skills-a?

Pisao sam ih prilično.

Na primer, ranije sam destilovao Wang Xiaobo.skill, ispalo je prilično zanimljivo.

Stari Wang-ove oči se odmah rasvetliše: "Možeš li da ispričaš kako si ga pisao?"

Jezgro Skill-a su tri fajla.

Prvi je SKILL.md — u frontmatter piše name i description, telo je tok rada. Drugi je references direktorijum, sa referentnim materijalima — vodič za stil, uzorke istorijskih članaka. Treći je scripts direktorijum, sa pomoćnim skriptama — na primer Python skripta za brojanje reči.

Stari Wang posle toga duboko uzdahne: "Dobro, tu smo otprilike završili."

Ja uzvratih pitanjem: "Zar je za praksu zaista potrebno toliko intenzivno?"

Stari Wang se nasmeši: "Dobro razumeš RAG, Agent, MCP, Skill, pa su zahtevi malo viši. Malo kasnije će HR razgovarati s tobom."

Napuštajući salu za sastanke, bacih pogled na telefon — prošlo je pun sat i po.

Inner monolog: Stari Wang ima dobru kondiciju, još uvek može da pita — a ja skoro da više ne mogu da izdržim.