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

 

지난 글에서는 RAG 검색을 개선하기 전에 테스트 기준을 먼저 정리해야 했던 이유를 적었다.

테스트 기준을 정리한 뒤 여러 방식으로 검색을 비교해보니, 검색기 자체에 큰 문제가 있다고 보기는 어려웠다. 정답 문서를 회수하는 능력은 어느 정도 안정적으로 나왔고, 검색 모델이나 벡터 DB 자체를 먼저 의심할 상황은 아니었다.

오히려 눈에 띈 것은 검색기 앞단의 질의처리였다.

같은 검색기를 쓰더라도 사용자 입력을 어떻게 해석하고, 어떤 형태로 검색기에 넘기느냐에 따라 결과가 달라졌다. 그래서 이번 글에서는 검색기 앞단의 질의처리 방향을 어떻게 정리했는지 적어보려고 한다.

 

1. 질의를 그대로 쓰는 편이 조금 더 나았다

가장 먼저 비교한 것은 문장을 그대로 검색하는 방식과, 형태소분석 후 키워드만 넘기는 방식이었다.

처음에는 형태소분석 후 키워드만 남기는 방식이 더 좋을 것이라고 생각했다. 한국어는 조사나 어미가 붙고, 복합명사도 많기 때문에 검색에 필요한 단어만 정리해서 넘기면 더 정확할 것 같았다.

하지만 테스트 결과는 예상과 조금 달랐다.

사용자의 질의를 그대로 검색에 넣는 방식이 형태소분석 후 키워드를 넘기는 방식보다 조금 더 안정적이었다.

다만 차이가 아주 크지는 않았다. 질의를 그대로 넣는다고 모든 문제가 해결되는 것도 아니었고, 형태소분석을 거친 방식이 완전히 나쁜 것도 아니었다.

그래도 한 가지는 분명했다.

검색 성능을 올리기 위해 질의를 과하게 가공할 필요는 없어 보였다. 사용자가 입력한 문장에는 생각보다 많은 맥락이 들어 있고, 그 맥락을 너무 일찍 잘라내면 오히려 검색에 필요한 정보가 사라질 수 있다.

 

2. 그렇다고 질의처리가 필요 없는 것은 아니었다

질의를 그대로 쓰는 편이 조금 더 나았다고 해서, 질의처리가 필요 없다는 뜻은 아니었다.

검색어를 과하게 가공하지 않는 것과, 검색 조건을 분리하지 않는 것은 다른 문제다.

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

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

 

이 문장을 검색어로는 그대로 살릴 수 있다. 하지만 그 안에 들어 있는 날짜, 지역, 문서 종류 같은 정보는 별도로 구조화할 수 있다.

- `작년 3월`은 날짜 조건에 가깝다.
- `서울`은 지역 조건에 가깝다.
- `공고`는 문서 종류나 검색 키워드에 가깝다.
- `AI 지원사업`은 검색 본문 질의에 가까운 표현이다.

이런 정보를 분리해두면 검색기는 더 명확한 조건으로 문서를 찾을 수 있다.

결국 중요한 것은 질의를 무조건 줄이는 것이 아니었다.

검색 본문으로 사용할 표현은 최대한 보존하고, 날짜나 지역, 파일 타입, 기관명처럼 조건으로 다룰 수 있는 정보만 분리하는 것이 더 적절해 보였다.

 

3. 형태소분석을 쓴 이유는 NER와 조건 분리 때문이었다

처음 형태소분석을 사용한 이유도 단순히 검색어를 짧게 만들기 위해서만은 아니었다.

더 중요한 목적은 NER와 조건 분리였다.

검색 요청에는 단순 키워드만 들어오지 않는다. 지역, 기관명, 날짜, 파일 타입, 문서 종류 같은 조건이 자연어 안에 섞여 들어온다.

이 정보를 검색 전에 어느 정도 뽑아낼 수 있으면, 검색 범위를 줄이거나 조건을 더 명확하게 만들 수 있다.

다만 테스트를 해보니, 형태소분석으로 뽑은 키워드만 검색어로 사용하는 것은 생각보다 큰 이점이 없었다.

형태소분석기는 원문 질의를 대체할 검색어를 만들기 위한 도구라기보다, 입력 안에서 조건 후보를 찾기 위한 도구에 가깝게 보는 편이 맞았다.

즉, 형태소분석의 역할은 사용자의 문장을 짧게 줄이는 것이 아니라, 검색어로 남길 정보와 조건으로 분리할 정보를 구분하는 데 있었다.

 

4. LLM 질의처리는 검색 본경로에 넣기 애매했다

그렇다면 이 질의처리를 LLM에 맡기면 어떨까?

사용자 입력을 넣고 검색 키워드, 날짜, 지역, 파일 타입 같은 정보를 JSON으로 추출하도록 하면 룰을 직접 많이 만들지 않아도 될 것 같았다.

예를 들면 이런 형태다.

{
  "keywords": ["AI 바우처", "지원사업"],
  "region": "서울",
  "date": "recent",
  "file_type": null
}

이 방식은 처음에는 꽤 매력적으로 보였다.

 

표현이 조금 달라져도 LLM이 의미를 이해해서 비슷한 구조로 뽑아줄 수 있을 것 같았다. 사전이나 룰을 계속 추가하는 것보다 유지보수도 쉬워 보였다.

 

하지만 실제로 테스트해보면 애매한 지점이 많았다.

 

Qwen 1.7B 모델에 프롬프팅만 적용해서 질의처리 테스트를 돌렸을 때 정확도는 50%대에 머물렀다. 검색 본경로에 넣기에는 불안정한 수치였다.

 

속도도 문제였다. 내가 테스트한 온디바이스 환경에서는 검색 전 질의처리에만 3초 이상 걸리는 경우가 있었다.

 

검색은 사용자가 입력하고 바로 결과를 기대하는 기능이다. 그런데 검색하기 전에 질의처리만으로 몇 초를 쓰는 것은 부담이 컸다. 검색기 자체가 빠르게 동작하더라도, 질의처리 단계에서 이미 시간이 많이 걸리면 사용자는 전체 검색이 느리다고 느낄 수밖에 없다.

 

그리고 LLM 출력은 예측하기 어렵다.

 

JSON 형식은 맞아 보여도 날짜 표현을 잘못 해석하거나, 검색 키워드로 남겨야 할 단어를 필터 조건으로 빼거나, 반대로 필터 조건을 키워드에 섞을 수 있다.

 

검색 본경로에서는 이런 작은 오류가 바로 검색 결과 품질로 이어진다.

 

그래서 LLM을 검색 전 질의처리에 바로 넣는 것은 적절하지 않다고 판단했다. 검색 품질이 압도적으로 좋아진다면 감수할 수도 있겠지만, 이번 테스트에서는 그 정도의 개선을 확인하지 못했다.

 

5. 필요한 것은 예측 가능한 질의처리였다

이 과정에서 내린 결론은, 질의처리가 더 똑똑해야 한다기보다 더 예측 가능해야 한다는 것이었다.

 

검색 본경로에서는 빠르고 안정적인 처리가 중요하다.

 

날짜, 지역, 파일 타입, 기관명처럼 명확하게 구조화할 수 있는 정보는 LLM보다 사전이나 라이브러리 기반으로 처리하는 편이 나아 보였다.

 

예를 들면 다음과 같은 방식이다.

 

• 파일 타입 동의어 사전
• 한국어 날짜 파서
• 지역명 사전
• 기관명 사전
• 문서 종류 분류 규칙

이 방식은 LLM처럼 유연하지는 않다. 대신 속도가 빠르고, 결과를 예측할 수 있고, 문제가 생겼을 때 어느 규칙을 고쳐야 하는지도 비교적 명확하다.

 

특히 검색 본경로에서는 이런 특성이 중요했다.

 

사용자 입력을 기다리게 하지 않고, 같은 입력에 대해 같은 결과를 내고, 실패했을 때 원인을 추적할 수 있어야 한다.

 

그래서 검색 전 질의처리는 LLM으로 크게 해결하기보다, 사전형 처리와 파서, 필요한 라이브러리를 조합하는 방향이 더 현실적이라고 봤다.

 

물론 LLM을 완전히 제외해야 한다는 뜻은 아니다. 다만 검색 전에 반드시 기다려야 하는 질의처리 단계에 넣기에는 부담이 컸다.

 

검색 본경로에서는 빠르고 예측 가능한 처리가 우선이고, LLM은 필요하다면 검색 이후의 설명, 요약, 추가 필터 제안 같은 보조 기능에서 사용하는 편이 더 자연스러워 보였다.

마치며

여러 테스트셋으로 비교해보니 검색기 자체는 생각보다 안정적이었다.

 

질의를 그대로 검색하는 방식은 형태소분석 후 키워드만 넘기는 방식보다 조금 더 나았다. 하지만 그렇다고 질의처리가 필요 없는 것은 아니었다.

 

검색 본문 질의는 과하게 가공하지 않는 편이 좋았고, 날짜나 지역, 파일 타입 같은 조건은 별도로 구조화하는 편이 더 적절해 보였다.

 

LLM을 검색 전 질의처리에 넣는 것도 고민했지만, 정확도와 속도 면에서 검색 본경로에 넣기에는 애매했다. Qwen 1.7B 프롬프팅 기반 테스트는 50%대 정확도에 머물렀고, 질의처리에만 3초 이상 걸리는 경우도 있었다.

 

그래서 지금 단계에서는 사전, 파서, 라이브러리 기반의 예측 가능한 질의처리가 더 현실적이라고 판단했다.

 

결국 핵심은 LLM을 쓰느냐 마느냐가 아니었다. 검색어로 남길 것, 필터 조건으로 분리할 것, 제거할 것을 나누는 기준이 더 중요했다.

 

다음 글에서는 이 질의처리기를 테스트하기 위해 어떤 기준과 테스트셋을 만들었는지 정리해보려고 한다.