Ramp, YAML 구성 시스템으로 ML 모델 배포 기간을 4개월에서 5분으로 단축

Ramp의 첫 신용 위험 모델을 프로덕션에 배포하는 데는 거의 4개월과 3,000줄이 넘는 코드가 필요했습니다. 금융 서비스 회사로서 Ramp는 모든 모델의 출력이 요청 시 정확히 재현 가능해야 했는데, 맞춤형 일회성 배포 코드로는 이를 보장하기 어려웠습니다. 머신러닝 논의는 모델 자체에 집중되는 경향이 있지만, 실제로 엔지니어링 시간은 '피처 파이프라인' — 원시 데이터를 정제하고, 형변환하고, 변환하여 사용 가능한 입력으로 만드는 코드 — 이 대부분을 차지했으며, 팀은 이것이 실제 작업의 99%라고 추정했습니다.

Ramp의 엔지니어링 팀은 이를 표준화하기 위해 YAML 기반 구성 시스템인 Turbo를 구축했습니다. 그들은 모든 ML 워크플로가 공유하는 엔티티를 식별했습니다: 피처 파이프라인(원시 데이터에서 피처로)과 모델 파이프라인(피처에서 예측으로)입니다. 'JobSpec' 클래스는 YAML 파일을 읽고 이를 Pydantic 객체로 구체화한 뒤 컴퓨팅 환경에 제출합니다 — 새 모델을 학습시키는 Train Job 또는 모델 저장소에서 모델을 불러오는 Predict Job입니다. 두 작업이 동일한 스키마를 공유하기 때문에 모델 배포는 구성 파일을 복사하고 몇 줄만 편집하는 것에 가깝습니다.

성과는 즉각적이었습니다: 오늘 구성 파일에 기술된 파이프라인은 기반 데이터가 변경되지 않는 한 1~2년 후에 다시 실행해도 동일한 결과를 생성하므로 재현성 요구 사항을 직접적으로 해결합니다. 마이그레이션된 시계열 예측 모델은 또한 모든 모델에 걸쳐 일관된 공휴일 처리를 무료로 얻었는데, 이 추상화로 구축된 모든 모델이 기능 엔지니어링 로직을 독립적으로 재구현하는 대신 동일한 로직을 상속받기 때문입니다.

모든 ML 파이프라인을 하나의 YAML 파일에 기술된 두 가지 재사용 가능한 구성 요소(피처, 모델)로 전환

피처 파이프라인과 모델 파이프라인을 재사용 가능한 엔티티로 분리함으로써, 모델링이 아닌 ML 작업의 99%를 한 번만 해결하면 되었습니다.

코드 라이브러리가 아닌 선언적 YAML 스키마를 사용함으로써 ML 배경이 없는 엔지니어도 파이프라인 코드를 직접 작성하지 않고 모델을 배포하고 유지 관리할 수 있었습니다.

학습과 예측이 하나의 스키마를 공유함으로써 개발자는 각 단계에 별도의 도구를 사용하는 대신 하나의 개념 집합만 배우면 둘 다 수행할 수 있었습니다.

기능 엔지니어링(예: 시계열 모델의 공휴일 처리)을 표준화함으로써 각 모델을 개별적으로 패치하는 대신 한 번에 전체 범주의 불일치 버그를 해결했습니다.

동일한 2단계 파이프라인 형태가 여러 시스템에서 반복될 때, 이를 한 번 선언적 스키마로 인코딩하십시오 — 그러면 전문가만 할 수 있던 수개월짜리 작업이 어떤 엔지니어든 작성할 수 있는 작업으로 바뀝니다.

Ramp가 Turbo에 대해 글을 쓸 당시, 새 모델은 평균 약 40줄의 YAML로 5분 이내에 배포할 수 있었으며, 이는 4개월과 3,000줄 이상의 코드에서 줄어든 것입니다. 거의 20개의 모델이 프로덕션에 있었고, 9명의 서로 다른 개발자가 구축했으며, 그중 다수는 Turbo가 존재하기 전에는 머신러닝 모델을 학습시키거나 배포한 적이 없었습니다.