RAG nije magija, nego inženjering pretrage koji većina radi loše

Klijent nam je pokazao demo svog "chatbota koji zna sve o našoj tvrtki". Pitali smo ga jednu konkretnu stvar: koji je rok za reklamaciju iz njihovih uvjeta poslovanja. Bot je samouvjereno izgovorio 30 dana. U dokumentu je pisalo 14. Nitko u sobi nije primijetio dok nismo otvorili PDF i provjerili. To je RAG u praksi kod većine: zvuči pametno, a griješi baš ondje gdje ne smije.

Priča koja se prodaje ide ovako. Ubaciš svoje dokumente u vektorsku bazu, spojiš LLM i dobiješ pametnog asistenta koji odgovara na temelju tvojih podataka. Tehnički je istina. Praktično, taj naivni pristup, ubaci PDF-ove i pusti cosine similarity, u 2026. je prototip u najboljem slučaju, a odgovornost u najgorem. Problem gotovo nikad nije model. Problem je pretraga koja modelu servira krive komade teksta, a onda model uljudno halucinira na temelju smeća.

Retrieval je pravi problem, ne generacija

RAG ima dva dijela. Retrieval, dio koji pronalazi relevantne komade iz vaših dokumenata, i generacija, dio gdje LLM piše odgovor. Svi pričaju o modelu jer je to zvučni dio. Ali ako retrieval dohvati krive paragrafe, ni najbolji model na svijetu ne može spasiti odgovor. Dobije loš materijal, napiše loš odgovor, i to samouvjereno.

Evo najčešćeg mjesta gdje puca. Vektorska pretraga radi na semantičkoj sličnosti. Sjajna je kad korisnik pita "kako otkazati pretplatu", a dokument govori o "prekidu ugovora". Ali ista ta pretraga je slaba kad korisnik traži točan pojam. Šifru artikla, ime funkcije, broj zakona, verziju proizvoda. Embedding vidi da su "v2.3.1" i "v2.4.0" jako slični, jer jesu, semantički. Za korisnika koji traži baš 2.3.1 to je pogrešan odgovor. Čista vektorska pretraga tu redovito promaši ono što bi obična tekstualna pretraga pogodila iz prve.

Chunking je odluka koju svi preskaču

Prije nego išta uđe u bazu, dokument se reže na komade. Taj korak, chunking, tim najčešće postavi na default i zaboravi. A on odlučuje o kvaliteti jednako koliko i izbor embedding modela. Ako komade režete premalene, izgubi se kontekst. Rečenica "to ne vrijedi za poslovne korisnike" nema smisla ako je odsječena od stavka na koji se odnosi. Ako režete prevelike komade, u pretragu ulazi šum, pola nevažnog teksta oko onog jednog bitnog retka, i model se izgubi.

Na jednom projektu gdje smo naslijedili gotov RAG, sve je bilo "po tutorialu": fiksni komadi od par tisuća znakova, bez preklapanja. Rezultat je bio da su se tablice i popisi lomili nasred retka. Cijena je bila u jednom komadu, uvjet uz cijenu u sljedećem, i model nikad nije vidio oba zajedno. Prešli smo na rezanje po strukturi dokumenta, komade veličine oko 500 tokena s malim preklapanjem, i posebno rukovanje tablicama. To sredi puno više problema nego zamjena modela za skuplji.

Kako to popraviti bez čarolije

Prvo, hibridna pretraga. Kombinacija klasične tekstualne pretrage (BM25, ista logika koju koristi svaka ozbiljna tražilica) i vektorske pretrage. Tekstualni dio hvata točne pojmove, vektorski hvata značenje. Rezultati se spoje. Ovo je najveći skok u kvaliteti za najmanje truda i trebao bi biti default, a ne napredna tehnika.

Drugo, reranking. Umjesto da modelu odmah date prvih pet rezultata pretrage, dohvatite dvadeset, pa ih poseban, precizniji model presloži po stvarnoj relevantnosti i onda LLM-u date samo najbolje. Ovaj korak košta malo latencije, a odbaci iznenađujuću količinu skoro-točnih ali krivih komada koji inače zavaraju model.

Treće, i ovo je ono što razlikuje igračku od proizvoda: mjerenje. Ako ne testirate retrieval na stvarnim pitanjima s poznatim točnim odgovorima, samo se nadate. Napravite set realnih pitanja korisnika, definirajte koji komad dokumenta sadrži točan odgovor i mjerite koliko često pretraga taj komad uopće dohvati. Bez toga svaka izmjena je pogađanje u mraku, a "čini se da radi bolje" nije metrika.

RAG nije magija i nikad nije ni bio. To je inženjering pretrage s LLM-om na kraju. Tvrtke koje to shvate grade asistente kojima korisnici vjeruju. One koje misle da je dovoljno ubaciti PDF-ove grade sustav koji samouvjereno kaže 30 dana kad je odgovor 14. Razlika nije u modelu. Razlika je u tome shvaćate li da ste zapravo gradili tražilicu.

Povezano:

• 84% developera koristi AI alate. Zašto onda kod nije bolji?
• AI u web developmentu 2025: gdje stvarno pomaže, a gdje je samo hype

Gradite internog asistenta ili "pitaj dokumente" chatbota i niste sigurni je li retrieval dovoljno dobar? Javite nam se i pogledat ćemo gdje vam se pretraga lomi.