왜 당신의 모델이 실패하는가 (힌트: 아키텍처가 아니다)

Source: Dev.to

소개

우리는 모두 그런 경험을 해봤습니다: 하이퍼파라미터를 며칠 동안 조정하고 아키텍처를 다듬어도 손실 곡선이 전혀 협조하지 않을 때 말이죠. 제 경험에 따르면 성공적인 프로젝트와 실패 사이의 차이는 모델 아키텍처가 아니라, 거의 항상 데이터 파이프라인에 있습니다.

최근에 사내 비공개 프로젝트를 위해 견고한 데이터 파이프라인 솔루션을 구축했습니다. 개인정보 보호 문제로 해당 독점 데이터를 공유할 수는 없지만, 제가 마주한 문제들은 보편적입니다: 뒤죽박죽인 파일 구조, 독점적인 라벨 포맷, 그리고 손상된 이미지들.

제가 어떻게 문제를 해결했는지 정확히 보여드리기 위해 Oxford 102 Flowers 데이터셋을 사용해 솔루션을 재현했습니다. 이 데이터셋은 실제 현장의 복잡함을 그대로 반영하고 있기 때문에 완벽한 연습장이 됩니다: 8,000개가 넘는 일반적인 이름을 가진 이미지가 깔끔한 카테고리 폴더 대신 독점적인 MATLAB (.mat) 파일 안에 라벨이 숨겨져 있습니다.

아래는 모델이 복잡함을 신경 쓰지 않도록, 혼란스러운 데이터를 깔끔하게 처리하는 버그 없는 PyTorch 데이터 파이프라인을 구축하는 단계별 가이드입니다.

Source: …

1️⃣ 전략: 지연 로딩 & 오프‑바이‑원 함정

데이터를 안정적으로 로드할 수 없으면 다른 모든 것이 무의미합니다.

이번 파이프라인을 위해 지연 로딩에 초점을 맞춘 커스텀 torch.utils.data.Dataset 클래스를 만들었습니다 – __init__에서는 파일 경로만 저장하고, 실제 이미지 데이터는 __getitem__에서 필요할 때 로드합니다.

핵심 교훈: Oxford 데이터셋은 라벨에 1‑베이스 인덱싱을 사용하지만, PyTorch는 0‑베이스 인덱싱을 기대합니다. 이 오프‑바이‑원 오류를 초기에 잡아두면 계속 혼란스러운 모델을 학습시키는 일을 피할 수 있습니다.

데이터셋 골격

from torch.utils.data import Dataset
from PIL import Image

class FlowerDataset(Dataset):
    def __init__(self, img_paths, labels, transform=None):
        self.img_paths = img_paths

        # 소스가 1‑베이스라면 0‑베이스 인덱싱에 맞게 조정
        self.labels = labels - 1
        self.transform = transform

    def __len__(self):
        return len(self.img_paths)

    def __getitem__(self, idx):
        # 여기서 지연 로딩이 이루어집니다
        img = Image.open(self.img_paths[idx]).convert('RGB')
        label = int(self.labels[idx])

        if self.transform:
            img = self.transform(img)

        return img, label

Source:

2️⃣ 일관성: 전처리 파이프라인

실제 데이터는 거의 일관되지 않습니다. Flowers 데이터셋에서는 이미지의 크기가 크게 다릅니다(예: 670×500 vs 500×694). PyTorch 배치는 동일한 차원을 요구하므로, 엄격한 변환 파이프라인이 필요합니다.

나는 이미지를 왜곡시키는 단순 리사이즈를 피합니다. 대신 짧은 변을 리사이즈하여 종횡비를 유지하고, 센터 크롭을 통해 동일한 정사각형으로 맞춥니다. 마지막으로 텐서로 변환하고 픽셀 강도를 [0, 255]에서 [0, 1]로 정규화합니다.

from torchvision import transforms

# Standard ImageNet normalization stats
mean = [0.485, 0.456, 0.406]
std  = [0.229, 0.224, 0.225]

base_transform = transforms.Compose([
    transforms.Resize(256),          # resize shorter side to 256
    transforms.CenterCrop(224),    # crop to 224×224
    transforms.ToTensor(),
    transforms.Normalize(mean=mean, std=std),
])

변환 후 샘플 출력:

3️⃣ 증강: 무한한 변형, 추가 저장소 없음

PyTorch의 실시간(on‑the‑fly) 증강의 가장 큰 장점 중 하나는 추가 저장소를 차지하지 않으면서 무한한 변형을 제공한다는 점이다.

훈련 중 이미지가 로드될 때만 무작위 변환(플립, 회전, 색상 jitter 등)을 적용함으로써, 모델은 매 epoch마다 각 이미지의 약간씩 다른 버전을 보게 된다. 이는 모델이 픽셀을 외우는 대신 형태와 색상 같은 필수적인 특징을 학습하도록 강제한다.

Note: 항상 검증 및 테스트에서는 증강을 비활성화해야 메트릭이 실제 성능 향상을 반영한다.

4️⃣ 버그 방지 파이프라인: 손상된 데이터 처리

이 부분은 튜토리얼에서는 종종 간과되지만 실제 운영에서는 매우 중요합니다. 하나의 손상된 이미지만 있어도 학습이 시작된 후 몇 시간 뒤에 크래시가 발생할 수 있습니다.

이를 해결하기 위해 __getitem__을 복원력 있게 만듭니다. 파일이 손상되었거나(손상된 바이트, 빈 파일 등) 문제가 있을 경우 오류를 로그하고 다음 유효한 이미지를 가져와야 합니다. 크래시하지 않도록 합니다.

def __getitem__(self, idx):
    try:
        img = Image.open(self.img_paths[idx]).convert('RGB')
        if self.transform:
            img = self.transform(img)

        # Optional: keep track of how many times each sample is accessed
        self.access_counts[idx] += 1
        return img, int(self.labels[idx])

    except Exception as e:
        # Log the problematic file and continue with the next one
        self.log_error(f"Failed to load {self.img_paths[idx]}: {e}")
        # Recursively try the next index (wrap around if needed)
        next_idx = (idx + 1) % len(self.img_paths)
        return self.__getitem__(next_idx)

self.log_error를 원하는 로깅 메커니즘(예: logging.warning, CSV에 기록 등)으로 교체하십시오.

마무리

lazy‑loading, 표준화 변환, 즉시 증강, 그리고 손상된 파일 방지를 통해 다음과 같은 데이터 파이프라인을 얻을 수 있습니다:

• 메모리 효율적 – 필요한 이미지만 RAM에 존재합니다.
• 견고함 – 인덱싱 quirks와 손상된 파일이 학습을 방해하지 않습니다.
• 확장성 – 동일한 패턴을 훨씬 크고 복잡한 데이터셋에도 적용할 수 있습니다.

Oxford 102 Flowers 데이터셋으로 한 번 시도해 보고, 같은 원칙을 여러분의 독점 데이터에 적용해 보세요. 즐거운 학습 되세요!

# Example of robust __getitem__ with error handling
def __getitem__(self, idx):
    try:
        # Load and process the image at the given index
        image = self.load_image(idx)
        label = self.labels[idx]
        return self.transform(image), label
    except Exception as e:
        # Log the error and move to the next valid sample
        logger.error(f"Error loading sample {idx}: {e}")
        # Recursively skip to the next valid sample
        new_idx = (idx + 1) % len(self)
        return self.__getitem__(new_idx)

5️⃣ Telemetry: 데이터 파악

마지막으로 파이프라인에 기본 텔레메트리를 추가했습니다. 로드 시간과 접근 횟수를 추적하면 특정 이미지가 학습 처리량을 저하시키는지(예: 거대한 고해상도 파일) 혹은 랜덤 샘플러가 일부 파일을 무시하고 있는지를 파악할 수 있습니다.

제 구현에서는 이미지 로드에 1초 이상 걸리면 시스템이 경고를 표시합니다. 학습이 끝난 뒤에는 다음과 같은 요약을 출력합니다:

Total images: 8,189
Errors encountered: 2
Average load time: 7.8 ms

Summary

If you are shipping models to production, you need to invest as much time in your data pipeline as you do in your model architecture.

By implementing lazy loading, consistent transforms, on‑the‑fly augmentation, and robust error handling, you ensure that your sophisticated neural network isn’t being sabotaged by a broken data strategy.