[바미] RAG는 어떤 질문에 약할까?

들어가기 전에

같은 RAG에 다음 두 질문을 입력했다고 가정해보겠습니다.

 

첫 번째 질문입니다.

A사의 2025년 2분기 영업이익은 얼마인가요?

RAG는 관련 문서를 검색하고 정확하게 답했습니다.

 

두 번째 질문입니다.

A사와 B사 중 2025년 2분기에 영업이익이 더 많이 증가한 회사는 어디인가요?

이번에는 틀린 답을 내놓았습니다.

 

두 질문 모두 같은 문서와 같은 검색 모델, 같은 LLM을 사용했습니다. 그런데 질문의 형태가 조금 달라지자 결과가 달라졌습니다.

첫 번째 질문은 하나의 문서에서 숫자 하나를 찾으면 답할 수 있습니다.

두 번째 질문에 답하려면 더 많은 과정이 필요합니다.

• A사의 2024년 2분기 영업이익 찾기
• A사의 2025년 2분기 영업이익 찾기
• B사의 2024년 2분기 영업이익 찾기
• B사의 2025년 2분기 영업이익 찾기
• 각 회사의 증가율 계산하기
• 두 증가율 비교하기

검색해야 하는 문서도 많고, 계산 과정도 추가됩니다. 하나의 근거만 빠져도 정확한 답을 만들기 어렵습니다.

RAG의 성능은 시스템 설정뿐 아니라 사용자가 어떤 형태로 질문하느냐에 따라서도 달라질 수 있습니다.

 

그런데 전체 질문의 평균 정확도만 보면 이런 차이가 잘 드러나지 않습니다.

이번 글에서는 RAG가 어떤 질문에서 주로 어려움을 겪는지 살펴보고, 질문 유형별로 성능을 나눠서 평가하는 방법을 정리해보겠습니다.

전체 정확도만 보면 문제가 없어 보일 수 있습니다

100개의 평가 질문에서 80개를 정확히 답했다고 가정해보겠습니다. 전체 답변 정확도는 80%입니다.

이 숫자만 보면 RAG가 대체로 잘 동작하는 것처럼 보입니다. 하지만 질문 유형별로 나누면 결과가 다음과 같을 수 있습니다.

 

질문	유형질문	수정답	수정확도
단순 사실 질문	20개	19개	95%
날짜·숫자 질문	20개	17개	85%
조건·예외 질문	15개	11개	73%
비교 질문	15개	10개	67%
여러 문서가 필요한 질문	15개	8개	53%
답이 없는 질문	15개	15개 중 15개	상황에 따라 다름

 

단순 사실 질문은 거의 모두 맞혔지만, 여러 문서를 함께 확인해야 하는 질문에서는 절반 정도만 맞혔습니다.

그런데 전체 평균에는 이 차이가 섞여 있습니다.

평균 정확도만 보고 임베딩 모델이나 Reranker를 교체하면 실제 문제를 해결하지 못할 수도 있습니다.

예를 들어 여러 문서가 필요한 질문에서 문제가 발생했다면 검색 모델 자체보다 다음 부분이 원인일 수 있습니다.

• 복잡한 질문을 여러 검색어로 나누지 못함
• 필요한 문서 중 일부만 검색됨
• 여러 문서의 정보를 연결하지 못함
• 한정된 Context에 모든 근거가 들어가지 못함
• LLM이 검색된 숫자를 비교하거나 계산하는 과정에서 실수함

전체 점수는 RAG가 얼마나 잘 동작하는지를 보여주지만, 어떤 질문에서 실패하는지는 알려주지 않습니다.

 

그래서 평가 질문에 유형을 표시하고, 유형별 점수를 함께 확인해야 합니다.

질문 유형을 나누는 기준은 하나가 아닙니다

질문은 여러 기준으로 분류할 수 있습니다.

답변 형태를 기준으로 나눌 수 있습니다

• 단어 또는 짧은 문장으로 답하는 질문
• 숫자로 답하는 질문
• 날짜로 답하는 질문
• 목록으로 답하는 질문
• 비교 결과를 답하는 질문
• 긴 설명이 필요한 질문

필요한 근거의 수를 기준으로 나눌 수 있습니다

• 하나의 문서만 필요한 질문
• 하나의 문서 안에서 여러 문단이 필요한 질문
• 여러 문서가 필요한 질문
• 여러 문서를 순서대로 찾아야 하는 질문

질문의 명확성을 기준으로 나눌 수 있습니다

• 대상과 조건이 명확한 질문
• 필요한 조건이 빠진 질문
• 여러 의미로 해석될 수 있는 질문
• 이전 대화가 없으면 이해하기 어려운 질문

답변 가능 여부를 기준으로 나눌 수 있습니다

• 문서에 답이 있는 질문
• 문서에 답의 일부만 있는 질문
• 문서에 답이 없는 질문
• 서로 충돌하는 답이 있는 질문

하나의 질문이 여러 유형에 동시에 포함될 수도 있습니다.

 

예를 들어 다음 질문을 살펴보겠습니다.

A사와 B사의 2024년 대비 2025년 매출 증가율을 비교해주세요.

 

이 질문에는 여러 특징이 있습니다.

• 숫자 질문
• 비교 질문
• 여러 문서가 필요한 질문
• 계산이 필요한 질문
• 여러 단계의 추론이 필요한 질문

따라서 질문마다 유형을 하나만 지정하기보다는 대표 유형과 추가 태그를 함께 저장하는 편이 좋습니다.

질문 유형은 서로 완전히 분리된 상자가 아니라, 하나의 질문이 가진 여러 난이도 요소를 표시하는 태그에 가깝습니다.

단순 사실 질문

단순 사실 질문은 하나의 문서에서 하나의 근거를 찾으면 답할 수 있는 질문입니다.

 

예를 들면 다음과 같습니다.

• 회사의 설립일은 언제인가요?
• 건강검진은 연간 몇 회 지원되나요?
• 서비스 이용료는 얼마인가요?
• 반품 신청 기간은 며칠인가요?

이런 질문은 일반적인 RAG가 비교적 잘 처리하는 유형입니다.

사용자의 질문과 정답 문서에 비슷한 단어가 포함되어 있을 가능성이 높고, 하나의 청크만 찾아도 답할 수 있기 때문입니다.

하지만 단순해 보이는 질문도 다음과 같은 경우에는 어려워질 수 있습니다.

같은 이름을 가진 대상이 여러 개 있습니다

Basic 요금제의 이용료는 얼마인가요?

 

문서에 과거 Basic 요금제와 현재 Basic 요금제가 모두 있다면 어떤 버전을 찾아야 하는지 구분해야 합니다.

질문과 문서의 표현이 다릅니다

사용자는 퇴사라고 질문했지만 문서에는 근로관계 종료라고 적혀 있을 수 있습니다.

키워드 검색만 사용한다면 관련 문서를 놓칠 수 있습니다.

비슷한 문서가 많습니다

• 2024년 이용약관
• 2025년 이용약관
• 개정 예정 이용약관
• 내부 검토용 이용약관

정답 문서를 검색했더라도 오래된 문서가 더 높은 순위에 나올 수 있습니다. 단순 사실 질문에서는 다음 항목을 확인하면 좋습니다.

• 정답 문서가 검색 결과에 포함되었는가
• 정답 문서가 상위 몇 위에 있었는가
• 올바른 문서 버전을 선택했는가
• 답변에 필요한 값을 정확하게 추출했는가
• 검색된 근거와 최종 답변이 일치하는가

평가 지표로는 다음을 사용할 수 있습니다.

• Hit@K
• Recall@K
• MRR
• 답변 정확도
• Faithfulness

단순 사실 질문에서조차 성능이 낮다면 먼저 검색의 기본 설정을 확인해야 합니다.

• 문서 파싱이 정상적으로 되었는가
• 정답 문서가 지식 베이스에 존재하는가
• 청크에 질문과 연결할 표현이 남아 있는가
• 임베딩 모델이 해당 언어와 도메인에 적합한가
• 메타데이터 필터가 정답 문서를 제외하지 않았는가

날짜와 숫자가 포함된 질문

날짜와 숫자 질문은 정답이 짧아 보여도 생각보다 많은 오류가 발생할 수 있습니다. 예를 들어 다음 질문이 있습니다.

A사의 2025년 2분기 영업이익은 얼마인가요?

 

RAG는 다음 내용을 정확하게 구분해야 합니다.

• 회사: A사
• 기간: 2025년 2분기
• 지표: 영업이익
• 단위: 원, 만 원, 억 원 또는 백만 원
• 값: 실제 숫자

문서에서 숫자 35만 찾았다고 정답이 되는 것은 아닙니다.

• 영업이익 35억 원
• 매출 35억 원
• 영업이익률 35%
• 전년 대비 35% 증가
• 2024년 영업이익 35억 원

같은 숫자라도 의미가 모두 다릅니다.

표의 제목과 단위가 분리될 수 있습니다

재무 문서의 표가 다음과 같다고 가정해보겠습니다.

구분	2024년 2분기	2025년 2분기
매출	320	360
영업이익	28	35

 

표 위에는 다음과 같이 적혀 있습니다.

단위: 억 원

문서를 청킹하거나 파싱하는 과정에서 단위: 억 원이 다른 청크로 분리되면 RAG는 35라는 숫자는 찾더라도 단위를 알지 못할 수 있습니다.

계산이 필요한 질문은 더 어려워집니다

다음 질문은 문서에 정답이 그대로 적혀 있지 않을 수 있습니다.

A사의 영업이익은 전년 동기 대비 몇 퍼센트 증가했나요?

 

문서에는 다음 값만 있을 수 있습니다.

• 2024년 2분기 영업이익: 28억 원
• 2025년 2분기 영업이익: 35억 원

RAG는 두 숫자를 검색한 뒤 증가율을 계산해야 합니다. 이 과정에서는 서로 다른 오류를 구분해야 합니다.

• 필요한 숫자를 검색하지 못함
• 잘못된 기간의 숫자를 검색함
• 단위를 잘못 해석함
• 계산식을 잘못 적용함
• 계산은 맞지만 반올림 규칙이 다름
• 올바른 값이 Context에 있었지만 LLM이 다른 숫자를 사용함

숫자 질문에서 정답이 틀렸다고 해서 항상 검색의 문제인 것은 아닙니다. 검색, 값 추출, 단위 해석과 계산 단계를 따로 확인해야 합니다.

 

날짜와 숫자 질문에서는 다음 항목을 평가하는 것이 좋습니다.

• 필요한 값이 모두 검색되었는가
• 숫자가 올바른 항목과 연결되었는가
• 기간과 문서 버전이 정확한가
• 단위가 보존되었는가
• 계산식이 올바른가
• 허용 오차 안에 답했는가

평가할 때 35억 원, 3,500,000,000원, 35억원처럼 표현만 다른 답을 오답으로 처리하지 않도록 숫자와 단위를 정규화할 필요도 있습니다.

조건과 예외가 포함된 질문

다음 질문을 살펴보겠습니다.

입사 1년 미만 직원이 한 달 동안 하루 결근했다면 연차가 발생하나요?

 

이 질문에 답하려면 여러 조건을 함께 확인해야 합니다.

• 적용 대상이 입사 1년 미만 직원인지
• 연차는 1개월 개근 시 발생하는지
• 결근이 있으면 개근으로 인정되지 않는지
• 별도의 예외 규정이 있는지

문서에는 다음과 같이 적혀 있을 수 있습니다.

입사 1년 미만인 직원은 1개월을 개근할 때마다 1일의 유급휴가가 발생합니다. 다만 해당 기간에 결근한 날이 있다면 그 달에는 유급휴가가 발생하지 않습니다.

 

청크가 작게 나뉘면 조건과 결론이 서로 다른 청크에 들어갈 수 있습니다.

• 청크 1: 입사 1년 미만 직원
• 청크 2: 1개월 개근 시 1일 발생
• 청크 3: 결근한 달에는 발생하지 않음

검색 결과에서 청크 2만 가져오면 RAG는 연차가 발생한다고 답할 수 있습니다. 하지만 예외가 담긴 청크 3까지 확인해야 정확한 답을 만들 수 있습니다.

따라서 조건 질문에서는 단순히 정답 문서가 하나 검색되었는지만 보면 부족하기 때문에 정답을 구성하는 핵심 사실을 미리 나눠두는 것이 좋습니다.

• 적용 대상
• 적용 조건
• 결론
• 예외 조건
• 적용 기간

그다음 검색 결과와 답변이 각 항목을 얼마나 포함했는지 평가합니다.

 

예를 들어 핵심 사실 네 개 중 세 개만 포함했다면 문맥 완전성을 0.75로 계산할 수 있습니다. 이 값은 정해진 표준 지표라기보다 프로젝트에서 정의하는 평가 항목입니다. 중요한 것은 모든 평가 질문에서 같은 기준을 사용하는 것입니다.

조건과 예외 질문에서는 다음 항목을 확인하면 좋습니다.

• 필요한 조건이 모두 검색되었는가
• 예외 조항이 함께 검색되었는가
• 조건과 결론의 관계를 올바르게 해석했는가
• 일부 조건만 보고 지나치게 일반화하지 않았는가
• 답변에 적용 범위를 명확하게 표시했는가

부정 표현이 포함된 질문

조건 질문 중에서도 부정 표현은 별도로 확인할 필요가 있습니다. 다음 두 문장은 비슷해 보이지만 의미가 반대입니다.

• 승인을 받은 사용자는 파일을 다운로드할 수 있습니다.
• 승인을 받지 않은 사용자는 파일을 다운로드할 수 없습니다.

사용자가 다음과 같이 질문할 수 있습니다.

승인 없이 다운로드할 수 없는 파일은 무엇인가요?

 

또는 다음처럼 물을 수 있습니다.

다운로드 승인이 필요하지 않은 경우가 있나요?

 

이런 질문에서는 승인, 다운로드, 파일처럼 주요 단어가 모두 포함되어 있어 관련 문서를 찾는 것 자체는 어렵지 않을 수 있습니다.

문제는 LLM이 다음 요소를 정확하게 해석해야 한다는 점입니다.

• 가능과 불가능
• 포함과 제외
• 필수와 선택
• 이상과 초과
• 이전과 이후
• 않은 경우와 한 경우

검색 점수는 높지만 최종 답변의 의미가 반대로 바뀌는 오류가 발생할 수 있습니다. 따라서 부정 표현 질문은 일반 조건 질문과 분리하여 실패율을 확인하는 것도 좋습니다.

비교 질문

비교 질문은 둘 이상의 대상을 같은 기준으로 확인해야 합니다.

예를 들면 다음과 같습니다.

• Basic과 Pro 요금제의 차이는 무엇인가요?
• A사와 B사 중 매출 증가율이 높은 회사는 어디인가요?
• 2024년과 2025년 휴가 규정에서 달라진 점은 무엇인가요?
• 국내 출장과 해외 출장의 지원 기준을 비교해주세요.

비교 질문에 답하려면 모든 대상에 대한 근거가 필요합니다.

A와 B를 비교하려면 A에 대한 좋은 문서 하나가 아니라, A와 B에 대한 충분한 문서가 모두 필요합니다.

사용자가 다음과 같이 질문했다고 가정해보겠습니다.

Basic과 Pro 요금제의 저장 공간과 이용료를 비교해주세요.

필요한 정보는 네 가지입니다.

• Basic 요금제의 저장 공간
• Basic 요금제의 이용료
• Pro 요금제의 저장 공간
• Pro 요금제의 이용료

검색 결과가 Basic 요금제 문서로만 채워지면 Precision은 높게 나올 수 있습니다.

모든 문서가 질문과 관련 있기 때문입니다.

하지만 Pro 요금제의 정보가 없으므로 비교 답변은 만들 수 없습니다.

이 경우에는 일반적인 Precision@K보다 대상별 근거가 모두 검색되었는지를 확인하는 것이 중요합니다.

• Basic 관련 근거 검색 여부
• Pro 관련 근거 검색 여부
• 비교 기준별 값 검색 여부
• 같은 기간과 같은 단위인지 여부

비교 질문은 여러 개의 작은 질문으로 나눌 수 있습니다.

• Basic 요금제의 저장 공간은 얼마인가
• Basic 요금제의 이용료는 얼마인가
• Pro 요금제의 저장 공간은 얼마인가
• Pro 요금제의 이용료는 얼마인가

각 질문으로 문서를 검색한 뒤 결과를 합치고 Reranker로 다시 정렬하는 방법을 사용할 수 있습니다.

질문 분해를 적용하더라도 평가할 때는 다음을 따로 확인해야 합니다.

• 원래 질문을 올바르게 나눴는가
• 각 하위 질문의 문서를 검색했는가
• 서로 다른 대상의 값을 혼동하지 않았는가
• 같은 기준으로 비교했는가
• 최종 결론이 검색된 값과 일치하는가

여러 문서가 필요한 질문

하나의 질문에 답하기 위해 두 개 이상의 문서를 연결해야 하는 질문을 Multi-hop 질문이라고 부르기도 합니다.

다음 질문을 살펴보겠습니다.

A사가 인수한 B사의 대표가 이전에 근무했던 회사는 어디인가요?

이 질문은 하나의 검색으로 바로 답하기 어렵습니다. 먼저 다음 정보를 찾아야 합니다.

• A사가 인수한 회사가 B사라는 사실
• B사의 대표가 누구인지
• 그 대표가 이전에 근무한 회사가 어디인지

검색 과정은 다음과 같이 이어질 수 있습니다.

• A사의 인수 관련 문서 검색
• 인수한 회사명 확인
• 해당 회사의 대표 관련 문서 검색
• 대표 이름 확인
• 대표의 경력 문서 검색
• 이전 근무 회사 확인

첫 번째 단계에서 회사를 잘못 찾으면 이후 검색도 모두 잘못된 방향으로 진행됩니다. 중간 단계에서 핵심 이름이 검색어에서 빠져도 다음 문서를 찾지 못합니다.

여러 단계가 필요한 질문은 마지막 답변만 평가하면 어느 단계에서 문제가 발생했는지 알기 어렵습니다.

여러 문서가 필요한 질문에서는 각 단계의 로그를 남기는 것이 중요합니다.

{
  "question": "A사가 인수한 B사의 대표가 이전에 근무했던 회사는 어디인가요?",
  "sub_questions": [
    {
      "question": "A사가 인수한 회사는 어디인가요?",
      "answer": "B사",
      "retrieved_document_ids": ["doc-12", "doc-45"]
    },
    {
      "question": "B사의 대표는 누구인가요?",
      "answer": "김바미",
      "retrieved_document_ids": ["doc-31"]
    },
    {
      "question": "김바미 대표가 이전에 근무한 회사는 어디인가요?",
      "answer": "C사",
      "retrieved_document_ids": ["doc-88", "doc-91"]
    }
  ],
  "final_answer": "C사입니다."
}

이 로그를 보면 다음을 구분할 수 있습니다.

• 질문 분해 실패
• 첫 번째 근거 검색 실패
• 중간 답 추출 실패
• 다음 검색어 생성 실패
• 최종 정보 결합 실패

평가 항목도 단계별로 나눌 수 있습니다.

• 하위 질문 생성 정확도
• 단계별 Recall@K
• 전체 근거 Coverage
• 중간 답변 정확도
• 최종 답변 정확도
• Faithfulness

여러 단계 중 하나라도 빠지면 최종 답변이 틀릴 수 있으므로, 단순 사실 질문보다 실패할 가능성이 높습니다.

여러 내용을 빠짐없이 설명해야 하는 질문

모든 질문에 하나의 짧은 정답이 있는 것은 아닙니다. 다음 질문을 살펴보겠습니다.

회사의 재택근무 규정을 설명해주세요.

 

이 질문에는 여러 내용이 포함될 수 있습니다.

• 신청 대상
• 신청 방법
• 승인 권한
• 가능한 근무 일수
• 출퇴근 기록 방법
• 보안 준수 사항
• 예외 대상
• 규정 위반 시 처리

RAG가 신청 방법만 정확히 설명했다고 해도 전체 질문에 충분히 답했다고 보기는 어렵습니다.

이런 질문에서는 Exact Match처럼 하나의 정답 문장과 완전히 일치하는지 확인하는 방식이 적합하지 않을 수 있습니다.

대신 질문을 여러 하위 항목으로 나눠서 답변이 얼마나 다뤘는지 확인할 수 있습니다.

• 핵심 항목을 몇 개 포함했는가
• 중요한 항목을 빠뜨리지 않았는가
• 관련 없는 내용을 추가하지 않았는가
• 각 설명이 검색된 근거와 일치하는가

예를 들어 반드시 포함해야 할 핵심 항목을 네 개로 정할 수 있습니다.

• 신청 대상
• 신청 방법
• 승인 기준
• 가능한 근무 일수

답변이 네 항목 중 세 개를 다뤘다면 핵심 항목 Coverage는 0.75가 됩니다. 여기에 부가적으로 설명하면 좋은 내용을 따로 표시할 수도 있습니다.

긴 설명형 질문은 답변이 맞는지만 볼 것이 아니라, 중요한 내용을 얼마나 빠짐없이 다뤘는지도 평가해야 합니다.

모호한 질문

다음 질문을 살펴보겠습니다.

환불 기간은 며칠인가요?

 

간단한 질문처럼 보이지만 필요한 정보가 빠져 있습니다.

• 어떤 상품인지
• 결제 수단이 무엇인지
• 환불 신청 가능 기간인지
• 신청 후 처리 기간인지
• 구매 취소인지 반품인지
• 국내 주문인지 해외 주문인지

문서에 다음 규정이 모두 있을 수 있습니다.

• 디지털 상품: 결제 후 7일 이내
• 배송 상품: 수령 후 14일 이내
• 환불 처리: 승인 후 영업일 기준 3~5일
• 해외 결제 취소: 최대 15일

RAG가 이 중 하나를 골라 단정적으로 답하면 문서에는 근거가 있더라도 사용자의 의도와 맞지 않을 수 있습니다.

이 경우 좋은 답변은 하나의 숫자를 바로 말하는 것이 아닐 수 있습니다.

다음처럼 추가 정보를 요청하는 편이 적절할 수 있습니다.

환불을 신청할 수 있는 기간을 말씀하시는 건가요, 아니면 신청 후 실제 환불까지 걸리는 기간을 말씀하시는 건가요?

 

또는 가능한 경우를 나눠서 설명할 수도 있습니다.

상품 종류에 따라 다릅니다. 디지털 상품은 결제 후 7일 이내이며, 배송 상품은 수령 후 14일 이내에 신청할 수 있습니다.

 

모호한 질문을 평가할 때 정답 문장 하나만 정해두면 문제가 생길 수 있습니다.

질문에 따라 다음 행동 중 무엇이 적절한지 표시하는 것이 좋습니다.

• 바로 답변 가능
• 추가 질문 필요
• 여러 해석을 나눠서 안내
• 사용자의 이전 대화를 참고
• 답변 불가

평가 항목은 다음과 같이 구성할 수 있습니다.

• 모호성을 인식했는가
• 잘못된 조건을 임의로 가정하지 않았는가
• 필요한 추가 질문을 했는가
• 가능한 해석을 적절히 제시했는가
• 확인되지 않은 답을 단정하지 않았는가

모호한 질문에 되묻는 것은 답변 실패가 아니라, 잘못된 답을 막기 위한 올바른 동작일 수 있습니다.

이전 대화가 필요한 질문

대화형 RAG에서는 현재 질문만 보고는 이해하기 어려운 경우가 많습니다.

예를 들어 앞선 대화가 다음과 같다고 해보겠습니다.

사용자:

Pro 요금제의 연간 결제 금액을 알려주세요.

RAG:

Pro 요금제의 연간 결제 금액은 120만 원입니다.

사용자:

그건 언제부터 적용됐어?

 

두 번째 질문만 검색에 사용하면 문제가 생깁니다. 그건이 무엇을 가리키는지 알 수 없기 때문입니다. 검색 전에 질문을 다음과 같이 바꿔야 합니다.

Pro 요금제의 연간 결제 금액 120만 원은 언제부터 적용되었나요?

 

이 과정을 Query Rewriting이라고 부를 수 있습니다. 대화형 질문에서는 다음 오류가 발생할 수 있습니다.

• 대명사가 가리키는 대상을 잘못 해석함
• 이전 대화의 오래된 주제를 현재 질문에 연결함
• 사용자가 주제를 바꿨는데 이전 문맥을 계속 사용함
• 필요한 조건을 다시 작성하면서 일부를 누락함
• 재작성된 검색어에 잘못된 정보가 추가됨

평가할 때는 최종 답변뿐 아니라 변환된 검색어도 저장해야 합니다.

• 원본 질문
• 이전 대화
• 변환된 독립 질문
• 검색 결과
• 실제 전달된 Context
• 최종 답변

대화형 질문에서는 같은 문장이라도 이전 대화에 따라 정답이 달라질 수 있습니다. 따라서 평가 데이터에도 필요한 대화 기록을 함께 저장해야 합니다.

답이 없는 질문

RAG가 가장 위험하게 실패하는 경우 중 하나는 문서에 답이 없는데도 답변을 만들어내는 경우입니다.

 

다음 질문을 살펴보겠습니다.

회사에서 반려동물 의료비를 지원하나요?

 

지식 베이스에 관련 규정이 없다고 가정해보겠습니다. 이 경우 RAG는 다음처럼 답해야 합니다.

제공된 문서에서는 반려동물 의료비 지원 여부를 확인할 수 없습니다.

 

하지만 검색 결과에 의료비, 지원, 복지와 관련된 문서가 나오면 LLM이 내용을 조합해 다음과 같이 답할 수 있습니다.

회사는 임직원의 반려동물 의료비를 연간 30만 원까지 지원합니다.

 

문서에 없는 내용을 자연스럽게 만들어낸 것입니다. 답이 없는 질문도 여러 형태로 나눌 수 있습니다.

• 관련 문서가 전혀 없음
• 비슷한 주제의 문서는 있지만 정답은 없음
• 문서에 답의 일부만 있음
• 질문이 지식 베이스의 범위를 벗어남
• 문서가 오래되어 현재 답을 확인할 수 없음
• 서로 충돌하는 문서가 있어 하나의 답을 정할 수 없음
• 질문 자체에 필요한 조건이 부족함

이런 질문을 평가 데이터에 포함하지 않으면 RAG가 모르는 것을 모른다고 말할 수 있는지 확인할 수 없습니다.

답이 없는 질문에서는 다음을 평가해야 합니다.

• 답이 없다는 것을 올바르게 판단했는가
• 관련 없는 문서를 근거로 답을 만들지 않았는가
• 확인할 수 없는 내용을 단정하지 않았는가
• 필요한 경우 추가 정보를 요청했는가
• 답변할 수 없는 이유를 적절하게 설명했는가

단순한 답변 정확도만 사용하면 모든 질문에 확인할 수 없습니다라고 답하는 시스템이 높은 점수를 받을 수도 있습니다.

그래서 답이 있는 질문과 없는 질문을 함께 평가해야 합니다.

• 답이 있는 질문에는 정확하게 답했는가
• 답이 없는 질문에는 적절하게 답변을 보류했는가

좋은 RAG는 모든 질문에 답하는 시스템이 아니라, 답할 수 있는 질문과 답할 수 없는 질문을 구분하는 시스템입니다.

서로 충돌하는 문서가 있는 질문

문서에는 답이 있지만 여러 문서의 내용이 다를 수도 있습니다.

예를 들어 다음 두 문서가 있다고 가정해보겠습니다.

• 2025년 1월 규정: 재택근무 주 2회 가능
• 2026년 3월 개정 규정: 재택근무 주 3회 가능

사용자가 다음과 같이 질문했습니다.

재택근무는 일주일에 몇 번까지 가능한가요?

 

RAG가 오래된 문서를 사용하면 주 2회라고 답할 수 있습니다. 두 문서를 모두 검색하면 서로 다른 숫자 때문에 혼란이 생길 수도 있습니다. 이런 질문에서는 다음 정보가 중요합니다.

• 문서의 시행일
• 개정 여부
• 적용 대상
• 현재 유효한 문서인지
• 이전 문서를 대체하는지
• 특정 조직에만 적용되는지

충돌하는 문서가 있다면 단순히 검색 점수가 높은 문서를 사용하는 것으로는 부족합니다.

메타데이터를 활용해 최신 문서를 우선하거나, 답변에서 충돌 사실을 알려야 합니다.

현재 적용되는 2026년 3월 개정 규정에 따르면 주 3회까지 가능합니다. 이전 규정에는 주 2회로 기재되어 있습니다.

 

평가 데이터에도 어떤 문서 버전을 기준으로 해야 하는지 표시해야 합니다.

질문 유형별로 같은 지표를 사용할 필요는 없습니다

질문 유형마다 성공의 의미가 다릅니다.

 

질문	유형주로 확인할 항목
단순 사실	정답 문서 검색, 첫 정답 순위, 답변 정확도
날짜·숫자	값·기간·단위 검색, 계산 정확도
조건·예외	핵심 조건 Coverage, 예외 포함 여부
부정 표현	긍정·부정 방향 해석 정확도
비교	비교 대상별 근거 Coverage, 최종 비교 정확도
여러 문서	단계별 Recall, 전체 근거 Coverage
긴 설명	핵심 하위 항목 Coverage, Faithfulness
모호한 질문	모호성 인식, 적절한 추가 질문
대화형 질문	독립 질문 재작성 정확도, 대화 문맥 활용
답이 없는 질문	답변 보류 정확도, 잘못된 단정 비율
충돌 문서	최신 문서 선택, 충돌 안내 여부

 

모든 질문에 Exact Match 하나만 적용하면 다음과 같은 올바른 행동을 오답으로 처리할 수 있습니다.

• 모호한 질문에 추가 정보를 요청함
• 답이 없는 질문에 답변을 보류함
• 충돌하는 문서가 있어 두 가능성을 함께 설명함
• 긴 설명형 질문에서 표현은 다르지만 핵심 내용을 모두 포함함

반대로 Faithfulness만 확인하면 문서에 충실하지만 사용자의 질문에는 충분히 답하지 못한 답변을 성공으로 판단할 수 있습니다.

질문 유형에 맞는 지표를 조합해야 합니다.

평가 데이터에 질문 유형을 저장해보겠습니다

평가 질문마다 다음과 같은 정보를 저장할 수 있습니다.

{
  "question_id": "eval-0042",
  "question": "A사와 B사 중 2025년 매출 증가율이 높은 회사는 어디인가요?",
  "primary_type": "comparison",
  "secondary_tags": [
    "numeric",
    "multi_document",
    "calculation"
  ],
  "answerability": "answerable",
  "required_document_count": 4,
  "required_facts": [
    "A사 2024년 매출",
    "A사 2025년 매출",
    "B사 2024년 매출",
    "B사 2025년 매출"
  ],
  "reference_answer": "B사",
  "evaluation_metrics": [
    "evidence_recall",
    "entity_coverage",
    "calculation_correctness",
    "answer_correctness",
    "faithfulness"
  ]
}

여기서 primary_type은 질문의 대표적인 특징입니다. secondary_tags에는 추가로 평가해야 할 난이도 요소를 저장합니다.

질문의 답변 가능 여부도 별도로 관리합니다.

• answerable: 문서에 충분한 답이 있음
• partially_answerable: 일부만 답할 수 있음
• unanswerable: 문서에서 확인할 수 없음
• ambiguous: 조건이 부족하거나 여러 의미로 해석됨
• conflicting: 문서끼리 충돌함

이 구조가 반드시 정답은 아닙니다. 프로젝트에서 실제로 자주 발생하는 질문을 기준으로 필요한 분류만 선택하면 됩니다.

질문 유형을 자동으로 분류할 수도 있습니다

질문이 많아지면 사람이 모든 질문에 유형을 붙이기 어려울 수 있습니다. 

LLM을 사용해 초안 분류를 만들 수 있습니다. 예를 들어 다음 항목을 판단하도록 요청할 수 있습니다.

• 하나의 문서로 답할 수 있는가
• 여러 문서가 필요한가
• 계산이 필요한가
• 비교가 필요한가
• 조건이나 예외가 포함되어 있는가
• 질문이 모호한가
• 답을 찾을 수 없는 질문인가
• 이전 대화가 필요한가

자동 분류 결과는 다음과 같이 저장할 수 있습니다.

{
  "primary_type": "comparison",
  "secondary_tags": [
    "numeric",
    "multi_document"
  ],
  "reason": "두 회사의 수치를 각각 검색한 뒤 비교해야 합니다.",
  "confidence": 0.91
}

다만 자동 분류를 그대로 정답으로 사용하면 안 됩니다.

• 비교 질문을 단순 사실 질문으로 분류할 수 있음
• 실제 문서 구조를 모르고 필요한 문서 수를 추정할 수 있음
• 답이 없는 질문을 답이 있는 것으로 판단할 수 있음
• 서비스 도메인의 중요한 조건을 놓칠 수 있음

처음에는 사람이 대표 질문을 검수하고, 분류 기준이 안정된 뒤 자동화를 확대하는 편이 좋습니다.

질문 유형별 점수를 계산해보겠습니다

평가 결과에 질문 유형이 저장되어 있다면 유형별 평균을 계산할 수 있습니다.

from collections import defaultdict
from statistics import mean


evaluation_results = [
    {
        "question_id": "q-001",
        "primary_type": "fact",
        "answer_correctness": 1.0,
        "context_recall": 1.0,
    },
    {
        "question_id": "q-002",
        "primary_type": "fact",
        "answer_correctness": 0.0,
        "context_recall": 1.0,
    },
    {
        "question_id": "q-003",
        "primary_type": "comparison",
        "answer_correctness": 0.0,
        "context_recall": 0.5,
    },
    {
        "question_id": "q-004",
        "primary_type": "comparison",
        "answer_correctness": 1.0,
        "context_recall": 1.0,
    },
]


def group_metrics_by_type(
    results: list[dict],
) -> dict[str, dict[str, float]]:
    grouped: dict[str, list[dict]] = defaultdict(list)

    for result in results:
        grouped[result["primary_type"]].append(result)

    summary: dict[str, dict[str, float]] = {}

    for question_type, items in grouped.items():
        summary[question_type] = {
            "count": len(items),
            "answer_correctness": mean(
                item["answer_correctness"]
                for item in items
            ),
            "context_recall": mean(
                item["context_recall"]
                for item in items
            ),
        }

    return summary

결과를 출력합니다.

summary = group_metrics_by_type(evaluation_results)

for question_type, metrics in summary.items():
    print(question_type, metrics)

대표 유형뿐 아니라 추가 태그별 점수도 계산할 수 있습니다.

 

예를 들어 numeric 태그가 있는 모든 질문과 multi_document 태그가 있는 모든 질문을 각각 모아서 결과를 확인할 수 있습니다.

이렇게 하면 비교 질문의 성능이 낮은 이유가 비교 자체 때문인지, 숫자 계산이나 여러 문서 검색 때문인지 더 자세히 살펴볼 수 있습니다.

가상의 평가 결과를 분석해보겠습니다

다음 표는 설명을 위해 만든 가상의 결과입니다. 

 

질문 유형	Context Recall	답변 정확도	Faithfulness
단순 사실	0.94	0.91	0.96
날짜·숫자	0.88	0.74	0.90
조건·예외	0.72	0.67	0.89
비교	0.69	0.58	0.86
여러 문서	0.55	0.43	0.84
긴 설명	0.76	0.64	0.92

 

이 결과에서 몇 가지 특징을 확인할 수 있습니다.

날짜·숫자 질문은 검색보다 답변 단계에서 많이 틀렸습니다

Context Recall은 0.88로 비교적 높지만 답변 정확도는 0.74입니다.

필요한 문서를 검색했지만 다음 과정에서 오류가 발생했을 수 있습니다.

• 숫자 추출
• 단위 해석
• 기간 구분
• 계산
• 반올림

이 경우 검색 모델을 교체하기보다 계산 과정을 분리하거나 구조화된 데이터를 활용하는 방안을 먼저 검토할 수 있습니다.

조건·예외 질문은 필요한 근거가 충분히 검색되지 않았습니다

Context Recall이 0.72입니다. 조건과 예외가 여러 청크로 나뉘어 일부 근거가 빠졌을 수 있습니다.

다음 부분을 살펴볼 수 있습니다.

• 청크 크기
• Parent-Child 검색
• 제목과 상위 조항 포함
• 검색 결과 수
• 질문 분해
• 인접 청크 함께 가져오기

여러 문서가 필요한 질문이 가장 약합니다

Context Recall과 답변 정확도가 모두 낮습니다. 단일 검색으로는 필요한 근거를 모두 모으지 못했을 가능성이 큽니다.

질문 분해나 반복 검색을 적용할 수 있습니다.

Faithfulness는 높지만 답변 정확도는 낮습니다

여러 문서 질문의 Faithfulness는 0.84입니다.

 

LLM은 검색된 문서에는 비교적 충실하게 답했지만, 검색된 문서가 불완전했기 때문에 최종 답변이 틀렸을 수 있습니다.

Faithfulness가 높다는 것은 검색된 근거를 잘 사용했다는 뜻이지, 필요한 근거를 모두 검색했다는 뜻은 아닙니다.

 

질문 유형별로 Context Recall과 Faithfulness를 함께 보면 검색과 생성 중 어디를 먼저 개선해야 하는지 판단하기 쉬워집니다.

질문 유형별 실패 사례를 직접 확인해야 합니다

유형별 점수가 낮다는 사실만으로는 구체적인 원인을 알 수 없습니다. 각 유형에서 실패한 질문을 모아 직접 확인해야 합니다.

비교 질문에서는 다음을 살펴봅니다.

• 한쪽 대상의 문서만 검색되었는가
• 서로 다른 기간의 값을 비교했는가
• 단위가 다른 값을 비교했는가
• 질문을 하위 질문으로 잘못 나눴는가

조건 질문에서는 다음을 확인합니다.

• 적용 대상이 빠졌는가
• 예외 조항이 검색되지 않았는가
• 조건과 결론이 다른 청크에 있었는가
• LLM이 일부 조건을 무시했는가

답이 없는 질문에서는 다음을 확인합니다.

• 비슷한 문서를 근거로 답을 만들어냈는가
• 답변할 수 없다는 지시가 부족했는가
• 검색 점수가 낮은 경우를 처리하지 않았는가
• 지식 베이스의 범위를 판단하지 못했는가

분석 결과를 표로 정리할 수 있습니다.

 

실패	원인질문 수
필요한 문서 일부 누락	18개
잘못된 문서 버전 사용	9개
조건 또는 예외 누락	13개
숫자 계산 오류	7개
모호한 질문을 임의로 해석	6개
답이 없지만 답변 생성	8개

 

이 표를 보면 다음 실험에서 무엇을 바꿔야 할지 정할 수 있습니다.

실제 사용자 질문의 비율도 고려해야 합니다

모든 질문 유형을 같은 개수로 평가하는 방법은 각 유형의 성능을 비교하기에는 좋습니다.

하지만 실제 서비스의 품질을 예상하려면 사용자 질문의 분포도 고려해야 합니다.

실제 질문이 다음과 같이 구성될 수 있습니다.

• 단순 사실 질문: 50%
• 조건·예외 질문: 20%
• 비교 질문: 10%
• 여러 문서 질문: 5%
• 모호한 질문: 10%
• 답이 없는 질문: 5%

평가 데이터가 단순 사실 질문 90%, 나머지 질문 10%로 구성되어 있다면 전체 점수가 높게 나올 가능성이 큽니다.

하지만 중요한 질문 유형의 성능을 제대로 확인하지 못합니다.

평가 데이터는 두 가지 관점으로 나누어 볼 수 있습니다.

균형 잡힌 평가 세트

각 질문 유형을 비슷한 수로 구성합니다.

• 유형별 성능 비교에 유리함
• 약한 질문 유형을 발견하기 쉬움
• 설정 변경이 특정 유형에 미친 영향을 확인하기 쉬움

실제 사용 비율을 반영한 평가 세트

운영 로그의 질문 분포를 반영합니다.

• 실제 서비스의 전체 품질을 예상하기 쉬움
• 사용자들이 자주 겪는 문제를 우선적으로 확인할 수 있음
• 전체 성공률과 비용을 현실적으로 계산할 수 있음

두 평가 결과를 모두 관리하는 편이 좋습니다.

균형 잡힌 데이터는 RAG의 약점을 찾기 위해 필요하고, 실제 사용 비율을 반영한 데이터는 서비스 품질을 예상하기 위해 필요합니다.

정확도뿐 아니라 위험도도 고려해야 합니다

질문 수가 적더라도 틀렸을 때 영향이 큰 유형이 있습니다. 예를 들어 다음 질문은 전체 사용자 질문에서 차지하는 비중이 낮을 수 있습니다.

• 계약 해지 조건
• 개인정보 삭제 기준
• 법적 의무
• 의료 관련 안내
• 결제와 환불 기준
• 사내 보안 정책

이런 질문을 틀리면 단순한 사용법 질문보다 피해가 클 수 있습니다. 따라서 질문 유형별 중요도를 표시할 수 있습니다.

• 낮음: 일반적인 기능 안내
• 보통: 업무 절차와 사용법
• 높음: 결제, 권한과 운영 정책
• 매우 높음: 법률, 의료, 보안과 개인정보

평가 결과를 볼 때 질문 수뿐 아니라 중요도에 따른 가중치를 적용할 수도 있습니다.

다만 가중 점수만 표시하면 실제 질문 수와 원래 점수가 가려질 수 있으므로 다음 값을 함께 보여주는 것이 좋습니다.

• 질문 수
• 원래 정확도
• 중요도
• 가중 점수
• 주요 실패 사례

반드시 남겨야 할 로그

질문 유형별 성능을 분석하려면 최종 답변만 저장해서는 부족합니다. 다음 항목을 함께 남기는 것이 좋습니다.

• 원본 질문
• 질문 유형과 추가 태그
• 이전 대화
• 변환된 검색어
• 생성된 하위 질문
• Retriever의 검색 결과와 점수
• Reranker 적용 후 순위
• LLM에 실제로 전달된 Context
• 최종 답변
• 사용된 문서의 버전
• 정답과 필요한 근거
• 검색 지표
• 답변 지표
• 응답 시간과 비용
• 사용자 피드백

여러 문서 질문에서는 각 검색 단계의 결과도 필요합니다. 모호한 질문에서는 RAG가 추가 질문을 했는지 저장해야 합니다.

답이 없는 질문에서는 답변을 보류했는지와 어떤 문서를 근거로 판단했는지 확인해야 합니다.

질문 유형 정보와 중간 단계의 로그가 함께 있어야 “비교 질문에 약하다”는 결과를 실제 개선 작업으로 연결할 수 있습니다.

자주 하는 실수

모든 질문에 하나의 유형만 붙입니다

질문은 여러 특징을 동시에 가질 수 있습니다. 대표 유형과 추가 태그를 함께 관리하는 편이 좋습니다.

질문의 문장 길이만으로 난이도를 판단합니다

짧은 질문도 여러 문서와 계산이 필요할 수 있습니다. 반대로 긴 질문이 하나의 문서에서 바로 답할 수 있는 경우도 있습니다.

질문의 길이보다 필요한 근거와 추론 단계를 확인해야 합니다.

쉬운 합성 질문만 사용합니다

문서의 문장을 그대로 질문으로 바꾸면 검색하기 쉬운 질문만 만들어질 수 있습니다.

실제 사용자는 다음과 같이 질문할 수 있습니다.

• 문서와 다른 표현 사용
• 필요한 조건 생략
• 여러 내용을 한 번에 질문
• 이전 대화를 이어서 질문
• 잘못된 가정을 포함
• 답이 없는 내용을 질문

실제 사용자 질문과 실패 사례를 평가 데이터에 계속 추가해야 합니다.

모호한 질문에 되묻는 것을 실패로 처리합니다

정보가 부족한 질문에서는 바로 답하지 않는 것이 더 안전할 수 있습니다.

평가 데이터에 기대 행동을 함께 표시해야 합니다.

모든 질문에 같은 지표를 적용합니다

단순 사실 질문과 긴 설명형 질문, 답이 없는 질문은 성공 기준이 다릅니다.

질문 유형에 맞는 지표를 사용해야 합니다.

질문 수가 너무 적은데 작은 차이를 믿습니다

비교 질문이 다섯 개뿐인데 정확도가 40%에서 60%로 올랐다면 실제로는 한 문제 차이입니다.

점수와 함께 질문 수와 개별 결과를 확인해야 합니다.

전체 평균만 보고 설정을 선택합니다

새로운 설정이 단순 사실 질문은 조금 개선했지만 중요한 조건 질문의 성능을 크게 떨어뜨릴 수 있습니다.

유형별 결과를 반드시 함께 확인해야 합니다.

중간 정리

질문 유형별 특징을 정리하면 다음과 같습니다.

 

질문 유형	어려운 이유	주요 평가 항목
단순 사실	유사 문서와 버전 혼동	Hit@K, MRR, 정확도
날짜·숫자	단위·기간·계산 오류	값 Coverage, 계산 정확도
조건·예외	근거가 여러 청크에 나뉨	조건 Coverage, Context Recall
부정 표현	의미의 방향을 반대로 해석	의미 일치 여부
비교	모든 대상의 근거가 필요함	대상별 Coverage, 비교 정확도
여러 문서	단계 중 하나만 실패해도 오답	단계별 Recall, 전체 근거 Coverage
긴 설명	여러 항목을 빠짐없이 다뤄야 함	하위 항목 Coverage, Faithfulness
모호한 질문	하나의 정답을 정하기 어려움	모호성 인식, 추가 질문 적절성
대화형 질문	이전 대화 없이 이해하기 어려움	Query Rewrite 정확도
답이 없는 질문	비슷한 문서로 답을 만들 수 있음	답변 보류 정확도
충돌 문서	서로 다른 버전의 답이 존재함	최신성, 충돌 안내 여부

 

질문 유형별 평가에서 기억해야 할 핵심은 다음과 같습니다.

• 전체 평균과 유형별 점수를 함께 확인합니다.
• 하나의 질문에 여러 태그를 붙일 수 있습니다.
• 질문 유형마다 성공 기준을 다르게 정합니다.
• 검색과 생성 단계의 지표를 함께 봅니다.
• 실제 사용자 질문과 실패 사례를 계속 추가합니다.
• 자주 묻는 질문뿐 아니라 위험도가 높은 질문도 포함합니다.
• 최종 답변과 함께 중간 검색 로그를 저장합니다.

마치며

RAG는 모든 질문에 똑같이 강하지 않습니다. 하나의 문서에서 하나의 값을 찾는 단순한 질문은 비교적 잘 처리하지만, 여러 조건을 확인하거나 여러 문서의 내용을 함께 연결해야 하는 질문에서는 쉽게 흔들릴 수 있습니다.

 

예를 들어 비교 질문에서는 한쪽 대상의 문서만 검색해 불완전한 결론을 내릴 수 있고 숫자 질문에서는 필요한 문서를 제대로 찾고도 단위나 계산을 잘못 처리할 수 있습니다. 조건이 포함된 질문에서는 본문만 확인한 채 예외 조항을 놓치기도 하며 질문의 의미가 모호한 경우에는 부족한 정보를 다시 묻지 않고 사용자의 의도를 임의로 가정할 수도 있습니다. 심지어 문서에 답이 없는 질문에서도 비슷한 내용을 근거로 그럴듯한 답을 만들어내는 경우가 있습니다.

 

이처럼 질문의 형태에 따라 실패하는 원인과 지점이 서로 다르기 때문에 모든 결과를 하나의 평균 점수로 합쳐버리면 RAG가 실제로 어떤 질문에 약한지 알아내기 어렵습니다.

RAG를 제대로 평가하려면 “몇 점인가?”뿐 아니라 “어떤 질문에서 틀렸는가?”를 함께 물어야 합니다.

 

질문마다 대표 유형과 추가 태그를 붙인 뒤, 유형별로 검색과 답변 성능을 나눠서 확인해야 합니다. 다만 모든 질문을 같은 기준으로 평가할 수는 없습니다. 단순 사실 질문에서는 정답 문서가 얼마나 높은 순위에 검색되었는지와 최종 답변이 정확한지가 중요하지만 비교 질문이나 여러 문서를 함께 봐야 하는 질문에서는 필요한 근거가 빠짐없이 모였는지를 먼저 확인해야 합니다.

 

질문의 의미가 모호하다면 곧바로 하나의 답을 단정하기보다 필요한 정보를 다시 물어야 하며 문서에서 답을 확인할 수 없는 질문이라면 그럴듯한 내용을 만들어내지 않고 답변을 보류할 수 있어야 합니다. 이처럼 질문 유형마다 기대하는 동작과 성공 기준이 다르기 때문에 유형별 평가 결과는 단순히 점수를 나눠보는 통계로 끝나지 않습니다.

• 비교 질문의 Coverage가 낮다면 질문 분해를 실험할 수 있습니다.
• 조건 질문에서 예외가 빠진다면 청킹 방식을 점검할 수 있습니다.
• 숫자 질문에서 계산 오류가 많다면 계산 도구를 분리할 수 있습니다.
• 답이 없는 질문에서 환각이 발생한다면 답변 보류 기준을 개선할 수 있습니다.
• 대화형 질문에서 검색이 실패한다면 Query Rewriting을 점검할 수 있습니다.

이렇게 유형별 실패 원인을 확인해야 다음 실험에서 무엇을 바꿔야 할지 정할 수 있습니다. 좋은 RAG 평가 데이터는 쉬운 질문만 많이 모아놓은 데이터가 아닙니다.

실제 사용자가 물어볼 수 있는 여러 형태의 질문과, RAG가 실패하기 쉬운 질문을 의도적으로 포함한 데이터입니다.

 

RAG가 어떤 질문에 약한지 알아야 그 약점을 개선할 수 있습니다.

참고 자료

• RAGChecker: A Fine-Grained Framework for Diagnosing Retrieval-Augmented Generation
• MultiHop-RAG: Benchmarking Retrieval-Augmented Generation for Multi-Hop Queries
• Question Decomposition for Retrieval-Augmented Generation
• Do RAG Systems Cover What Matters? Evaluating and Optimizing Responses with Sub-Question Coverage
• Unanswerability Evaluation for Retrieval Augmented Generation
• AmbigQA: Answering Ambiguous Open-domain Questions
• mt RAG: A Multi-Turn Conversational Benchmark for Evaluating Retrieval-Augmented Generation Systems
• MTRAG-UN: A Benchmark for Open Challenges in Multi-Turn RAG Conversations
• TAT-QA: A Question Answering Benchmark on a Hybrid of Tabular and Textual Content in Finance
• GRADE: Generating Multi-hop QA and Fine-grained Difficulty Matrix for RAG Evaluation