Timeouti, ne znanje: Kada Legal-RAG evaluatori mjere latenciju

U svijetu evaluacije RAG sustava (Retrieval-Augmented Generation), često se fokusiramo na kvalitetu generiranih odgovora i relevantnost dohvaćenih dokumenata. No, ponekad pravi krivac za loše rezultate nije ni znanje ni generiranje, već nešto sasvim drugo – latencija i timeouti. Ovaj članak analizira slučaj u kojem je legal-RAG sustav za odgovaranje na pitanja (QA) dobio iznenađujuće niske ocjene, iako su njegove sposobnosti bile na visokoj razini. Ključni problem bio je u evaluacijskom procesu, točnije u vremenskim ograničenjima koja su postavljena na proxy poslužitelju.

Što se dogodilo?

Naš legal-RAG sustav, dizajniran za pružanje preciznih odgovora na pravna pitanja na temelju relevantnih zakonskih dokumenata, prolazio je kroz standardnu evaluaciju. Evaluator je slao upite i mjerio kvalitetu odgovora. No, sustav je sustavno dobivao niske ocjene, unatoč tome što su ručne provjere pokazivale da su odgovori točni i dobro potkrijepljeni. Nakon detaljne analize, otkrili smo da evaluator nije ni dočekao odgovore – oni su stizali prekasno, nakon što je evaluator već odustao čekajući.

Uloga nginx proxyja i timeouta

U našoj arhitekturi, nginx je služio kao reverzni proxy između evaluatora i RAG sustava. Nginx je imao konfigurirana vremenska ograničenja (timeoute) za čitanje zahtjeva i slanje odgovora. Kada je RAG sustav trebao više vremena za generiranje odgovora – na primjer, zbog složenog dohvaćanja dokumenata ili generiranja dugog, detaljnog odgovora – nginx bi prekinuo vezu s evaluatorom, šaljući mu poruku o grešci ili prazan odgovor. Evaluator je to interpretirao kao neuspjeh sustava, iako je sustav zapravo radio ispravno, samo je trebao više vremena.

Budžet latencije: ključni faktor

Ovaj slučaj naglašava važnost definiranja realnog budžeta latencije za RAG sustave, posebno u pravnoj domeni gdje su odgovori često složeni i zahtijevaju dubinsku analizu. Ako evaluator postavi prekratak timeout, sustav koji pruža kvalitetne, ali sporije odgovore, bit će nepravedno kažnjen. S druge strane, predug timeout može dovesti do frustracije korisnika u stvarnom vremenu. Stoga je ključno pronaći ravnotežu i prilagoditi evaluacijske parametre stvarnim karakteristikama sustava.

Kako smo riješili problem?

Nakon što smo identificirali uzrok, poduzeli smo nekoliko koraka. Prvo, povećali smo timeout vrijednosti u nginx konfiguraciji, omogućivši RAG sustavu više vremena za generiranje odgovora. Drugo, optimizirali smo sam RAG sustav kako bi smanjili latenciju – ubrzali smo dohvaćanje dokumenata, poboljšali keširanje i optimizirali generiranje odgovora. Također smo dodali logiranje vremena odziva kako bismo lakše pratili performanse. Nakon ovih promjena, evaluacijski rezultati su se dramatično poboljšali, potvrđujući da je problem bio u latenciji, a ne u znanju.

Pouke za evaluaciju RAG sustava

Ovaj slučaj donosi važne pouke za sve koji razvijaju ili evaluiraju RAG sustave:

• Uvijek provjerite evaluacijske parametre: Prije nego što donesete zaključke o kvaliteti sustava, provjerite jesu li timeouti i druga vremenska ograničenja postavljena u skladu s očekivanim vremenom odziva.
• Razumijevanje arhitekture: Poznavanje cijelog lanca – od evaluatora, preko proxyja, do samog RAG sustava – ključno je za dijagnosticiranje problema.
• Optimizacija latencije: Iako je kvaliteta odgovora primarna, latencija je jednako važna za praktičnu upotrebu. Redovito pratite i optimizirajte vrijeme odziva.
• Testiranje u stvarnim uvjetima: Evaluacije bi trebale simulirati stvarne uvjete korištenja, uključujući i vremenska ograničenja koja će korisnici iskusiti.

Na kraju, važno je shvatiti da evaluacija RAG sustava nije samo mjerenje točnosti odgovora. To je složen proces koji uključuje i tehničke aspekte poput latencije, skalabilnosti i pouzdanosti. Ignoriranje tih aspekata može dovesti do pogrešnih zaključaka i loših odluka.

U našem slučaju, rješenje je bilo jednostavno – prilagoditi timeout i optimizirati performanse. No, bez dubinske analize, mogli smo pogrešno zaključiti da naš RAG sustav nije dobar, što bi bilo daleko od istine. Zato je ključno uvijek imati na umu da loši rezultati evaluacije ne moraju značiti loše znanje – ponekad je krivac običan timeout.