구조가 깨졌지만 메타데이터로 page 확인이 가능하다면 그냥 문서에서 다시 해당 page를 가져와서 분할을 시도하는게 더 낫지 않아? 그렇게 안하는 이유가 뭐야?
실무적인 데이터 엔지니어링 환경에서 '원천 페이지 재호출'을 하지 않고 '강제 분할'을 선택하는 데에는 몇 가지 현실적인 이유가 있습니다.
1. "같은 기계(Parser)는 같은 불량을 냅니다"
가장 결정적인 이유입니다. utils.py에서 8,000자가 넘는 노드가 발생했다는 건, 그 페이지를 읽어낸 PDF 파서(Parser)가 이미 해당 페이지의 구조를 해석하는 데 실패했다는 뜻입니다.
2. 비용과 속도: "공정의 병목 현상"
데이터 파이프라인은 보통 [원천 파일 → 전체 텍스트 추출 → 노드 분할 → 필터링]의 단방향 흐름으로 설계됩니다.
- IO 부하: 필터링 단계에서 갑자기 "이 페이지 다시 읽어와!"라고 역행하면, 닫혀 있던 PDF 파일을 다시 열고, 해당 페이지를 찾고, 다시 파싱하는 무거운 작업이 추가됩니다.
- 비효율: 만약 1,000페이지 중 100페이지에서 이런 문제가 생기면, 전체 처리 속도가 기하급수적으로 느려지는 병목(Bottleneck) 현상이 발생합니다.
3. "데이터 심폐소생술"의 관점
우리가 하려는 강제 분할(Force-chopping)은 '완벽한 복구'라기보다는 '최소한의 검색 가능성 확보'에 가깝습니다.
- 구조는 포기, 키워드는 보존: 비록 문단은 깨졌어도 8,000자 안의 단어들은 살아있습니다. 1,000자씩 잘라두면, 나중에 사용자가 그 안의 키워드로 질문했을 때 검색 결과에는 걸리게 됩니다.
- LLM의 추론 능력: 요즘 LLM은 앞뒤가 조금 잘린 문맥이라도 검색된 조각들을 합쳐서 주면, 그 안에서 의미를 찾아내 답변을 생성합니다.
정말로 "원천 페이지에서 다시 제대로 가져오고 싶다"면, 단순 재시도가 아니라 '다른 공정(다른 파서)'을 써야 합니다.
[개선된 공정 제안]
1. 기본 파서로 전체 파싱 진행.
2. 8,000자 초과 노드 발생 시 '비상 공정' 가동.
- 해당 페이지를 텍스트가 아닌 이미지(OCR)로 읽거나, 훨씬 정교한(하지만 느린) AI 기반 파서로 해당 페이지만 다시 읽기.
이제 개발해야지...