보통 snapshot에서는 makespan을 줄이던 policy가 특정 설비에 유리한 lot이 많아지자 TCT를 크게 늘렸다. 이런 결과를 발견했다면 “학습 데이터를 더 다양하게 만들자”는 처방부터 내리기 쉽다. 그러나 새로운 조건을 학습에 추가하기 전에, 무엇 때문에 실패했는지 구분해야 한다. 특정 lot의 edge 처리시간을 잘못 읽은 오류와 편중된 구성을 경험하지 못한 문제는 다른 수정이 필요하다.

05편은 실패를 드러낼 조건을 설계했다. 이 글은 발견한 실패를 줄이기 위해 학습 분포, 관측, 모델, 적용 범위 가운데 무엇을 바꿀지 다룬다. 사례는 한 snapshot의 설비–lot 그래프에서 스케줄을 만드는 문제이며, 아래 실험 순서와 수치는 설계 제안이다. 이 편에서는 처리 조건이 다른 lot을 P/Q 제품군으로 묶고, 자격·고장·관측 지연을 확장 조건으로 추가한다. 제어할 설비 집합을 B라고 부른다.

1. 일반화 실패와 입력 계약 위반을 구분한다

일반화는 학습에 직접 사용하지 않은 조건에서도 원하는 성능을 내는 능력이다. 견고성은 지연이나 고장 같은 변동에도 성과와 제약을 허용 범위 안에 유지하는 성질로 사용하겠다. 두 표현은 겹치지만, 단순한 관측 코드 오류까지 모두 일반화 문제로 부르면 원인을 놓친다.

발견한 현상먼저 분리할 원인첫 확인 실험
Q 제품 비중이 높을 때만 TCT 악화부족한 학습 경험 / 잘못된 Q feature같은 snapshot을 전처리 전후 비교하고, 정상·Q 다수 조건을 각각 재생
후보 lot이 많아지면 특정 lot을 선택하지 않음edge 누락 / 그래프 ID·갱신 오류 / 학습 규모 부족원본 조합과 graph edge ID 대조, 생성 단계별 갱신 확인
설비 고장 직후 timeout 증가낯선 상태 / 후보 수 증가에 따른 계산량모델 계산 시간과 상태 조회 시간을 분리 측정
반복 재계획 확장의 긴 평가에서 WIP가 계속 증가단기 목적 / 용량 초과 / 잘못된 초기화같은 부하에서 기준 규칙의 장기 안정성도 확인
새 제품·처리조건에서 실패관측 범주 미지원 / 새로운 물리 관계지원되지 않는 값 탐지와 처리시간·자격 계약 확인

코드 오류라면 코드를 고치고 회귀 검사를 추가한다. 주어진 입력으로는 서로 다른 상태를 구분할 수 없다면 관측을 보강해야 한다. 정상적인 입력이고 표현도 충분하지만 특정 상황을 거의 경험하지 못했다면 학습 분포 변경을 검토한다. 환경이 실제 시스템과 다른 경우에는 simulator부터 수정한다. 이 순서를 건너뛰고 학습량만 늘리면 같은 오류를 더 잘 학습할 수 있다.

2. 무엇을 무작위화할지 명세로 남긴다

domain randomization은 학습 환경의 특성을 일정한 분포에서 바꿔 가며 여러 조건을 경험하게 하는 방법이다. Peng 등의 연구는 로봇의 동역학을 무작위화한 시뮬레이션 학습과 실제 로봇의 물체 밀기 과제를 다뤘다. 그 결과가 FAB의 성능을 보장하지는 않지만, 하나의 고정 모델에만 맞추지 않는 학습 설계의 근거가 된다. Peng et al., ICRA 2018

환경의 모수를 , 그 학습 분포를 라고 하면 가능한 학습 목적은 다음과 같다.

이 식은 여러 환경에서의 기대 reward를 높이겠다는 뜻이다. 어떤 환경을 얼마나 자주 뽑는지가 학습 목표의 일부다. 극단적 조건을 자주 뽑으면 학습 중 그 조건의 중요도가 커진다. 운영 성과를 보고할 때에는 별도로 정한 운영 분포의 비중을 사용해야 한다.

FAB 사례에서는 다음처럼 항목별 명세를 만들 수 있다.

변경 대상샘플링 단위의 예유지할 관계
P/Q 제품 비중snapshot별 대상 lot 구성 선택비중의 합, 제품별 처리시간·자격 관계
처리시간snapshot별 평균 계수 + 설비–lot별 변동제품·설비 조합별 차이와 양의 시간
설비 고장정의한 고장 과정에서 사건 생성가동시간 기반 고장이라면 사용량과의 관계
초기 WIP검증된 상태 묶음 또는 일관된 생성기진행 중 작업의 잔여시간, 위치, 설비 점유
관측 지연채널별 지연 과정timestamp와 결측 표시, 인과적 정보 가용성

같은 snapshot 안의 조합 선택마다 처리 조건을 다시 뽑으면 한 스케줄을 만드는 동안 공장이 바뀐 셈이다. 처음 고정한 조건은 생성 종료까지 유지하고, 실행 변동은 별도 evaluator에서 정한 규칙으로 발생시킨다. 설비 성능 저하가 수일간 지속되는 현상이라면 그 모수를 계획·실행 구간에 걸쳐 유지하는 편이 적절할 수 있고, 개별 작업의 변동은 작업마다 다시 뽑을 수 있다. 어떤 시간 규모에서 무엇이 바뀌는지까지 명세에 포함한다.

제품 구성, 가용 설비, 처리시간을 각각 무작위화하는 것만으로는 충분하지 않다. Q 비중 증가와 Q 전용 설비의 보전이 동시에 발생하는 조건처럼 상관된 변화도 검토한다. 물리적으로 불가능한 조합은 제거하고, 가능하지만 드문 조합은 별도 stress 시험으로 관리한다.

3. 학습 분포를 넓히는 비용을 측정한다

넓은 학습 분포가 항상 유리한 것은 아니다. 같은 계산 예산에서 학습해야 할 조건이 많아지고, 관측으로 구분되지 않는 환경 사이에서 서로 충돌하는 행동을 배울 수 있다. 정상 조건의 성과가 떨어질 수도 있지만 반드시 떨어지는 것도 아니다. 이를 실험으로 확인해야 한다.

가상 실험에서는 다음 네 설정을 같은 기준으로 비교할 수 있다.

  1. 기존의 정상 조건에서만 학습한 기준 모델.
  2. 제품 비중만 바꿔 학습한 모델.
  3. 제품 비중과 처리시간을 함께 바꾼 모델.
  4. 위 조건에 관측 지연을 추가한 모델.

각 설정에서 여러 번 독립 학습하고 정상 성능, 변경 조건 성능, 실패율, 필요한 학습 비용을 함께 기록한다. 어려운 조건에서 나아졌다는 이유로 정상 조건의 손실을 숨기지 않는다. 반대로 평균 성능이 비슷해도 특정 제품의 장기 대기가 줄었다면 운영상 가치가 있을 수 있다.

학습 중 사용한 모수를 policy 입력에 넣는 것도 주의해야 한다. 운영에서는 알 수 없는 고장률의 참값을 simulator가 제공하면, 학습 때만 유리한 정보를 사용하게 된다. 실제로 추정할 수 있는 값이라면 추정 오차와 지연까지 포함하고, 알 수 없다면 관측 이력에서 적응할지 또는 보수적인 결정을 할지 정한다.

4. Curriculum은 학습 순서이지 최종 시험의 대체물이 아니다

curriculum은 쉬운 조건에서 시작해 학습 진행에 따라 조건을 어렵게 만드는 방식이다. 이 사례라면 두 설비·두 lot의 edge 선택과 reward부터 확인하고, lot 수·설비 수를 늘린 뒤 자격 edge·처리시간 변동·setup을 필요한 순서로 추가할 수 있다. 가변 크기를 읽는 graph 모델이라도 큰 그래프에서 성능이 유지되는지는 따로 확인한다.

단계 이동 기준은 “학습 step이 어느 정도 지났다”보다 해당 단계에서 확인할 능력과 연결하는 편이 좋다. 예를 들어 유효 후보 중 선택이 안정적으로 작동하고, validation에서 기본 규칙과의 차이를 해석할 수 있을 때 다음 단계를 연다. 초반의 높은 reward만으로 성공을 판정하지 않는다.

다음 단계로 넘어가며 이전 조건을 전부 빼면 이전 행동을 잊을 수도 있다. 학습 batch나 episode 구성에 이전 조건을 일부 유지하고, 고정된 회귀 평가군으로 확인한다. 회귀 평가군은 과거에 통과했던 조건에서 성능이 다시 나빠졌는지 살펴보는 집합이다. 이 집합을 모델 선택에 사용했다면 최종 test와는 별도로 취급해야 한다.

이 글의 단계 구성은 특정 curriculum 알고리즘의 구현을 제시한 것이 아니다. 어느 단계에서 무엇을 학습하고, 다음 단계에서 어떤 성능을 유지해야 하는지 명시하는 과제 운영 방식이다.

5. 평균 향상과 최악 조건의 허용 여부를 분리한다

P 비중이 높은 조건에서 큰 이득을 얻어 평균 makespan이 줄었더라도 Q 전용 설비가 고장 났을 때 특정 제품이 계속 밀린다면 별도의 판단이 필요하다. 운영 빈도 가중 평균과 동등 평균을 함께 보고, 주판정은 사전 계약을 따른다. 그 밖에 시나리오별 TCT 한도, 배정 유효성, 생성시간을 확인한다. 반복 재계획 확장에서는 회복 시간과 미완료 age도 추가한다.

유한한 시나리오 집합 에서 상대 성능을 다음처럼 요약할 수도 있다.

값이 클수록 좋은 KPI 에 대해, 시험한 조건 중 baseline 대비 가장 불리한 기대 차이를 보겠다는 뜻이다. 실제로는 유한 표본으로 각 기대값을 추정하므로 불확실성을 함께 다뤄야 한다. 이 수치는 시험하지 않은 모든 환경에 대한 보증도, 극히 드문 단일 사건의 손실 상한도 아니다.

성과 분포의 tail, 즉 극단적인 손실 구간을 목표에 반영하려면 tail의 정의와 표본 수부터 정해야 한다. 평균 reward에 작은 벌점을 추가했다는 이유만으로 tail 문제가 해결됐다고 할 수 없다. 드문 사건의 관측이 부족하면 추정이 불안정하다는 사실을 결과에 남긴다.

6. 재학습과 적용 범위 제한을 함께 검토한다

새로운 제품·처리조건의 입력 표현이 지원되지 않는다면 당장 모든 상황을 모델에 맡길 필요는 없다. 기존 규칙으로 처리할 범위를 명시하고, 그 범위에 대한 데이터를 모은 뒤 별도 후보를 검증할 수 있다. 다만 다른 policy와 섞어 실행하면 상태 분포도 달라지므로 전체 배포 시스템을 다시 평가해야 한다.

실패의 원인우선 대응재검증할 것
정상 schema의 일부 범위를 거의 학습하지 못함학습 분포·초기 상태 확대새 조건의 개선과 기존 조건의 손실
필요한 정보가 관측에 없음feature·이력 또는 의사결정 단위 재설계추가 정보의 운영 가용성, 입력 계약
실제 설비 동작이 simulator와 다름환경 보정·모델 구조 수정기존 정책과 새 정책 양쪽의 검증
물량이 가용 용량을 지속 초과적용 한계 명시, 상위 운영 판단policy 교체로 해결할 수 있는 범위
드물고 지원하지 않는 조합제한 적용과 fallback경계 탐지, 전환 후 queue와 KPI

분포 밖 상태를 완벽하게 감지하는 장치가 있다고 가정해서는 안 된다. 명시적인 schema·자격·범위 검사는 구현할 수 있지만, 복잡한 상태의 낯섦을 수치 하나로 판정하는 방법에는 놓침과 과잉 탐지가 있을 수 있다. 탐지기를 넣었다면 탐지기까지 포함한 policy가 평가 대상이다.

이 편의 산출물은 실패 조건, 수정 가설, 학습 분포 변경, 유지할 회귀 조건, 남은 적용 제한을 기록한 대응 보고서다. 실패 사례를 학습에 넣었다면 그 사례는 이제 개발 자료다. 개선을 최종 주장할 독립 조건은 새로 남겨 두어야 한다.

참고문헌

이전: 08. 학습 진단 · 시리즈 목차 · 다음: 10. 배포 검증