PaddleOCR Detection 파인튜닝 실전 기록 (중간 점검)

프로젝트 배경

OCR 프로젝트에서 텍스트 인식(recognition) 이전 단계인 텍스트 영역 검출(detection) 성능을 개선하기 위해 PaddleOCR의DB 기반 Detection 모델을 파인튜닝했다.

 

환경 요약:

• OS: Windows
• GPU: RTX 4070 Ti
• Framework: PaddleOCR
• Task: Text Detection (DB)
• Dataset: 약 16만 라인 규모 (train + val)

목표:

• 1주일 이내 학습 완료
• 실사용 가능한 Detection 성능 확보

학습 파이프라인 개요

Detection 학습 흐름은 다음과 같다.

1. 원본 OCR 데이터 → PaddleOCR 포맷으로 변환
2. YAML 설정 파일로 모델/학습/데이터 정의
3. tools/train.py로 학습 실행
4. Epoch 중간마다 validation 평가
5. Best model 자동 저장
6. 성능 정체 시 학습 종료 판단

사용한 핵심 설정 (YAML 기준)

Global 설정 요약

• epoch_num: 20
• use_gpu: True
• save_model_dir: 모델 저장 경로
• save_epoch_step: epoch 단위 저장
• eval_batch_step: 일정 step마다 validation 수행
• pretrained_model: 기존 DB Detection 사전학습 모델 사용

중요 포인트:

• epoch 수는 “최대 한계”일 뿐, 실제 종료 기준은 metric이다.
• PaddleOCR은 best metric 기준으로 자동 저장한다.

---

Architecture (Detection)

• Algorithm: DB
• Backbone: PPLCNetV3 (scale 0.75)
• Neck: RSEFPN
• Head: DBHead

DB 계열 특징:

• 초반 epoch에서 성능이 급격히 상승
• 이후 epoch에서는 미세 조정 또는 오히려 흔들릴 수 있음

---

Loss 구성

• DBLoss
  • DiceLoss (main)
  • Shrink map loss
  • Threshold map loss
  • Binary map loss

Loss 해석 포인트:

• loss < 1.3 진입 시 이미 수렴 구간
• 이후 loss 감소폭은 성능 향상과 반드시 비례하지 않음

---

학습 로그 해석 (중요)

초기 학습 로그 예시

epoch: [1/20]
loss: 1.27
precision: 0.000
recall: 0.000
hmean: 0.000

• 아직 validation 단계가 오지 않았거나
• 모델이 threshold 기준을 통과하지 못한 상태

Validation 이후 로그

cur metric
precision: 0.8889
recall:    0.8677
hmean:     0.8781

의미:

• Detection 기준으로 매우 높은 성능
• 실사용 가능한 수준
• 이미 “완성 구간” 진입

이 시점에 PaddleOCR는 자동으로:

save best model is to output/det_ke_model/best_accuracy

best model을 저장한다.

---

왜 epoch가 안 올라가 보였는가?

로그를 보면 오랫동안 다음과 같이 출력되었다. 이는 정상 동작이다.

epoch: [1/20]
global_step: 4000

 

이유:

• epoch는 “데이터 전체 1회 순회” 기준
• 데이터가 16만 라인으로 매우 크기 때문에
• step 수가 많아 epoch 증가가 느리게 보임

즉,

• 학습이 멈춘 것이 아님
• 단지 1 epoch 내부에서 step이 계속 증가 중

---

학습 시간 계산 결과

실제 계산:

• Epoch당 약 22시간
• 20 epoch 전체: 약 18일
• 1주일 목표 대비 약 2.6배 초과

원인:

• 대규모 데이터셋
• Detection 특성상 고해상도 입력
• IPS 약 2.6 samples/s

---

성능 대비 시간 관점에서의 결론

epoch 1에서 이미 다음 성능 달성:

• hmean ≈ 0.88
• precision / recall 균형 양호
• best model 저장 완료

Detection(DB) 특성상:

• 1~2 epoch이 성능의 80~90%를 결정
• 이후 epoch은 미세한 튜닝 단계

따라서,

• epoch 수를 끝까지 채우는 것은 비효율적
• 성능 정체 시 즉시 종료가 합리적

---

언제 멈추는 게 적당한가? (정리)

종료 기준

1. best hmean 이후 2회 연속 갱신 실패
2. 또는 epoch 2 종료 시점
3. 또는 loss가 1.2 근처에서 진동만 할 때

현재 프로젝트는:

• 이미 조건 1, 3을 만족
• epoch 2까지 갈 필요도 없는 상태

---

핵심 메서드 / 스크립트 정리

공부용 메모로 중요한 실행 포인트만 정리한다.

데이터 변환

• OCR 데이터 → PaddleOCR Detection 포맷
• train_label.txt / val_label.txt 생성

학습 실행

• tools/train.py
• -c config.yml
• -o Global.use_gpu=True

체크포인트

• best 모델:
  output/det_ke_model/best_accuracy
• epoch 모델:
  output/det_ke_model/epoch_x

재시작 학습

• Global.checkpoints에 경로 지정 시 이어서 학습 가능
• best_accuracy는 “추론용”, resume은 보통 epoch 모델 사용

---

현재 단계 요약

• Detection 모델 학습: 성공
• 성능: 실사용 가능 이상
• 남은 작업:
  • Recognition 연계 테스트
  • 후처리(box 정렬, 필터링)
  • 실제 문서 기준 OCR 품질 검증

---

마무리 정리

이번 학습에서 가장 중요한 교훈은 다음이다.

• epoch 수는 목표가 아니다
• metric이 목표다
• Detection은 빨리 수렴하고, 빨리 멈추는 게 맞다

이 상태에서 더 많은 epoch을 돌리는 것은
성능 대비 시간 효율이 급격히 떨어진다.

다음 단계는 Recognition 또는 후처리 개선로 넘어가는 것이 가장 합리적인 선택이다.