RAG 검색 개선기: 질의처리기 모델 파인튜닝하기

 

지난 글에서는 질의처리기를 테스트하기 위한 테스트셋을 어떻게 만들었는지 정리했다.

 

질의처리 테스트셋을 만들고 나니 다음 질문이 생겼다. 테스트셋을 기준으로 작은 모델을 학습시키면, 룰 기반 질의처리기를 대체하거나 보완할 수 있을까?

 

검색 본경로에 큰 LLM을 그대로 넣기는 어려웠다. 프롬프팅만으로 질의처리를 맡겼을 때 정확도는 50%대에 머물렀고, 온디바이스 환경에서는 속도 부담도 컸다. 하지만 질의처리 작업 자체는 범위가 비교적 명확했다.

사용자의 입력에서 검색 키워드, 날짜, 파일 타입, 작성자, 경로 같은 정보를 JSON 형태로 뽑아내면 된다. 자유로운 답변을 생성하는 것보다 훨씬 좁은 문제였다.

그래서 작은 모델을 이 작업에 맞게 파인튜닝해보면 어떨까 생각했다.

이번 글에서는 질의처리기를 작은 모델로 만들어보려고 했던 파인튜닝 실험 과정을 정리해보려고 한다.

// 구글 colab을 이용한 LLM 파인튜닝해보기

1. 질의처리기 분석

처음부터 모델에게 검색 결과를 설명하거나 답변을 생성하게 하려던 것은 아니었다.

목표는 훨씬 좁았다. 사용자의 질의를 받아서 검색에 필요한 구조화된 정보를 JSON으로 뽑는 것이다.

이때 모델이 해야 할 일은 답변을 만드는 것이 아니라, 검색에 필요한 조건을 분리하는 것이다.

> 작년 팀장님이 작성한 pdf 제안서 찾아줘
{
  "keywords": ["제안서"],
  "date": "작년",
  "file_type": "pdf",
  "author": "팀장님"
}

 

이런 구조화 결과가 안정적으로 나오면, 검색기는 이 정보를 바탕으로 더 명확하게 문서를 찾을 수 있다.

즉, 이번 파인튜닝의 목표는 LLM을 검색기로 만드는 것이 아니라, 검색기 앞단의 질의처리기를 만드는 것이었다.

2. 출력 스키마 확정하기

파인튜닝을 하려면 먼저 모델이 어떤 형식으로 답해야 하는지 정해야 했다.

질의처리 결과는 자유 텍스트가 아니라 JSON이어야 했다. 그래야 검색 파이프라인에서 바로 사용할 수 있고, 테스트도 자동화할 수 있다.

그래서 출력 스키마를 먼저 고정했다.

문서 검색에 사용할 주요 필드들을 정하고, 모델은 입력 문장을 이 필드들로 변환하도록 했다.

이 과정에서 중요한 결정이 하나 있었다.

날짜 계산을 모델에게 전부 맡기지 않기로 한 것이다. 예를 들어 "지난달", "작년 3월", "이번 주" 같은 표현은 모델이 바로 절대 날짜로 바꿀 수도 있다. 

 

하지만 이렇게 하면 현재 날짜 기준이 달라질 때 결과도 달라지고, 테스트도 불안정해진다.

그래서 모델은 날짜 표현을 추출하고, 실제 날짜 범위 계산은 후처리에서 담당하는 방향으로 정리했다.

모델이 모든 것을 해결하게 하기보다, 모델이 잘할 수 있는 부분과 코드가 안정적으로 처리할 수 있는 부분을 나눴다.

3. 낮은 초기 정확도...

초기에는 Qwen3 1.7B 모델에 프롬프팅만 적용해서 질의처리를 테스트했다.

결과는 좋지 않았다. 정확도는 50%대에 머물렀다. 검색 본경로에 넣기에는 불안정한 수준이었다.

특히 복합 조건에서 많이 흔들렸다.

날짜, 작성자, 파일 타입, 키워드가 함께 들어오면 일부 필드는 맞히지만 다른 필드를 놓치는 경우가 많았다. 파일 타입을 검색 키워드에 섞거나, 작성자를 일반 키워드처럼 처리하거나, 날짜 표현을 잘못 해석하는 식이었다.

이 결과를 보고 프롬프팅만으로는 어렵다고 판단했다.

문제 자체는 작아 보였지만, 실제로는 검색 도메인에 맞는 출력 규칙을 꽤 엄격하게 배워야 했다.

4. 파인튜닝 테스트 데이터 보강하기

파인튜닝을 하기전 어느 부분이 취약한지 확인했다.

처음부터 한 번에 완성하려고 하기보다, 실패 유형을 보고 데이터를 보강하는 방식으로 진행했다.

Round1 에서는 기본적인 출력 형식과 주요 필드를 맞추는 데 집중했다.

하지만 결과를 보면 부족한 부분이 분명했다. 어떤 카테고리는 어느 정도 맞혔지만, 특정 조건과 여러 조건이 결합된 복합 조건에서는 성능이 낮았다.Round2에서는 Round1에서 약했던 유형을 중심으로 데이터를 보강했다.

특히 취약 카테고리를 추가했다. 그 결과 일부 카테고리는 개선됐지만, 여전히 복합 질의는 어렵게 남았다.

Round3에서는 데이터를 더 보강했고, 전체 정확도는 90%대까지 올라갔다.

이때부터는 질의처리 전용 모델로 쓸 수 있겠다는 가능성이 보이기 시작했다.

실험을 하면서 느낀 것은, 파인튜닝은 한 번에 끝나는 작업이 아니라는 점이었다.

모델이 틀린 유형을 보고, 그 유형을 다시 데이터로 만들고, 다시 테스트하는 반복 과정에 가까웠다.

5. 의외로 좋은 성능... 그러나

흥미로웠던 점은 모델 크기와 버전에 따른 정확도 차이였다.

처음에는 당연히 Qwen 3.0 1.7B 모델이 더 나을 것이라고 생각했다. 파라미터 수가 더 크면 질의처리도 더 잘할 것 같았다.

하지만 Round4에서 Qwen3.5 0.8B 모델을 테스트해보니 결과가 달랐다. 0.8B 모델이 1.7B 모델보다 더 좋은 결과를 보였다.

첫번째 테스트부터 96%까지 올라갔고, 1.7B보다도 높은 점수를 냈다.

 

모델 크기보다 베이스 모델의 세대와 데이터 품질이 더 중요할 수 있다는 걸 확인한 지점이었다. 온디바이스 환경에서는 모델 크기도 중요하다. 작은 모델이 충분한 정확도를 낼 수 있다면, 메모리와 배포 측면에서 훨씬 유리하다.

 

그래서 0.8B 모델의 결과는 꽤 의미가 있었다. 다만 속도는 생각보다 단순하지 않았다.

tokens/sec만 보면 작은 모델이 유리해 보일 수 있지만, 실제 응답 시간은 생성 토큰 수와 종료 여부에 크게 영향을 받았다. 학습이 부족한 모델은 JSON을 출력한 뒤에도 불필요한 토큰을 계속 생성하면서 오히려 응답이 느려질 수 있었다.

결국 작은 모델이 빠르려면, 단순히 모델 크기만 작아서는 부족했다. 원하는 형식으로 짧고 안정적으로 끝내는 것도 중요했다.

6. 오버피팅과 어려운 테스트셋에서의 한계

첫 테스트 결과만 보면 파인튜닝은 꽤 성공적으로 보였다. 하지만 더 어려운 테스트셋을 돌려보니 상황이 달라졌다.

어려운 테스트셋에는 역순 표현, 외래어, 다양한 도메인 표현, 복합 조건이 더 많이 들어갔다.

예를 들어 주요 데이터가 앞에 나오지 않거나, 조건 순서가 바뀌거나, 도메인이 아닌 마케팅, 인사, 재무, 법무, 영업 같은 표현이 섞이는 식이었다. 이 테스트에서는 성능이 크게 떨어졌다.

Round3 1.7B 모델은 19% 수준이었고, Round4 0.8B 모델도 27% 정도에 머물렀다.

v1에서 90% 이상이 나왔던 것과 비교하면 꽤 큰 차이였다.

이 결과는 조금 아팠지만, 오히려 중요한 사실을 보여줬다.

모델이 좋아진 것이 아니라, 테스트셋에 익숙해진 것일 수도 있다는 점이다.

학습 데이터와 비슷한 표현에서는 잘 동작하지만, 표현 순서나 도메인이 바뀌면 금방 흔들릴 수 있었다.

그래서 v1 점수만 보고 실서비스 투입 가능하다고 판단하는 것은 위험했다.

 

7. 그래도 가능성은 있었다

그렇다고 이 실험이 실패였다고 보지는 않았다. 실험을 진행하면서 오버피팅이 무조건 나쁜가?에 대해서도 고민하게 됐다.

작은 모델이 질의처리 JSON을 안정적으로 뽑을 수 있다는 가능성은 확인했다. 특히 범위를 잘 제한한 태스크에서는 충분히 의미 있는 결과가 나왔다.

 

자유로운 답변 생성이 아니라, 정해진 스키마에 맞춰 검색 조건을 추출하는 작업이라면 작은 모델도 꽤 잘할 수 있었다.

다만 역할을 명확히 해야 했다.

이 모델이 곧바로 검색 품질을 개선한다고 말할 수는 없다.

질의처리 결과가 좋아졌다고 해서 최종 검색 결과가 좋아졌다는 뜻은 아니기 때문이다. 검색 결과가 실제로 좋아졌는지는 다시 검색 테스트와 E2E 테스트로 확인해야 한다.

그래서 지금 단계의 결론은 이 정도였다.

작은 모델로 질의처리기는 만들 수 있다.

하지만 검색을 완전히 맡기기보다는, 룰 기반 질의처리기를 보완하거나 후보를 제안하는 역할이 더 현실적이다.

마치며

이번 실험은 작은 모델로 질의처리기를 만들 수 있는지 확인하기 위한 작업이었다.

처음에는 프롬프팅만으로도 어느 정도 될 것이라고 생각했지만, 정확도는 50%대에 머물렀다. 그래서 출력 스키마를 고정하고, 실패 유형을 기준으로 데이터를 보강하면서 파인튜닝을 진행했다.

그 결과 Qwen 3.5 0.8B 모델이 96%까지 올라갔다. 작은 모델도 구조화 추출 태스크에서는 충분히 가능성이 있다는 걸 확인했다.

하지만 어려운 테스트에서는 27% 수준으로 떨어졌다. 이 결과를 보면서 다시 처음 질문으로 돌아오게 됐다.

무엇을 기준으로 좋아졌다고 말해야 할까?

파인튜닝 모델로 질의처리 정확도가 올라간 것과, 실제 검색 품질이 좋아진 것은 같은 말이 아니다.

좋은 검색 품질을 만들려면 질의처리 결과만 좋아서는 부족하다. 질의처리 속도도 충분히 빨라야 하고, 사용자의 핵심 키워드가 검색기에 잘 전달되어야 한다. 또한 검색 대상 문서도 검색하기 좋은 형태로 정리되어 있어야 한다.

결국 질의처리, 검색기, 문서 데이터가 함께 맞물려야 사용자가 체감하는 검색 품질이 좋아진다.

작은 모델은 질의처리기를 보완할 수 있다. 하지만 그것이 검색 시스템 전체의 개선으로 이어졌는지는 별도의 테스트로 확인해야 한다. 결국 이번 시리즈는 검색 시스템을 개선한 기록이라기보다, 개선됐다고 말하기 위한 기준을 하나씩 만들어간 과정에 가까웠다.