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

 

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

 

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

 

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

 

사용자의 입력에서 검색 키워드·날짜·파일 타입·작성자·경로 같은 정보를 JSON으로 뽑아내면 된다. 자유로운 답변을 생성하는 것보다 훨씬 좁은 문제였다. 그래서 작은 모델을 이 작업에 맞게 파인튜닝해보면 어떨까 생각했다. 이번 글은 RAG 구축 고려사항 중 모델 양자화에도 닿는 실험이다.

1. 목표는 답변이 아니라 구조화였다

처음부터 모델에게 검색 결과를 설명하거나 답변을 생성하게 하려던 건 아니었다. 목표는 훨씬 좁았다. 사용자의 질의를 받아서 검색에 필요한 구조화된 정보를 JSON으로 뽑는 것. 모델이 할 일은 답을 만드는 게 아니라 검색에 필요한 조건을 분리하는 것이었다.

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

이런 구조화 결과가 안정적으로 나오면 검색기는 이 정보를 바탕으로 더 명확하게 문서를 찾을 수 있다. 즉 이번 파인튜닝의 목표는 LLM을 검색기로 만드는 게 아니라, 검색기 앞단의 질의처리기를 만드는 것이었다.

2. 출력 스키마를 먼저 고정했다

파인튜닝을 하려면 모델이 어떤 형식으로 답해야 하는지부터 정해야 했다. 질의처리 결과는 자유 텍스트가 아니라 JSON이어야 했다. 그래야 검색 파이프라인에서 바로 쓸 수 있고 테스트도 자동화된다. 그래서 출력 스키마를 먼저 고정하고, 모델은 입력 문장을 이 필드들로 변환하게 했다.

 

이 과정에서 중요한 결정이 하나 있었다. 날짜 계산을 모델에게 맡기지 않은 것이다. "지난달", "작년 3월" 같은 표현을 모델이 바로 절대 날짜로 바꿀 수도 있지만, 그렇게 하면 검색 시점이 달라질 때 결과도 달라지고 테스트도 불안정해진다. 그래서 모델은 날짜 표현만 추출하고, 실제 날짜 범위 계산은 후처리가 담당하게 나눴다.

 

모델이 모든 걸 해결하게 하기보다, 모델이 잘하는 부분과 코드가 안정적으로 처리할 부분을 가른 셈이다.

3. 프롬프팅만으로는 50%대였다

초기에는 Qwen3 1.7B에 프롬프팅만 적용해 질의처리를 시켜봤다. 결과는 좋지 않았다. 정확도는 50%대에 머물렀고, 검색 본경로에 넣기엔 불안정했다.

 

특히 복합 조건에서 많이 흔들렸다. 날짜·작성자·파일 타입·키워드가 함께 들어오면 일부 필드는 맞히지만 다른 필드를 놓쳤다. 파일 타입을 검색 키워드에 섞거나, 작성자를 일반 키워드처럼 처리하거나, 날짜 표현을 잘못 해석하는 식이었다.

 

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

 

프롬프팅만으로는 어렵다고 판단했다.

4. 실패 유형을 보고 데이터를 보강했다

파인튜닝은 한 번에 완성하기보다, 실패 유형을 보고 데이터를 보강하는 방식으로 진행했다.

 

 

Round1에서는 기본 출력 형식과 주요 필드를 맞추는 데 집중했다. Round2에서는 약했던 유형, 특히 취약 카테고리를 보강했다. Round3에서는 데이터를 더 채워 전체 정확도가 90%대까지 올라갔고, 이때부터 질의처리 전용 모델로 쓸 수 있겠다는 가능성이 보였다.

 

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

5. 작은 모델이 더 좋았다, 다만 속도는 단순하지 않았다

흥미로운 건 모델 크기와 세대에 따른 차이였다. 처음엔 당연히 파라미터가 큰 Qwen3 1.7B가 나을 줄 알았다. 그런데 Round4에서 Qwen3.5 0.8B를 테스트해보니 0.8B가 1.7B보다 더 좋은 결과를 냈고, 96%까지 올라갔다. 모델 크기보다 베이스 모델의 세대와 데이터 품질이 더 중요할 수 있다는 걸 확인한 지점이었다. 온디바이스에서는 작은 모델이 메모리·배포 면에서 훨씬 유리하니, 이 결과는 꽤 의미가 있었다.

 

다만 속도는 생각보다 단순하지 않았다. tokens/sec만 보면 작은 모델이 유리해 보이지만, 실제 응답 시간은 생성 토큰 수와 종료 여부에 크게 좌우됐다. 학습이 부족한 모델은 JSON을 다 출력하고도 불필요한 토큰을 계속 만들며 오히려 느려졌다. 작은 모델이 빠르려면 크기만 작아서는 부족하고, 원하는 형식으로 짧고 안정적으로 끝내는 것까지 돼야 했다.

6. 어려운 테스트셋에서 무너졌다

첫 결과만 보면 파인튜닝은 꽤 성공적으로 보였다. 그런데 더 어려운 테스트셋을 돌려보니 상황이 달라졌다. 어려운 셋에는 역순 표현, 외래어, 마케팅·인사·재무·법무 같은 다양한 도메인, 복합 조건이 더 많이 들어갔다.

 

 

주요 정보가 앞에 안 나오거나, 조건 순서가 바뀌거나, 낯선 도메인 표현이 섞이면 성능이 크게 떨어졌다. Round3 1.7B는 19%, Round4 0.8B도 27% 수준이었다. v1에서 90%를 넘겼던 것과 비교하면 큰 차이였다.

 

이 결과는 조금 아팠지만 중요한 사실을 보여줬다. 모델이 좋아진 게 아니라 테스트셋에 익숙해진 것일 수도 있다는 점이다. 학습 데이터와 비슷한 표현에서는 잘 동작하지만 순서나 도메인이 바뀌면 금방 흔들렸다. 그래서 v1 점수만 보고 실서비스 투입이 가능하다고 판단하는 건 위험했다.

7. 그래도 실패는 아니었다

그렇다고 이 실험이 실패였다고 보지는 않았다. 작은 모델이 질의처리 JSON을 안정적으로 뽑을 수 있다는 가능성은 확인했다. 자유로운 답변 생성이 아니라 정해진 스키마에 맞춰 검색 조건을 추출하는, 범위가 좁은 태스크라면 작은 모델도 꽤 잘했다.

 

다만 역할을 명확히 해야 했다. 이 모델이 곧바로 검색 품질을 개선한다고 말할 수는 없다. 질의처리 결과가 좋아졌다고 해서 최종 검색 결과가 좋아졌다는 뜻은 아니기 때문이다. 그건 다시 검색 테스트와 E2E 테스트로 확인해야 한다.

 

그래서 이 단계의 결론은 이 정도였다. 작은 모델로 질의처리기는 만들 수 있다. 하지만 검색을 완전히 맡기기보다, 룰 기반 질의처리기를 보완하거나 후보를 제안하는 역할이 더 현실적이다.

마치며

처음에는 프롬프팅만으로도 어느 정도 될 줄 알았지만 50%대에 머물렀고, 출력 스키마를 고정하고 실패 유형으로 데이터를 보강하며 파인튜닝한 끝에 Qwen3.5 0.8B가 96%까지 올라갔다. 작은 모델도 구조화 추출 태스크에서는 충분히 가능성이 있었다. 하지만 어려운 테스트에서는 27%로 떨어졌고, 그걸 보며 다시 처음 질문으로 돌아왔다. 무엇을 기준으로 좋아졌다고 말해야 할까?

 

질의처리 정확도가 올라간 것과 실제 검색 품질이 좋아진 건 같은 말이 아니다. 좋은 검색 품질은 질의처리 결과만으로 되지 않는다. 질의처리가 빨라야 하고, 핵심 키워드가 검색기에 잘 전달돼야 하고, 검색 대상 문서도 검색하기 좋은 형태로 정리돼 있어야 한다. 질의처리·검색기·문서 데이터가 함께 맞물려야 사용자가 체감하는 품질이 좋아진다.

 

결국 이번 시리즈는 검색 시스템을 개선한 기록이라기보다, "개선됐다"고 말하기 위한 기준을 하나씩 만들어간 과정에 가까웠다.