RAG 검색 품질 개선을 위한 Recall@k 평가 적용

왜 검색 품질 평가가 필요했나

서비스 향상 및 구조 개선 시 검색 품질이 하락되는 경우를 방지하기 위해 검증 로직이 필요했습니다.

하지만 검색로직에서 점수가 높은 상위문서를 기반으로 답변을 제공함에 있어서 제일 높은 점수의 문서가 정답이라는 보장이 없었습니다. 이를 해결하기 위해 상위문서 3개를 검사하는 방식을 선택했습니다.

기존 RAG 검색 방식의 문제점

기존 RAG 검색은 키워드 기반 BM25를 사용하였습니다. 하지만 정확한 키워드를 입력하는 사례가 적었고 이로인해 검색 품질 저하 현상이 발생했습니다.

이를 해결하기 위해 의미기반 검색도 추가하여 비슷한 맥락이 있어도 문서가 검색될 수 있도록 개선하는 필요가 있었습니다.

LLM 답변 품질과 검색 품질의 관계

LLM은 자연스러운 문장 생성에만 사용하고 있기에 답변 품질은 검색 품질에 따라 향상되는 구조를 가지고 있습니다. 이로인해 검색 품질의 향상이 곧 답변 품질의 향상이라는 생각을 하게되었고 검색 품질을 더 높이는 방식을 고안 했습니다. 또한 정확한 문서 기반의 내용을 제공하기 위해 프롬프트 제어를 통해 할루시네이션 현상을 극복하였습니다.

Recall@k를 선택한 이유

문서 검색에서는 항상 가장 높은 점수의 1개 문서만 정답이라고 보기 어렵기 때문에 Recall@k를 평가 지표로 선택했습니다. 상위 3개의 문서에 클라이언트가 원하는 정보가 있다면 검색 로직은 올바르게 구성되어있다고 봤습니다. 5개가 아닌 3개를 택한 이유는 상위 문서가 너무 많을 시 로직이 잘못되었다고 판단될 수 있기에 3개로 줄였습니다.

Recall이란?

Confusion matrix 기준에서 Recall(재현률)은 실제 positive 중 positive로 예측한 비율을 나타냅니다. 즉 찾도록 정한 대상을 정확하게 찾아낸 사례의 비율을 말합니다.

Recall@k 개념

추천 시스템의 성능을 평가하는 지표로 검색된 항목들 중 추천된 상위 K개의 항목에 포함된 비율을 측정합니다. 주로 원하는 항목을 얼마나 잘포착하는지 평가하는데 사용됩니다.

Recall@k는 추천된 항목의 전체 수가 아닌, 모든 항목 중에서 얼마나 많이 추천했는지에 초점을 둡니다.

동숲 프로젝트에서는 질문별로 상위 k개 문서 안에 정답 문서가 포함되면 1, 포함되지 않으면 0으로 기록하고, 전체 질문에 대한 평균을 Recall@k로 계산했습니다.

Recall@1, Recall@3, Recall@5 차이

상위 k개의 항목의 수를 정하는 부분입니다.

Recall@1의 경우 단일 최고 예측이 정확한지 확인합니다. 단, 매우 엄격합니다.

Recall@3의 경우 상위 3개 항목에 대한 보장 범위를 평가합니다.

Recall@5의 경우 상위 5개 항목 내의 커버리지를 평가합니다. 일반적으로 k=1 or 3 보다 높습니다.

현 프로젝트에는 Recall@3를 도입하였습니다. 검색된 문서가 너무 많으면 정확한 정보를 제공하기 어렵다고 판단하였고, 판단 문서를 전처리하면서 중복된 내용을 정리하는 노이즈 제거를 거쳤기 때문입니다.

동숲 프로젝트 평가 환경 구성

평가 대상

평가 대상은 동숲 프로젝트의 RAG 검색 로직이었습니다.

동숲 챗봇은 사용자의 질문이 들어오면 먼저 학교 관련 문서에서 근거가 될 수 있는 문서를 검색하고, 검색된 문서를 기반으로 LLM이 답변을 생성하는 구조로 구성되어 있습니다.

따라서 평가의 핵심은 LLM이 답변을 얼마나 자연스럽게 생성하는지가 아니라, 사용자의 질문에 필요한 근거 문서가 검색 결과 상위에 포함되는지를 확인하는 것이었습니다.

평가 대상 문서는 다음과 같이 구성했습니다.

학교 공지사항
학사 일정
대학 규정집
학과 및 부서 정보
담당자 연락처 정보
기숙사 관련 정보
졸업 요건 및 학점 관련 정보

이 문서들은 크롤링을 통해 수집한 뒤, 제목, 본문, URL, 문서 유형, 부서, 작성일, 연락처 등의 메타데이터로 정리하여 검색 인덱스에 저장했습니다.

Evaluation Dataset 구성

검색 품질을 평가하기 위해 실제 사용자가 질문할 가능성이 높은 문장을 기준으로 Evaluation Dataset을 구성했습니다.

단순히 문서 제목을 그대로 질문으로 사용하는 것이 아니라, 사용자가 챗봇에게 자연스럽게 물어볼 만한 표현을 기준으로 질문을 만들었습니다.

예를 들어 다음과 같은 형태의 질문을 평가 데이터로 구성했습니다.

질문	기대하는 정답 문서
학생성공지원팀 전화번호 알려줘	학생성공지원팀 또는 교직원 연락처 문서
호텔관광학과 담당자 연락처 알려줘	호텔관광학과 담당자 정보 문서
졸업식 언제야?	학사 일정 또는 졸업식 관련 공지 문서
졸업학점 알려줘	졸업 요건 또는 학칙/규정 문서
기숙사 정보 알려줘	기숙사 안내 문서

이처럼 질문과 정답 문서를 미리 매핑해두고, 검색 결과 상위 k개 안에 정답 문서가 포함되는지 확인하는 방식으로 평가했습니다.

질문 데이터 구성 기준

질문 데이터는 다음 기준을 바탕으로 구성했습니다.

실제 사용자가 자주 물어볼 가능성이 높은 질문인가?
정답이 특정 문서에 근거해 판단 가능한가?
질문 표현이 문서 제목과 완전히 일치하지 않아도 검색되어야 하는가?
학사, 부서, 연락처, 규정, 공지 등 다양한 유형을 포함하는가?

이 기준을 둔 이유는 검색 로직이 특정 유형의 질문에만 잘 동작하는지 확인하기 위해서였습니다.

예를 들어 연락처 질문은 부서명과 전화번호가 정확히 검색되어야 하고, 학사 일정 질문은 날짜 정보가 포함된 문서가 검색되어야 합니다. 반면 졸업학점과 같은 질문은 규정집이나 졸업 요건 문서처럼 비교적 긴 문서 안에서 관련 내용을 찾아야 합니다.

즉 질문 유형별로 검색 난이도가 다르기 때문에, 다양한 케이스를 포함해 평가 데이터셋을 구성했습니다.

정답 문서(Ground Truth) 정의

Recall@k를 계산하기 위해서는 각 질문에 대해 정답 문서, 즉 Ground Truth를 미리 정의해야 했습니다.

동숲 프로젝트에서는 정답 문서를 URL 또는 문서 ID 기준으로 정의했습니다.

예를 들어 “학생성공지원팀 전화번호 알려줘”라는 질문의 경우, 검색 결과 상위 3개 안에 학생성공지원팀 연락처가 포함된 문서가 있으면 성공으로 판단했습니다.

정답 문서는 다음 기준으로 정의했습니다.

질문에 대한 답변 근거가 명확히 포함되어 있는 문서
실제 사용자에게 답변할 때 참고해야 하는 공식 문서
동일한 정보가 여러 문서에 존재하는 경우, 대표 문서 또는 최신 문서
URL 또는 문서 제목 기준으로 식별 가능한 문서

이 과정에서 중요한 점은 단순히 LLM이 그럴듯한 답변을 생성했는지가 아니라, 답변의 근거가 되는 문서가 실제로 검색되었는지를 평가했다는 점입니다.

Recall@k 평가 방식 적용

평가 과정

Recall@k 평가는 다음 순서로 진행했습니다.

Evaluation Dataset에 저장된 질문을 하나씩 입력합니다.
현재 적용된 검색 로직으로 Hybrid Search를 수행합니다.
검색 결과에서 상위 k개의 문서를 추출합니다.
상위 k개 문서 안에 미리 정의한 정답 문서가 포함되어 있는지 확인합니다.
포함되어 있으면 1, 포함되어 있지 않으면 0으로 기록합니다.
전체 질문 수 대비 성공한 질문 수의 비율을 계산합니다.

예를 들어 10개의 평가 질문 중 8개의 질문에서 정답 문서가 상위 3개 안에 포함되었다면 Recall@3는 0.8, 즉 80%로 계산할 수 있습니다.

Recall@3 = 정답 문서가 상위 3개 안에 포함된 질문 수 / 전체 평가 질문 수

평가 지표

평가 지표	의미
Recall@1	가장 높은 검색 결과 1개 안에 정답 문서가 포함되는 비율
Recall@3	상위 3개 검색 결과 안에 정답 문서가 포함되는 비율
Recall@5	상위 5개 검색 결과 안에 정답 문서가 포함되는 비율

동숲 프로젝트에서는 최종적으로 Recall@3를 중심으로 평가했습니다.

Recall@1은 가장 이상적인 결과를 확인할 수 있지만, 실제 RAG 구조에서는 상위 1개 문서만으로 답변을 생성하지 않고 여러 개의 문서를 context로 전달하기 때문에 지나치게 엄격하다고 판단했습니다.

반대로 Recall@5는 정답 문서가 포함될 가능성은 높아지지만, 너무 많은 문서를 허용하면 검색 품질이 실제보다 좋게 평가될 수 있습니다. 또한 LLM에 전달되는 context가 길어져 불필요한 정보가 포함될 가능성도 있습니다.

따라서 동숲 프로젝트에서는 상위 3개 문서 안에 정답 문서가 포함되는지를 기준으로 검색 품질을 평가했습니다.

Recall 평가 결과 분석

개선 전 검색 결과

초기 검색 방식은 BM25 기반 키워드 검색에 많이 의존하고 있었습니다.

이 방식은 사용자의 질문과 문서에 포함된 단어가 정확히 일치할 때는 좋은 결과를 보였지만, 표현이 조금만 달라져도 원하는 문서가 상위에 노출되지 않는 문제가 있었습니다.

예를 들어 사용자는 “졸업식 언제야?”라고 질문하지만, 실제 문서에는 “학위수여식”, “학사일정”, “졸업 관련 안내”와 같은 표현으로 작성되어 있을 수 있습니다. 이 경우 단순 키워드 검색만으로는 사용자의 의도를 충분히 반영하기 어려웠습니다.

또한 연락처 관련 질문에서도 문제가 있었습니다. 사용자가 “호텔관광학과 담당자 연락처 알려줘”라고 입력했을 때, 문서에 학과명은 포함되어 있지만 연락처 정보가 다른 섹션에 있거나, 담당자 정보가 별도의 문서에 분리되어 있는 경우 검색 순위가 밀리는 문제가 발생했습니다.

Hybrid Search 적용 후 결과

Hybrid Search를 적용한 뒤에는 키워드가 정확히 일치하지 않더라도 의미적으로 관련 있는 문서가 검색 결과에 포함될 가능성이 높아졌습니다.

BM25는 질문에 포함된 명확한 키워드를 기준으로 문서를 찾고, SentenceTransformer 기반 임베딩 검색은 질문과 문서의 의미적 유사도를 기준으로 문서를 찾습니다.

두 검색 결과를 함께 활용하면서 다음과 같은 개선을 기대할 수 있었습니다.

문서 제목과 질문 표현이 달라도 관련 문서 검색 가능
부서명, 연락처, 학사 일정 등 명확한 키워드는 BM25로 보완
질문의 의도와 문서 내용이 유사한 경우 임베딩 검색으로 보완
특정 검색 방식 하나에 의존하지 않는 안정적인 검색 구조 구성

특히 동숲 프로젝트에서는 학교 문서의 표현 방식이 일정하지 않았기 때문에, 키워드 검색과 의미 검색을 함께 사용하는 방식이 더 적합하다고 판단했습니다.

개선된 부분

Hybrid Search와 문서 정제를 적용하면서 다음과 같은 부분이 개선되었습니다.

키워드가 정확히 일치하지 않아도 관련 문서가 검색될 수 있음
문서 유형, 부서, URL 등의 메타데이터를 활용해 검색 결과를 해석하기 쉬워짐
LLM에 전달되는 context의 관련성이 높아짐
검색 실패 원인을 더 명확하게 구분할 수 있음
답변 생성 이전 단계에서 품질을 검증할 수 있음

무엇보다 검색 결과를 정량적으로 확인할 수 있게 되면서, 단순히 “답변이 좋아 보인다”가 아니라 “정답 문서가 상위 k개 안에 포함되었는가”를 기준으로 개선 여부를 판단할 수 있었습니다.

Recall 실패 케이스 분석

Recall@3 평가를 진행하면서 실패한 케이스는 단순히 “검색이 안 됐다”로 처리하지 않고, 원인별로 나누어 분석했습니다.

1. 데이터 누락 문제

첫 번째는 애초에 검색 대상 문서에 정답이 되는 정보가 포함되어 있지 않은 경우였습니다.

예를 들어 사용자가 특정 부서의 연락처나 특정 일정에 대해 질문했지만, 해당 정보가 수집된 데이터셋에 존재하지 않으면 검색 로직이 아무리 좋아도 정답 문서를 찾을 수 없습니다.

이 경우는 검색 알고리즘의 문제가 아니라 데이터 수집 범위의 문제로 판단했습니다.

해결 방향은 다음과 같습니다.

누락된 문서 추가 수집
학과/부서 페이지 수집 범위 확대
공지사항과 학사 일정 데이터 최신화
연락처 데이터 별도 관리

2. 문서 전처리 문제

두 번째는 문서가 수집되었지만 전처리 과정에서 필요한 정보가 제거되거나, 불필요한 정보가 너무 많이 남아 검색 품질이 떨어지는 경우였습니다.

학교 홈페이지 문서는 메뉴, 푸터, 사이드바, 반복 문구 등 실제 답변과 무관한 텍스트가 많이 포함될 수 있습니다. 이런 정보가 검색 인덱스에 함께 들어가면 질문과 관련 없는 문서가 높은 점수를 받을 수 있습니다.

반대로 전처리 과정에서 연락처, 작성일, 부서명처럼 중요한 정보가 제거되면 정답 문서가 검색되기 어려워집니다.

해결 방향은 다음과 같습니다.

메뉴, 푸터, 반복 문구 제거
제목과 본문 분리
연락처, 부서명, 작성일 등 중요 정보 보존
URL과 문서 유형 메타데이터 유지

3. Chunking 문제

세 번째는 문서 chunking 문제였습니다.

문서가 너무 크게 나뉘면 하나의 chunk 안에 불필요한 정보가 많이 포함되어 검색 정확도가 떨어질 수 있습니다. 반대로 너무 작게 나뉘면 질문에 필요한 문맥이 분리되어 LLM이 답변을 생성하기 어려울 수 있습니다.

예를 들어 졸업 요건과 관련된 문서에서 “졸업학점”이라는 단어는 한 chunk에 있고, 실제 학점 기준은 다른 chunk에 분리되어 있다면 검색 결과에는 일부 정보만 포함될 수 있습니다.

해결 방향은 다음과 같습니다.

문단 또는 섹션 단위 chunking 적용
제목 정보를 chunk에 함께 포함
너무 짧은 chunk 병합
하나의 답변에 필요한 정보가 분리되지 않도록 조정

4. 검색 우선순위 문제

네 번째는 정답 문서가 검색 결과에는 포함되었지만 상위 3개 안에 들어오지 못하는 경우였습니다.

이 경우 데이터도 존재하고 전처리도 되었지만, 검색 점수 계산이나 우선순위 조정이 부족한 문제로 볼 수 있습니다.

예를 들어 연락처 질문에서는 연락처 정보가 포함된 문서가 우선되어야 하지만, 단순히 부서명이 많이 등장하는 다른 문서가 더 높은 순위에 배치될 수 있습니다.

해결 방향은 다음과 같습니다.

BM25와 임베딩 검색 점수의 가중치 조정
문서 유형별 우선순위 반영
연락처 질문에서는 전화번호/부서 정보가 포함된 문서 가중치 부여
학사 일정 질문에서는 날짜 정보가 포함된 문서 우선
중복 문서 제거

Recall 개선을 위해 적용한 방법

Hybrid Search Weight 조정

Hybrid Search를 적용하면서 BM25와 임베딩 검색 결과를 단순히 합치는 것이 아니라, 두 검색 방식의 가중치를 조정했습니다.

BM25의 비중이 너무 높으면 키워드가 정확히 일치하는 문서만 상위에 노출될 수 있고, 임베딩 검색의 비중이 너무 높으면 의미적으로는 비슷하지만 실제 답변 근거로는 부족한 문서가 상위에 노출될 수 있습니다.

따라서 동숲 프로젝트에서는 질문 유형과 검색 결과를 확인하면서 BM25와 임베딩 기반 검색의 균형을 조정했습니다.

특히 부서명, 학과명, 전화번호처럼 명확한 키워드가 중요한 질문은 BM25의 장점이 컸고, “졸업식 언제야?”, “기숙사 정보 알려줘”처럼 표현이 다양할 수 있는 질문은 의미 기반 검색의 보완 효과가 컸습니다.

Metadata 기반 검색 보정

문서 정제 과정에서 저장한 메타데이터도 검색 품질 개선에 활용했습니다.

단순히 본문 내용만 검색하는 것이 아니라, 문서 제목, URL, 문서 유형, 부서명, 작성일, 연락처 등의 정보를 함께 관리했습니다.

이를 통해 검색 결과를 해석하거나 우선순위를 조정할 때 다음과 같은 보정이 가능했습니다.

연락처 질문 → 연락처 또는 부서 정보가 있는 문서 우선
학사 일정 질문 → 일정 관련 문서 우선
규정 관련 질문 → 대학 규정집 문서 우선
최신 정보가 필요한 질문 → 작성일 기준 확인
동일한 URL의 중복 문서 제거

이 방식은 별도의 무거운 모델을 추가하지 않고도 검색 결과의 품질을 개선할 수 있다는 점에서 현재 프로젝트 환경에 적합했습니다.

질문 유형별 검색 우선순위 적용

동숲 챗봇에서 사용자가 입력하는 질문은 모두 같은 유형이 아니었습니다.

연락처를 묻는 질문, 학사 일정을 묻는 질문, 졸업 요건을 묻는 질문, 기숙사 정보를 묻는 질문은 필요한 문서 유형이 서로 다릅니다.

따라서 질문 유형에 따라 검색 우선순위를 다르게 적용했습니다.

예를 들어 “전화번호”, “연락처”, “담당자”와 같은 표현이 포함된 질문은 연락처 정보가 있는 문서를 우선하도록 했습니다. “졸업식”, “일정”, “언제”와 같은 표현이 포함된 질문은 학사 일정이나 공지 문서를 우선하도록 했습니다.

이 방식은 복잡한 의도 분류 모델을 추가하지 않고도, 간단한 규칙과 메타데이터를 활용해 검색 결과를 보정할 수 있다는 장점이 있었습니다.

적용하면서 고려한 점

Recall@k를 적용하면서 가장 중요하게 고려한 점은 평가 지표가 실제 서비스 구조와 맞아야 한다는 것이었습니다.

동숲 챗봇은 검색 결과 1개만 사용하는 구조가 아니라, 상위 여러 개의 문서를 context로 구성해 LLM에 전달하는 구조입니다. 따라서 Recall@1만으로 평가하면 실제 서비스 구조보다 지나치게 엄격한 기준이 될 수 있습니다.

반대로 너무 큰 k 값을 사용하면 검색 품질이 좋지 않아도 정답 문서가 우연히 포함될 가능성이 높아집니다. 이 경우 실제로는 불필요한 문서가 많이 포함되어 LLM 답변 품질이 떨어질 수 있음에도, 평가 지표상으로는 좋아 보이는 문제가 발생할 수 있습니다.

그래서 동숲 프로젝트에서는 Recall@3를 기준으로 삼았습니다.

상위 3개 안에 정답 문서가 포함된다면 LLM이 답변을 생성할 때 필요한 근거를 사용할 수 있고, 동시에 너무 많은 문서를 context에 넣어 노이즈가 증가하는 문제도 줄일 수 있다고 판단했습니다.

또한 Recall@k는 검색 품질을 평가하는 지표이지, LLM의 최종 답변 품질을 직접 평가하는 지표는 아닙니다. 따라서 Recall 결과가 좋더라도 프롬프트 구성이나 답변 생성 방식에 따라 최종 응답 품질은 달라질 수 있습니다.

이 점을 고려해 Recall@k 평가는 RAG 파이프라인 중 검색 단계의 품질을 확인하는 용도로 사용했습니다.

결과와 기대 효과

Recall@3 기반 평가를 적용하면서 검색 품질을 더 명확하게 확인할 수 있었습니다.

기존에는 챗봇 답변을 직접 확인하면서 “괜찮다” 또는 “이상하다” 정도로 판단했다면, Recall@3 평가를 통해 정답 문서가 실제로 검색 결과 상위에 포함되는지 확인할 수 있었습니다.

이를 통해 다음과 같은 효과를 얻을 수 있었습니다.

검색 로직 변경 후 품질 하락 여부 확인 가능
Hybrid Search 적용 전후 비교 가능
실패 케이스를 원인별로 분류 가능
데이터 누락과 검색 로직 문제를 구분 가능
LLM 답변 오류의 원인이 검색 단계인지 생성 단계인지 분리 가능

특히 RAG 구조에서는 LLM이 잘못된 답변을 생성했을 때 원인을 파악하기 어렵습니다. 검색 결과가 잘못된 것인지, 프롬프트가 부족한 것인지, 모델이 문맥을 잘못 이해한 것인지 구분해야 하기 때문입니다.

Recall@3 평가는 이 중 검색 단계의 문제를 먼저 분리해서 확인할 수 있게 해주었습니다.

배운 점

기존에 모델 학습 및 예측 중심의 프로젝트를 진행할 때는 주로 정답률(Accuracy)에 의존하는 경향이 있었습니다. 입력에 대해 모델이 정답을 바로 예측했는지를 중심으로 평가했기 때문에, 이번 프로젝트에서도 처음에는 정확한 답변 1개가 바로 나와야 한다고 생각했습니다.

하지만 동숲 프로젝트의 RAG 기반 LLM 서비스에서는 단순히 최종 답변만 확인하는 방식으로는 문제를 정확히 파악하기 어려웠습니다. LLM의 답변이 부정확할 때 그 원인이 모델 자체에 있는지, 프롬프트에 있는지, 아니면 검색된 문서가 잘못되었기 때문인지 구분하기 어려웠기 때문입니다. 이로 인해 처음에는 답변 품질을 높이기 위해 모델 교체를 고려하기도 했습니다.

Recall@k 평가를 적용하면서 문서 기반 LLM 서비스에서는 최종 답변뿐만 아니라, 답변 생성에 사용되는 검색 결과 자체를 검증하는 과정이 필요하다는 점을 배웠습니다. 특히 검색 결과 상위 1개 문서만 보는 것이 아니라, 상위 k개 문서 안에 정답 근거가 포함되어 있는지를 확인하면서 검색 로직의 품질을 더 현실적으로 평가할 수 있었습니다.

이를 통해 검색 품질 개선은 단순히 검색 알고리즘만의 문제가 아니라는 것도 알게 되었습니다. 정답 문서가 검색되지 않는 원인은 데이터 누락, 문서 전처리 문제, chunking 문제, 메타데이터 부족, 검색 우선순위 문제 등 여러 단계에서 발생할 수 있었습니다. 따라서 Recall@k 평가는 단순히 점수를 계산하는 지표가 아니라, RAG 파이프라인의 어느 부분을 개선해야 하는지 찾기 위한 기준이 되었습니다.

결과적으로 이번 경험을 통해 RAG 기반 LLM 서비스에서는 “모델이 답을 잘 생성하는가”만큼이나 “모델에게 전달할 근거 문서를 잘 찾고 있는가”가 중요하다는 것을 배웠습니다. 앞으로 문서 기반 AI 서비스를 개선할 때는 LLM의 최종 응답만 평가하는 것이 아니라, 검색 로직, 문서 전처리, 메타데이터, chunking까지 함께 검증하는 방식으로 접근해야겠다고 느꼈습니다.