RAG dohvat na velikoj skali: chunking, hibridno pretraživanje i Bayesovo podešavanje

RAG sustavi padaju u produkciji iz istog razloga kao i većina search sustava: zadane postavke su podešene za praktičnost, a ne za vaše podatke. Fiksne veličine chunkova, dohvat iz samo jednog modaliteta i pogađanje hyperparametara mogu demo učiniti uvjerljivim, dok tiho uništavaju recall i troše budžet za latenciju.

Rješenje nije veći model. Rješenje je retrieval pipeline koji poštuje strukturu dokumenta, kombinira metode pretraživanja i mjeri tradeoffe kao pravi produkcijski sustav.

Kada se default RAG pipeline raspada?

Default RAG pipeline raspada se kada je struktura dokumenta važna, kada je formulacija upita nedosljedna i kada latencija počne rasti kroz svaku fazu. Chunking s fiksnim brojem tokena, pretraživanje samo vektorima i hard-coded top-k vrijednosti mogu raditi za proof of concept, ali se obično raspadnu čim im date ugovore, dokumentaciju, tickete ili bilo što s gustom tehničkom terminologijom.

To je važno jer je retrieval dio koji odlučuje hoće li LLM uopće vidjeti pravi dokaz. Ako pogrešan kontekst uđe u prompt, kvaliteta generiranja je već izgubljena prije nego što model odgovori.

Zašto fiksni chunkovi stvaraju loš retrieval

Chunking nije detalj formatiranja. On određuje koje značenje preživi do indeksa.

Prozor od 512 tokena može prepoloviti klauzulu, odvojiti potpis funkcije od objašnjenja ili razmazati jedan support issue preko više chunkova. U pravnom dokumentu to znači da odgovor može propustiti iznimku koja mijenja cijelo značenje. U API dokumentaciji to znači da model vidi primjer, ali ne i upozorenje. U support transkriptu to znači da se ključna namjera korisnika zakopa pod krivi tijek razgovora.

Bolji pristup je da chunking prati izvorni materijal. Chunking svjestan strukture zadržava zaglavlja, odlomke, klauzule i code blockove gdje god je moguće. Semantic chunking može pomoći kada su granice nejasne, ali je skuplji i treba ga rezervirati za dokumente gdje sama struktura nije dovoljna. Agentic chunking može dati izvrsne granice za složeno interno znanje, ali je sporiji i teže ga je opravdati osim ako su dokumenti visoke vrijednosti.

Zamislite to kao utovar u transportni kontejner. Ako svaki objekt razbijete na nasumične dijelove, cargo i dalje možete premjestiti, ali ćete potrošiti puno vremena pokušavajući rekonstruirati što pripada zajedno. Retrieval ima isti problem.

Zašto tip dokumenta treba određivati strategiju

Ne treba vam jedna chunking politika. Treba vam politika po klasi dokumenta.

Arhiva pravnih dokumenata trebala bi davati prednost granicama klauzula i većim chunkovima s overlapom ondje gdje kontekst prelazi preko susjednih sekcija. Referentni API materijali obično bolje rade s granicama svjesnima funkcija i umjerenim veličinama chunkova. Support tickete treba čuvati po turnovima razgovora, jer značenje često živi u izmjeni poruka, a ne u jednoj poruci. Interni wiki dokumenti mogu opravdati teže metode ako je sadržaj neuredan i cijena pogrešnog odgovora visoka.

Poslovna implikacija je jednostavna: bolje chunkanje smanjuje broj loših retrievala prije nego što uopće dotaknete model. To znači manje hallucinationa, manje ponovnih pokušaja i manje vremena potrošenog na kompenziranje pokvarenog indeksa.

Kako kombinirati vector search, BM25 i reranking?

Treba ih kombinirati jer svaki od njih griješi na drugačiji način. Vector search je dobar za semantičku sličnost, ali slab na točne pojmove. BM25 je jak na exact match, ali slijep za značenje. Reranking vraća relevantnost tako što mali skup kandidata ocjenjuje s dubljim kontekstom.

To je važno jer korisnici ne pretražuju čistim, kuriranim formulacijama. Oni upisuju error codeove, poluzapamćena imena proizvoda, nejasne simptome i kratka pitanja koja treba interpretirati.

Zašto hibridni retrieval pobjeđuje jednu metodu pretraživanja

Hibridni retriever obično radi bolje kada vector search i BM25 pokreće paralelno, spoji liste kandidata i zatim reranka spojeni skup. Reciprocal Rank Fusion je praktičan način za kombiniranje rezultata bez trošenja vremena na kalibraciju nekompatibilnih scoreova. Jednostavan je, stabilan i lako ga je razumjeti.

Reranker je mjesto gdje kvaliteta najviše raste. Cross-encoder uspoređuje upit i kandidata zajedno, što je sporije od embeddingsa, ali znatno preciznije. U produkciji se taj dodatni trošak obično isplati jer rerankate samo uzak presjek kandidata. Uzorak je sličan skladišnom sustavu odabira: prvo široki intake, a zatim provjera kvalitete na malom skupu koji stvarno ide dalje.

Zašto je query expansion važniji nego što ljudi očekuju

Korisnici često postave pogrešno pitanje za odgovor koji zapravo žele. Query expansion to popravlja tako da prije pretrage generira nekoliko alternativnih formulacija, sinonima i podpitanja.

To je najvažnije za kratke upite i dvosmislenu namjeru. Jedan upit može promašiti relevantan dokument jer je formulacija preuska. Tri do pet proširenih upita može dramatično poboljšati recall, posebno ako rezultate spojite u jedan skup i potom rerankate kandidate.

Plaćate više embeddingsa ili više search poziva, ali trošak je obično podnošljiv ako posao paralelizirate. Pravi dobitak nije samo bolji recall. To je manje support problema u kojima je sustav izgledao pametno, ali je propustio očit izvor.

Kako podešavati RAG bez pogađanja?

Podešavate ga tako da retrieval tretirate kao mjereni sustav, a ne kao skup folklornih defaulta. Veličina chunka, overlap, top-k, broj proširenja i dubina rerankera sve su to parametri s realnim posljedicama na latenciju i recall.

To je važno jer ručno odabrane vrijednosti često prežive dugo nakon što je tim koji ih je odabrao zaboravio razlog. Kad se to dogodi, sustav postaje teško poboljšati i još teže braniti.

Zašto je Bayesova optimizacija pravi alat ovdje

Bayesova optimizacija dobar je izbor jer je tuning retrievala skup i nelinearan. Ne tražite jednostavnu krivulju. Balansirate sukobljene ciljeve kroz prostor u kojem jedna promjena može pomoći recallu, a pogoršati latenciju.

Praktična postavka je jednostavna: izgradite golden set upita, pokrenite kandidatne konfiguracije na njemu i svaku izvedbu ocijenite prema recallu i latenciji. Zatim pretražujte prostor samplerom koji uči iz prethodnih pokušaja. Rezultat nije jedna čarobna postavka. To je Pareto frontier koji pokazuje tradeoff između brzine i točnosti.

To je korisno za product odluke. Support bot s velikim throughputom može prihvatiti nešto niži recall kako bi ostao unutar budžeta latencije. Legal assistant može tolerirati sporije odgovore ako je kvaliteta odgovora osjetno bolja. Poanta je odlučiti svjesno, umjesto naslijediti nasumični default.

Zašto instrumentacija mora biti dio sustava

Ako ne možete mjeriti kvalitetu retrievala u produkciji, letite naslijepo.

Pratite end-to-end retrieval latenciju, vrijeme rerankera, volumen query expansiona i uzorkovani recall prema verzioniranom golden setu. To vam daje način da uhvatite regresije kada novo pravilo chunkinga, update indeksa ili novi reranker model promijeni ponašanje. Bez te vidljivosti, drift performansi izgleda kao da je "model postao lošiji", iako je pravi problem obično upstream.

Dobar retrieval dashboard je kao checkout pipeline pod Black Friday opterećenjem. Ne čekate da prihod nestane prije nego što provjerite gdje se stvorio red. Pratite usko grlo dok se događa.

Što vas košta ako to ignorirate

Ignoriranje kvalitete retrievala košta stvarni novac. Sustav koji odgovara sporo ili promašuje relevantan kontekst troši inženjersko vrijeme, povećava opterećenje supporta i vraća korisnike na ručno pretraživanje ili ljudsku pomoć.

Proizvod kojem treba previše vremena da pronađe pravi odgovor djeluje pokvareno čak i kad model tehnički "radi". Tim korisničke podrške koji mora ručno provjeravati odgovore gubi sate svaki tjedan. Pravni ili interni knowledge sustav koji promaši ključni kontekst može stvoriti rizik koji je teško uočiti dok netko ne donese lošu odluku.

Trošak nije apstraktan. Pojavljuje se kao niže povjerenje, veći churn i više vremena potrošenog na popravljanje iste klase problema. Morate odlučiti je li retrieval temeljni sustav ili naknadna misao.

Neviox Implementation Check

Provjerite je li vaša chunking strategija vezana uz tip dokumenta - ako svi izvori koriste isti fiksni window, značenje cijepate na pogrešnim mjestima.

Provjerite kombinira li vaš retriever barem dvije metode pretraživanja i reranka li kandidate , ako se oslanja samo na jedan signal, ostavljate recall na stolu.

Provjerite evaluiraju li se retrieval postavke prema verzioniranom golden setu , ako se tuning radi po osjećaju, jedan ste deploy udaljeni od slanja regresija u produkciju.