개발과 일상

파인튜닝 글에서 작은 LLM으로 질의처리기를 만들어봤지만, 표준 어순에선 잘 되다가 변형에서 무너졌고 결국 곁가지로 남았다고 적었다. 그러면 본선 질의처리기는 어떻게 됐을까. 결국 LLM을 걷어내고 규칙 기반으로 다시 만들었다. 사실 질의처리 글에서 이미 답이 나와 있었다 — 질의처리의 핵심은 LLM을 쓰느냐가 아니라, 검색어·필터·제거를 나누는 기준이라는 것. 이 글은 RAG 구축 고려사항 중 질의 강화·키워드 추출의 마지막 매듭이다.1. 왜 다시 규칙이었나LLM으로 질의를 처리하면 깔끔해 보인다. 그런데 검색 본경로에 두기엔 세 가지가 걸렸다. 1. 호출이 느렸고,2. 같은 질의에 매번 결과가 조금씩 달라졌으며(비결정성)3. 파인튜닝으로 정확도를 올려도 학습에 없던 표현에서 흔들렸다(오버피팅). 돌아..

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

지난 글에서는 검색을 개선하기 전에 평가셋부터 다시 짜야 했던 이유를 적었다. 이번 글은 RAG 구축 고려사항 중 질의 강화·키워드 추출에 해당한다. 결론부터 말하면, 질의를 키워드로 바꾸는 게 오히려 검색을 깎아먹었다.검색기를 의심했는데, 검색기 문제가 아니었다검색 품질이 아쉬우면 가장 먼저 검색기를 의심하게 된다. 나도 그랬다. 임베딩 모델을 바꿔보고, 인덱싱 방식을 손보고, 청크 크기를 조절하며 며칠을 보냈다. "검색이 약하니 검색기를 강하게 만들면 되겠지"라는 게 당연한 출발점이었다. 그런데 평가셋을 정리하고 나서, 검색기는 그대로 둔 채 질의를 넘기는 방식만 바꿔 같은 조건에서 비교해봤다. 원질의를 그대로 검색할 때, 키워드만 추출해 넘길 때, 추출한 키워드를 확장해 넘길 때. 결과는 예상과 정..