U menzi, kolega pita: Što stalno pričate o Embedding-u, Rerank-u, šta je to? Službenica na izdavanju hrane uskače: To je da LLM razume ljudski govor. Divim se, divim.
Bilo da je Claude Code ili Codex, pri čitanju izvornog koda projekta ili baze znanja su izuzetno jaki — pitajte šta god hoćete, tačno lociraju odgovarajući blok koda ili dokument.
Kako se to postiže?

Iza toga stoji zasluga Embedding-a.
U današnjem tekstu polazimo od principa Embedding-a i Rerank-a, u vezi sa stvarnim implementacijama PaiSmart RAG i PaiCLI Agent projekata, da potpuno razjasnimo ova dva segmenta znanja.

01. Zašto nam treba RAG?
Sposobnosti današnjih modela su veoma jake, bilo da je GPT-5.5 ili Opus 4.7.
U suštini, svakodnevno kodiranje i deo tekstova može se prepustiti njima.
I kvalitet je visok.
Ali postoje dva problema koje LLM teško rešava.
Prvo, datum prekida znanja.
Nakon završetka treniranja, znanje modela se zamrzava u tom trenutku. Šta se dogodilo u maju 2026, model završen 2025. ne može da zna.
Drugo, slepilo za privatne podatke.
Interna dokumentacija kompanije, repozitorijumi koda, podaci o klijentima — sve što nije bilo u podacima za treniranje, model uopšte ne prepoznaje.
Trenutno postoje dva rešenja — jedno je pretraga interneta, koja Agentu daje trenutni pristup najnovijem znanju.

Drugo je RAG. Ideja je jednostavna: pre nego što se pita, iz baze znanja izvuci relevantan sadržaj i ubaci ga u kontekst LLM-a, da radi "otvorenu knjigu".
Jezgro ove tehnike pretrage je Embedding.

02. Šta je Embedding?
Embedding pretvara tekst u skup vektora, čime računar semantički razume jezik matematičkim putem.
Na primer, "Wang Er je glup" i "Wang Er verovatno nije normalan" u semantičkom smislu su potpuno isti.
Embedding radi sledeće: pretvara ove dve rečenice svaku u 2048-dimenzionalni vektor (skup od 2048 floating-point brojeva), a zatim računa kosinusnu sličnost između ova dva vektora da bi se dobilo "koliko su slični".
U vektorskom prostoru, tekstovi slične semantike se grupišu zajedno, a tekstovi različite semantike se razdvajaju. "Mobitel jabuka" i "iPhone" imaju vektorsko rastojanje malo, dok "mobitel jabuka" i "svinja koja se penje na drvo" imaju veliko rastojanje.

Embedding model koristi arhitekturu sa dva tornja (Bi-Encoder).
Query i dokument se nezavisno kodiraju u vektore, bez međusobnog ometanja.
Ova arhitektura ima ogromnu prednost: vektori dokumenata se mogu unapred izračunati i sačuvati, pa pri upitu dovoljno izračunati vektor Query-ja i porediti sličnost.
Pretraga kroz nekoliko miliona dokumenata — u milisekundama.
03. Kako dobro odraditi Chunk?
Embedding model ima ograničenje ulazne dužine (obično 8192 token-a), pa je nemoguće ubaciti dokument od desetinama hiljada znakova u jednom komadu. Zato dokument prvo treba iseći na komade (Chunk), pa svaki komad posebno Embedding-ovati.
Da li je Chunk dobro odsečen, direktno određuje kvalitet pretrage.
Ako je prevelik, u jednom Chunk-u bude više tema, pa pri pretrazi uvučeš gomilu irrelevantnih informacija. Ako je premali, kontekst puca i LLM dobije isečke koji se ne uklapaju.
Strategija sečenja PaiSmart-a koristi semantički svestrano sečenje, podrazumevana veličina chunk-a 512 znakova, preklapanje 100 znakova. Pri sečenju se ne radi mehaničko odsecanje po broju znakova, već se koristi HanLP za kinesku segmentaciju i trudi se da seče na granicama rečenica.

Konkretno, podeljeno je u četiri nivoa:
- Prvi nivo prvo seče po pasusima (dvostruki novi red
\n\n) - Drugi nivo, ako je pasus predug, seče po rečenicama
- Treći nivo koristi HanLP tokenizator na granicama reči
- Četvrti nivo, ako ništa drugo ne može, seče po znakovima.
Tako svaki Chunk bude semantički kompletan.
Zona preklapanja (Overlap) je takođe pažljivo određena. PaiSmart ne uzima jednostavno poslednjih 100 znakova prethodnog Chunk-a, već radi semantički svestrano preklapanje, koristi rezultat HanLP segmentacije da nađe odgovarajuću granicu rečenice, čime se obezbeđuje da preklapanje ne prepolovi reč.
Strategija sečenja PaiCLI-ja je potpuno drugačija, jer obraduje kod, a ne dokument.
Kod ima prirodnu strukturu — fajl, klasa, metod — te strukture su same po sebi najbolja granica sečenja. PaiCLI koristi JavaParser za AST parsiranje, sekući Java kod na tri nivoa: nivo fajla (ceo fajl kad je prevelik, ne koristi se), nivo klase (deklaracija klase plus prvih nekoliko redova), nivo metoda (svaka metoda kao poseban komad). Ne-Java fajlovi se seku po 2000 znakova.

Ovakvo sečenje na osnovu AST je znatno preciznije od sečenja po broju redova. Jedna metoda je jedna kompletna semantička jedinica, ne dolazi do situacija kao "gornja polovina je if, donja else".
04. Embedding u PaiSmart-u
PaiSmart je RAG baza znanja koju smo napravili — korisnik otprema dokument i može pitati prirodnim jezikom, sistem iz dokumenata izdvaja relevantne isečke i prosleđuje LLM-u radi generisanja odgovora.
Za Embedding, PaiSmart podrazumevano koristi Alibaba Qwen text-embedding-v4 model, dimenzija vektora 2048, preko OpenAI-kompatibilnog interfejsa. Takođe podržava prebacivanje na Zhipu embedding-3 model, takođe 2048 dimenzija.

Način poziva je paketni.
EmbeddingClient šalje tekst u serijama (podrazumevano 10) API-ju, sa automatskim retry mehanizmom (3 pokušaja, razmak 1 sekund), kao i rate limit (60 poziva/min) i praćenje kvote.
Vektorsko skladište ide preko Elasticsearch-a.
Vektor od 2048 dimenzije generisan za svaki Chunk se čuva u ES indeksu knowledge_base, pri upitu radi KNN pretragu. Prednost ES-a je prirodna podrška za hibridnu pretragu — može istovremeno vektorsku pretragu sličnosti (KNN) i podudaranje ključnih reči (BM25), čime se dva puta rezultata stapaju u rangiranju.

Konkretna implementacija ove hibridne pretrage nalazi se u HybridSearchService.

Prvo KNN priziva topK × 30 kandidata (na primer topK=5 → 150), a zatim BM25 radi rescore i ponovo rangira. Težina KNN-a 0.2, težina BM25 1.0, što znači da je konačno rangiranje dominantno zasnovano na podudaranju ključnih reči, uz semantičku sličnost kao sporedni faktor.
Zašto je težina podudaranja ključnih reči toliko visoka?
Jer u kineskom scenariju, pitanja korisnika često sadrže vrlo jasne ključne reči (na primer "proces povrata novca", "prava odobrenja"), i isečci dokumenata u kojima se te ključne reči tačno podudaraju su najčešće najrelevantniji. Čista semantička pretraga može biti poremećena isečcima koji "značenjski liče, ali ne pričaju o toj stvari".
05. Embedding u PaiCLI-ju
PaiCLI je Agent CLI alat koji smo napravili, sa ugrađenom funkcijom semantičke pretrage koda. Prirodnim jezikom opišete kod koji tražite i on iz celog projekta nalazi najrelevantnije blokove koda.
Za razliku od PaiSmart-a, PaiCLI koristi lokalni Embedding model, preko Ollama-e pokreće nomic-embed-text.
Pre korišćenja projekat se mora indeksirati:
> /index
🔍 Početak indeksiranja: /Users/itwanger/Documents/GitHub/paicli
📁 Pronađeno 42 fajla za indeksiranje
Napredak: 10/42 (Main.java)
...
✅ Indeksiranje završeno: 238 blokova koda, 156 relacijaPosle indeksiranja možete pretraživati prirodnim jezikom:
Kako je implementirana ReAct petlja Agent-a
Ispod haibe radi sledeće: svaki blok koda posle Embedding-a generiše vektor koji se čuva u lokalnoj SQLite bazi (JSON serijalizacija). Pri pretrazi se i tekst upita Embedding-uje, zatim se prolazi kroz sve vektore blokova koda i računa kosinusna sličnost, uzima se topK rezultata.

U CodeRetriever-u je implementirana hibridna pretraga — nije samo semantička, već ima i bodovanje ključnih reči. Ako ime klase ili ime metode bloka koda sadrži ključnu reč upita, daje se bonus +0.3. Ako putanja fajla sadrži ključnu reč, +0.1. Ako je blok koda na nivou metoda (neposredan odgovor), dodatno +0.15. Ako i semantička i pretraga ključnih reči pogode isti blok koda, dodatni bonus +0.1 za dvostruki pogodak.
Ovaj višestepeni Boost mehanizam, iako ne koristi namenski Rerank model, u scenariju pretrage koda daje odlične rezultate. Jer je samo imenovanje koda jak semantički signal — metoda se zove runReactLoop, pri pretrazi "ReAct petlja" ključna reč direktno pogađa.
06. Qwen Embedding
PaiSmart podrazumevano koristi Qwen text-embedding-v4 — da vidimo zašto baš on.
Qwen Embedding ide preko OpenAI kompatibilnog interfejsa.
2048-dimenzionalni vektor balansira preciznost i trošak skladištenja. Što veća dimenzija, to bogatija semantička izražajnost, ali i veći trošak skladištenja i računanja. 2048 je trenutno mainstream izbor za kineski Embedding.

Qwen3-Embedding je open source verzija text-embedding-v4, na MMTEB višejezičnoj listi za pretragu pokazuje jake rezultate. U kombinaciji sa Qwen3-Reranker-4B može formirati "efikasan priziv + precizno preuređivanje" kombinaciju, sa višestrukim rundama pretrage tačnost za 15-20% veća nego kod jednog modela.

PaiSmart takođe podržava dinamičku promenu provider-a Embedding-a.
U ModelProviderConfigService podešene su dve opcije — Alibaba Cloud i Zhipu AI, može se menjati u toku rada.

Ali obratite pažinu: posle promene Embedding modela, stari vektori postaju nevažeći, morate sve dokumente ponovo Embedding-ovati i obnoviti indeks. Jer vektori koje generišu različiti modeli pripadaju različitim semantičkim prostorima, njihovo mešanje dovodi do haosa u rezultatima pretrage.
07. Ollama nomic-embed-text
Razlog zašto PaiCLI bira nomic-embed-text je jednostavan: besplatan, lokalni, brz.
nomic-embed-text je open source Embedding model autora Nomic AI, Apache 2.0 licenca, može se koristiti komercijalno. Preko Ollama-e se pokreće jednom komandom:
ollama pull nomic-embed-textNajnovija V2 verzija koristi MoE (mixture of experts) arhitekturu, ukupno 475M parametara, aktivnih samo 137M, dovoljno mala da radi na CPU. Podržava Matryoshka representation learning, pa se dimenzija vektora može komprimirati sa 768 na 256 pa i na 64, uz minimalan gubitak značajno smanjujući troškove skladištenja.
Podržava Embedging za preko 100 programskih jezika, u scenarijima koda daje znatno bolje rezultate od opštih modela za tekst. PaiCLI ga je izabrao upravo zbog te sposobnosti razumevanja koda.

Međutim, nomic-embed-text ima jedno ograničenje — performanse padaju kod dugačkih tekstova. Prema testu Milvus-a (2026), posle 4000 znakova (oko 1000 token-a) kvalitet pretrage primetno opada. PaiCLI je preduzeo odgovarajuću meru — ograničio ulaz svakog Chunk-a na 2000 znakova.
Ako scenarij zahteva jače sposobnosti za dugačke tekstove, može se preko env varijable prebaciti na OpenAI ili Zhipu Embedding model:
EMBEDDING_PROVIDER=openai
EMBEDDING_MODEL=text-embedding-3-large
EMBEDDING_BASE_URL=https://api.openai.com/v1
EMBEDDING_API_KEY=sk-xxx08. Koja je razlika između Embedding-a i Rerank-a?
Ovo su dva koncepta koja mnogi mešaju.
Embedding radi priziv, brzo pronalazi top-50 moguće relevantnih isečaka iz stotina hiljada dokumenata. Brzina je prvi prioritet, u milisekundama.
Rerank radi precizno rangiranje, iz top-50 koje je Embedding prizvao bira najzaista relevantnih top-5 za LLM. Preciznost je prvi prioritet, sme da bude spor.
Arhitektonski su potpuno različiti.
Embedding koristi Bi-Encoder (model sa dva tornja), Query i dokument se nezavisno kodiraju. Rerank koristi Cross-Encoder (ukršteni koder), Query i kandidat dokument se spajaju i zajedno ubacuju u model, što modelu omogućava da vidi interakcije između njih u sitnim detaljima.

Da pojednostavnimo.
Embedding je kao kad u biblioteci pretražuješ ključne reči preko sistema — za nekoliko sekundi nađeš 50 knjiga koje su možda relevantne. Rerank je kao da te 50 knjova staviš na sto i iznova listaš sadržaj i sažetke, birajući 5 zaista najrelevantnijih. Sistema je brz ali ne i nužno tačan, ljudski odabir je tačan ali spor.
Trenutno mainstream Rerank modeli uključuju jina-rerank-v3 (Jina AI, specijalno optimizovan za Agentic-RAG), Qwen3-Reranker-4B (Alibaba Qwen, vodeća preciznost za kinesko semantičko razumevanje, MMTEB-R 72.74), bge-reranker-v2-m3 (BAAI, posle kvantizacije ispod 200MB, pogodan za edge deployment).
PaiSmart trenutno ne koristi nezavisan Rerank model, već koristi Elasticsearch-ov BM25 rescore za preuređivanje. KNN prvo priziva kandidate, a BM25 zatim prebodira na osnovu podudaranja ključnih reči.
Ovaj pristup u kineskom scenariju daje dobre rezultate, ali za sledeći korak preciznosti planiramo da priključimo Qwen3-Reranker.
PaiCLI koristi višestepeni Boost mehanizam kao zamenu za Rerank, u scenariju pretrage koda dovoljno.
09. Kako raditi Embedding za kineski?
Kineski nema prirodne razmake za segmentaciju — "jabuka" je voće ili brand telefona, kontekst odlučuje.
Opšti višejezični modeli u hvatanju kineske semantike su očigledno slabiji od modela specijalno treniranih za kineski.
Pri izboru kineskog Embedding modela, prvo pogledajte MTEB (Massive Text Embedding Benchmark) kinesku podlistu za pretragu CMTEB-R. To je rang-lista na HuggingFace koja specijalno ocenjuje sposobnost pretrage Embedding modela, podeljena po jeziku i tipu zadatka.

Trenutno među open source kineskim Embedding modelima, Qwen3-Embedding pokazuje vrlo dobre rezultate.
10. Kako raditi Embedding za kod?
Kod se mnogo razlikuje od prirodnog jezika. Semantika prirodnog jezika je u rečenici, semantika koda je u strukturi.
PaiCLI-jev pristup: prvo preko AST-a razbije kod u smislene strukturne jedinice, a zatim svaku jedinicu posebno Embedding-uje. CodeChunk ima metod toEmbeddingText() koji ispred sadržaja koda dodaje oznaku tipa:
[method:Agent.runReactLoop()] ReAct petlja: čita korisnički unos...Ovaj prefiks [method:Agent.runReactLoop()] je ključan. On kaže Embedding modelu "ovo je metoda, zove se runReactLoop", čime model bolje razume ulogu bloka koda.
Pored samog bloka koda, PaiCLI izdvaja i relacije između blokova: extends (nasleđivanje), implements (implementacija), imports (uvoz), calls (poziv), contains (sadrži).

Te relacije se čuvaju u SQLite tabeli code_relations, i pri pretrazi se mogu koristiti za proširenje grafa relacija. Pošto se nađe jedna klasa, preko grafa relacija se izvuku i njeni roditeljske klase, implementirani interfejsi i metodi koje poziva.
Za izbor modela za Embedding koda, Nomic izdaje Nomic Embed Code koji podržava preko 100 programskih jezika i u zadacima pretrage koda daje znatno bolje rezultate od opštih tekstualnih embedding modela. Jina ima Jina Code V2 specijalno za Embedding koda.
11. Pitanja sa intervjua — brzo pitanje, brz odgovor
Za pripremu AI intervjua, ovih 10 pitanja pokriva ključne tačke znanja o Embedding-u i Rerank-u.
Q1: Koja je razlika između Embedding-a i Rerank-a?
Embedding koristi Bi-Encoder arhitekturu sa dva tornja za priziv, Query i dokument se nezavisno kodiraju u vektore, brz ali prosečne preciznosti.
Rerank koristi Cross-Encoder ukršteni koder za precizno rangiranje, Query i dokument se spajaju i zajedno kodiraju, visoka preciznost ali spor.

U RAG sistemu obično prvo Embedging priziva top-50, a zatim Rerank radi precizno rangiranje i bira top-5.
Q2: Kako odabrati top-K?
Top-K Embedding priziva — što veći nije uvek bolji.
K premali lako propusti tačan odgovor, K prevelik unosi šum i smanjuje preciznost Rerank-a.

Opšte iskustvo: sa Rerank-om K=20-50, bez Rerank-a K=5-10. PaiSmart postavlja topK × 30 kao prozor priziva, a zatim posle BM25 rescore uzima topK rezultata.
Q3: Koji je mehanizam bodovanja Rerank modela?
Cross-Encoder Query i dokument spaja u jedan ulaz [CLS] query [SEP] document [SEP], model vraća relevantnost u opsegu 0-1.
Taj rezultat model daje nakon što vidi čitav Query i dokument, pouzdaniji je od kosinusne sličnosti Embedding-a.
Q4: Kako odrediti veličinu Chunk-a?
Potrebno je balansirati granularitet pretrage i celovitost konteksta. Obično 300-800 znakova je dobro, uz zonu preklapanja od 50-150 znakova.
PaiSmart koristi 512 + 100 overlap, PaiCLI koristi sečenje na nivou metoda (prirodna semantička granica).
Q5: Zašto posle promene Embedding modela treba obnoviti indeks?
Vektori koje generišu različiti modeli pripadaju različitim semantičkim prostorima.
Model A misli da je rastojanje između "jabuka" i "voće" 0.1, model B možda misli da je 0.5. Ako su vektori u indeksu generisani sa A, a vektor upita sa B, rezultat kosinusne sličnosti nema smisla.
Q6: Kako se radi hibridna pretraga?
Vektorska pretraga (KNN) i pretraga ključnih reči (BM25) se pokreću istovremeno, dva puta rezultata se stapaju u rangiranju.

Česti načini stapanja: ponderisana suma (PaiSmart: KNN težina 0.2 + BM25 težina 1.0) i RRF (Reciprocal Rank Fusion).
Q7: Koje posebnosti ima kineski Embedding?
Kineski nema razmake za segmentaciju, opšti višejezični modeli u hvatanju kineske semantike su slabiji od specijalno treniranih. Pri izboru modela pogledajte MTEB kinesku podlistu (CMTEB-R), trenutno Qwen3-Embedding daje vrlo dobre rezultate. U fazi sečenja koristite kineski tokenizator da obezbedite granice Chunk-a.
Q8: U čemu se razlikuje Embedding koda i Embedding teksta?
Semantika koda je u strukturi (ime klase, ime metode, relacije poziva), a semantika teksta u rečenici.
Za Embedding koda najbolje je prvo uraditi AST parsiranje, seći po strukturnim jedinicama, a zatim u Embedding ulaz dodati oznaku tipa strukture (na primer [method:xxx]). Namenski modeli za kod (Nomic Embed Code, Jina Code V2) daju bolje rezultate od opštih.
Q9: Kako odabrati dimenzionalnost vektora?
Što veća dimenzija, to bogatija semantička izražajnost, ali veći trošak skladištenja i računanja. Trenutno mainstream izbori: 768 (laki, za lokalni deployment), 1024-1536 (balansirani), 2048-3072 (visoka preciznost, za enterprise RAG).
Q10: Kada dodati Rerank, a kada ne treba?
Kada primetite da u top-50 Embedding priziva ima tačnog odgovora ali ga nema u top-5, to znači da vam treba Rerank.

Ako količina dokumenata nije velika (nekoliko stotina do hiljadu Chunk-ova), ili su ključne reči upita vrlo jasne (na primer pretraga imena klasa i metoda u kodu), Embedding + bodovanje ključnih reči je dovoljno, ne treba dodatni Rerank model.
