FEMS 프로젝트 #2 에서 230 페이지 코퍼스로 RAG 를 돌려보면서 의문이 생겼다.
- 벡터 DB 에 넣을 데이터를 어떻게 선정하고 정제하는가?
- 아날로그 데이터를 스캔해서 쓴다면 파일 제목을 붙이는 게 중요한가?
찾아본 결과를 RAG 데이터 파이프라인 전체 흐름으로 정리한다.
Table of contents
Open Table of contents
Garbage in, garbage out — LLM 도 예외 없음
RAG 파이프라인에서 가장 중요하고 손이 많이 가는 단계가 데이터 준비 라고 한다. 모델 / 임베딩 모델 / 벡터 DB 를 고르는 것보다 데이터의 품질이 결국 결과를 결정 한다는 흐름이다.
이전 회사에서 efficient-det 을 전이학습해 화재 감지 모델 을 만든 적이 있다. 그런데 데이터셋이 잘못된 방법으로 증강되어 중복된 사진 이 많이 들어갔다. 결과:
- 검증 (validation) 점수 높음 — 사실상 같은 사진을 외운 셈이다
- 테스트 (test) 점수 거의 0 — 새 사진에는 일반화가 안 된다
비전 모델 시절에 손가락에 박힌 교훈인데, LLM / RAG 에도 그대로 적용된다. 어떤 모델을 쓰든 데이터가 엉망이면 답도 엉망이다.
1. 데이터 선정 — “검색되어야 할 질문” 기준으로 거꾸로
처음엔 단순히 “도메인 관련 데이터들을 다 넣으면 되겠지” 라고 생각했다. 그런데 그게 아니었다.
핵심: “검색되어야 할 질문” 을 기준으로 거꾸로 선정한다.
실제 서비스가 가동된다고 가정하고 어떤 형태로 서비스될지, 어떤 질문이 들어올지 를 미리 상상해본다. 그러면 자연스럽게 “이 질문에 답하려면 어떤 데이터가 필요한가” 가 잡힌다.
도메인 기준으로 무작정 다 넣으면 노이즈가 늘어나고, 검색 결과도 흐려진다. 질문이 먼저, 데이터가 나중이다.
선정할 때 보는 기준
| 기준 | 체크 포인트 |
|---|---|
| 정확성·신뢰성 | 최신 버전인가, 공식 승인된 문서인가 |
| 중복 여부 | 같은 내용이 여러 문서에 흩어져 있으면 검색 시 비슷한 청크만 나온다 |
| 밀도 | 정보가 거의 없는 표지 / 목차 / 빈 양식은 노이즈가 된다 |
| 시의성 | 시간이 지나면 달라지는 정보 → 갱신 주기를 정한다 |
FEMS #2 에서 만들었던
readable_ratio품질 게이트가 위 표의 “밀도” 기준의 자동화된 부분에 해당한다.
2. 클렌징 (Cleansing) — 자동 + 사람 검수
데이터 정제는 크게 둘로 나뉜다:
- 클렌징 — 텍스트 자체를 깨끗하게
- 청킹 — 의미 단위로 자르되 약간 오버랩
클렌징은 다 수작업인가?
No. 대부분 툴/코드로 자동화하고 사람은 검수 역할 을 한다.
자동 처리 대상:
- 반복 문구 — 페이지 번호, 머리말/꼬리말, “Confidential” 같은 워터마크
- 깨진 특수문자, 잘못된 줄바꿈 — 정규식 / 간단한 규칙으로
도구로 처리 가능:
- PyMuPDF — PDF 파싱
- LangChain / LlamaIndex — 클렌징 단계 추상화
- LLM 자체 — “이 텍스트를 정리해줘” 식 호출. 비싸지만 정확하다
사람이 해야 하는 부분
- 어떤 패턴을 노이즈로 볼지 정의 — 도메인 따라 다르다
- 메타데이터 채우기 (다음 항목)
- 자동 클렌징 결과 샘플 검수
자동화가 핵심이지만 샘플 확인은 반드시 사람이 해야 한다.
3. 메타데이터 — 청크 앞에 문서 제목·섹션 경로 붙이기
파일 제목도 메타데이터의 일종이다. 메타데이터의 역할:
- 검색 필터링 — “이 부서 문서만”, “이 연도만” 같은 조건
- 청크의 컨텍스트 복원 — 청크만 달랑 있으면 LLM 이 “어디에 붙어있던 내용인지” 파악하기 곤란하다
핵심 트릭: 청크 앞에 문서 제목이나 섹션 경로를 prefix 로 붙이면 임베딩 품질 + 검색 정확도가 눈에 띄게 상승한다.
예:
원본 청크:
"베이스라인 기간을 ECM 시행 전 일정 기간으로 설정합니다..."
prefix 적용:
"[fems_mv_guideline.pdf > 3. M&V 절차 > 3.1 베이스라인 기간 설정]
베이스라인 기간을 ECM 시행 전 일정 기간으로 설정합니다..."prefix 만 다르고 본문은 동일한데, 임베딩 벡터가 더 풍부한 의미를 담게 된다. “M&V” 같은 키워드가 청크 본문엔 없어도 prefix 에 있으면 매칭된다.
→ FEMS #2 에서 만든 코퍼스에도 이걸 적용하면 검색 품질이 더 올라갈 것 같다.
4. 아날로그 데이터 처리 — OCR + 전처리 + 검수
스캔한 종이 문서를 RAG 에 넣어야 할 수도 있다:
기본 흐름
스캔 이미지 → (이미지 전처리) → OCR → (텍스트 검수) → 메타데이터 부여 → 청킹단계별 주의
- 스캔 품질이 나쁘면 OCR 오류가 그대로 서비스 품질에 반영된다 — 그래서 OCR 전에 이미지 전처리 (회전 보정 / 명암 / 노이즈 제거) 가 필요한 케이스가 있다
- OCR 결과 검수 필수 — 자동화의 한계다
- 메타데이터 부여 단계가 필수 — 스캔 파일은 보통 제목이 날짜 (
scan_20240612.pdf) 같은 식이라 그 자체로는 검색 가치가 0이다
인식 품질 자동 탐지
전수 검사는 비효율적이라 자동 탐지로 1차 필터링 후 의심 페이지만 수동으로 검수한다.
| 자동 탐지 방법 | 설명 |
|---|---|
대체 문자 (�, □) 탐지 | OCR 실패 흔적 — 가장 기본 |
| 한글 자모 분리 탐지 | ”한국어” → “ㅎㅏㄴㄱㅜㄱㅓ” 같은 분리 케이스 |
| 사전 일치율 | 추출 텍스트를 한국어 사전에 매칭. 비율 낮으면 OCR 실패 의심 |
| OCR 엔진 신뢰도 | Tesseract 등은 단어/문자별 confidence score 제공 |
자동 탐지에서 의심 페이지는 전수 검수, 나머지는 무작위 샘플링 으로 전체 품질을 추정한다.
5. 데이터 품질 관리 — 한 번 하고 끝이 아니다
데이터 준비는 루프 로 운영한다. 한 번 인덱싱하고 끝이 아니라:
평가셋 구축
질문 - 정답 쌍을 만들어둔다. 청킹 전략이나 임베딩 모델을 바꿀 때마다 검색 정확도를 즉시 측정 가능하도록 한다.
이게 없으면 “임베딩 모델을 바꿨는데 답이 더 좋아진 건가? 더 나빠진 건가?” 가 감으로만 판단되는데, 평가셋이 있으면 숫자로 비교 할 수 있다. 퀀트 글의 회고 에서 깨달은 “느낌 벤치마킹 → 수치 벤치마킹” 흐름과 같은 얘기다.
그 외 지속 관리 항목
- 검색 결과 모니터링 — 실제 사용 로그 주기적 확인
- 갱신·버전 관리 — 문서 바뀌면 기존 임베딩을 어떻게 교체할지 정책
- 중복 / 노이즈 정기 점검 — 시간이 지나면 새로 쌓인다
전체 흐름 요약
위에서 다룬 단계들을 한 줄로:
선정 → 클렌징 → 청킹 → 메타데이터 부여 → 임베딩 → 평가셋 → (개선 루프)
한 번 하고 끝이 아니라 평가셋을 기준으로 반복 개선 하는 운영이다.
회고
가장 인상 깊은 깨달음 두 가지:
- “검색되어야 할 질문” 기준으로 거꾸로 선정 — 도메인 다 모으기 ≠ 좋은 RAG. 질문이 먼저다.
- 청크 앞에 문서 제목·섹션 경로 prefix — 코드 한 줄 추가로 검색 품질이 의미 있게 오르는 trick 이다.
FEMS #2 의 코퍼스도 prefix 패턴 + 평가셋 구축을 적용해보면 결과가 어떻게 달라질지 궁금해진다.
더 공부해볼 것
1. 청크 prefix 효과의 정량 측정
- 동일 코퍼스 / 질문셋 / 임베딩 모델로 prefix 있음 vs 없음 A/B
- 1순위 매칭 dist 변화 / top-3 적중률 변화
- 어느 깊이의 섹션 경로까지 포함하는 게 최적인가 (제목만 / 제목+섹션 / 전체 path)
2. 평가셋 구축 방법론
- 수작업 vs LLM 생성 — LLM 으로 질문 자동 생성하면 셋 자체가 편향
- Ground truth 를 누가 어떻게 정하는가
- RAGAS / TruLens / DeepEval 같은 RAG 평가 프레임워크 비교
- 검색 정확도 (Hit Rate, MRR, NDCG) vs 응답 품질 (Faithfulness, Answer Relevance) 의 분리
3. 청킹 전략 심화
- Fixed-size / Recursive / Semantic / Sentence-window — 도메인별 최적
- Overlap 의 적정 비율 (0 / 10% / 20%)
- Hierarchical retrieval — 작은 청크 + 큰 청크 두 단계 검색
- 한국어에 특히 잘 맞는 split point (조사 / 어미 경계)
4. OCR 파이프라인
- Tesseract vs PaddleOCR vs EasyOCR vs 클라우드 OCR (Naver CLOVA / Google Document AI) 한국어 성능 비교
- 레이아웃 분석 — 표 / 그림 / 다단 텍스트 처리
- 이미지 전처리 — deskew / binarize / denoise 의 효과
- 스캔 PDF → 텍스트 PDF 변환 후 pypdf 로 처리하는 우회 패턴
5. 메타데이터 활용 패턴
- Self-Query Retrieval — LLM 이 질문에서 메타데이터 필터를 자동 추출 (예: “2024년 자료만” → year=2024)
- Hybrid Search — 벡터 + 메타데이터 필터 + 키워드 BM25
- 메타데이터 스키마 설계 — 너무 많으면 채우기 부담, 너무 적으면 필터를 걸 수 없다
6. 데이터 버전 관리
- 문서 v1 → v2 업데이트 시 기존 임베딩 어떻게 처리
- 청크 단위 diff → 변경된 청크만 재임베딩
- 시점별 RAG 답변 일관성 (legal 영역에서 중요)
- DVC / LakeFS 같은 데이터 버전 관리 도구