Retriever와 retriever 평가 지표

RAG 혹은 LLM 의 답변 평가 시에 답변의 근거를 가져오는 Retriever와 평가 지표에 대해 기재한다.

Retriever 란?

RAG에서 사용자 질문에 답하는 데 필요한 근거 문서를 찾아오는 컴포넌트.
rag의 전체흐름은 아래와 같다.

사용자 질문
    ↓
Retriever
    ↓
retrieval_context
    ↓
Generator
    ↓
actual_output

retriever는 정책 문서 레포지토리에서 관련되는 근거 문서를 조회한다. generator는 이 근거들을 기반으로 최종 답변을 작성하게 된다.

Retriever가 필요한 이유

LLM이 학습한 자체 지식만 사용하면 다음과 같은 문제가 발생할 수 있다.

• 최신 정책을 모를 수 있음
• 회사 내부 정보를 모름
• 근거 없이 그럴듯한 답변을 만들 수 있음
• 어느 문서를 사용했는지 추적하기 어려움

RAG는 답변 전에 관련 문서를 검색해서 이 문제를 줄인다.

Retriever 내부의 일반적인 동작

retriever는 일반적으로 아래와 같이 동작한다.

1. 사용자 질문을 검색 query로 변환
2. 문서 index에서 관련 chunk 검색
3. 각 chunk에 유사도 score 부여
4. score 순서로 정렬
5. 상위 top-k개 반환
6. 필요하면 reranker로 순서를 다시 조정

1. 문서를 chunk 단위로 나눈다.

원본 정책 문서가 매우 길면 검색하기 어렵기 때문에 미리 작은 단위로 나눈다.

환불 정책 전체 문서
├─ chunk 1: 환불 가능 기간
├─ chunk 2: 환불 신청에 필요한 정보
├─ chunk 3: 환불 요청 채널
└─ chunk 4: 환불 제외 상품

2. 질문과 관련 있는 chunk를 검색한다.

질문: 지난주 상품을 환불하려면 어떻게 해야 하나요?

retriever는 다음 문서들의 관련도를 계산한다.

0.94  구매 후 30일 이내에는 환불할 수 있습니다.
0.89  환불 요청에는 주문 번호와 구매일이 필요합니다.
0.85  환불은 고객센터를 통해 요청해야 합니다.
0.31  일반 배송은 평균 2~3일이 걸립니다.
0.18  회원 등급은 구매 금액을 기준으로 산정합니다.

3. top-k만 반환한다.

이후에 top-k 를 반환한다. 만약 3 이라면 상위 세 문서만 반환한다.

[
    "구매 후 30일 이내에는 환불할 수 있습니다.",
    "환불 요청에는 주문 번호와 구매일이 필요합니다.",
    "환불은 고객센터를 통해 요청해야 합니다.",
]

여기서 top-k 가 너무 작으면 필요한 문서가 누락될 수도 있고, 너무 크면 불필요한 문서들이 섞일 수 있다.

Retriever와 Reranker의 차이

retriever는 많은 문서 중에 관련 있어 보이는 후보를 빠르게 찾는다. Reranker는 찾은 후보들을 더 자세히 비교해서 순서를 조정한다.

Retriever가 실패하면 Generator는 어떻게 되는가?

Retriever와 Genarator는 서로 다른 컴포넌트지만 결과에는 연쇄적으로 영향을 준다.

1. Retriever가 근거를 누락한 경우

Retriever:
환불 기간과 고객센터 문서만 반환
    ↓
Generator:
“30일 이내에 고객센터로 요청하세요.”

환불 시도 시에 주문번호와 구매일이 필요한 경우에는, 위 내용대로라면 최종 답변이 불완전하다. 이것은 가져오는 근거가 잘못되었기 때문이다.

2. Retriever는 정상인데 Generator가 무시한 경우

Retriever:
환불 기간, 필요 정보, 고객센터 문서를 모두 반환
    ↓
Generator:
“30일 이내에 환불할 수 있습니다.”

필요한 근거는 모두 검색되었지만, Genarator가 주문번호와 고객센터 내용을 사용하지 않았다. 이 경우라면 Generator를 먼저 조사해야한다.

3. 애초에 Retriever가 잘못된 문서를 가져온 경우

Retriever:
“구 정책에서는 90일 이내 환불할 수 있습니다.”
    ↓
Generator:
“90일 이내에 환불할 수 있습니다.”

이 경우에 가져온 근거가 잘못되었으므로 답변도 잘못된 답변이 나온다.

위와 같은 경우들에는, 최종답변만 평가하는 블랙박스 테스트로는 근거가 되는 문서를 잘못 가져왔는지, 제대로된 문서를 가져왔지만 답변을 잘못했는지에 대해서 구분할 수가 없다.

그래서 retrieval context를 직접 확인해야한다.

Retrieval 평가 메트릭

평가 메트릭에는 대표적으로 3개가 있다.

• ContextualRecallMetric: 필요한 근거가 제대로 포함되어 있는지?
• ContextualRelevancyMetric: 가져온 내용에 쓸데없는 정보가 섞여있는지?
• ContextualPrecisionMetric: 유용한 근거가 앞쪽에 배치되었는지?

메트릭	비교하는 값	주요 질문	낮을 때 첫 조사 대상
Contextual Recall	expected_output ↔ retrieval_context	기대 답변에 필요한 근거를 모두 검색했는가?	query, index, chunk, top-k
Contextual Relevancy	input ↔ retrieval_context	검색 결과의 내용이 질문과 관련 있는가?	query, filter, chunk, top-k
Contextual Precision	input + expected_output ↔ 순서가 있는 retrieval_context	유용한 근거를 앞쪽에 가져왔는가?	ranking, reranker

1. Contextual Recall

실제 답변을 작성하는 데 필요한 근거를 제대로 가져오는가?

기대 결과와 실제 읽어온 근거값을 바탕으로 비교한다.

필요한 근거를 모두 가져왔지만, 불필요한 문서를 함께 가져 온 경우에는 recall 점수가 높을 수 있다. 기본적으로 이 지표는 빠진 것이 있는지를 체크하기 때문이다.

2. Contextual Relevancy

검색 결과에 포함된 내용들이 사용자 질문과 관련 있는가?

사용자의 질문에 대해서 조회한 문서들이 관련이 있는지를 판단한다.

관련도가 높지만 관련은 있으나 필요한 문서를 모두 검색하지 않는 경우에 문제가 발생한다.

즉, Relevancy는 높지만, Recall 점수는 낮은 경우다. 그래서 두 지표는 따로 사용해야한다.

3. Contextual Precision

관련도가 높은 문서를 검색 결과의 앞쪽에 배치했는가?

답변을 하기에 관련도가 높은 문서가 순위가 높게 판단되었는지를 확인한다.
여러 문서를 가져와도 관련도가 높은 문서들이 순위가 높다면, 이 메트릭의 평가점수는 높다. 그런데 필요한 문서들을 잘 가져와도 관련도가 높은 문서들의 순위가 낮다면, 이 메트릭의 평가점수는 낮게 측정된다.

필요한 문서가 존재하기 때문에 recall의 점수는 높고, 문서들을 잘 가져왔기 때문에 relevancy 점수도 높을 수 있다. 그러나 관련 문서의 순위가 뒤로 밀렸으므로 precision의 점수는 낮아진다.

관련 지표들의 해석

• 낮은 Contextual Recall
  • 필수 근거가 검색되지 않았을 가능성
  • query, index, chunk, top-k부터 조사
• 낮은 Contextual Relevancy
  • 무관한 내용이 많이 유입됐을 가능성
  • query, filter, chunk, top-k부터 조사
• 낮은 Contextual Precision
  • 유용한 근거가 뒤로 밀렸을 가능성
  • ranking, similarity score, reranker부터 조사

결국, Retriever는 세 조건을 만족해야한다.

• 필요한 근거를 모두 가져온다 -> Recall
• 불필요한 근거를 적게 가져온다 -> Relevancy
• 중요한 근거를 앞에 배치한다 -> Precision