RAG Ingestion: 검색 실패 뒤에 숨은 병목 현상

Source: Dev.to

대부분의 팀은 검색 실패가 임베딩 모델이 충분히 강력하지 않거나, 검색기가 제대로 튜닝되지 않았거나, 프롬프트 설계가 미흡해서 발생한다고 생각합니다. 실제 현업 AI 시스템을 배포하는 과정을 도와오면서 저는 다른 현상을 보았습니다: 검색은 이미 인제션이 흐트러진 뒤에 오래도록 실패합니다.

• 누군가 나쁜 설계 선택을 해서가 아니라.
• 시스템이 충분히 정교하지 않아서가 아니라.
• 하지만 작고 반복적이며 차별화되지 않은 인제션 작업이 조용히 형태를 바꾸기 때문입니다.

이러한 인제션 실패는 깊은 전문 지식을 요구하지 않지만, 전체 워크플로우를 무너뜨립니다.

검색 실패의 진짜 원인: 인제션 드리프트

실제 RAG 시스템에서는 인제션이 상류에서 이루어집니다. 상류 텍스트가 잡음이 많거나, 일관성이 없거나, 구조적으로 손상돼 있다면, 하류의 모든 컴포넌트가 그 오류를 물려받게 됩니다.

흔한 인제션 드리프트 패턴

• 일관성 없는 추출 – PDF, HTML, Markdown, Confluence 등 서로 다른 포맷이 같은 규칙을 사용해도 텍스트를 다르게 추출합니다.
• 정규화 드리프트 – 사소한 공백/구두점 차이가 청크 경계를 깨뜨립니다.
• 헤딩 계층 붕괴 – 추출 도구가 H1 → H3 → H6을 같은 레벨로 평탄화해 의미 구조를 잃게 합니다.
• 혼합 인코딩 – 파일 유형에 따라 공백과 토큰 경계가 예측 불가능하게 이동합니다.
• 보이지 않는 아티팩트 – OCR 잡음, HTML 태그, 숨겨진 유니코드 문자 등이 텍스트를 조용히 오염시킵니다.
• 메타데이터 불일치 – 문서 메타데이터와 추출된 텍스트 간의 관계가 깨집니다.
• 문서 진화 – 새로운 버전의 문서는 오래된 버전의 임베딩과 거의 일치하지 않습니다.
• 불완전한 추출 – 테이블, 리스트, 구조화된 요소가 파이프라인 중간에 사라집니다.
• 일관성 없는 세그멘테이션 – 청크 경계는 깔끔한 구조에 의존하는데, 구조가 흐트러지면 모든 것이 흐트러집니다.

이 중 어느 하나도 고급 수준의 전문 지식을 요구하지 않지만, 관리하지 않으면 전체 검색 경험을 불안정하게 만듭니다.

인제션 드리프트 진단 방법 (조기 탐지 기법)

수년간 저는 전체 파이프라인을 재구축하지 않고도 드리프트를 빠르게 드러내는 신뢰할 수 있는 탐지 체크리스트를 구축했습니다.

제가 신뢰하는 조기 탐지 체크리스트

• 지난 주 추출 결과와 이번 주 추출 결과 비교 – 드리프트는 검색에 영향을 주기 전에 diff에서 나타납니다.
• 헤딩 깊이 검사 – 붕괴되거나 예상치 못한 헤딩 점프가 RAG 드리프트를 예고합니다.
• 토큰 수 변동 모니터링 – 급격한 변화는 거의 항상 인코딩 드리프트를 의미합니다.
• 동일 파일에 두 개의 추출기 적용 – 구조가 일치하지 않으면 인제션이 불안정함을 나타냅니다.
• 빈 섹션 찾기 – 빈 섹션 = 부분적 혹은 실패한 추출.
• 테이블/리스트 보존 여부 확인 – 사라진 테이블은 답변 품질을 저하시킵니다.
• 샘플 문서를 주간 재임베드 – 주간 벡터 거리 비교; 이동이 있으면 인제션이 변한 것입니다.

이 단계들은 어떤 검색 디버깅보다 빠르게 진실을 밝혀줍니다.

RAG 파이프라인을 안정화하는 마이크로‑수정

실제 운영 팀에 반복적으로 권장해 온 실용적이고 고급 수준의 수정 사항들입니다.

드리프트를 줄이는 수정 방법

• 단일 추출 표준 강제 – 동일한 툴체인, 동일한 버전 사용; 혼합 추출기 금지.
• 정제 전에 숨은 문자 제거 – 보이지 않는 아티팩트가 임베딩에 들어가는 것을 방지합니다.
• 헤딩 계층 정규화 – 구조를 보존하고, 붕괴되거나 일관성 없는 헤딩을 수정합니다.
• 초기에 인코딩 안정화 – 모든 파일을 시작 단계에서 UTF‑8로 변환합니다.
• 테이블을 일급 요소로 취급 – JSON이나 Markdown으로 추출하고, 절대 무시하지 않습니다.
• 인제션 파이프라인 버전 고정 – 버전 드리프트 = 인제션 드리프트.
• 모호하거나 잘못된 구조 거부 – 파일 구조가 손상됐을 경우 파이프라인을 조기에 중단합니다.
• 주간 체크섬으로 인제션 드리프트 추적 – 간단한 MD5/SHA 체크섬으로 초기 구조 드리프트를 포착합니다.
• 텍스트 동일성 확인 후 재청크 – 새로운 텍스트가 지난 주와 일치하는지 검증한 뒤에만 재청크합니다.

이러한 수정은 제가 RAG 배포에서 보는 “신비한” 검색 실패의 80 % 이상을 차단합니다.

인제션이 재앙이 되는 경우

일부 인제션 실패는 검색 품질을 완전히 파괴합니다. 가장 흔히 보는 패턴은 다음과 같습니다:

• 복잡한 레이아웃이나 일관성 없는 OCR을 가진 PDF.
• 예측 불가능하게 추출되는 깊게 중첩된 HTML 콘텐츠.
• 다중 포맷 문서(Markdown + HTML + Confluence).
• 주간 업데이트되지만 재인제션되지 않는 문서.
• 테이블이나 메타데이터가 자주 변동되는 지식 베이스.

이러한 엣지 케이스가 발생하면 시스템을 재구성해야 합니다—단순히 튜닝만으로는 부족합니다.

인제션을 과도하게 엔지니어링하지 말아야 할 때

데이터셋이 작고, 정적이며, 업데이트가 거의 없을 경우 수동 정제와 추출이 더 간단할 수 있습니다. 그러나 데이터가 지속적으로 변화하거나 다중 포맷이라면 인제션 일관성이 필수입니다.

최종 정리

검색이 먼저 깨지는 경우는 드뭅니다.
인제션이 먼저 깨집니다.

인제션 파이프라인이 안정될수록 모델이나 검색기 변경에 관계없이 RAG 시스템의 동작이 예측 가능해집니다.