목차
설계 전제와 문서 청킹
추출한 문서를 RAG에 연결할 때는 청크를 나누는 기준부터 정해야 합니다. 임베딩 모델과 벡터 데이터베이스를 준비한 뒤 검색·필터링·리랭킹 단계를 연결합니다. RAG는 문서 추출 → 청킹 → 임베딩 → 저장 → 검색 → 필터링 → 리랭킹 → LLM 생성 순서로 구성할 수 있습니다. 질문과 관련된 문서 조각을 먼저 찾고, 검색된 내용을 LLM에 컨텍스트로 전달해 근거 있는 답을 생성하는 구조입니다.
문서 청킹은 원문을 검색 가능한 단위로 나누는 단계입니다. 청크가 너무 작으면 맥락이 부족하고, 너무 크면 검색 결과에 불필요한 내용이 섞입니다. 일반적인 시작점으로는 청크당 256~512 토큰, 청크 사이 10~20% 정도를 겹치게(overlap) 자르는 방식이 널리 쓰입니다 — 문장이나 문단 경계에서 자르지 않으면 이 값을 지켜도 맥락이 끊길 수 있으므로, 실제로는 이 범위를 출발점으로 삼아 자신의 문서 구조에 맞게 조정하는 것이 안전합니다.
임베딩과 벡터 검색
임베딩 모델은 문장이나 문서를 숫자 벡터로 변환합니다. 선택할 때는 한국어 처리 품질, 문서와 검색어의 언어 조합, 벡터 차원, 처리 비용, 운영 환경을 함께 비교해야 합니다. 임베딩 모델은 문서를 검색 가능한 벡터로 바꾸고, 생성 모델은 검색된 내용을 바탕으로 답을 만드는 서로 다른 역할을 맡습니다.
검색 결과가 전혀 없으면 먼저 임베딩 생성과 인덱스 저장·반영이 정상적으로 이루어졌는지, 메타데이터 필터가 결과를 제외하고 있지 않은지 확인해야 합니다. 그다음 검색 설정과 검색어·문서의 언어 조합을 점검하고, 결과의 관련성이 낮다면 청킹 품질을 살펴봅니다.
메타데이터 필터링과 리랭킹
메타데이터 필터링은 문서 본문 외에 저장한 속성으로 검색 범위를 제한하는 방법입니다. 문서 유형, 작성일, 부서, 권한, 제품명 같은 값을 함께 저장하면 검색어와 관련 없는 영역을 먼저 제외할 수 있습니다. 필터 값이 실제 저장값과 다르면 유사도 검색 전에 결과가 모두 사라집니다. 원문과 저장된 메타데이터를 확인하고, 필터를 하나씩 해제해 어느 조건에서 결과가 0건이 되는지 점검해야 합니다.
리랭킹은 1차 벡터 검색 결과를 별도의 리랭킹 모델이 검색어와 청크의 관계에 따라 다시 정렬하는 단계입니다. 벡터 검색은 빠르게 후보를 찾고, 리랭킹은 후보의 문맥 적합도를 세밀하게 판단하는 역할을 맡습니다. 따라서 후보를 너무 적게 가져오면 리랭킹 모델이 좋은 문서를 검토할 기회가 줄어들고, 너무 많이 가져오면 비용과 지연 시간이 커집니다.
예를 들어 사내 운영 문서를 검색한다면 질문과 정답 근거가 담긴 문서 구간을 먼저 짝지어 평가 목록을 만듭니다. “서비스 재시작 절차는?”이라는 질문에 해당 절차가 들어 있는 청크가 상위 결과에 나타나는지 확인하고, 나타나지 않으면 문서 분할과 검색 조건을 점검합니다. 이 예시는 평가 방법을 설명하기 위한 가상의 사례입니다.
같은 질문 목록으로 청크 크기와 겹침을 바꿔 검색 결과를 비교하세요. 질문별 상위 결과에 정답 근거가 포함되는 비율과 응답 지연을 함께 기록하면, 청크가 커져 문맥은 늘었지만 검색 결과가 흐려지는 경우도 발견할 수 있습니다. 정답 근거가 검색되지 않은 상태에서는 리랭킹만 바꿔도 빠진 문서를 복구할 수 없습니다.
문서 ID와 버전, 원문 위치를 청크에 함께 저장하면 답변의 근거를 다시 확인하고 문서 갱신 시 오래된 청크를 교체하기 쉽습니다. Microsoft의 문서 분할 가이드는 문서 구조와 모델 입력 제한을 고려해 분할 크기를 정하도록 설명합니다. 메타데이터 필터는 검색 범위를 정하는 기능이므로, 접근 권한은 별도의 인증·인가 정책으로 확인해야 합니다.
문서 권한이 바뀔 때의 검색 점검
사내 문서 검색에서는 같은 질문이라도 사용자마다 볼 수 있는 문서가 다를 수 있습니다. 예를 들어 인사 문서는 인가된 사용자에게만 검색되도록, 요청자의 인증된 권한을 기준으로 검색 범위를 제한하세요. 권한 확인은 검색 화면의 선택값을 믿는 방식이 아니라 서버의 인증·인가 정책과 연결해야 합니다.
문서 접근 권한이 변경되면 검색 인덱스의 권한 정보와 기존 답변 캐시도 함께 점검하세요. 권한이 없는 시험 계정으로 해당 문서가 검색 결과와 생성 답변에 나타나지 않는지 확인하고, 접근을 허용한 계정에서는 필요한 근거가 검색되는지도 살펴봅니다. Microsoft의 검색 보안 필터 설명은 사용자·그룹 식별자에 따른 검색 결과 제한 방식을 다룹니다. 이는 가상의 점검 절차이며 특정 시스템에서 검증한 결과는 아닙니다.
결론
좋은 RAG 파이프라인은 문서를 청킹하고 임베딩해 저장한 뒤, 벡터 검색과 메타데이터 필터링으로 후보를 찾고 리랭킹으로 순서를 다듬는 구조입니다. 검색된 문서 조각은 LLM에 컨텍스트로 전달되며, LLM은 이를 근거로 답을 생성합니다.