RAG 적재(ingest) 플레이북: 문서 업로드 → 임베딩 → 검색 인덱스

RAG의 품질은 “프롬프트”보다 적재(ingest) 품질이 더 크게 좌우합니다.

• 문서가 너무 길면 검색이 흐려지고
• 문서가 너무 짧으면 문맥이 끊기며
• 문서가 더러우면(광고/네비/중복) 답변이 이상해집니다.

이 문서는 운영 환경에서 “검색이 되는 RAG”를 만들기 위한 적재 체크리스트입니다.

0) 먼저: 넣으면 안 되는 것(익명화/시크릿)

RAG는 “문서가 서비스로 흘러 들어가는 통로”입니다.

• .env, API 키, DB 패스워드, 토큰 등 시크릿
• 실사용자 이메일/전화/주소 등 PII
• 내부 경로/서버 설정 중 외부 공개하면 위험한 내용

은 적재 전에 반드시 제거/치환하세요.

1) 문서 원천을 타입별로 나누기

예시:

• service_index: 운영 가이드/표준 운영 절차(SOP)처럼 “정확도가 중요한” 문서
• text_index: 일반 노트/로그/긴 문서처럼 “폭이 중요한” 문서

검색 시에는 보통 service_index를 우선하고, 부족할 때만 text_index를 보조로 쓰는 게 안정적입니다.

2) 전처리(HTML → 텍스트, 중복 제거)

권장 목표:

• 메뉴/푸터/사이드바 같은 반복 요소 제거
• 본문만 남기기
• 제목/섹션 헤딩을 메타데이터로 보존

3) 청킹(Chunking) 기본값

정답은 없지만, 시작점으로 쓸 수 있는 기준입니다.

• 청크 길이: 300800 토큰(또는 1,5003,000자) 정도
• 오버랩: 10~20% (문맥 끊김 완화)
• 청크 메타데이터: { sourcePath, title, heading, chunkIndex }

4) 임베딩 저장(필수 메타)

최소한 아래는 남겨두는 것을 추천합니다.

• source(파일 경로/문서 ID)
• title(사람이 이해할 수 있는 이름)
• text(청크 본문)
• embedding(벡터)
• created_at, updated_at
• collection(인덱스 분리 키)

5) 업데이트 전략(증분 적재)

문서는 계속 바뀝니다.

• 파일 해시/수정시간을 기록
• 변경된 문서만 재청킹/재임베딩
• 삭제된 문서는 인덱스에서도 제거

“드라이런 모드”를 만들어, 실제 저장 전에 대상/개수/예상 비용을 확인하는 걸 추천합니다.

6) 품질 확인(최소 체크)

• 대표 질문 10~20개를 뽑아 “참고 문서”가 제대로 잡히는지 확인
• 중복/유사 청크가 너무 많지 않은지 확인
• 모델이 근거 없는 말을 할 때, 어떤 문서가 원인인지 역추적 가능해야 함

같이 보면 좋은 문서:

• RAG 보안: 프롬프트 인젝션(문서 지시문) 방어하기
• Structured Data(JSON‑LD) (문서 메타를 구조화하는 관점)