사내 문서로 RAG를 붙이기 전에 정리할 4가지: 범위, 권한, 갱신, 평가 질문

사내 문서 검색에 RAG를 붙이자는 이야기가 나오면 보통 임베딩 모델과 벡터 DB부터 고릅니다. 그런데 프로젝트를 실제로 막는 건 그 앞 단계인 경우가 많습니다.

1. 범위: 어떤 문서를 넣을까

처음부터 전사 문서를 넣기보다, 질문이 많이 몰리는 영역 하나로 시작하는 편이 좋습니다. 인사 규정, 제품 FAQ, 개발 위키처럼 경계가 분명한 묶음이 좋습니다. 오래된 문서와 최신 문서가 섞여 있으면 답이 엇갈리니, 넣기 전에 폐기된 문서를 걸러 내세요.

2. 권한: 누가 무엇을 볼 수 있나

원래 문서 권한이 검색 결과에도 그대로 적용돼야 합니다. 권한이 다른 문서를 한 인덱스에 넣고 나중에 거르려고 하면 빠뜨리기 쉽습니다. 문서마다 권한 정보를 함께 저장하고, 검색 단계에서 거르는 구조를 먼저 정하세요.

3. 갱신: 문서가 바뀌면

문서가 수정·삭제됐을 때 인덱스에 언제 반영할지 정합니다. 매일 전체를 다시 넣을지, 바뀐 문서만 반영할지에 따라 구조가 달라집니다. 답변에 원문 링크와 수정일을 같이 보여 주면 사용자가 오래된 정보를 알아채기 쉽습니다.

4. 평가 질문: 무엇으로 판단할까

실제 사용자가 할 법한 질문 30~50개와 정답이 들어 있는 문서를 미리 모아 두세요. 모델이나 청크 크기를 바꿀 때마다 같은 질문으로 비교하면 감으로 고르는 일을 줄일 수 있습니다.

이 네 가지가 정해지면 청킹, 임베딩 모델, 리랭커 같은 기술 선택이 훨씬 쉬워집니다. 커뮤니티에 올라온 청킹·리랭커 비교 글도 함께 참고해 보세요.