개발과 일상

BM25로 키워드 검색을 뜯어본 것부터 시작해서, 평가셋, 질의처리기, 하이브리드 검색, 한국어 임베딩, 리랭커까지 왔다. 검색 하나를 붙들고 꽤 오래 적은 셈이다. 검색 개선기를 완결 짓기 전에 한 번 정리해두려고 한다. 뭘 만들었고, 뭐가 아쉬웠고, 다음은 어디로 갈 것 같은지도 생각해봤다.결과물최종 결과물은 온디바이스에서 도는 RAG 기반 검색기를 만들었다. 별도의 온프렘/클라우드 서버는 없고 사용자 기기 안에서 돌아가는 구조라, 2B급 소형 모델을 중심으로 붙였다. 개선기에 적어둔 것들이 그 안에 하나씩 들어가 있다. 전체를 늘어놓으면 이런 구조다.질의 "지난달 회의 자료" │ ├ 질의처리 슬롯(기간·종류)과 키워드로 쪼갠다 │ ├ 1차 검색 키워드(BM25) ─┐ ..

지난 글에서는 질의처리기를 테스트하기 위한 테스트셋을 어떻게 만들었는지 정리했다. 테스트셋을 만들고 나니 다음 질문이 생겼다. 이 테스트셋을 기준으로 작은 모델을 학습시키면, 룰 기반 질의처리기를 대체하거나 보완할 수 있을까? 검색 본경로에 큰 LLM을 그대로 넣기는 어려웠다. 프롬프팅만으로 질의처리를 맡겼을 때 정확도는 50%대에 머물렀고, 온디바이스 환경에서는 속도 부담도 컸다. 하지만 질의처리 작업 자체는 범위가 비교적 명확했다. 사용자의 입력에서 검색 키워드·날짜·파일 타입·작성자·경로 같은 정보를 JSON으로 뽑아내면 된다. 자유로운 답변을 생성하는 것보다 훨씬 좁은 문제였다. 그래서 작은 모델을 이 작업에 맞게 파인튜닝해보면 어떨까 생각했다. 이번 글은 RAG 구축 고려사항 중 모델 양자화에도..