RAG nije uspeo — ali koji sloj je zapravo zakazao? Dijagnostička metoda

RAG sistem vraća slab, pogrešan, nepotpun ili nepotkrepljen odgovor. Uobičajena dijagnoza je „pretraga nije uspela“ ili „model je halucinirao“. Obe oznake su previše široke da bi bile korisne. Produkcioni RAG pipeline može da zakaže pre pretrage, tokom pretrage, tokom rangiranja, tokom sastavljanja konteksta, tokom generisanja ili nakon generisanja kada se proveravaju dokazi i validnost.

Zašto „RAG nije uspeo“ nije dijagnoza

Generisanje potpomognuto pretragom kombinuje nekoliko mehanizama: korisnički zahtev se interpretira, konstruiše se jedna ili više pretraga, pronalazi se materijal kandidata, rezultati se filtriraju ili ponovo rangiraju, izabrani dokazi se ubacuju u kontekst modela, a model generiše odgovor. Produkcioni sistemi mogu dodati dozvole, filtere metapodataka, pravila svežine, citate, prepisivanje upita, hibridnu pretragu, pozive alata, memoriju i eksterno stanje.

Pogrešan konačni odgovor vam stoga ne govori koja komponenta je zakazala. Model je možda dobio pogrešne dokaze. Možda je dobio tačne dokaze pomešane sa previše šuma. Dokazi mogu biti tačni ali zastareli. Izvor možda nikada nije ni sadržao odgovor. Ili je model možda ignorisao savršeno adekvatan kontekst.

OpenAI smernice za RAG već prave fundamentalnu razliku između neuspeha pretrage i neuspeha modela: sistem može da obezbedi pogrešan kontekst ili može da obezbedi tačan kontekst i ipak generiše pogrešan odgovor. AWS na sličan način razdvaja evaluaciju samo pretrage od evaluacije pretrage i generisanja. Za produkcijsku dijagnostiku, tu razliku treba odvesti dalje.

RAG Failure Stack

Sloj 1 — Pokrivenost izvora: može li sistem uopšte da odgovori na ovo?

Pre podešavanja embedding-a, rerankera ili prompt-ova, proverite da li odgovor postoji u prostoru znanja koji sistem sme da koristi. Ovo zvuči očigledno, ali mnogi RAG neuspesi su zapravo neuspesi korpusa. Tražena činjenica može biti odsutna, skrivena u neindeksiranom prilogu, dostupna samo u novijem dokumentu, sačuvana u sistemu izvan RAG korpusa ili blokirana dozvolama.

Metrika pretrage ne može da povrati informaciju koja nikada nije indeksirana. Veći top-k ne može da pronađe dokument koji pipeline ne sadrži. Ako test pokrivenosti izvora ne uspe, ispravno rešenje je ingestija, izbor izvora, dozvole ili eksplicitno ponašanje „nije odgovorivo iz dostupnih dokaza“.

Sloj 2 — Konstrukcija upita: da li je sistem korpusu postavio pravo pitanje?

Korisnički upit nije uvek upit za pretragu. Produkcioni sistemi prepisuju pitanja, razrešavaju zamenice, izvlače entitete, prevode jezike, dodaju ograničenja metapodataka, dele složena pitanja ili generišu više pretraga. Svaka transformacija može da poboljša pretragu, ali svaka transformacija može i da uništi informaciju.

Zahtev kao što je „Da li se politika još uvek primenjuje na izvođače u Nemačkoj nakon septembarskog ažuriranja?“ sadrži najmanje entitet, populaciju, jurisdikciju i vremensku granicu. Prepisani upit koji postane „politika za izvođače“ može da pronađe semantički povezan tekst, ali izgubi promenljive koje odlučuju da li je odgovor validan.

Sloj 3 — Pronalaženje kandidata: da li su relevantni dokazi ušli u skup?

Pronalaženje kandidata je prvenstveno problem odziva. Dijagnostičko pitanje još uvek nije da li je najbolji rezultat rangiran prvi; već da li su se relevantni dokazi pojavili bilo gde u skupu kandidata. Ako se poznati ispravan izvor ne pojavljuje, istražite indeksiranje, deljenje na delove, ugrađivanja, leksičko podudaranje, metapodatke, hibridnu pretragu, rukovanje jezikom, sinonime i proširenje upita.

Ovde je evaluacija samo pretrage dragocena. AWS izlaže relevantnost konteksta i pokrivenost konteksta za RAG evaluaciju samo pretrage. Važna proizvodna navika je da se evaluira pretraga pre generisanja, tako da uglađen konačan odgovor ne može sakriti slab skup kandidata.

Sloj 4 — Rangiranje i filtriranje: da li su pravi dokazi odbačeni ili zakopani?

Sistem može imati dobar odziv i ipak ne uspeti jer su relevantni dokazi rangirani ispod bučnog ali semantički sličnog materijala. Ponovni rangirači, pojačavanja skorašnjosti, težine autoriteta, jezičke preferencije, filteri zakupaca, kontrole pristupa, filteri statusa proizvoda i uklanjanje duplikata menjaju ono što preživi u konačnom kontekstu.

Otklanjanje grešaka bi stoga trebalo da sačuva punu listu kandidata, ne samo konačnih top-k. Ako su zlatni dokazi pronađeni na rangu 18 i ponovni rangirač ih je uklonio, ispravka nije ista kao promašaj pretrage.

Sloj 5 — Sastavljanje konteksta: da li su korisni dokazi postali upotrebljiv kontekst?

Uspeh pretrage ne garantuje uspeh konteksta. Relevantni delovi mogu biti skraćeni, odvojeni od svojih kvalifikatora, duplicirani dok ne dominiraju upitom, pomešani sa kontradiktornim verzijama ili okruženi dovoljno irelevantnog teksta da odlučujući odlomak izgubi istaknutost.

Granice delova su posebno važne. Rečenica može sadržati pravilo dok sledeća rečenica sadrži izuzetak. Ako su indeksirane odvojeno i samo prva je pronađena, pretraživač može izgledati relevantno dok sastavljeni kontekst postaje obmanjujući.

Sloj 6 — Generisanje: može li model ispravno koristiti ispravne dokaze?

Kada je sistem dokazano obezbedio dovoljno dokaza, generisanje postaje nezavisno testabilno. Model može preterano generalizovati, kombinovati nekompatibilne odlomke, ignorisati negativnu izjavu, ne uspeti da prati traženi format odgovora, izmisliti vezu između činjenica ili odgovoriti iz parametarske memorije umesto iz pronađenih dokaza.

Zato je samo end-to-end ispravnost nedovoljna za dijagnozu. OpenAI preporučuje evaluaciju kao strukturiran način razumevanja ponašanja aplikacije, dok Anthropic-ove smernice za evaluaciju agenata naglašavaju višestruka ispitivanja, ocenjivače, tragove i realistične slučajeve neuspeha. Za RAG, generator treba testirati i sa normalnom pretragom i sa kontrolisanim zlatnim kontekstom.

Sloj 7 — Pripisivanje dokaza: da li je odgovor zaista podržan?

Uverljiv odgovor sa citatima i dalje može biti slabo utemeljen. Citirani dokument može biti relevantan za temu ali ne podržava konkretnu tvrdnju. Jedna rečenica može biti podržana dok je druga izvedena. Citat može ukazivati na izvor koji protivreči odgovoru kada se pročitaju njegovi uslovi.

Evaluacija citata stoga pripada posle generisanja. AWS razlikuje preciznost citata od pokrivenosti citata: da li su citirani odlomci ispravno citirani i da li je odgovor dovoljno podržan citatima. U proizvodnji, podrška na nivou tvrdnje je korisnija od tretiranja prisustva bilo kog citata kao kvaliteta dokaza.

Sloj 8 — Validnost i svežina: da li su dokazi bili ispravni za ovu verziju stvarnosti?

RAG može pronaći savršeno autentičan, visoko relevantan, verno citiran izvor i ipak proizvesti pogrešan odgovor ako izvor više nije validan za trenutno pitanje. Politike se menjaju. API-ji se ukidaju. cene se menjaju. ponašanje softvera se menja između verzija. inventar proizvoda se menja. dozvole se menjaju. zakrpe igara menjaju mehaniku.

Ovo je odvojena klasa neuspeha od halucinacije. Dokazi su stvarni; njihova primenljivost je pogrešna. Robustan sistem stoga zahteva vremenske oznake, metapodatke o verziji ili jurisdikciji gde je relevantno, autoritet izvora, pravila zamene i eksplicitan mehanizam za odlučivanje kada stariji dokazi moraju biti ograničeni ili napušteni.

Najbrži metod izolacije: test sa orakulskim kontekstom

Najkorisnija prva podela je jednostavna: ručno obezbedite generatoru mali skup dokaza za koje znate da su dovoljni da odgovore na pitanje. Zadržite zadatak i očekivani odgovor nepromenjenim.

Produkcijska dijagnostička sekvenca

Ne menjajte tri sloja odjednom

Česta greška pri otklanjanju grešaka je menjanje ugrađivanja, veličina delova, top-k, upita i modela u jednoj iteraciji. Ako se rezultat poboljša, ne znate zašto. Ako se pogorša, ne znate koja promena je izazvala regresiju.

Tretirajte otklanjanje grešaka u RAG-u kao eksperimentalnu dijagnostiku: držite što veći deo procesa konstantnim i zamenite jednu neizvesnu komponentu kontrolisanim ulazom. Zlatni dokumenti izoluju pronalaženje. Zlatni delovi izoluju izbor delova. Fiksni kontekst izoluje generisanje. Fiksni model izoluje promene u pronalaženju. Fiksni korpus izoluje promene u unosu i indeksiranju.

Matrica neuspeha za uobičajene RAG simptome

Merite svaki sloj metrikom na koju zaista može da utiče

Tačan odgovor i dalje može da sakrije RAG defekt

Obrnuti problem je takođe važan. RAG sistem može da proizvede tačan odgovor dok je pronalaženje pokvareno. Model možda već zna odgovor iz treninga, zaključuje ga iz slabih dokaza ili tačno pogađa. Ako evaluacija gleda samo konačni odgovor, sistem može izgledati zdravo dok pitanje ne dođe do informacija koje postoje samo u privatnom korpusu.

To je isti problem pouzdanosti koji se šire pojavljuje u agentskim sistemima: tačnost ishoda nije dovoljna da dokaže da je put izvršavanja bio pouzdan. Za RAG, tragovi treba da sačuvaju najmanje upit za pronalaženje, skup kandidata, rangiranje, konačni kontekst, odgovor, citate, verziju modela, verziju korpusa/indeksa i relevantne filtere.

Koristite konkurentske hipoteze, a ne omiljeno objašnjenje

Ako loš odgovor odmah postane „problem sa embeddingom“, istraga je već pristrasna. Jača metoda otklanjanja grešaka zapisuje konkurentske hipoteze pre promene sistema: nedostajući izvor, loše prepisivanje upita, nizak recall pretrage, loše rangiranje, skraćivanje konteksta, konfliktne verzije, greška generisanja, greška citiranja ili zastareli dokazi.

Zatim izaberite test koji bi razdvojio te hipoteze. To je efikasnije od prikupljanja više primera koji podržavaju prvo objašnjenje. Isti princip važi za AI-podržano tehničko rezonovanje uopšte: korisna dijagnoza je ona koja preživi diskriminišuće testove, a ne ona koja samo zvuči uverljivo.

Šta bi promenilo ovaj odgovor?

Tačni dijagnostički slojevi se menjaju sa arhitekturom. Jednostavna RAG aplikacija sa jednim dokumentom možda nema prepisivanje upita, reranker ili sloj citiranja. Agentni sistem pretrage može dodati planiranje, višestruke pretrage, izbor alata, memoriju, dozvole i iterativno prikupljanje dokaza. Strukturisano pretraživanje baze podataka možda uopšte ne koristi chunk-ove ili embedding-e.

Osnovna metoda i dalje važi: identifikujte komponente koje mogu nezavisno da promene rezultat, konstruišite kontrolisane testove koji zamenjuju neizvesne komponente poznato-ispravnim ulazima i merite svaku komponentu koristeći dokaze prikladne tom sloju.

Ograničenja

Stvarni otkazi su često povezani. Slab upit može smanjiti recall, što menja rangiranje, što menja kontekst, što povećava varijansu generisanja. Test sa oracle kontekstom je dijagnostička prečica, a ne dokaz da je jedna komponenta isključivo odgovorna. Skupovi podataka za evaluaciju takođe mogu biti nereprezentativni, a ocenjivači zasnovani na modelima mogu uneti sopstvene greške.

Predloženi stack je stoga najbolje koristiti kao strukturu istrage: logujte pipeline, izolujte promenljive, reprodukujte otkaze, testirajte konkurentska objašnjenja i zadržite end-to-end evaluaciju nakon popravki na nivou slojeva.

Zaključak

„RAG nije uspeo“ treba da bude početak istrage, a ne zaključak. Korisna dijagnoza identifikuje da li je sistemu nedostajao dokaz, pretraživao pogrešno, nije uspeo da ga pronađe, loše ga rangirao, sastavio neupotrebljiv kontekst, generisao pogrešno, loše pripisao tvrdnje ili primenio dokaz izvan njegove granice važenja.

Praktično pravilo je jednostavno: zamenite neizvesnost kontrolisanim dokazima sloj po sloj. Počnite sa testom oracle konteksta. Razdvojite evaluaciju samo pretrage od evaluacije generisanja. Sačuvajte puni trag. Zatim popravite komponentu koja je zaista otkazala umesto da podešavate ceo RAG stack po intuiciji.

Česta pitanja

Pojmovnik

Primarni izvori i dodatno čitanje