Two pipelines, two failure modes, four metrics
A RAG system has two stages and at least four ways to fail. The retrieval stage may pull wrong or insufficient docs; the generation stage may hallucinate, summarize wrong, or answer the wrong question. You must evaluate each stage independently.
Retrieval-stage metrics
- Recall@k — fraction of relevant docs retrieved in the top k.
- Precision@k — fraction of top-k docs that are relevant.
- nDCG@k — normalized Discounted Cumulative Gain. Rewards relevant docs ranked higher.
- MRR — Mean Reciprocal Rank. Average of 1/rank of the first relevant doc.
Generation-stage metrics
- Faithfulness — does the answer make claims supported by the retrieved context?
- Answer Relevancy — does the answer address the user's question?
- Citation accuracy — if your system cites sources, do citations link to actual supporting passages?
Why decomposed metrics matter
An aggregate "RAG quality score" is useless for debugging. Per-stage metrics tell you exactly where to spend engineering effort:
- Low recall → fix the retriever (better embeddings, hybrid search, query rewriting).
- High recall, low faithfulness → fix the generator prompt, lower temperature, enforce citations.
- High faithfulness, low relevance → the retriever finds correct docs but the generator answers a different question — usually a prompt issue.
Principle: Always measure retrieval and generation independently in RAG. A composite score lies; per-stage metrics tell the truth.
Build a RAG eval set
For each case, capture: question, expected_relevant_doc_ids, reference_answer. The first lets you score retrieval; the third lets you score generation. The middle is the bridge. Without all three, you can only do half the eval.