RAG 검색 개선기: 질의처리 테스트셋을 만들며 고민한 것들

 

지난 글에서는 검색기 앞단의 질의처리 방향을 어떻게 정리했는지 적었다.

테스트 결과, 사용자의 질의를 그대로 검색하는 방식이 형태소분석 후 키워드만 넘기는 방식보다 조금 더 안정적이었다. 하지만 그렇다고 질의처리가 필요 없는 것은 아니었다. 검색 본문으로 사용할 표현은 최대한 보존하되, 날짜나 지역, 파일 타입, 기관명처럼 조건으로 다룰 수 있는 정보는 별도로 구조화하는 편이 더 적절해 보였다.

결국 핵심은 LLM을 쓰느냐 마느냐가 아니었다.

검색어로 남길 것, 필터 조건으로 분리할 것, 제거할 것을 나누는 기준이 더 중요했다.

그렇다면 다음으로 정해야 할 것은 이 기준을 어떻게 테스트할 것인가였다.

검색기는 정답 문서가 검색 결과 상위에 들어오는지를 보면 된다. 하지만 질의처리기는 정답 문서를 직접 찾는 컴포넌트가 아니다. 사용자의 문장을 검색 가능한 구조로 바꾸는 역할을 한다.

그래서 질의처리 테스트셋은 검색 테스트셋과 달라야 했다.

이번 글에서는 질의처리기를 테스트하기 위해 어떤 기준을 정했고, 테스트셋을 만들면서 어떤 점을 고민했는지 정리해보려고 한다.

 

1. 검색 테스트와 질의처리 테스트는 달랐다

검색 테스트에서는 비교적 명확한 기준을 세울 수 있다.

사용자 질의가 있고, 정답 문서가 있다. 검색 결과 상위 k개 안에 정답 문서가 들어오면 성공으로 볼 수 있다. 정답 문서가 몇 번째에 나왔는지를 기준으로 MRR 같은 지표도 계산할 수 있다.

하지만 질의처리 테스트는 달랐다.

질의처리기는 문서를 직접 찾지 않는다. 대신 사용자의 입력을 해석해서 검색에 사용할 구조를 만든다.

예를 들어 사용자가 다음과 같이 입력했다고 하자.

> 작년 3월 서울에서 올라온 AI 지원사업 공고 찾아줘

검색 테스트라면 이 질의에 대해 어떤 문서가 검색 결과에 올라왔는지를 보면 된다.

하지만 질의처리 테스트에서는 다른 것을 봐야 한다.

이 문장을 어떻게 해석했는지, 어떤 정보는 검색어로 남겼는지, 어떤 정보는 필터 조건으로 분리했는지, 어떤 정보는 제거했는지를 봐야 한다.

예를 들면 다음과 같은 구조를 기대할 수 있다. (실제 이렇게 사용하진 않았지만 예를 들어서)

{
  "keywords": ["AI 지원사업"],
  "date": {
    "type": "created_at",
    "from": "2025-03-01",
    "to": "2025-03-31"
  },
  "region": "서울",
  "file_type": null,
  "organization": null,
  "author": null,
  "document_type": "공고"
}

즉, 질의처리 테스트의 성공 기준은 “정답 문서를 찾았는가”가 아니라 “사용자의 의도를 검색 가능한 구조로 잘 바꿨는가”에 가까웠다.

 

이 차이를 먼저 분리하지 않으면 평가가 애매해진다. 검색 결과가 나빴을 때 검색기가 문제인지, 질의처리기가 잘못된 조건을 만들었는지 구분하기 어렵다.

 

반대로 검색 결과가 좋았을 때도, 질의처리가 잘해서인지 검색기가 우연히 잘 찾은 것인지 알기 어렵다. 그래서 검색 테스트와 질의처리 테스트는 분리해서 봐야 했다.

 

2. 먼저 질의처리기의 책임 범위를 정해야 했다

질의처리 테스트셋을 만들기 전에 먼저 정해야 했던 것은 출력 스키마였다. 질의처리기가 어떤 정보를 뽑아야 하는지 정하지 않으면, 테스트셋도 만들 수 없다.

 

처음에는 단순히 검색 키워드만 잘 뽑으면 된다고 생각할 수 있다. 하지만 실제 검색 요청을 보면 키워드만으로는 부족한 경우가 많다.

 

사용자는 다음과 같이 검색한다.

지난달 받은 pdf 찾아줘
김팀장이 쓴 제안서 찾아줘
서울 AI 지원사업 공고 찾아줘
2024년 예산 관련 회의록 보여줘
마케팅 폴더에 있는 발표자료 찾아줘

이런 입력에는 검색 키워드뿐 아니라 여러 조건이 섞여 있다. 그래서 질의처리기가 책임질 수 있는 필드를 먼저 정해야 했다.

 

예를 들면 다음과 같은 필드들이 후보가 됐다.

 

• keywords: 검색 본문으로 사용할 키워드
• date: 생성일, 수정일, 수신일 같은 날짜 조건
• region: 지역 조건
• file_type: pdf, ppt, excel 같은 파일 타입
• organization: 기관명이나 회사명
• author: 작성자
• document_type: 공고, 보고서, 제안서, 회의록 같은 문서 종류
• path: 특정 폴더나 경로
• sort: 최신순, 오래된순 같은 정렬 조건

이 필드들을 정하는 일은 단순히 JSON 구조를 정하는 일이 아니었다. 질의처리기의 책임 범위를 정하는 일이었다.

 

예를 들어

- 지난달 받은 pdf라는 입력이 있을 때, 질의처리기가 지난달을 날짜 범위로 변환해야 할까? 아니면 상대 표현 그대로 넘겨야 할까?

- 서울 AI 지원사업 공고에서 서울은 검색 키워드로 남겨야 할까, 지역 필터로 분리해야 할까?

- 김팀장이 쓴 제안서에서 김팀장은 작성자로 볼 수 있을까, 아니면 단순 키워드로 남겨야 할까?

 

이런 기준이 정해지지 않으면 같은 질의에 대해 여러 정답이 가능해진다. 그리고 여러 정답이 가능하면 자동 테스트가 어려워진다. 그래서 먼저 질의처리기가 어디까지 책임질지 정해야 했다.

 

모든 것을 완벽히 해석하는 것이 목적은 아니었다.

 

검색 본경로에서 빠르고 예측 가능하게 처리할 수 있는 정보만 우선 대상으로 잡는 것이 더 중요했다.

 

3. 테스트셋은 카테고리별로 나눠야 했다

출력 스키마를 정한 뒤에는 테스트셋을 어떻게 나눌지 고민했다.

모든 질의를 하나의 테스트셋에 넣으면 전체 정확도는 볼 수 있다. 하지만 어떤 유형에서 실패하는지는 알기 어렵다.

예를 들어 전체 정확도가 80%라고 하더라도, 단순 키워드 질의는 거의 맞히지만 날짜 조건에서 계속 실패할 수 있다. 파일 타입은 잘 뽑지만 작성자와 기관명을 자주 헷갈릴 수도 있다. 복합 질의에서는 조건 일부만 맞히고 나머지는 놓칠 수도 있다.

그래서 테스트셋은 카테고리별로 나눠야 했다.

처음에는 다음과 같은 범주를 생각했다.

- 단순 키워드 질의
- 날짜 조건 질의
- 파일 타입 질의
- 작성자 조건 질의
- 기관명 조건 질의
- 경로 조건 질의
- 복합 질의

카테고리를 나누면 단순히 전체 점수만 보는 것이 아니라, 질의처리기가 어떤 유형의 입력에서 잘 동작하고 어떤 유형에서 흔들리는지를 볼 수 있다.

특히 복합 질의는 따로 보는 것이 중요했다.

실제 사용자 질의는 날짜, 작성자, 파일 타입, 문서 종류, 키워드가 한 문장 안에 섞이는 경우가 많다. 이때는 일부 필드는 맞고 일부 필드는 틀릴 수 있기 때문에, 단순한 성공/실패보다 어떤 필드가 자주 실패하는지를 보는 편이 더 유용했다.

 

4. 테스트 문장은 일부러 다양하게 만들어야 했다

카테고리를 나누는 것만으로는 부족했다.

각 카테고리 안에서도 표현을 다양하게 만들어야 했다.

실제 사용자는 같은 의도라도 같은 방식으로 말하지 않는다.

예를 들어 날짜 조건만 해도 표현은 여러 가지가 될 수 있다.

작년 3월 문서 찾아줘
3월에 작성한 문서 보여줘
지난달 받은 pdf 찾아줘
최근 올라온 공고 찾아줘
작년에 공유받은 자료 있어?

 

파일 타입이나 작성자 조건도 마찬가지다.

pdf 파일 찾아줘
피디에프 자료 보여줘
김팀장이 쓴 제안서
김팀장이 준 자료
홍길동이 공유한 회의록

이런 표현의 다양성이 없으면 테스트셋은 너무 쉬워진다.

 

예를 들어 모든 날짜 질의가 {date}에 작성한 {document_type} 형태라면, 질의처리기는 그 패턴만 맞혀도 높은 점수를 받을 수 있다. 하지만 실제 사용자 입력은 그렇게 정직하지 않다.

 

말을 줄이기도 하고, 순서를 바꾸기도 하고, 조건과 키워드를 섞기도 한다.

 

그래서 테스트 문장은 일부러 다양하게 만들어야 했다.

 

테스트셋이 너무 정형화되면 구현이 그 테스트셋에만 맞춰질 수 있다. 반대로 표현이 다양하면 질의처리기가 실제 입력에서 어느 정도 버티는지 더 잘 볼 수 있다.

5. 템플릿만으로는 다양한 질의를 만들기 어려웠다

처음에는 테스트 문장을 템플릿으로 만들려고 했다.

예를 들면 이런 방식이다.

{date}에 작성한 {document_type} 찾아줘
{date}에 받은 {file_type} 문서 찾아줘
{author}가 작성한 {keyword} 문서 찾아줘
{region}에서 올라온 {keyword} 공고 찾아줘​

이 방식은 만들기 쉽고, 정답 JSON도 비교적 명확하다. 어떤 슬롯이 어떤 필드로 매핑되어야 하는지 사람이 바로 알 수 있기 때문이다.

 

하지만 금방 한계가 보였다.

 

템플릿으로 만든 문장은 너무 규칙적이었다. 실제 사용자는 필요한 말만 짧게 던지기도 하고, 조건을 애매하게 말하기도 하고, 순서를 바꾸기도 한다.

예전에 공유받은 바우처 자료
서울 쪽 AI 지원사업 공고
김팀장이 준 제안서
지난달쯤 봤던 pdf
최근 올라온 공고 중에 서울 관련된 거

템플릿만으로는 이런 표현의 흔들림을 충분히 만들기 어려웠다.

 

그래서 테스트 질의 생성에는 프론티어 모델을 활용했다.

 

사람이 먼저 카테고리와 출력 스키마를 정하고, 각 카테고리별로 필요한 의도를 정의했다.

 

그다음 프론티어 모델에게 같은 의도를 가진 다양한 사용자 표현을 생성하도록 맡겼다. 다만 모든 것을 모델에 맡기지는 않았다.

 

테스트셋은 평가 기준이기 때문에, 생성된 문장이 그럴듯하다고 해서 바로 사용할 수는 없었다. 모델이 만든 질의와 예상 JSON은 사람이 다시 검수했다.

 

결국 데이터 생성은 모델의 도움을 받되, 카테고리와 스키마, 최종 정답 기준은 사람이 고정하는 방식으로 가져갔다.

마치며

이번 글에서는 질의처리기를 평가하기 위한 테스트셋을 만들면서 고민했던 것들을 정리했다.

질의처리 테스트는 검색 테스트와 달랐다. 정답 문서가 상위에 올라왔는지를 보는 것이 아니라, 사용자의 문장이 검색 가능한 구조로 잘 변환됐는지를 봐야 했다.

그래서 먼저 질의처리기의 책임 범위와 출력 스키마를 정하고, 테스트셋을 카테고리별로 나눴다. 또한 실제 사용자 입력에 가까운 표현을 만들기 위해 템플릿만 사용하지 않고, 프론티어 모델을 활용해 다양한 질의를 생성한 뒤 사람이 정답 JSON을 검수했다.

결국 질의처리 테스트셋은 단순한 예제 모음이 아니었다. 질의처리기가 무엇을 책임지고, 어떤 출력을 내야 하며, 어떤 실패를 드러내야 하는지 정리한 기준에 가까웠다.

다음 글에서는 이렇게 만든 테스트셋을 바탕으로 실패 케이스를 어떻게 모으고, 이를 파인튜닝 데이터로 확장할 수 있을지 정리해보려고 한다.