RAG koji preživi produkciju: hibridni retrieval, evaluacije i kada je GraphRAG prekompliciran

RAG demo može izgledati izvrsno, a njegova produkcijska verzija tiho odgovara na pogrešno pitanje. Indeks je zastario, upit sadrži točan kod proizvoda koji semantičko pretraživanje promašuje, najbolji chunk je relevantan ali nepotpun, i nitko to ne primijeti dok klijent ne donese odluku na temelju tog odgovora.

RAG u produkciji nije prvenstveno vježba u pisanju promptova. To je retrieval i evaluacijski sustav s LLM-om na kraju. Trajno rješenje obično je manje egzotično nego što arhitektonski dijagram sugerira: kombinirajte komplementarne retrieval metode, učinite dokaze vidljivima, mjerite načine kvara koji su vam važni i zadržite najjednostavniji sustav koji zadovoljava zahtjev.

Ovo je popratni tekst uz praktični Qdrant vodič za hibridno pretraživanje i raniji vodič za evaluaciju RAG-a. Fokus je na odlukama koje se pojavljuju nakon prvog uspješnog prototipa.

Počnite s ugovorom o kvaru

Prije nego odaberete vektorsku bazu podataka ili okvir za orkestraciju, zapišite što za vašu aplikaciju znači „pogrešno”. Asistent za korisničku podršku može zakazati tako da citira zastarjelu politiku, izostavi uvjet podobnosti ili samouvjereno odgovori izvan baze znanja. Interni inženjerski asistent može zakazati tako da dohvati sličnu, ali nekompatibilnu verziju API-ja.

Pretvorite te kvarove u eksplicitne zahtjeve:

• Koji su izvori mjerodavni kada se dokumenti ne slažu?
• Koliko svjež mora biti odgovor?
• Mora li svaka bitna tvrdnja imati citat?
• Što sustav treba učiniti kada su dokazi slabi ili ih nema?
• Koji korisnici ili zakupnici smiju dohvatiti koji dokument?
• Koji proračun latencije i troška vrijedi za uobičajen zahtjev?

Ta pitanja određuju dizajn retrievala. Daju vam i granicu koju možete testirati. „Odgovor zvuči korisno” nije produkcijski kriterij; „odgovor citira važeću politiku povrata i odbija odgovoriti kada nijedna politika ne potkrepljuje tvrdnju” jest.

Zašto je hibridni retrieval razumna osnovica

Dense retrieval predstavlja upit i dokumente kao vektore, a zatim pronalazi semantički slične odlomke. Dobar je s parafrazama: „Koliko dugo mogu raditi iz druge zemlje?” može se povezati s odlomkom naslovljenim „privremena lokacija za rad na daljinu”. Može imati problema s identifikatorima, neuobičajenim imenima, kodovima pogrešaka, brojevima verzija i kratkim upitima u kojima jedan token nosi većinu značenja.

Sparse retrieval, koji se obično temelji na inverznom indeksu kao što je BM25, ocjenjuje preklapanje pojmova. Snažan je kada korisnik upiše točan SKU, CVE, naziv funkcije, broj tiketa ili citirani izraz. Manje je tolerantan na sinonime i promjene formulacije.

Hibridni retrieval pokreće oba pristupa i kombinira njihove kandidate. To nije suvišan posao. Dvije metode griješe na različite načine, što je upravo ono što želite od generatora kandidata u prvoj fazi. Gore navedeni Qdrant primjer pokazuje isti princip s dense i sparse reprezentacijama; odabir pohrane može se razlikovati, ali logika retrievala ostaje prenosiva.

Korisna putanja zahtjeva izgleda ovako:

1. Normalizirajte upit, a da pritom ne uništite značajne identifikatore.
2. Primijenite filtre autorizacije i zakupnika prije vraćanja kandidata.
3. Pokrenite sparse i dense retrieval neovisno, obično za više kandidata nego što ih na kraju prikazujete.
4. Spojite rangirane liste metodom kao što je reciprocal rank fusion ili upotrijebite kalibriranu ponderiranu kombinaciju.
5. Ponovno rangirajte spojene kandidate skupljim modelom ili korakom ocjenjivanja.
6. Uklonite suvišne chunkove, sastavite kontekst i odgovorite samo na temelju odabranih dokaza.

Ne pretpostavljajte da je isti top-k ispravan za svaku fazu. Pretraga prve faze može dohvatiti 30 kandidata iz svake metode. Fuzija to može svesti na upravljiv skup, a reranker može odabrati završnih pet do osam odlomaka. Točni brojevi ovise o radnom opterećenju; izmjerite ih umjesto da kopirate pomodnu konfiguraciju.

Reranking opravdava svoju latenciju kada je korpus zahtjevan

Početni retrieval optimiziran je za recall i propusnost. Mora brzo pronaći vjerojatne dokaze. Reranker može zajedno pregledati upit i tekst kandidata te donijeti nijansiraniju odluku o relevantnosti nego što to čini pojedinačni rezultat vektorske sličnosti.

Upotrijebite ga tamo gdje dodatna latencija donosi nešto vidljivo: duge dokumente, gotovo identične politike, tehničku terminologiju ili pitanja u kojima odlomak mora zadovoljiti nekoliko ograničenja odjednom. Nemojte ga dodavati samo zato što svaki arhitektonski dijagram ima kutiju za reranker. Na malom, čistom korpusu s kratkim dokumentima bolje chunkiranje i filtri metapodataka mogu donijeti veći dobitak.

Mjerite reranking kao kompromis. Bilježite latenciju retrievala, latenciju rerankinga, obujam tokena, stopu pogodaka u cacheu i promjenu stope korisnih odgovora. Reranker koji poboljša benchmark za jedan postotni bod, a pritom udvostruči p95 latenciju, možda nije pravi izbor za interaktivnog asistenta. Reranker koji spriječi skupu compliance pogrešku može vrijediti mnogo više od svoje cijene po zahtjevu.

Chunking je dio kvalitete retrievala

Hibridno pretraživanje ne može vratiti informaciju koja je loše razdvojena. Chunk koji sadrži definiciju bez njezine iznimke tehnički je relevantan, ali operativno nesiguran. Chunk koji počinje usred postupka može se dobro poklopiti, a korisnika ostaviti bez preduvjeta ili završnog koraka.

Preferirajte granice koje čuvaju značenje: naslove, grupe popisa, blokove koda, retke tablica i cjelovite klauzule politike. Uz tekst pohranite naslov dokumenta, putanju do odjeljka, izvor, verziju, datum objave i metapodatke za kontrolu pristupa. Malo preklapanja može pomoći na prijelazima, ali preklapanje nije zamjena za razdvajanje koje razumije strukturu.

Zatim pregledajte stvarne promašaje. Za svako neuspješno pitanje provjerite je li problem u ingestiji, autorizaciji, granicama chunkova, formulaciji upita, generiranju kandidata, rerankingu, sastavljanju konteksta ili generiranju. Ispravite najraniju fazu koja zakaže. Prebacivanje na veći model na kraju često skriva, a ne rješava nedostatak u retrievalu.

Evaluacija retrievala ide odvojeno od evaluacije odgovora

Generirani odgovor može izgledati uvjerljivo čak i kada je retriever promašio najbolji dokaz. Obrnuto, retriever može vratiti pravi dokaz, a model za odgovore ga pogrešno protumači. Vodite te evaluacije odvojeno kako se u jednom rezultatu ne bi izgubila dijagnoza.

Izgradite mali, verzionirani evaluacijski set iz stvarnih pitanja i poznatih incidenata. Svaki slučaj treba sadržavati očekivani izvor ili prihvatljive izvore, granice relevantnih odlomaka gdje je to praktično i ponašanje koje se očekuje kada dokaza nema. Uključite teške negativne primjere: dokumente koji spominju isti proizvod ili temu, ali ne odgovaraju na pitanje.

Za retrieval su korisne sljedeće offline mjere:

• Recall@k: pojavljuje li se prihvatljiv odlomak među prvih k.
• Precision@k: koliki je dio vraćenog skupa koristan.
• MRR ili nDCG: pojavljuje li se najbolji dokaz blizu vrha i kako je poredana stupnjevana relevantnost.
• Ispravnost filtriranja: ulaze li zabranjeni dokumenti ili dokumenti pogrešnog zakupnika ikada u skup kandidata.
• Ispravnost svježine: je li zamijenjeni dokument lošije rangiran ili isključen.

Te metrike nisu međusobno zamjenjive. Sustav podrške može dati prednost recallu u fazi kandidata, a zatim rerankingom i ograničenjima konteksta poboljšati preciznost. Radni tok u pravnom području ili u području internih politika može zahtijevati stroga ograničenja izvora i verzija čak i ako to smanjuje recall.

Za odgovore mjerite utemeljenost, cjelovitost, ispravnost citata, ponašanje pri odbijanju i praćenje uputa. Model procjenitelj može pomoći u trijaži velikih testnih setova, ali nije proročište. Dajte mu rubriku, pitanje, dohvaćene dokaze i odgovor; ne dopustite mu da dodijeli bodove za činjenice kojih nema u dokazima. Uzmite uzorke i ručno pregledajte odluke procjenitelja, posebno za slučajeve visokog rizika.

Neka regresije ne prolaze nezapaženo

Regresijski set testova trebao bi se pokrenuti kada promijenite chunking, embeddinge, filtre metapodataka, reranking, promptove, modele ili izvorne podatke. Uz svako pokretanje pohranite konfiguraciju retrievala i snimku korpusa. Inače promjenu rezultata može uzrokovati indeks koji se mijenja, a ne vaš kod.

Koristite tri sloja provjera:

1. Determinističke provjere kontrole pristupa, obveznih citata, rukovanja praznim rezultatima, valjanosti sheme i poznatih pravila izvora i verzija.
2. Metrike retrievala na označenim pitanjima, s pragovima i putem pregleda za očekivane kompromise.
3. Provjere odgovora uz pomoć procjenitelja i uz ljudski pregled za utemeljenost, cjelovitost, ton i kvalitetu odbijanja.

Uz širi uzorkovani set držite mali set „nikada ne slomiti”. Taj mali set treba sadržavati incidente koji su prije stigli do korisnika, točne identifikatore, adversarijalno dvosmislena pitanja i pitanja koja moraju proizvesti „Nemam dovoljno dokaza.” Prosjeci se mogu poboljšati dok jedno kritično ponašanje regresira; provjere po pojedinačnom slučaju to hvataju.

Produkcijska telemetrija treba povezati trag od upita do ID-jeva dohvaćenih dokumenata, rezultata, filtara, izlaza rerankera, verzije prompta, odgovora, citata, latencije i troška. Uklonite ili maskirajte osjetljive podatke u tekstu i primijenite kontrolu pristupa na tragove. Pregledavajte odgovore s niskom pouzdanošću ili one koje je korisnik ispravio kao nove evaluacijske slučajeve. Time zatvarate petlju, a da se pritom ne pretvarate da offline testovi pokrivaju svako buduće pitanje.

GraphRAG: kada opravdava složenost

GraphRAG može pomoći kada odgovor ovisi o eksplicitnim odnosima, a ne samo o sličnosti: pitanja s više koraka preko entiteta, ovisnosti organizacije ili imovine, strukture vlasništva koje se mijenjaju ili pitanja poput „koje usluge ovise o komponenti u vlasništvu tima koji održava ovaj sustav?” Graf može te odnose učiniti dostupnima za upite i podržati sažetke na razini zajednica ili entiteta nad velikim korpusom.

Ta korist dolazi s pravim operativnim računom. Potrebna vam je strategija ekstrakcije entiteta i odnosa, identifikatori koji ostaju stabilni, pipeline za ažuriranje grafa, rješavanje sukoba, porijeklo podataka, dozvole, retrieval koji razumije graf i testovi za pogreške ekstrakcije. Graf nije automatski istinit zato što ga je izvukao LLM. Pogrešan brid može zavarati više od promašenog odlomka jer stvara uvjerljiv put između nepovezanih činjenica.

GraphRAG je vjerojatno pretjeran kada je većina pitanja jednokoračni lookup, kada dokumenti već sadrže potreban odgovor, kada filtri metapodataka rješavaju problem pristupa ili kada se korpus i tim još brzo mijenjaju. Loš je i kao prvi potez kada nemate označena pitanja, proces svježine izvora ni način da pregledate izvučene odnose. Graf neće nadoknaditi slabu ingestiju i izostalu evaluaciju.

Prije uvođenja provjerite konkretne signale:

• Izmjereni skup važnih pitanja dosljedno zahtijeva dva ili više retrieval koraka.
• Hibridni retrieval vraća prave dokumente, ali aplikacija ne može pouzdano povezati njihove entitete ili ograničenja.
• Obilazak odnosa je produktni zahtjev, a ne arhitektonska preferencija.
• Korpus ima stabilne identifikatore, vlasnike, porijeklo i održiv put ažuriranja.
• Možete si priuštiti evaluaciju kako izvučenih bridova tako i završnih odgovora.

Počnite s uskim dijelom grafa ili relacijskom tablicom susjedstva za jedan radni tok. Usporedite to s pažljivo ugođenim hibridnim baselineom na istim pitanjima, uz isti proračun latencije i isti pregled kvarova. Ako graf ne poboljša odluku koja je važna, uklonite ga. „GraphRAG” nije značka zrelosti.

Produkcijski put koji ostaje dosadan

Razuman rollout je inkrementalan: uspostavite vlasništvo nad izvorima i filtre pristupa; poboljšajte chunking i metapodatke; dodajte sparse retrieval uz dense retrieval; spojite i ponovno rangirajte; izradite označene testove retrievala i odgovora; zatim instrumentirajte živi put. Tek nakon što baseline ima mjerljive kvarove razmislite o obilasku grafa ili drugim specijaliziranim slojevima.

Najbolji produkcijski RAG sustav nije onaj s najviše komponenti. To je onaj koji može objasniti zašto je odlomak odabran, otkriti kada se kvaliteta promijenila, odbiti odgovor kada nedostaju dokazi i dati svojim operaterima praktično rješenje. Hibridni retrieval poboljšava pokrivenost. Evaluacija pretvara kvalitetu u inženjerski signal. GraphRAG ima svoje mjesto — ali samo kada odnosi opravdavaju tu mašineriju.