사내 문서 검색 RAG 만들다가 3주 날린 이야기
사내 위키 문서가 8000개쯤 되는데 검색이 너무 구려서 RAG로 똑똑한 검색기 만들어볼까 하고 시작했습니다. 결과부터 말하면 지금 절반쯤 성공했습니다. 삽질 기록 공유합니다.
먼저 크롤링. 위키가 사내망이라 접근 권한부터 막혔고, 결국 API 뚫어서 가져오는 데만 일주일 걸렸습니다.
그다음이 문제였어요. 문서를 그냥 잘게 쪼개서 임베딩했더니 청크가 문맥을 다 잃어가지고, '휴가 규정'을 물어보면 권한 신청 하는 문서만 퍼오더군요 ㅋㅋ 결국 문서 단위로 제목·헤딩까지 메타데이터로 붙여서 다시 인덱싱했습니다.
이렇게 고치니까 확실히 답변 품질이 올라가더라고요. 결론은 임베딩보다 전처리가 8할이라는 것.
지금은 리랭커 붙이는 작업 중인데 이것도 또 어떤 지옥이 펼쳐질지 모르겠습니다. 혹시 사내 RAG 하신 분들 청크 사이즈랑 프롬프트 어떻게 잡으셨는지 조언 좀 해주세요.
7 개의 답변
오 이건 몰랐네. 임베딩보다 전처리가 8할이라니 메모해둬야겠다
청크 사이즈는 문서 성격마다 다르긴 한데 저는 512토큰에 오버랩 20%로 잡고 헤딩 경로를 청크 앞에 텍스트로 박아넣었습니다. 예를 들면 '[인사규정 > 휴가 > 연차] 본문...' 이런 식으로요. 이거 하나로 '휴가 규정' 같은 애매한 질의 매칭률이 확 올라가더라고요. 리랭커는 bge-reranker 계열로 시작하시면 무난합니다
글쎄 그건 좀... 전처리 8할이라는 거 결국 그냥 메타데이터 잘 붙였다는 얘기 아닌가요? 임베딩 모델 바꿔가면서 비교한 수치가 있는지 궁금하네요. 체감이랑 실제 지표는 다를 수 있으니까요