6.2 머신러닝 엔지니어링 (MLOps)

개요와 동기

흔히 MLOps라 부르는 머신러닝 엔지니어링은 머신러닝을 노트북과 실험에서 꺼내 믿을 만하고, 관찰 가능하고, 유지보수 가능한 프로덕션 시스템으로 가져오는 규율입니다. 전통적 소프트웨어는 코드가 말하는 대로 동작합니다. ML 시스템은 코드, 데이터, 학습된 모델 파라미터가 함께 말하는 대로 동작합니다. 그래서 ML 시스템은 테스트하기 더 어렵고, 재현하기 더 어렵고, 세상이 학습 데이터에서 멀어짐에 따라 조용히 실패하기 쉽습니다. MLOps는 코드와 데이터와 모델이라는 이 세 부분의 현실에 소프트웨어 엔지니어링의 엄밀함, 곧 버전 관리, 테스트, 지속적 전달, 모니터링을 가져옵니다.

큰 팀에게 MLOps는 시연에서 눈부신 일회성 모델과, 많은 팀이 안전하게 만들고, 배포하고, 운영할 수 있는 모델 군단을 가르는 것입니다. 공유 플랫폼과 실천이 없으면 모든 팀이 데이터 파이프라인, 학습 루프, 배포를 다시 발명하고, 여섯 달 뒤 아무도 재현할 수 없는 취약한 시스템만 남습니다. 기업은 수십 개의 모델로 확장하고, 서비스 수준 목표를 충족하고, 주어진 예측이 어떻게 만들어졌는지 묻는 감사자를 만족시키기 위해 MLOps에 의존합니다.

정부와 규제 산업에서 MLOps는 흔히 위장한 컴플라이언스 요건입니다. 재현성, 계보, 버전 관리는 기관이 법적으로 중대한 질문에 답하게 해 줍니다. 정확히 어떤 모델이, 어떤 데이터로, 어떤 코드로 학습되어, 시민에게 영향을 준 결정을 내렸는가? 성숙한 MLOps 실천은 그 질문이 여러 해 뒤에도 답해질 수 있게 하며, 이는 좋은 엔지니어링이자 법적 보호 장치입니다.

함께 보기: 8.1장(CI/CD와 전달), 9.2장(관측 가능성과 모니터링), 6.6장(AI 인프라와 운영).

핵심 원칙

데이터, 코드, 모델을 함께 버전 관리되는 산출물로 다루십시오. 어느 하나를 바꾸면 시스템 행동이 바뀝니다.
데이터에서 학습된 모델, 배포까지의 경로를 자동화해 반복 가능하고 감사 가능하게 하십시오.
모든 모델을 그것을 만든 정확한 데이터, 코드, 구성에 추적 가능하게 하십시오.
배포 전에 대표성 있는 보류 데이터로 모델을 평가하고, 배포 후에도 계속 평가하십시오.
모델은 저하된다고 가정하십시오. 첫날부터 드리프트(라이브 데이터나 입출력 관계가 모델이 학습한 것에서 서서히 벌어지는 것), 데이터 품질 문제, 성능 저하를 모니터링하십시오.
영리하지만 재현할 수 없는 실험보다 지루하고 재현 가능한 파이프라인을 선호하십시오.
실험 속도와 프로덕션 신뢰성의 관심사를 분리하고, 둘을 의도적으로 잇습니다.

권장 사항

전체 ML 수명 주기를 명시적으로 관리한다

각 단계를 정의하고 계측하십시오. 데이터 수집과 검증, 피처 엔지니어링, 학습, 평가, 배포, 모니터링입니다. 단계 사이의 경계를 명시적으로 해 각각이 테스트, 재시도, 감사될 수 있게 하십시오. 모델이 즉흥적 노트북에서 학습되어 운영 쪽으로 담 너머로 던져지는 흔한 실패를 피하십시오. 대신 수명 주기를 오케스트레이션된 파이프라인으로 감싸, 권한 있는 엔지니어가 깨끗한 체크아웃에서 실행할 수 있게 하십시오.

피처 스토어, 실험 추적, 모델 레지스트리를 쓴다

피처 스토어는 피처 정의를 중앙화해 같은 변환이 학습과 서빙 양쪽에서 돌게 합니다. 이는 학습-서빙 편향(학습용과 라이브 예측용으로 피처가 계산되는 방식의 불일치)을 없애고, 팀이 피처를 다시 계산하는 대신 재사용하게 합니다. 실험 추적은 모든 학습 실행의 파라미터, 코드 버전, 데이터 버전, 지표를 기록해 결과가 비교 가능하고 재현 가능하게 합니다. 모델 레지스트리는 학습된 모델의 기록 시스템으로, 버전, 계보, 평가 결과, 승인 상태, 배포 단계를 담습니다. 이들이 함께 행동이 바뀔 때 “무엇이 바뀌었나?”에 답하고, 거버넌스가 적용되는 단계를 거쳐 모델을 승격하거나 롤백하게 해 줍니다.

데이터와 모델을 계보와 함께 재현 가능하고 버전 관리되게 한다

코드만이 아니라 데이터셋의 버전을 관리하십시오. 학습 실행이 불변 스냅샷을 참조하도록 콘텐츠 주소 지정 저장소나 데이터 버전 관리 도구를 쓰십시오. 코드는 git 커밋으로, 환경은 잠긴 의존성과 컨테이너 이미지로 고정하십시오. 계보를 끝에서 끝까지 포착하십시오. 어떤 원시 데이터가 어떤 피처를 먹였고, 어떤 피처와 코드가 어떤 모델을 만들었고, 그 모델이 어디에 배포되어 있는지입니다. 사고나 감사가 닥칠 때 계보는 포렌식 악몽을 단순한 질의로 바꿔 줍니다. 결과가 의존하는 곳에서는 무작위성(시드)과 하드웨어를 기록하십시오.

워크로드에 맞게 배포 패턴을 고른다

배치 점수화는 일정에 따라 큰 데이터셋 위에서 돌아갑니다. 운영이 가장 단순하고 지연에 관대하며 보고서와 주기적 결정에 이상적입니다.
온라인(실시간) 서빙은 빠듯한 지연 예산 안에서 개별 요청에 응답합니다. 저지연 피처 조회와 신중한 용량 계획이 필요합니다.
스트리밍은 이벤트가 도착하는 대로 지속적으로 점수화합니다. 신선도가 중요한 사기 탐지와 모니터링에 맞습니다.
엣지는 지연, 프라이버시, 연결성, 데이터 주권의 이유로 기기나 온프레미스 하드웨어에서 모델을 돌립니다. 정부와 현장 환경에서 흔합니다.

요건을 충족하는 가장 단순한 패턴을 고르고, 섀도 배포, 카나리, 즉각적 롤백으로 롤아웃을 설계하십시오.

드리프트, 저하, 데이터 품질을 모니터링한다

프로덕션의 입력과 출력을 계측하십시오. 데이터 드리프트(입력 분포의 이동), 개념 드리프트(입력과 목표 사이의 관계 변화), 데이터 품질 실패(널, 스키마 변경, 끊어진 상류 원천), 가지고 있다면 지연된 실측값에 대해 측정한 성능 저하를 지켜보십시오. 알림 임계값을 정하고, 런북을 쓰고, 모니터링을 재학습 트리거에 연결하십시오. 조용한 저하는 고전적인 ML 실패 모드이고, 모니터링이 그것에 대한 유일한 방어입니다.

장단점

결정	옵션 A	옵션 B	트레이드오프
서빙 패턴	배치	온라인	단순함과 비용 대 신선도와 지연
피처 계산	피처 스토어	모델별 파이프라인	일관성과 재사용 대 구축 오버헤드
플랫폼	관리형 MLOps 플랫폼 구매	오픈 소스 도구 조립	속도와 지원 대 유연성과 종속
재학습	일정에 따라	드리프트로 촉발	예측 가능성 대 대응성과 복잡성
재현성의 엄밀함	전체 데이터 버전 관리	가벼운 추적	감사 강도 대 저장소와 노력

포괄적 트레이드오프는 지금의 투자 대 나중의 취약함입니다. 무거운 재현성과 모니터링 인프라는 앞서 노력이 들지만, 설명할 수 없는 실패, 재현할 수 없는 모델, 침식된 신뢰라는 훨씬 큰 비용을 막습니다. 관리형 플랫폼은 팀을 빠르게 하지만 종속을 만들 수 있고, 오픈 소스 스택은 통합 작업의 대가로 통제를 줍니다. 큰 조직은 보통 이 복잡성을 포장된 길 기본값 뒤에 숨기는 공유 플랫폼 팀에서 이득을 봅니다.

팀과 논의할 질문

배포된 모델이 조용히 저하되었음을 고객이나 시민이 피해를 입기 전에 어떻게 알게 되며, 그 알림은 누가 소유합니까? 조용한 쇠퇴는 고전적인 ML 실패 모드입니다. 코드는 여전히 돌고, 모델은 여전히 확신에 찬 점수를 반환하며, 세상이 학습 데이터에서 드리프트함에 따라 품질이 미끄러집니다. 많은 모델을 운영하는 큰 팀에서는 이것이 군단에 대해 한 번이 아니라 모델별로 답해져야 합니다. 각각이 고유한 드리프트 프로필과 실측값 지연을 갖기 때문입니다. 데이터 드리프트, 개념 드리프트, 데이터 품질 단절에 대한 현재의 모니터, 알림 임계값, 누가 대응하는지 정하는 런북을 가져오십시오. 레이블이 몇 주 늦게 도착하는 규제 환경에서는 그동안 지켜볼 수 있는 대리 신호를 논의하십시오. 지연된 실측값을 기다린다는 것은 피해를 발견하기를 기다린다는 뜻이기 때문입니다. 모델의 드리프트 알림에 지명된 단일 소유자가 없다면 그 모델은 사실상 모니터링되지 않는 것입니다.
감사자가 18개월 전의 특정 예측을 재현해 달라고 요청한다면, 실제로 끝에서 끝까지 할 수 있겠습니까? 재현성은 좋은 엔지니어링 속에 숨은 컴플라이언스 요건입니다. 정확히 어떤 모델이, 어떤 데이터로, 어떤 코드로 학습되어 누군가에게 영향을 준 결정을 내렸는지 기관이 답하게 해 줍니다. 실제 예를 가져와 추적해 보십시오. 불변 데이터 스냅샷, git 커밋, 잠긴 의존성과 컨테이너 이미지, 기록된 시드, 원시 데이터에서 피처를 거쳐 배포된 모델까지의 계보입니다. 신호는 그 사슬의 어느 고리가 빠졌거나 수작업인가입니다. 정부와 규제 산업에서는 법이 실제로 요구하는 보존 기간을 정하고, 저장소가 그 기간 내내 계보를 답할 수 있게 유지하는지 확인하십시오. 틈이 있으면 일상적인 질의가 포렌식 비상 사태가 되기 때문입니다.
모델을 프로덕션으로 승격하고 롤백하는 규칙은 무엇이며, 레지스트리가 시행합니까 아니면 신뢰로만 시행합니까? 거버넌스 없는 승격은 노트북 실험이 프로덕션으로 새어 나가는 방식이고, 아무도 깨끗하게 되돌릴 수 없어 나쁜 모델이 남아 있는 방식입니다. 많은 팀에서 성숙과 취약의 차이는 모델 레지스트리가 의무적 승인과 평가로 승격을 관문 통제하느냐, 엔지니어가 가중치를 손으로 밀어 넣을 수 있느냐입니다. 현재 승격 경로, 롤백 메커니즘, 전체 트래픽 전에 섀도 배포나 카나리가 실제로 돌아간다는 증거를 가져오십시오. 재학습이 일정에 따르는지 드리프트로 촉발되는지, 재학습된 모델이 배포 전에 검증 관문을 통과하는지 논의하십시오. 검증 없이 라이브 데이터로 재학습하면 드리프트나 오염이 증폭되기 때문입니다. 답은 사람들이 따르리라 믿는 위키 페이지가 아니라 플랫폼에서 시행되어야 합니다.
MLOps 플랫폼을 오픈 소스 도구로 만들 것인가, 관리형을 살 것인가, 둘을 섞을 것인가? 종속을 따져 본 사람은 누구입니까? 이 선택은 앞으로 모든 모델이 얼마나 빨리 출하되는지, 데이터와 파이프라인에 대한 통제를 얼마나 유지하는지의 상한을 정합니다. 관리형 플랫폼은 팀을 빠르게 프로덕션으로 데려가고 지원을 지지만, 피처 정의, 계보 기록, 모델 산출물을 쉽게 떠날 수 없는 독점 형식에 가둘 수 있습니다. 조립한 오픈 소스 스택은 실제 통합과 유지보수 노동의 대가로 이식성을 유지해 줍니다. 각 경로의 총소유비용(라이선스 또는 구축, 저장소, 재학습용 컴퓨트, 운영할 플랫폼 인력), 인프라를 운영할 팀 역량에 대한 정직한 판독, 구체적인 퇴출 시험을 가져오십시오. 레지스트리, 피처 스토어, 계보를 내보내 다른 곳에서 다시 구축할 수 있는가? 기업과 정부 환경에서는 조달 제약과 데이터 주권 규칙을 더하십시오. 학습 데이터를 규제 기관이 금지하는 지역이나 형식에 저장하는 플랫폼은 아무리 편리해도 부적격이기 때문입니다.
피처 스토어와 모델 레지스트리는 하나의 중앙화된 플랫폼이어야 합니까, 팀별로 연합되어야 합니까? 학습-서빙 편향은 오늘 우리에게 얼마를 치르게 합니까? 피처 정의를 중앙화하면 피처가 학습에서는 한 방식으로, 서빙에서는 다른 방식으로 계산되는 편향이 없어집니다. 이는 조용하고 비싼 정확도 손실의 원천이지만, 단일 플랫폼은 모든 팀을 늦추는 병목이 될 수 있습니다. 연합은 팀에 자율을 주는 대신 배관과 두 팀이 같은 피처를 일관성 없이 정의할 가능성을 늘립니다. 편향이 이미 문 곳이 어디인지, 몇 팀이 피처를 재사용하고 몇 팀이 다시 만드는지, 공유 플랫폼 팀이 제공할 수 있는 포장된 길 기본값의 증거를 가져오십시오. 큰 조직에서는 감사 가능한 단일 기록 시스템의 거버넌스 이점을 중앙 대기열의 전달 비용에 견주어 저울질하고, 규제 환경에서는 감사자가 어떤 예측이든 그것을 만든 정확한 피처 코드까지 추적할 수 있게 해 주는 중앙화된 계보를 선호하십시오.
각 모델의 배포 패턴을 실제 지연, 신선도, 주권 필요에 맞췄습니까, 아니면 모든 것을 하나의 모양으로 기본 설정했습니까? 배치, 온라인, 스트리밍, 엣지는 각각 운영 비용과 복잡성이 매우 다르며, 잘못 고르면 야간 보고서에 필요 없던 실시간 인프라에 과소비하거나 사기 점수기가 의존하는 신선도를 굶깁니다. 요건이 실제로 정당화하는 패턴이 무엇인지 워크로드별로 정하고, 현대적으로 느껴진다는 이유로 가장 복잡한 옵션으로 표준화하는 것에 저항하십시오. 각 모델의 지연 예산, 물량, 오래된 답의 비용, 실측값 지연을 가져오십시오. 정부와 현장 환경에서는 엣지와 온프레미스 배포를 신중히 저울질하십시오. 데이터 주권 규칙이나 간헐적 연결이 모델을 로컬 하드웨어에 두도록 강제할 수 있고, 그 선택이 거기에 밀어 넣는 모든 모델의 버전 관리, 모니터링, 롤백 방식을 다시 형성하기 때문입니다.

분야별 관점

스타트업. 가장 희소한 자원은 엔지니어링의 주의이므로 MLOps를 가볍게 유지하고 사 쓰십시오. 단순한 호스팅 도구로 실험을 추적하고, 배포된 각 모델을 git의 학습 데이터 스냅샷과 코드 커밋에 고정하고, 플랫폼 대신 값싼 드리프트 검사 하나를 더하십시오. 두 번째나 세 번째 모델이 재사용을 값하게 할 때까지 피처 스토어와 맞춤 파이프라인은 건너뛰십시오. 유지할 수 없는 취약한 스택은 없는 역량보다 더 빨리 여러분을 가라앉힙니다.

소기업. ML 플랫폼 전문가도 빠듯한 예산도 있을 테니, MLOps를 인력을 두는 시스템이 아니라 이미 운영하는 도구에 내장된 것으로 다루십시오. 버전 관리, 배포, 모니터링을 대신 처리해 주는 관리형 서비스를 선호하고, 규율을 데이터 위생과 재현성의 문제로 구성하십시오. 어떤 모델과 데이터가 주어진 결과를 만들었는지 알고 롤백할 능력을 유지하십시오. 나중의 전환이 가능하도록 데이터와 모델을 내보낼 수 있는 벤더를 선호하십시오.

대기업. 문제는 수십 개 모델과 많은 팀에 걸친 규모입니다. 그룹들이 파이프라인을 다시 발명하지 않도록 공유 피처 스토어, 실험 추적, 거버넌스가 적용되는 승격이 있는 모델 레지스트리입니다. 포장된 길 기본값을 제공하는 플랫폼 팀에 예산을 잡고, 모든 모델이 감사 가능하고 모든 사고가 설명 가능하도록 계보와 모니터링을 표준화하고, 빌드 대 구매와 종속을 기저 도구가 교체 가능하게 유지하는 인터페이스 뒤에서 의도적으로 관리하십시오. 검증 관문과 롤백을 관례가 아니라 플랫폼에서 시행하십시오.

정부. 재현성, 계보, 버전 관리는 위장한 컴플라이언스 요건이므로 첫날부터 일급으로 다루십시오. 배포된 모든 모델 뒤의 정확한 데이터셋과 코드의 버전을 관리하고, 법적으로 요구되는 기간 동안 그 계보를 보존하고, 시민에게 영향을 준 과거의 어떤 예측이든 재현할 수 있어야 합니다. 중대한 결정은 사람이 리뷰하게 하고, 데이터 주권 규칙이 요구하는 곳에서는 엣지와 온프레미스 배포를 저울질하고, 어떤 벤더 플랫폼이든 데이터, 피처, 계보의 완전한 이식성을 보장하도록 요구하십시오.

사례

스타트업. 작은 분석 스타트업이 데이터 과학자 한 명과 가벼운 구성으로 첫 이탈 예측 모델을 출하했습니다. 단순한 호스팅 도구로 실험을 추적하고, 배포된 각 모델을 git의 학습 데이터 스냅샷과 코드 커밋에 고정하고, 최근 입력을 학습 분포와 비교하는 기본적인 주간 작업을 추가했습니다. 한 데이터 원천이 날짜 형식을 바꿔 예측이 드리프트하기 시작했을 때, 그 단순한 검사가 화난 고객의 전화 뒤가 아니라 며칠 안에 그것을 잡았고, 팀은 마지막 정상 모델을 재현해 롤백할 수 있었습니다.

기업. 한 소매 은행은 수십 개의 신용 및 사기 모델을 운영합니다. 팀 전반에 공유되는 피처 스토어, 실험 추적 서비스, 의무적 승인 관문이 있는 모델 레지스트리로 표준화했습니다. 프로덕션의 모든 모델은 학습 데이터 스냅샷과 코드 커밋으로 거슬러 추적됩니다. 사기 모델은 스트리밍 점수기로 배포되고 신용 모델은 배치로 돌아갑니다. 모니터링 계층이 입력 드리프트를 지켜보다 데이터 원천 스키마가 바뀌면 알리는데, 이는 한때 끊어진 상류 피드가 결정을 오염시키기 전에 잡아냈습니다.

정부. 한 공공 급여 기관은 사례 리뷰의 우선순위를 정하는 데 ML 모델을 씁니다. 그 결정이 시민의 서비스 접근에 영향을 주므로, 기관은 배포된 모든 모델 뒤의 정확한 데이터셋과 코드의 버전을 관리하고, 이 계보를 법적으로 요구되는 기간 동안 보존하며, 요청 시 과거의 어떤 예측이든 재현할 수 있습니다. 모델은 사람이 표시된 사례를 리뷰하는 배치로 배포되고, 들어오는 인구가 이동할 때마다 드리프트 모니터가 의무적 재평가를 강제하여, 모델이 검증된 조건 밖에 조용히 적용되는 일이 결코 없습니다.

비즈니스 사례: 동기, ROI, TCO

MLOps는 취약한 실험을 믿을 만한 자산으로 바꿔 스스로를 보상합니다. ROI는 새 모델의 더 빠른 프로덕션 도달 시간, 더 적은 비싼 사고, 더 적은 중복 인프라, 작은 플랫폼 팀으로 많은 모델을 운영하는 능력에서 나옵니다. 공유 피처 스토어와 레지스트리는 팀이 같은 배관을 다시 만들기를 멈추므로 모델당 전달 시간을 극적으로 줄일 수 있습니다.

TCO는 플랫폼 구축이나 라이선스, 버전 관리되는 데이터와 모델의 저장소, 재학습용 컴퓨트, 이 모두를 운영할 인력을 포함합니다. 이를 도입하지 않는 비용에 견주어 저울질하십시오. 재현하거나 감사할 수 없는 모델, 고객이나 시민을 해치는 조용한 실패, 규제 지적입니다. 규제 환경에서 감사의 설명할 수 없는 모델 비용은 MLOps 투자 전체를 압도할 수 있습니다. 리더십에는 MLOps를 오버헤드가 아니라 위험 감소와 전달 가속, 곧 모든 미래의 모델이 지나갈 포장된 길로 구성하여 설득하십시오.

안티패턴과 함정

노트북에서 프로덕션으로의 도약. 재현성 없이 거버넌스 없는 노트북에서 학습된 모델을 배포하는 것.
학습-서빙 편향. 학습과 서빙에서 다른 피처 코드로 조용한 정확도 손실을 일으키는 것.
데이터 버전 관리 없음. 코드의 버전은 관리하지만 데이터는 관리하지 않아 실행을 재현할 수 없는 것.
배포하고 잊기. 모니터링 없이 모델을 출하해 사용자가 불평할 때에야 저하를 발견하는 것.
자동 조종 재학습. 검증 없이 라이브 데이터로 자동 재학습해 드리프트나 오염을 증폭하는 것.
일회성 인프라. 모든 팀이 자기 파이프라인을 만들어 비용과 취약함을 늘리는 것.
지연된 레이블 무시. 실측값이 몇 주 뒤에 도착하는데 정확도를 즉시 측정할 수 있다고 가정하는 것.

성숙도 모델

시작. 모델이 노트북에서 즉흥적으로 만들어지고, 수동 배포, 데이터나 모델의 버전 관리 없음, 모니터링 없음. 과거 예측을 재현하는 것은 짐작입니다.
발전. 일부 실험 추적과 모델 레지스트리가 나타나지만 실천은 팀마다 다릅니다. 배포는 반자동화되고, 기본 모니터링이 몇 모델을 덮으며, 데이터 버전 관리는 부분적이고 계보에 틈이 있습니다.
표준화. 피처 스토어, 레지스트리, 재현 가능한 파이프라인, 끝에서 끝까지의 계보를 갖춘 공유 플랫폼이 문서화되어 조직 전체에서 시행됩니다. 드리프트와 데이터 품질 모니터링이 모델 전반에서 돌고, 승격과 롤백이 모든 팀이 쓰는 거버넌스 경로를 따릅니다.
관리. 군단이 기준선에 대해 측정됩니다. 드리프트율, 데이터 품질 단절, 지연된 실측값에 대한 모델 정확도, 학습-서빙 편향, 프로덕션 도달 시간, 모델별 운영 비용이 지표로 추적되고, 알림 임계값과 검증 관문이 증거에 따라 시행되며, 각 모델의 건강은 지명된 소유자와 함께 고정된 주기로 리뷰됩니다.
오케스트레이션. 수명 주기가 완전히 자동화되고, 감사 가능하며, 적응적입니다. 드리프트로 촉발되는 재학습이 검증 관문 뒤에서 돌고, 셀프서비스 포장된 길이 팀이 안전하게 출하하게 하며, 지속적 평가가 모델 성능을 비즈니스 지표에 묶고, 플랫폼이 전달, 위험, 컴플라이언스와 통합되어 데이터와 조건이 이동함에 따라 모델이 일상적으로 퇴역하고, 교체되고, 범위가 다시 정해집니다.

논의를 위한 아이디어

실험의 자유와 프로덕션 재현성의 균형을 어떻게 맞춥니까?
여러분의 사용 사례에 맞는 재학습 트리거(일정, 드리프트, 성능 쇠퇴)는 무엇입니까?
데이터와 모델 계보를 얼마나 오래 보존해야 하며, 무엇이 그 요건을 정합니까?
피처 스토어와 레지스트리는 중앙화된 플랫폼이어야 합니까, 팀별로 연합되어야 합니까?
실측 레이블이 긴 지연과 함께 도착할 때 정확도를 어떻게 모니터링합니까?
엣지 배포는 언제 추가된 운영 복잡성만큼 값을 합니까?

핵심 요점

ML의 행동은 코드와 데이터와 모델에서 나옵니다. 셋을 함께 버전 관리하고 다스리십시오.
피처 스토어, 실험 추적, 레지스트리가 재현 가능한 ML의 뼈대입니다.
계보는 모델을 감사 가능하게 하고 사고를 설명 가능하게 합니다. 규제 환경에서 필수입니다.
지연, 신선도, 주권 필요에 맞게 배치, 온라인, 스트리밍, 엣지를 고르십시오.
모델은 저하됩니다. 드리프트, 데이터 품질, 쇠퇴 모니터링은 선택이 아닙니다.

참고 문헌과 더 읽을거리

Chip Huyen, Designing Machine Learning Systems.
Andriy Burkov, Machine Learning Engineering.
D. Sculley et al., Hidden Technical Debt in Machine Learning Systems.
Mark Treveil et al., Introducing MLOps.
Valliappa Lakshmanan, Sara Robinson, and Michael Munn, Machine Learning Design Patterns.
Emmanuel Ameisen, Building Machine Learning Powered Applications.