learning rate와 iteration 수를 함께 볼 때는 단순히 반복을 늘리면 좋아진다고 생각하면 안 된다. 같은 learning rate라도 반복 횟수와 데이터 순서, 최근 데이터 가중 효과에 따라 모델이 다른 방향으로 수렴할 수 있다.
이 글은 learning rate를 0.1로 둔 실험에서 iteration을 4000, 8000, 16000, 32000으로 늘렸을 때 결과가 최근 데이터 쪽으로 강하게 맞춰지는 현상을 기록한 작업노트다.
핵심 정리
원문 실험 로그의 핵심은 learning rate가 고정되어 있어도 iteration이 커질수록 과거 데이터의 영향이 기대만큼 남지 않고 최근 데이터에 더 강하게 피팅되는 현상이 보였다는 점이다. 반복 횟수가 늘면 손실이 더 줄어드는 것처럼 보일 수 있지만, 목표가 전체 데이터의 균형 있는 반영이라면 단순한 반복 증가는 오히려 특정 구간에 치우친 결과를 만들 수 있다. 따라서 이런 실험에서는 learning rate, iteration, 데이터 입력 순서, 누적 업데이트 방식, 초기값, 수렴 기준을 함께 기록해야 한다. 수렴 속도 차이도 중요한 단서다. 오른쪽 데이터 구간이 더 빨리 맞춰진다면 학습 과정이 의도한 가중 구조를 따르는지 다시 확인해야 한다.
- 같은 learning rate에서도 iteration 수가 결과를 크게 바꿀 수 있다.
- 반복 횟수가 늘어도 항상 더 좋은 일반화로 이어지는 것은 아니다.
- 최근 데이터에 과하게 맞춰지는지 구간별 결과를 나누어 확인한다.
- learning rate와 iteration은 따로 보지 말고 함께 기록한다.
- 데이터 입력 순서가 업데이트 결과에 영향을 주는지 확인한다.
- 수렴 속도가 구간마다 다르면 모델이나 업데이트 방식의 편향을 의심한다.
- 실험 로그에는 초기값, 반복 수, learning rate, 결과 배열을 함께 남긴다.
- 목표가 과거 데이터 반영이라면 감쇠 방식이나 가중치 설계를 별도로 점검한다.
원문은 숫자 로그가 길게 이어져 있어서 검색자가 문제의 핵심을 바로 파악하기 어렵습니다. 보강문에서는 로그가 말하는 현상을 먼저 요약하고, 어떤 실험 조건을 함께 봐야 하는지 정리했습니다. 이 글의 초점은 특정 모델 성능 자랑이 아니라 learning rate와 iteration이 실제 결과에 어떤 식으로 얽히는지 관찰한 기록입니다.
이어서 볼 글
- Q-Learning Learning Rate 문제: 작은 학습률과 느린 수렴 - learning rate와 수렴 속도의 관계를 다른 실험 맥락에서 다룬다.
learning rate가 iteration에 영향을 받는 문제
이것도 아래 문제랑 엮여 있는데..
백문이 불여일견.. 아래 데이터를 보자.(learning rate = 0.1인 상황)
run("first", 1)
run("second", 2)
[2][2] 0.1 4000
[(((0, 0, 0), (1, 0, 2)), 880531.0788911874), (((0, 0, 0), (1, 10, 2)), 956820.8422473016), (((0, 0, 0), (1, 20, 2)), 1043860.1849327616), (((0, 0, 0), (1, 30, 2)), 1128824.4551833489), (((0, 0, 0), (1, 40, 2)), 1300219.0306824401), (((0, 0, 0), (1, 50, 2)), 1499959.5162339772)]
[(((0, 0, 0), (1, 0, 2)), 861331.577112289), (((0, 0, 0), (1, 10, 2)), 953632.7724324213), (((0, 0, 0), (1, 20, 2)), 1043501.9834596844), (((0, 0, 0), (1, 30, 2)), 1128807.318727137), (((0, 0, 0), (1, 40, 2)), 1300219.0106819747), (((0, 0, 0), (1, 50, 2)), 1499959.5178728462)]
[(((0, 0, 0), (1, 0, 2)), 860584.4231047228), (((0, 0, 0), (1, 10, 2)), 953627.6738777378), (((0, 0, 0), (1, 20, 2)), 1043501.9834337721), (((0, 0, 0), (1, 30, 2)), 1128807.318727137), (((0, 0, 0), (1, 40, 2)), 1300219.0106819747), (((0, 0, 0), (1, 50, 2)), 1499959.5178728462)]
[(((0, 0, 0), (1, 0, 2)), 860508.2370935935), (((0, 0, 0), (1, 10, 2)), 953627.5968407411), (((0, 0, 0), (1, 20, 2)), 1043501.9834337657), (((0, 0, 0), (1, 30, 2)), 1128807.318727137), (((0, 0, 0), (1, 40, 2)), 1300219.0106819747), (((0, 0, 0), (1, 50, 2)), 1499959.5178728462)]
[2][2] 0.1 8000
[(((0, 0, 0), (1, 0, 2)), 737916.6715624315), (((0, 0, 0), (1, 10, 2)), 833611.9636924887), (((0, 0, 0), (1, 20, 2)), 924615.9302019004), (((0, 0, 0), (1, 30, 2)), 1100146.0692519762), (((0, 0, 0), (1, 40, 2)), 1300000.0427282962), (((0, 0, 0), (1, 50, 2)), 1499999.9972244485)]
[(((0, 0, 0), (1, 0, 2)), 737577.825729132), (((0, 0, 0), (1, 10, 2)), 833539.3227920731), (((0, 0, 0), (1, 20, 2)), 924614.5383968088), (((0, 0, 0), (1, 30, 2)), 1100146.0692178488), (((0, 0, 0), (1, 40, 2)), 1300000.0427282958), (((0, 0, 0), (1, 50, 2)), 1499999.9972244485)]
[2][2] 0.1 16000
[(((0, 0, 0), (1, 0, 2)), 547711.4671152403), (((0, 0, 0), (1, 10, 2)), 704437.7877148614), (((0, 0, 0), (1, 20, 2)), 900032.7472189047), (((0, 0, 0), (1, 30, 2)), 1100000.0000726467), (((0, 0, 0), (1, 40, 2)), 1300000.0000000014), (((0, 0, 0), (1, 50, 2)), 1499999.999999999)]
[2][2] 0.1 32000
[(((0, 0, 0), (1, 0, 2)), 500253.43048952665), (((0, 0, 0), (1, 10, 2)), 700000.0532747698), (((0, 0, 0), (1, 20, 2)), 900000.0000001788), (((0, 0, 0), (1, 30, 2)), 1100000.0000000019), (((0, 0, 0), (1, 40, 2)), 1300000.0000000014), (((0, 0, 0), (1, 50, 2)), 1499999.999999999)]
[(((0, 0, 0), (1, 0, 2)), 500253.43046172964), (((0, 0, 0), (1, 10, 2)), 700000.0532747698), (((0, 0, 0), (1, 20, 2)), 900000.0000001788), (((0, 0, 0), (1, 30, 2)), 1100000.0000000019), (((0, 0, 0), (1, 40, 2)), 1300000.0000000014), (((0, 0, 0), (1, 50, 2)), 1499999.999999999)]
보면은..
learning rate = 0.1 이므로 과거데이터가 큰 영향을 주기를 바라지만, iteration이 커질수록 그런거 없고 최근 데이터에 피팅되버리는 문제가 보인다.
그리고 수렴속도가 오른쪽에 있는게 훨씬 빠르다는 문제점도 잘 보인다.
'Data Engineering' 카테고리의 다른 글
| 주식 데이터 정합성 점검: 누락, 중복, 기준일 확인 방법 (0) | 2026.06.02 |
|---|---|
| 최대우도추정 MLE 개념: 확률과 likelihood 차이 (0) | 2026.05.21 |
| Apache Flink Window 개념: Tumbling, Event Time, Watermark, Trigger (1) | 2023.10.29 |
| flink Table API를 사용한 실시간 Reporting샘플 (0) | 2023.10.28 |
| Flink 기본 개념: JobManager, TaskManager, ValueState (1) | 2023.10.28 |
