'30% 향상'이라는 숫자, 어디서부터 시작됐나요?
항공 정비 문서를 대상으로 RAG(Retrieval-Augmented Generation) 시스템을 구축한 사례(dev.to, Beyond Keywords)가 흥미로운 수치를 제시합니다. BM25 단독 검색 대비 재현율(Recall) 30% 향상, 벡터 검색 단독 대비 정밀도(Precision) 25% 향상. 수치만 보면 하이브리드 검색과 RRF(Reciprocal Rank Fusion)의 조합이 꽤 매력적입니다. 그런데 저는 이 숫자를 보자마자 첫 번째 질문이 떠올랐습니다. 베이스라인은 어떻게 정의됐고, 테스트셋 샘플 사이즈는 충분했나요?
하이브리드 검색의 구조: 왜 BM25 혼자는 부족한가
이 사례의 핵심 아키텍처는 세 가지 검색 신호를 결합하는 방식입니다. BM25는 'APU', 'master warning' 같은 정확한 용어 매칭을 담당하고, 벡터 임베딩(all-MiniLM-L6-v2, 384차원)은 의미적으로 유사한 절차를 포착합니다. 여기에 파트 번호·섹션 메타데이터 필터링이 추가 부스팅 역할을 합니다. RRF는 세 신호의 순위를 단순 점수 합산이 아닌 역순위 합으로 통합해, 어느 한 신호가 압도적으로 높은 스코어를 가져도 결과가 왜곡되지 않도록 설계됩니다.
기술적으로는 타당한 접근입니다. 하지만 Ablation study가 공개되지 않은 상태에서 '30% 향상'이 BM25→하이브리드 전환 덕분인지, 청킹 전략(800 토큰, 120 오버랩) 최적화 덕분인지, 아니면 단순히 임베딩 모델 선택 덕분인지는 분리해서 측정하기 어렵습니다. 각 컴포넌트의 기여도를 독립적으로 검증하는 ablation이 없다면, 이 숫자는 상관관계일 뿐 인과관계가 아닙니다.
그런데 진짜 문제는 검색 알고리즘이 아닐 수 있습니다
공급망 S&OP 데이터 파이프라인 사례(dev.to, Why Your Excel Is Lying to You)는 완전히 다른 도메인에서 같은 교훈을 전달합니다. ERP에서 export된 원시 데이터에는 '100단위 주문이 100,000단위로 입력된 오타', 날짜 컬럼에 텍스트로 저장된 값, 공백 셀이 일상적으로 존재합니다. 이 '노이즈'가 예측 알고리즘에 그대로 투입되면 Bullwhip 효과처럼 오차가 증폭됩니다.
이 사례가 제시하는 해법은 Z-Score 기반 이상치 탐지입니다. 판매 수량의 Z-Score가 3 초과(평균으로부터 3σ 이상)인 데이터 포인트를 삭제하는 대신 플래그를 달아 예측에서 제외하고 사람이 검토하도록 유도합니다. 주목할 점은 저자 스스로 한계를 명시한다는 겁니다. "간헐적 수요처럼 정규분포를 따르지 않는 경우, IQR이나 MAD(Median Absolute Deviation)가 더 robust합니다." 이런 맥락 인식이 있어야 실제 프로덕션에서 쓸 수 있는 파이프라인이 됩니다.
두 사례가 함께 가리키는 맹점: 데이터 품질이 모델 성능의 천장입니다
항공 정비 RAG 시스템과 공급망 데이터 파이프라인은 도메인이 전혀 다르지만, 동일한 구조적 취약점을 공유합니다. 입력 데이터의 품질이 보장되지 않으면, 아무리 정교한 검색 알고리즘도 garbage-in-garbage-out을 피할 수 없습니다.
RAG 사례의 Python 인제스천 파이프라인을 보면, PDF에서 텍스트를 추출하는 extract_text_by_page 함수가 PyPDF2를 사용합니다. 항공 정비 매뉴얼처럼 도식, 테이블, 다단 레이아웃이 많은 문서에서 PyPDF2의 텍스트 추출 품질은 상당히 불안정합니다. 섹션 메타데이터를 정규식으로 추출하는 infer_section, infer_chapter 함수도 실제 매뉴얼의 포맷 다양성을 얼마나 커버하는지 검증 데이터가 없습니다. 임베딩 전에 텍스트 품질 분포를 확인하셨나요? 청크별 길이 분포, null 비율, 섹션 추출 성공률은 측정됐나요?
프로덕션에서 이 성능이 유지될까요?
두 사례 모두 오프라인 실험 환경의 성능을 보고합니다. 그러나 실제 운영 환경에서는 다른 변수들이 개입합니다.
- 데이터 드리프트: 항공 매뉴얼은 개정됩니다. 새 버전 문서가 인덱스에 추가될 때 기존 임베딩과의 분포 차이를 모니터링하고 있나요?
- 쿼리 분포 변화: 실제 정비사가 입력하는 질문 패턴이 테스트셋과 다를 경우 재현율 30% 향상이 유지된다는 보장이 없습니다.
- 임베딩 모델 버전 관리: all-MiniLM-L6-v2가 업데이트될 경우 기존 인덱스와의 임베딩 공간 불일치(embedding space mismatch)가 발생합니다. 재인덱싱 전략이 준비되어 있나요?
- 이상치 임계값의 적합성: Z-Score 3σ는 정규분포 가정 하에 약 0.3%의 데이터를 플래그하는 기준입니다. 실제 비즈니스 맥락에서 이 임계값이 적절한지는 도메인 전문가와 함께 검증해야 합니다.
시사점: 데이터 파이프라인은 MLOps의 '첫 번째 관문'입니다
두 사례가 공통적으로 제안하는 아키텍처 원칙이 있습니다. 단일 진실 공급원(Single Source of Truth)을 중심에 두고, 데이터가 저장소에 들어오기 전에 통계적 검증을 거치는 'Quality Valve' 구조입니다. S&OP 사례에서는 Supabase + Row Level Security로 이를 구현했고, 항공 RAG 사례에서는 Elasticsearch 인덱스가 그 역할을 담당합니다.
그런데 여기서 한 가지 더 물어볼 수 있습니다. 이 Quality Valve 자체의 성능은 어떻게 측정하나요? 이상치 탐지의 Precision과 Recall은 측정됐나요? 정상 데이터를 이상치로 잘못 분류하는 False Positive Rate는요? 데이터 정제 레이어도 결국 하나의 분류 모델입니다. 평가 지표 없이 신뢰하기는 어렵습니다.
전망: '데이터 중심 AI'로의 전환이 가속됩니다
RAG 성능 지표 경쟁과 데이터 파이프라인 자동화는 서로 독립적인 흐름처럼 보이지만, 결국 같은 방향을 가리킵니다. 모델 아키텍처보다 데이터 품질이 실제 프로덕션 성능을 결정하는 비중이 훨씬 크다는 현실 인식이 확산되고 있습니다.
'SOTA 달성'이라는 레이블보다 중요한 질문은 이것입니다. 내 데이터 파이프라인은 얼마나 깨끗한가? 이상치 탐지 로직의 재현 가능성은 보장되어 있나요? 임베딩 인덱스의 데이터 드리프트를 자동으로 감지하는 모니터링이 붙어 있나요?
하이브리드 검색의 RRF 파라미터를 튜닝하기 전에, 먼저 Jupyter에서 df.describe()와 df.isnull().sum()을 실행해보세요. 그 출력이 당신의 RAG 성능 향상폭을 이미 결정하고 있을 가능성이 높습니다.