개발과 일상

지난 글에서는 검색기 앞단의 질의처리 방향을 어떻게 정리했는지 적었다.테스트 결과, 사용자의 질의를 그대로 검색하는 방식이 형태소분석 후 키워드만 넘기는 방식보다 조금 더 안정적이었다. 하지만 그렇다고 질의처리가 필요 없는 것은 아니었다. 검색 본문으로 사용할 표현은 최대한 보존하되, 날짜나 지역, 파일 타입, 기관명처럼 조건으로 다룰 수 있는 정보는 별도로 구조화하는 편이 더 적절해 보였다.결국 핵심은 LLM을 쓰느냐 마느냐가 아니었다.검색어로 남길 것, 필터 조건으로 분리할 것, 제거할 것을 나누는 기준이 더 중요했다.그렇다면 다음으로 정해야 할 것은 이 기준을 어떻게 테스트할 것인가였다.검색기는 정답 문서가 검색 결과 상위에 들어오는지를 보면 된다. 하지만 질의처리기는 정답 문서를 직접 찾는 컴포넌..

지난 글에서는 RAG 검색을 개선하기 전에 테스트 기준을 먼저 정리해야 했던 이유를 적었다.테스트 기준을 정리한 뒤 여러 방식으로 검색을 비교해보니, 검색기 자체에 큰 문제가 있다고 보기는 어려웠다. 정답 문서를 회수하는 능력은 어느 정도 안정적으로 나왔고, 검색 모델이나 벡터 DB 자체를 먼저 의심할 상황은 아니었다.오히려 눈에 띈 것은 검색기 앞단의 질의처리였다.같은 검색기를 쓰더라도 사용자 입력을 어떻게 해석하고, 어떤 형태로 검색기에 넘기느냐에 따라 결과가 달라졌다. 그래서 이번 글에서는 검색기 앞단의 질의처리 방향을 어떻게 정리했는지 적어보려고 한다. 1. 질의를 그대로 쓰는 편이 조금 더 나았다가장 먼저 비교한 것은 문장을 그대로 검색하는 방식과, 형태소분석 후 키워드만 넘기는 방식이었다.처..