회사 문서 검색 챗봇 만들면서 배운 것들 (RAG 삽질기)
사내 위키가 너무 방대해서 검색이 안 되는 문제를 해결하려고 RAG 기반 챗봇을 사내에 붙여봤습니다. 지금은 20명 정도가 쓰고 있는데, 삽질한 내용을 정리해두면 저 같은 분들께 도움이 될 것 같습니다.
첫 번째, 청킹 전략이 성능의 8할입니다. 처음엔 페이지만큼 잘라서 넣었는데 답변이 문맥을 놓치는 일이 많았어요. 제목과 소제목 기준으로 자르고, 잘린 조각 앞뒤로 문서 제목을 붙여주니까 확 좋아졌습니다.
두 번째, 임베딩 모델을 바꾸면 인덱스를 다시 만들어야 합니다. 이걸 대충 넘겼다가 3일 동안 이상한 답변을 디버깅했네요.
세 번째, 검색된 문서를 반드시 보여주세요. 사용자 신뢰가 완전히 달라집니다. 답이 틀려도 근거를 볼 수 있으면 쓸 만한 도구가 됩니다.
네 번째, 평가 데이터를 만들었어야 합니다. 그럴듯한 답변에 속아서 한참 헤맸습니다. 지금은 질문 100개 정도 만들어두고 배포 전에 돌립니다.
지금 남은 과제는 권한 처리입니다. 인사 문서랑 일반 문서가 한 인덱스에 섞여 있어서, 이 부분은 결국 별도 컬렉션으로 나눠야겠더군요. 비슷하게 사내 RAG 붙여보신 분들 경험 공유해주시면 좋겠습니다.
9 개의 답변
세 번째 진심 중요. 출처 안 보여주면 챗봇 답변을 아무도 안 믿어요
평가 질문 100개면 충분하다고 보세요?
근데 권한 처리를 '남은 과제'로 두고 이미 20명한테 오픈한 건 좀 위험하지 않나요? 인사 문서가 한 인덱스에 섞여 있다면서요. 사내 규정상 접근 권한 없는 문서가 검색 결과에 뜨는 것만으로도 문제될 수 있어서, 제 생각엔 이건 기능이 아니라 오픈 전 필수 조건입니다
청킹 얘기 좀 더 듣고 싶네요. 소제목 기준으로 자른다면 청크 간 오버랩은 어느 정도 주셨나요? 표나 이미지가 섞인 문서는 어떻게 처리하셨는지도 궁금합니다
오 이건 몰랐네요. 평가 데이터셋부터 만들어야겠다
청킹이 8할이라는 말 진짜 공감합니다ㅋㅋ 저희도 페이지 단위로 자르다가 문서 구조 살리니까 답변 퀄이 확 달라지더라구요
임베딩 모델 바꾸고 인덱스 재생성 안 해서 이상한 답 나오는 거 저도 겪었는데, 그거 진짜 원인 찾기 지옥이죠. 저희는 인덱스 생성 스크립트에 모델 이름이랑 버전 해시를 메타데이터로 박아두고 배포 때 체크하게 만들어서 그 뒤로는 안 겪었습니다. 참고하시면 좋을 듯
솔직히 이 정도는 RAG 한 번 만들어본 사람이면 다 아는 얘기 아닌가요? 특히 1번 2번은 기본 중의 기본이고... 권한 처리처럼 진짜 어려운 부분은 툭 던지고 끝나서 좀 아쉽네요
권한은 사후 필터링보다 사전 필터링이 답입니다. 검색 단계에서 사용자 ACL을 메타데이터 필터로 걸어버려야 해요. 결과 받고 나서 걸러내면 청크가 5개 검색됐는데 2개 날아가고 남은 걸로 답변 만들다 보니 품질이 널뛰더라구요. 저희는 문서 최상위 폴더 단위로 권한 그룹 매핑해서 붙였습니다