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