팀이 모델 마이그레이션(model migration)을 하는 경우는 제공자가 버전을 종료할 때, 더 새로운 모델이 더 저렴하거나 더 나을 때, 애플리케이션을 호스팅 모델에서 자체 인프라의 모델로 옮길 때입니다. 어느 경우든 단계는 같습니다. 평가 세트와 통과 기준을 고정하고, 현재 모델과 후보 모델을 같은 입력으로 실행하고, 결과를 비교합니다. 새 모델이 다르게 동작하는 부분은 프롬프트, 임곗값, 후처리를 조정하고, 후보 모델이 기준을 충족하면 배포합니다. 나란히 비교하는 실행을 건너뛰면 회귀를 테스트가 아니라 사용자에게서 발견하게 됩니다.
마이그레이션 결과를 나중에 해석할 수 있게 하는 쪽은 데이터입니다. 두 실행 사이에 데이터가 바뀌면 비교에 두 원인이 섞이고, 결과를 움직인 것이 새 모델인지 새 데이터인지 아무도 말할 수 없습니다. 전환 전에 데이터 버전과 평가 조건을 고정하면 모델만 유일한 변수로 남습니다. 마이그레이션을 모델 드리프트와 구분할 때 쓰는 원칙과 같습니다. 실제 예시는 Model migration: freeze the data version에서 볼 수 있습니다.
모델 마이그레이션은 데이터 마이그레이션과 어떻게 다른가요?
모델 마이그레이션은 어떤 모델이 답하는지를 바꿉니다. 데이터 마이그레이션은 데이터가 저장된 위치를 바꾸고, 흔히 데이터의 형태도 바꿉니다. 제공자를 바꾸는 시점은 데이터를 함께 옮기기 편한 때라서 팀은 두 작업을 함께 진행하곤 합니다. 바로 그때 비교 결과를 해석할 수 없게 됩니다.
- 모델 마이그레이션: 같은 입력, 같은 평가 세트, 새 모델. 바뀐 결과는 모델 때문입니다.
- 데이터 마이그레이션: 같은 모델, 새 출처나 스키마. 필드 의미, 인코딩, 기본값이 오류 하나 없이 바뀔 수 있습니다.
- 둘을 동시에 진행하는 경우: 바뀐 결과마다 원인이 두 가지이며, 어느 쪽이 결과를 움직였는지 알 수 없습니다.
두 작업을 차례로 진행하고 그 사이에 데이터 버전을 고정하면 각 변경을 따로 판단할 수 있습니다.
AI 업무에서 모델 마이그레이션은 어디서 문제가 되나요?
한 팀이 분류 워크로드를 종료된 모델에서 후속 모델로 옮깁니다. 나란히 비교한 실행에서 약간의 개선이 나타나 전환을 적용합니다. 같은 주에 다른 팀이 프롬프트가 참조하는 기준 테이블을 갱신합니다. 한 달 뒤 예전에는 잡아내던 분류를 놓치기 시작하지만, 원인이 새 모델인지 새 기준 데이터인지 아무도 알 수 없습니다.
마이그레이션 자체는 올바르게 진행했지만, 그 아래에서 데이터가 바뀌었습니다. 비교 전에 데이터 버전과 평가 조건을 고정하고, 각 실행이 무엇을 읽었는지 기록하고, 데이터가 바뀌면 비교를 다시 실행해야 합니다. Syntitan은 각 실행을 해당 Version과 평가 조건에 연결해 Execution Trace로 남깁니다. 이 기록이 있어야 두 번째 비교가 가능합니다.