Kako evaluirati RAG: metrike pretrage, vjernost izvoru i zlatni skup

RAG sistem ima dvije faze koje griješe na različite načine. Pretraga može promašiti odlomak u kojem je odgovor. Generisanje može zanemariti, pogrešno pročitati ili uljepšati odlomak koji je dobilo. Ako ocjenjujete samo konačni odgovor, saznate da nešto nije u redu, ali ne i koju polovinu treba popraviti.

Ovaj vodič je za inženjere i vlasnike proizvoda koji vode RAG chatbotove, asistente za pretragu ili odgovaranje na pitanja iz dokumenata i žele mjerenja kojima mogu vjerovati. Pokriva dvije porodice metrika, provjeru vjernosti izvoru, izradu zlatnog skupa i mjesta gdje LLM sudije navode na pogrešan zaključak.

Metrike čitajte zajedno. Nizak recall uz visoku vjernost izvoru znači da se model dobro ponaša na lošem kontekstu, pa popravite pretragu. Visok recall uz nisku vjernost znači da pravi odlomci stižu, a model se od njih udaljava, pa pogledajte prompt, model ili format konteksta. Tačni odgovori uz nisku vjernost su također upozorenje: model odgovara iz podataka na kojima je treniran, a to prestaje raditi čim vaši dokumenti kažu nešto drugačije od općeg znanja.

Kada su relevantni odlomci označeni, metrike pretrage su jeftine i determinističke, pa ih pokrećite pri svakoj promjeni. Naš vodič o embeddingima i semantičkoj pretrazi pokazuje kako izračunati recall@k i nDCG.

Vjernost izvoru (faithfulness) pita da li odgovor kaže samo ono što izvori potkrepljuju. Ocjenjivanje cijelog odgovora odjednom nije pouzdano, jer se jedna nepotkrijepljena rečenica lako sakrije među tačnim. Pouzdaniji način:

1. 01Odgovor podijelite na pojedinačne tvrdnje uz pomoć modela, ili podjelom na rečenice za kratke odgovore.
2. 02Za svaku tvrdnju pitajte model u ulozi sudije da li je pronađeni odlomci potkrepljuju, da li joj proturječe ili o njoj ništa ne kažu.
3. 03Tražite od sudije da citira dokaz i provjerite da taj citat postoji u izvorima.
4. 04Za svaki odgovor prijavite udio potkrijepljenih tvrdnji i označite svaku tvrdnju kojoj izvori proturječe.

import json
from anthropic import Anthropic

client = Anthropic()

JUDGE_PROMPT = """Decide whether the sources support the claim.
Reply with JSON only: {{"verdict": "supported" | "contradicted" | "not_found", "quote": "<exact text or empty>"}}

Sources:
{sources}

Claim:
{claim}"""

def judge_claim(claim: str, sources: list[str]) -> dict:
    context = "\n\n".join(sources)
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=300,
        messages=[{"role": "user", "content": JUDGE_PROMPT.format(sources=context, claim=claim)}],
    )
    result = json.loads(response.content[0].text)
    if result["verdict"] == "supported" and result["quote"] not in context:
        result["verdict"] = "unverified"  # the judge quoted text that is not in the sources
    return result

Provjera citata je važna. Sudije ponekad označe tvrdnju kao potkrijepljenu i izmisle dokaz, a poređenje nizova to jeftino uhvati. U stvarnoj upotrebi prije poređenja normalizujte razmake i gdje je moguće koristite strukturirane izlaze, da se JSON uvijek može parsirati.

Zlatni skup (golden set) je pažljivo odabrana zbirka pitanja uz opis tačnog ishoda. Za RAG svaka stavka treba sadržavati:

• Pitanje, napisano onako kako ga pitaju stvarni korisnici.
• Identifikatore odlomaka koji sadrže odgovor.
• Referentni odgovor, ili ključne činjenice koje tačan odgovor mora sadržavati.
• Oznake za namjeru, težinu i rizik, plus oznaku za pitanja na koja dokumenti nemaju odgovor.

Pitanja uzimajte iz logova pretrage, tiketa podrške i od stručnjaka iz oblasti, a pitanja bez odgovora namjerno uključite. Ciljajte na nekoliko stotina stavki kroz glavne vrste dokumenata. Relevantne odlomke označite na nivou koji preživi novu podjelu teksta, na primjer dokument i sekciju, da skup ostane važeći kada promijenite strategiju chunkinga.

Zlatni skup verzionirajte i pregledajte ga kada se dokumenti promijene. Inače će pitanje čiji je odgovor prešao u novu verziju pravilnika kažnjavati sistem zato što je u pravu.

Modeli u ulozi sudije omogućuju evaluaciju odgovora u velikom obimu, ali imaju dobro poznate slabosti:

• Pristrasnost prema dužini i stilu. Sudije obično daju prednost dužim i samouvjerenijim odgovorima. Ocjenjujte prema konkretnim kriterijima i ključnim činjenicama i ne pitajte koji je odgovor ukupno bolji.
• Sklonost sebi. Sudija može davati prednost izlazima iz svoje porodice modela. Gdje možete, za sudiju koristite drugi model od onog koji generiše odgovore.
• Pristrasnost prema poziciji. Kod poređenja u parovima prva opcija češće pobjeđuje. Pokrenite oba redoslijeda.
• Nejasne rubrike. "Ocijenite korisnost od 1 do 10" daje šum. Koristite nekoliko kategorija s napisanim definicijama.
• Neprovjerene sudije. Ručno ocijenite uzorak i izmjerite slaganje prije nego što povjerujete sudiji, i provjerite ponovo nakon promjene modela ili prompta sudije.
• Curenje informacija. Ako sudija vidi referentni odgovor dok provjerava vjernost izvoru, može nagrađivati poklapanje s referencom umjesto poklapanja s izvorima.

1. 01Sastavite zlatni skup stvarnih pitanja s označenim odlomcima, referentnim činjenicama i pitanjima bez odgovora.
2. 02Metrike pretrage pokrećite pri svakoj promjeni chunkinga, embeddinga, pretrage ili ponovnog rangiranja.
3. 03Provjere vjernosti izvoru, tačnosti, navedenih izvora i odbijanja pokrećite pri svakoj promjeni prompta ili modela.
4. 04Sudiju uporedite s ljudskim ocjenama i provjerite ponovo kad god se sudija promijeni.
5. 05Nove verzije puštajte tek kada prođu dogovorene pragove, kako je opisano u članku LLM evaluacije prije svake nove verzije.
6. 06Svake sedmice uzmite uzorak razgovora iz stvarne upotrebe i greške pretvorite u nove stavke zlatnog skupa.

Ovakvu evaluaciju postavljamo prije podešavanja bilo kojeg RAG sistema, jer svaku kasniju promjenu pretvara u odluku zasnovanu na mjerenju. Naš RAG projekat za advokatsku kancelariju primjer je sistema izrađenog na ovaj način, vodič za RAG chatbot u stvarnoj upotrebi pokriva samu izradu, a kako radimo objašnjava gdje su evaluacije u našem procesu isporuke.