A legtöbb csapat túl egyszerű metrikákkal próbálja mérni a RAG rendszerét - például egyetlen “jó-e a válasz?” típusú mutatóval. Ez önmagában nem elég.

 

Egy válasz lehet:

 

pontos, de irreleváns  

releváns, de hallucinált  

vagy majdnem jó — csak pont a lényeg hiányzik

 

Erre való a RAGAS.

Ebben a posztban bemutatom az alapvető RAGAS mutatókat, erősségeiket és gyengeségeiket.

 

Nem azt méri, hogy “jó-e a válasz”.

Hanem szétszedi a RAG pipeline-t — és külön méri a rétegeket.

 

De van egy fontos tanulság, amit fontos kiemelni:

 

a RAGAS nem végső ítélet.

Inkább erős warning signal.

 

Főleg answer relevancy esetén.

 

A saját kísérletemben 43 kérdést generáltam egy bank Tudástárából.

 

A 4 metrika, amit néztem:

 

Faithfulness  

A modell azt mondja, ami a kontextusban van?  

→ ha nem, hallucinál

 

Context recall  

A szükséges információ bekerült a kontextusba?  

→ ha nem, retrieval hiba

 

Context precision  

A kontextus mennyire tiszta?  

→ ha nem, a modell zajos inputból dolgozik

 

Answer relevancy  

A válasz mennyire illeszkedik a kérdéshez és az elvárt válaszhoz?  

→ itt viszont óvatosnak kell lenni

 

Mert az answer relevancy komplex ground truth esetén könnyen félrevezethet.

 

Az én kísérletemben például:

 

a recall felment 0.95-re,  

de az answer relevancy megakadt ~0.65 körül.

 

Elsőre úgy tűnt:

 

👉 nem retrieval probléma  

👉 hanem prompt probléma

 

De amikor mélyebbre mentem, kiderült:

 

sok alacsony relevancy score mögött nem valódi hiba volt.

 

Hanem az, hogy a generált válasz:

 

- bővebb volt, mint a referencia válasz  

- más szavakkal fogalmazta meg ugyanazt  

- vagy több kontextusból jövő információt adott vissza, mint amit a ground truth tartalmazott

 

Magyarul:

 

bizonyos komplexebb esetekben az answer relevancy score alacsony lett akkor is, amikor emberi szemmel a válasz megfelelő volt.

 

Ezért építettem rá egy külön LLM autoeval réteget.

 

Nem a RAGAS helyett.

Hanem fölé.

 

A logika:

 

1. RAGAS jelez, hogy valami gyanús  

2. LLM judge megnézi, hogy ez valódi hiba-e  

3. különválasztjuk a false negative eseteket a tényleges hibáktól  

4. csak ezután mondjuk meg, hogy retrieval, prompt vagy modell reasoning probléma történt-e

 

Ez volt az egyik legfontosabb tanulság:

 

A RAG evaluation nem arról szól, hogy keresel egy tökéletes metrikát.

 

Hanem arról, hogy több mutatót rétegezel egymásra.

 

RAGAS jó első diagnosztikai réteg.

 

De ha komplex, üzleti tudásbázison dolgozol,

akkor szükséged lesz egy második rétegre is:

 

egy answer diagnostic modulra,

ami megmondja, hogy az alacsony score mögött valódi hiba van-e,

vagy csak a metrika nem érti elég jól a választ.

 

A RAG nem egy modell.

Hanem egy pipeline.

 

És az evaluation sem egy score.

Hanem egy diagnosztikai rendszer.