Agentic Chunking: Kada LLM poboljšava RAG, a kada ga komplikuje

Agentic Chunking nije automatski bolji. Upoređujemo RAG strategije, validaciju LLM granica i načine merenja kvaliteta i troškova.

11. novembar 2026.

Agentic Chunking nije standardizovan algoritam i ne daje automatski bolji rezultat od determinističke segmentacije.
Parser, poreklo podataka, revizije dokumenata i prava pristupa važniji su od prividno smislenih granica.
LLM predloge za granice treba proveriti i chunkove formirati iz neizmenjenog originalnog teksta.
Upoređujemo fixed-size, structure-aware i LLM-assisted pristupe na stvarnim pitanjima i merljivim troškovima.
Parent-child i Contextual Retrieval često rešavaju gubitak konteksta bez agentičke segmentacije.

Bolji chunk nije automatski i bolji odgovor

RAG sistem može da izgubi ključnu informaciju mnogo pre nego što pošalje prompt jezičkom modelu. Dovoljno je da parser odvoji tabelu od napomene, izgubi naslov odeljka ili pomeša revizije tehničkog uputstva. Retriever zatim pronalazi semantički sličan tekst, ali to ne znači da je pronašao važeći odgovor.

Agentic Chunking koristi LLM ili višekoračni workflow da protumači strukturu dokumenta i predloži granice smislenih celina. To može da pomogne kada su izvori neujednačeni. Međutim, dodatni poziv modela nije dokaz da će retrieval biti bolji.

Način segmentacije tretiramo kao arhitektonsku odluku koju treba izmeriti. Bitno je da korisnik dobije tačan izvor, odgovarajuću verziju i informacije za koje ima pravo pristupa, uz prihvatljive troškove indeksiranja i rada sistema.

Šta zapravo znači Agentic Chunking

Agentic Chunking nije naziv jednog standardizovanog algoritma. U nekim implementacijama LLM određuje prelaze između tema i predlaže gde dokument treba podeliti. U drugima više koraka služi za klasifikaciju odeljaka, povezivanje chunkova ili dodavanje konteksta.

LLM koji predlaže pozicije preseka nije samim tim autonomni agent. Dodavanje sažetog konteksta pre računanja embeddinga nije isto što i menjanje granica chunka. Parent-child retrieval je zaseban mehanizam pretrage, a ne nužno metod LLM segmentacije.

Pre izbora pristupa definišemo šta model dobija kao ulaz, šta sme da promeni, koja ograničenja moraju da ostanu netaknuta i kako sistem proverava rezultat. Bez tih detalja poređenje metoda nema veliku praktičnu vrednost.

Pet različitih pristupa segmentaciji dokumenata

Fixed-Size Chunking deli sadržaj prema broju tokena ili karaktera, uz opcioni overlap. Brz je, ponovljiv i ekonomičan. Dobra je početna varijanta za poređenje, iako ponekad deli tabele i uputstva na nezgodnom mestu.

Structure-Aware Chunking prati postojeću strukturu: poglavlja, naslove, pasuse, liste, tabele i kod. Za dobro organizovanu tehničku dokumentaciju to je često prvi izbor. Preduslov je da parser pravilno prepozna redosled čitanja i hijerarhiju.

Semantic Chunking može da koristi razlike u embedding sličnosti susednih rečenica kako bi prepoznao promenu teme. Za to nije uvek potreban generativni LLM. Na primer, SemanticSplitterNodeParser u LlamaIndex koristi skorove sličnosti i pragove.

LLM-assisted ili Agentic Chunking prepušta modelu da protumači strukturu ili predloži granice. Takav pristup može biti koristan kod složenih dokumenata, ali donosi dodatne model pozive, moguće nestabilne granice i potrebu za strožom validacijom.

Hierarchical Chunking čuva manje celine pogodne za pretragu i veze ka većim nadređenim odeljcima. Pretraga pronalazi precizan deo, a aplikacija po potrebi dodaje kontekst. Za to nije neophodan agent.

Praktične varijante parsera i hijerarhijskog pristupa opisane su u LlamaIndex dokumentaciji za Node Parsers.

Primer iz industrije: jedna napomena menja značenje tabele

Zamislimo dokumentaciju pogonske jedinice sa naslovom „Serija M-400, revizija 5“, tabelom momenata zatezanja i napomenom: „Ove vrednosti ne važe za visokotemperaturnu varijantu; pogledati odeljak 7.3“. Primer je ilustrativan, nije referenca na stvarni projekat ili kupca.

Ako se dokument deli na blokove od po 500 tokena, napomena može završiti u drugom chunku. Semantička pretraga pronalazi traženi moment zatezanja, ali ne i ograničenje njegove primene. AI asistent tada može da pruži veoma konkretan, a za datu konfiguraciju pogrešan odgovor.

Structure-Aware Chunking može da zadrži naslov, redove tabele, jedinice i napomenu kao povezanu celinu. Hijerarhijski retrieval može da učita nadređeni odeljak uz pronađenu stavku. LLM segmentaciju razmatramo tek kada deterministički pristupi ne uspevaju da sačuvaju te veze.

Važeći status dokumenta mora da dolazi iz odgovarajućeg izvornog ili poslovnog sistema. Jezički model ne sme da ga određuje samo na osnovu sličnosti teksta.

Kvalitet počinje od parsera, ne od LLM-a

PDF ekstrakcija često pogrešno tumači tabele, raspored u više kolona, fusnote i reference. Skenirana dokumenta donose OCR greške. LLM ne može automatski da popravi sve što je izgubljeno pri ekstrakciji.

Najpre čuvamo strukturu koju izvor omogućava: naslove, putanju poglavlja, liste, tabele, kod, brojeve strana i pozicije teksta. Zatim uvodimo normalizaciju i stručnu klasifikaciju gde je potrebna.

Tek onda biramo strukturni, semantički ili LLM-assisted chunking. Kod tehničkih tabela, jedinica mere i revizija eksplicitna pravila često su važnija od jezički elegantnih granica.

Pipeline treba da olakša pronalaženje informacije, bez prećutnog menjanja izvora, redosleda ili uslova primene.

Kontrolisana segmentacija umesto prepisivanja izvornog teksta

Kada LLM predlaže granice, ne treba da preformuliše tehnički obavezujući sadržaj. Bezbedniji obrazac je da vrati pozicije karaktera ili reference na postojeće odeljke. Deterministička funkcija zatim izdvaja originalni tekst.

Validiramo da li su pozicije ispravne i sortirane, da li postoje nedozvoljene praznine ili preklapanja, da li tabele ostaju celovite i da li su sačuvani source ID i revizija. Produkciona implementacija uključuje i ograničenja veličine.

Neispravan rezultat pokreće eksplicitan fallback na strukturni split. Beležimo grešku, verziju modela i prompta i trošak obrade. Tehnička validacija ne garantuje stručno ispravne granice, ali sprečava neprimetnu izmenu izvornog teksta.

TypeScript: provera LLM granica prema originalu

Model predlaže granice, a deterministički kod izdvaja chunkove iz originalnog teksta. U produkciji dodajemo pravila za tabele, limite, dozvole i fallback.

TypeScript

type SourceSection = {
  sourceId: string
  revision: string
  text: string
  allowedRoles: string[]
}

type Chunk = {
  sourceId: string
  revision: string
  allowedRoles: string[]
  start: number
  end: number
  text: string
}

// LLM vraca samo pozicije preseka, ne prepisan tekst.
// Kod greske prelazimo na deterministicki fallback.
export function materializeChunks(source: SourceSection, proposedOffsets: number[]): Chunk[] {
  const offsets = [...proposedOffsets]
  const valid = offsets.every(
    (offset, index) =>
      Number.isInteger(offset) &&
      offset > 0 &&
      offset < source.text.length &&
      (index === 0 || offset > offsets[index - 1])
  )

  if (!valid) {
    throw new Error('Neispravne granice: potreban fallback')
  }

  const cuts = [0, ...offsets, source.text.length]
  const chunks = cuts.slice(1).map((end, index) => {
    const start = cuts[index]
    return {
      sourceId: source.sourceId,
      revision: source.revision,
      allowedRoles: [...source.allowedRoles],
      start,
      end,
      text: source.text.slice(start, end),
    }
  })

  if (chunks.map((chunk) => chunk.text).join('') !== source.text) {
    throw new Error('Izvorni tekst promenjen: potreban fallback')
  }

  return chunks
}

Metapodaci određuju da li rezultat sme da se koristi

Chunk nije samo tekst i embedding. Čuvamo stabilan source ID, reviziju, putanju odeljka, poziciju u originalu, vreme izmene i metapodatke potrebne za kontrolu pristupa.

U industriji su često važni i ID proizvoda, konfiguracija mašine, period važenja, lokacija i klasifikacija. Promene prava pristupa, povučene revizije i obrisani izvori moraju da se odraze u indeksu.

Kontrola pristupa mora da se izvrši pre prosleđivanja teksta modelu. Metadata model razlikuje važeći dokument od teksta koji je samo semantički sličan.

Takvu integraciju razvijamo kroz Data Engineering.

JSON: chunk sa poreklom i uslovima važenja

Ilustrativni primer, bez stvarnih podataka o kupcu ili mašini. Source URL je placeholder; prava pristupa preuzimamo iz nadležnog sistema.

JSON

{
  "sourceId": "manual-m400",
  "revision": "5",
  "sectionPath": ["Pogon", "Održavanje", "Moment zatezanja"],
  "machineFamily": "M-400",
  "variant": "standard",
  "validFrom": "2026-01-01",
  "allowedRoles": ["service", "engineering"],
  "charStart": 8240,
  "charEnd": 9132,
  "chunkingStrategy": "structure-aware-v2",
  "parentSectionId": "manual-m400-r5-7",
  "sourceUrl": "https://example.invalid/manual-m400"
}

Contextual Retrieval nije isto što i menjanje granica

Ponekad je korisnije već formiranom chunku dodati kontekst: iz kog priručnika dolazi, kom poglavlju pripada i na koju varijantu proizvoda se odnosi. To može da poboljša pretragu bez izmene izvornog pasusa.

Anthropic ovaj pristup naziva Contextual Retrieval. Dodatni kontekst koristi se uz embedding search i BM25; ne podrazumeva nužno drugačije chunk granice.

Izvučene metapodatke, proverene činjenice iz poslovnih sistema i generisana objašnjenja držimo odvojeno. Generisani tekst ne sme postati izmišljena tehnička činjenica.

Tehnički pristup opisuje Anthropic: Introducing Contextual Retrieval.

Parent-child retrieval često rešava stvarni problem

Kod dugih pravilnika, specifikacija i priručnika indeksiramo manje celine, a čuvamo veze sa većim nadređenim odeljcima. Kada retrieval pronađe red tabele, aplikacija može da dopuni kontekst.

Primer: red sa dozvoljenom temperaturom ne sadrži uvek jedinicu, uslove i reviziju. Sve to može da stoji u parent odeljku. Nije potrebno poslati ceo priručnik, ali izolovan broj nije dovoljan.

Hijerarhijski indeks zahteva dodatno održavanje. Ipak, često je lakši za proveru od slobodno generisanih celina. Zato Structure-Aware i Parent-Child Retrieval koristimo kao početne varijante.

LlamaIndex dokumentuje Hierarchical Node Parser.

Ne postoji univerzalno dobra veličina chunka

Pravilo od 500 ili 1.000 tokena nije univerzalna arhitektura. Manji chunkovi mogu olakšati precizan retrieval, ali gube povezane rečenice. Veći zadržavaju kontekst, ali povećavaju model input i latenciju.

Ni overlap nije besplatan. Previše ponovljenog teksta stvara redundantne rezultate i potiskuje različite relevantne izvore. Bolje je očuvati veze između odeljaka i kontekst širiti po potrebi.

NVIDIA je upoređivala chunking strategije i pokazala da performanse zavise od podataka i vrste pitanja. To ne dokazuje univerzalnu prednost konkretne veličine ili LLM metode.

Detalji poređenja: Finding the Best Chunking Strategy for Accurate AI Responses.

Evaluacija: da li dodatni LLM pozivi opravdavaju trošak?

Na istim izvorima i pitanjima upoređujemo najmanje tri pristupa: deterministički baseline, Structure-Aware ili hijerarhijski chunking i LLM-assisted varijantu. Embeddings, retriever i filtere održavamo što sličnijim.

Test skup obuhvata pitanja sa očekivanim izvorima i negativne primere: zastarele revizije, slične šifre delova, tabelarne vrednosti sa uslovima, dvosmislene pojmove i pitanja bez validnog odgovora.

Merimo Recall@k, Precision@k ili MRR, stručnu tačnost odgovora, ispravnost citiranih izvora, veličinu indeksa, vreme indeksiranja, broj tokena, latenciju i cenu po uspešno rešenom pitanju.

Testiramo i ponovljivost: da li ponovna obrada daje iste granice i šta se menja posle updatea modela ili prompta.

Studija u NAACL Findings 2025 nije našla konzistentne prednosti Semantic Chunkinga koje bi generalno opravdale dodatni računarski trošak. Nalaz ne obuhvata sve agentic metode, ali pokazuje potrebu za merenjem.

TypeScript: Recall@k kao početna retrieval metrika

Pojednostavljen Macro Recall@k na nivou source ID-ja. Za detaljnu evaluaciju koristimo odeljke ili tekstualne opsege. Recall ne meri tačnost odgovora ni trošak.

TypeScript

type RetrievalCase = {
  question: string
  relevantSourceIds: string[]
  retrievedSourceIds: string[]
}

export function recallAtK(cases: RetrievalCase[], k: number): number {
  if (!Number.isInteger(k) || k <= 0) {
    throw new Error('k mora biti pozitivan ceo broj')
  }

  const scored = cases
    .filter((test) => test.relevantSourceIds.length > 0)
    .map((test) => {
      const expected = new Set(test.relevantSourceIds)
      const found = new Set(test.retrievedSourceIds.slice(0, k))
      const matches = [...expected].filter((id) => found.has(id))
      return matches.length / expected.size
    })

  if (scored.length === 0) {
    throw new Error('Nema validnih test primera')
  }

  return scored.reduce((sum, score) => sum + score, 0) / scored.length
}

Produkcija: versioning, lineage i observability

Chunking nije nebitan preprocessing korak. Promena parsera, modela, prompta ili metadata šeme može da promeni granice i rezultate pretrage.

Verzionišemo strategiju ekstrakcije i segmentacije, održavamo source ID-jeve i beležimo vezu originalnog dokumenta, chunka i indeksa. Izmene i brisanja moraju da se propagiraju.

Pratimo ingestion greške, svežinu indeksa, raspodelu chunkova, retrieval kvalitet, latenciju i trošak. Traces povezuju pitanje, filtere, izvore, model i odgovor.

O tome detaljnije u tekstu AI agenti u produkciji: Observability.

Kada koristimo Agentic Chunking, a kada ne

Počinjemo determinističkim parserom i merljivim baseline pristupom. Za uredan Markdown, API dokumentaciju ili pravilnike sa jasnim naslovima Structure-Aware Chunking je često bolji prvi izbor.

LLM-assisted segmentaciju testiramo kada je korpus heterogen, promene teme su teško prepoznatljive ili strukturna pravila stalno razdvajaju povezane informacije. I tada čuvamo original, validiramo pozicije i definišemo fallback.

Ako problem leži u zastarelim matičnim podacima, kontradiktornim revizijama ili nepovezanim ERP, PLM i SharePoint informacijama, chunking nije glavni problem. Tada je potreban Data Engineering, pouzdani identifikatori i eventualno Knowledge Graph.

Integraciju i obradu razvijamo kroz Data & AI Engineering.

Od pronađenog pasusa do odluke u poslovnom procesu

Dobar chunk nije cilj. U servisnom procesu odgovor mora da se odnosi na odgovarajuću mašinu, važeću reviziju i konkretan sledeći korak. Sama semantička sličnost nije dovoljna.

Kroz Valanor AI povezujemo poslovne, mašinske i senzorske podatke sa analitikom, Machine Learningom i AI workflowima. Razvijamo podatkovnu osnovu, retrieval, evaluaciju i vezu sa proverljivim zadacima.

LLM koristimo kada njegov doprinos zaista poboljša kvalitet ili operativni rezultat. Dodatni model poziv mora da bude opravdan.

Česta pitanja o Agentic Chunkingu

Šta je Agentic Chunking?

LLM-assisted ili višekoračna segmentacija koja analizira sadržaj, predlaže granice ili dodaje strukturu. Nije jedan standardizovan algoritam.

Koja je razlika između Agentic i Semantic Chunkinga?

Semantic Chunking najčešće koristi embedding sličnosti i pragove; agentic pristupi mogu da koriste generativni LLM i više koraka. Metode se preklapaju, ali nisu isto.

Da li svaki RAG sistem zahteva Agentic Chunking?

Ne. Strukturna deterministička segmentacija često je jeftinija i pouzdanija. LLM treba koristiti kada evaluacija pokaže korist.

Koliko veliki treba da budu chunkovi?

Nema univerzalne veličine. Zavisi od dokumenta, vrste pitanja, retrievera i ograničenja konteksta.

Da li je Contextual Retrieval isto?

Ne. Contextual Retrieval dodaje kontekst postojećim chunkovima; Agentic Chunking često određuje same granice.

Kako sprečiti gubitak informacija?

Sačuvati original i pozicije, proveravati tabele i naslove, voditi revizije i identifikatore izvora i koristiti deterministički fallback.

Kako se meri korist?

Na realnim pitanjima uz Recall@k, ranking, tačnost i izvore odgovora, latenciju i ukupne troškove.

Data & AI Engineering

Proverimo kvalitet vašeg RAG sistema na stvarnim podacima.

Razvijamo obradu dokumenata, retrieval, evaluaciju i kontrolisanu integraciju AI sistema sa vašim izvorima podataka i poslovnim procesima.

Razgovarajmo o vašem projektu

Aleksandar Basara

Managing Director

aleks@valanor.co

Bulevar Milutina Milankovića 7Đ, 11070 Beograd, Srbija