RAG 검색 개선기: 검색기보다 먼저 봐야 했던 질의처리

 

지난 글에서는 검색을 개선하기 전에 평가셋부터 다시 짜야 했던 이유를 적었다. 이번 글은 RAG 구축 고려사항 중 질의 강화·키워드 추출에 해당한다.

 

결론부터 말하면, 질의를 키워드로 바꾸는 게 오히려 검색을 깎아먹었다.

검색기를 의심했는데, 검색기 문제가 아니었다

검색 품질이 아쉬우면 가장 먼저 검색기를 의심하게 된다. 나도 그랬다. 임베딩 모델을 바꿔보고, 인덱싱 방식을 손보고, 청크 크기를 조절하며 며칠을 보냈다. "검색이 약하니 검색기를 강하게 만들면 되겠지"라는 게 당연한 출발점이었다.

 

그런데 평가셋을 정리하고 나서, 검색기는 그대로 둔 채 질의를 넘기는 방식만 바꿔 같은 조건에서 비교해봤다. 원질의를 그대로 검색할 때, 키워드만 추출해 넘길 때, 추출한 키워드를 확장해 넘길 때. 결과는 예상과 정반대였다.

 

모드               MRR@10   Recall@3
raw_query          0.935    0.950
source_keywords    0.706    0.787
final_keywords     0.752    0.837

원질의를 그대로 넣은 게 가장 셌다. 키워드로 압축한 순간 MRR이 0.935에서 0.706으로 뚝 떨어졌고 거기에 확장을 붙여 0.752로 일부 회복했지만 원질의 근처에도 못 갔다.

 

"키워드화하면 더 잘 찾는다"는 건 그냥 내 머릿속 가정이었을 뿐, 숫자는 정반대를 가리키고 있었다. 검색기를 붙들고 있던 며칠이 머쓱해지는 순간이었다.

키워드로 바꾸는 순간 정보가 샌다

왜 이런 일이 벌어질까. 질의를 키워드로 바꾸는 과정 자체가 정보를 흘린다.

 

우선 질의를 짧게 자르면 문맥이 날아간다. 단어들 사이의 관계, 수식, 부정 같은 게 다 빠지고 명사 몇 개만 남는다. 게다가 추출 과정도 완벽하지 않다. 핵심어가 누락되거나, 형태소 분석이 단어를 잘못 쪼개기도 한다.

 

예를 들어 "5G"처럼 숫자와 알파벳이 붙은 토큰은 "G"만 남고 "5"가 떨어져 나가는 식으로 깨진다. 원질의에는 멀쩡히 들어 있던 단서가, 키워드화 단계를 거치며 사라지는 것이다.

 

그러니 애초에 방향이 틀린 질문을 하고 있었다. "질의를 어떻게 더 잘게 쪼갤까"가 아니라, "원질의의 정보를 어떻게 안 잃을까"가 맞는 질문이었다. 검색어는 가능한 한 원질의에 가깝게 남기는 게 유리했다.

그럼 질의처리는 무엇을 해야 하나

그렇다고 질의처리를 통째로 없앨 수는 없다. 실제 질의에는 검색어가 아닌 것들이 섞여 있기 때문이다.

 

"최근 서울에서 진행하는 AI 바우처 지원사업 찾아줘" 같은 질의를 보자. 여기서 "최근"은 날짜 조건이고, "서울"은 지역 조건이며, "찾아줘"는 그냥 말버릇이다. 이걸 전부 검색어로 던지면 오히려 노이즈가 된다.

 

그래서 질의처리의 역할을 키워드 추출 이 아니라 분류 로 다시 잡았다.

검색어로는 "AI 바우처 지원사업" 같은 내용어를 원질의에 가깝게 남긴다. "최근"은 날짜로, "서울"은 지역으로 빼서 필터로 처리한다. 날짜나 지역은 본문 검색어로 던지는 것보다 메타데이터로 거르는 게 훨씬 정확하기 때문이다.

 

"찾아줘" 같은 군더더기는 버린다. 이렇게 나누면 검색어는 풍부하게 유지되면서 검색 범위는 필터로 깔끔하게 좁혀진다.

LLM이냐 아니냐는 핵심이 아니었다

여기서 한 가지가 더 분명해졌다. 이 분류를 LLM으로 하느냐 규칙으로 하느냐는 본질이 아니었다. 정작 중요한 건 무엇을 검색어로 남기고, 무엇을 필터로 분리하고, 무엇을 버릴지에 대한 기준 이었다.

 

기준이 없으면 아무리 큰 LLM을 붙여도 결과가 매번 흔들렸다. 같은 질의를 두 번 넣으면 다른 분류가 나오기도 했다. 반대로 기준이 단단하면, 의외로 무거운 모델 없이도 안정적으로 처리할 수 있었다. 화려한 모델을 얹는 것보다, 분류 기준을 또렷하게 세우는 쪽이 먼저였다.

마치며

검색을 개선하려고 검색기부터 팠는데, 정작 손봐야 할 곳은 그 앞단의 질의처리였다. 그리고 질의처리의 핵심은 더 똑똑한 추출이 아니라 "검색어·필터·제거를 나누는 기준"이라는 것 — 이 기준이 시리즈 후반에서 질의처리기를 다시 만드는 결론으로 그대로 이어진다.

 

다음 글에서는 이 질의처리를 어떻게 검증할지, 즉 질의처리 테스트셋을 만들며 고민한 것들을 적는다.