내부 지식 에이전트 구축 시 엔지니어링 시간의 70%가 데이터 수집에 소요되는 현실

커뮤니티 반응

작성자의 경험에 깊이 공감하며, 많은 엔지니어들이 RAG의 실질적인 병목 현상이 데이터 파이프라인에 있다는 점에 동의하고 있습니다.

주요 논점

01찬성다수

RAG 시스템의 실질적인 가치는 데이터 수집 파이프라인의 견고함에서 나온다

합의점 vs 논쟁점

합의점

데이터 수집은 일회성 작업이 아닌 지속적인 유지보수가 필요한 영역이다
상용 파싱 도구만으로는 기업 내부의 특수한 문서 형식을 완벽히 처리하기 어렵다

논쟁점

자체 파이프라인 구축과 Denser 같은 관리형 서비스 이용 사이의 효율성 비교

실용적 조언

RAG 구축 시 검색 알고리즘보다 데이터 소스별 버전 관리와 파싱 예외 처리에 더 많은 리소스를 할당하라
OCR 결과물에 대한 유효성 검사 로직을 추가하여 잘못된 데이터가 임베딩되는 것을 방지하라

섹션별 상세

전체 엔지니어링 시간의 70%가 데이터 수집 및 전처리에 투입되었으며 검색 튜닝은 15%에 불과했다. SharePoint, Confluence, Notion 등 파편화된 소스마다 서로 다른 파서와 업데이트 주기가 필요하여 통합 관리가 매우 어렵다. 이는 RAG 구축 시 기술적 난이도가 모델 선택보다 데이터 파이프라인 구축에 집중되어 있음을 시사한다.

스캔된 PDF 문서의 OCR 처리 과정에서 표가 많은 페이지의 경우 약 12.5%(8건 중 1건)의 확률로 인식이 실패한다. 잘못 인식된 텍스트가 그대로 임베딩되어 검색 레이어에 저장되면서 시스템 전체의 신뢰도를 떨어뜨리는 '조용한 실패'가 발생한다. 상용 도구로 해결되지 않는 특수 문서 파싱을 위해 결국 자체 코드를 작성해야 하는 상황이 빈번하다.

검색 알고리즘은 완벽하게 작동했음에도 불구하고 최신 문서가 아닌 폐기된 문서를 참조하여 오답을 내놓는 사례가 발생했다. 이는 검색(Retrieval)의 문제가 아니라 문서의 버전 관리와 동기화가 포함된 수집 파이프라인의 문제이다. 시스템 설계 시 수집을 일회성 작업이 아닌 지속적인 상태 동기화 과정으로 정의해야 한다.

파편화된 소스의 멀티 소스 풀링과 버전 추적을 위해 Denser를 도입하여 파이프라인을 관리했다. 기존의 많은 RAG 논의가 청킹이나 임베딩 모델 선택에만 집중하는 것과 달리, 실무에서는 데이터의 최신성을 보장하는 오케스트레이션 레이어가 더 중요하다. 재처리 로직과 예외 처리를 해결하는 것이 시스템 안정성의 핵심이다.

용어 해설

데이터 수집 및 전처리(Ingestion): — 외부 소스의 데이터를 LLM이 처리할 수 있는 형태로 변환하여 시스템에 입력하는 과정이다. 소스 연결, 파싱, 청킹, 임베딩 단계를 포함하며 실무에서는 데이터의 최신성 유지와 품질 관리가 가장 큰 도전 과제이다.
광학 문자 인식(OCR): — 이미지나 스캔된 문서 내의 텍스트를 기계가 읽을 수 있는 텍스트 데이터로 변환하는 기술이다. 표가 많은 복잡한 문서에서는 인식 오류가 발생하기 쉬우며, 잘못된 텍스트가 임베딩될 경우 RAG 시스템의 답변 품질을 심각하게 저하시킨다.
리랭커(Reranker): — 초기 검색 단계에서 추출된 문서 후보들의 관련성을 정밀하게 재평가하여 순위를 다시 매기는 모델이다. 검색 정확도를 높이는 핵심 요소이지만, 원본 데이터 자체가 잘못되었거나 최신성이 결여된 경우에는 리랭커만으로 문제를 해결할 수 없다.

언급된 도구

Denser추천

멀티 소스 데이터 수집 및 버전 추적을 위한 오케스트레이션 파이프라인