프로덕션 ML 시스템: 배포 테스트
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이제 유니콘 출현을 예측하는 유니콘 모델을 배포할 준비가 되었습니다.
배포 시 머신러닝 (ML) 파이프라인이 문제 없이 실행, 업데이트, 제공되어야 합니다. 모델을 배포하는 것이 큰 배포 버튼을 누르는 것만큼이나 쉬웠으면 좋겠네요. 안타깝게도 전체 머신러닝 시스템에는 다음에 관한 테스트가 필요합니다.
- 입력 데이터 검증
- 특성 추출 유효성 검사
- 새 모델 버전의 품질 검증
- 게재 인프라 검증
- 파이프라인 구성요소 간의 통합을 테스트합니다.
많은 소프트웨어 엔지니어는 테스트 기반 개발 (TDD)을 선호합니다. TDD에서 소프트웨어 엔지니어는 '실제' 소스 코드를 작성하기 전에 테스트를 작성합니다.
하지만 머신러닝에서는 TDD가 까다로울 수 있습니다.
예를 들어 모델을 학습하기 전에 손실을 검증하는 테스트를 작성할 수 없습니다. 대신 먼저 모델 개발 중에 달성 가능한 손실을 발견한 후에 달성 가능한 손실에 대해 새 모델 버전을 테스트해야 합니다.
유니콘 모델 정보
이 섹션에서는 유니콘 모델을 참조합니다. 다음 사항에 유의하시기 바랍니다.
머신러닝을 사용하여 유니콘 출현을 예측하는 분류 모델을 빌드하고 있습니다. 데이터 세트에는 유니콘이 등장한 10,000개와 등장하지 않은 10,000개가 자세히 설명되어 있습니다. 데이터 세트에는 위치, 시간, 고도, 온도, 습도, 나무 덮음, 무지개 유무, 기타 여러 지형지물이 포함됩니다.
재현 가능한 학습을 사용하여 모델 업데이트 테스트
유니콘 모델을 계속 개선하고 싶을 수 있습니다. 예를 들어 특정 기능에 추가 특성 추출을 수행한 후 더 나은 결과 (또는 적어도 동일한 결과)를 얻기 위해 모델을 재학습한다고 가정해 보겠습니다.
안타깝게도 모델 학습을 재현하기 어려운 경우가 있습니다.
재현성을 개선하려면 다음 권장사항을 따르세요.
랜덤 숫자 생성기에 결정론적 시드를 설정합니다.
자세한 내용은 데이터 생성의 무작위화를 참고하세요.
모델 구성요소가 매 실행마다 난수 생성기에서 동일한 난수를 가져오도록 고정된 순서로 모델 구성요소를 초기화합니다.
ML 라이브러리는 일반적으로 이 요구사항을 자동으로 처리합니다.
모델을 여러 번 실행한 결과의 평균을 구합니다.
모델이나 파이프라인을 조사할 때 코드와 매개변수를 정확하게 파악할 수 있도록 사전 반복 시에도 버전 관리를 사용하세요.
이 가이드라인을 따르더라도 여전히 비결정론의 다른 소스가 존재할 수 있습니다.
머신러닝 API 호출 테스트
API 호출 업데이트를 테스트하려면 어떻게 해야 하나요? 모델을 재학습할 수도 있지만 시간이 많이 걸립니다. 대신 단위 테스트를 작성하여 무작위 입력 데이터를 생성하고 단일 단계의 경사 하강을 실행합니다. 이 단계가 오류 없이 완료되면 API 업데이트로 인해 모델이 손상되지 않은 것입니다.
파이프라인 구성요소의 통합 테스트 작성
ML 파이프라인에서 한 구성요소를 변경하면 다른 구성요소에 오류가 발생할 수 있습니다. 전체 파이프라인을 엔드 투 엔드 방식으로 실행하는 통합 테스트를 작성하여 구성요소가 함께 작동하는지 확인합니다.
통합 테스트를 지속적으로 실행하는 것 외에도 새 모델과 새 소프트웨어 버전을 푸시할 때 통합 테스트를 실행해야 합니다. 전체 파이프라인을 실행하는 속도가 느려 지속적 통합 테스트가 더 어려워집니다. 통합 테스트를 더 빠르게 실행하려면 데이터의 하위 집합을 사용하거나 더 간단한 모델을 사용하여 학습하세요. 세부정보는 모델과 데이터에 따라 다릅니다. 연속적인 적용 범위를 얻으려면 더 빠른 테스트가 모든 새 버전의 모델 또는 소프트웨어에서 실행되도록 조정합니다.
그동안 느린 테스트는 백그라운드에서 계속 실행됩니다.
모델 제공 전에 모델 품질 검증
새 모델 버전을 프로덕션으로 푸시하기 전에 다음 두 가지 유형의 품질 저하를 테스트합니다.
갑작스러운 성능 저하. 새 버전의 버그로 인해 품질이 크게 저하될 수 있습니다. 이전 버전과 비교하여 새 버전의 품질을 확인하여 유효성을 검사합니다.
느린 성능 저하 갑작스러운 성능 저하 테스트는 여러 버전에서 모델 품질이 느리게 저하되는 것을 감지하지 못할 수 있습니다. 대신 검증 데이터 세트에서 모델의 예측이 고정된 임곗값을 충족하는지 확인합니다. 검증 데이터 세트가 실시간 데이터와 다른 경우 검증 데이터 세트를 업데이트하고 모델이 여전히 동일한 품질 기준을 충족하는지 확인합니다.
제공하기 전에 모델-인프라 호환성 확인
모델이 서버보다 빠르게 업데이트되면 모델에 서버와 다른 소프트웨어 종속 항목이 있을 수 있으며, 이로 인해 비호환성이 발생할 수 있습니다. 서버의 샌드박스 버전에서 모델을 스테이징하여 모델에서 사용하는 작업이 서버에 있는지 확인합니다.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[null,null,["최종 업데이트: 2025-07-27(UTC)"],[[["\u003cp\u003eDeploying a machine learning model involves validating data, features, model versions, serving infrastructure, and pipeline integration.\u003c/p\u003e\n"],["\u003cp\u003eReproducible model training involves deterministic seeding, fixed initialization order, averaging multiple runs, and using version control.\u003c/p\u003e\n"],["\u003cp\u003eIntegration tests ensure that different components of the ML pipeline work together seamlessly, and should be run continuously and for new model/software versions.\u003c/p\u003e\n"],["\u003cp\u003eBefore serving a new model, validate its quality by checking for sudden and slow degradations against previous versions and fixed thresholds.\u003c/p\u003e\n"],["\u003cp\u003eEnsure model-infrastructure compatibility by staging the model in a sandboxed server environment to avoid dependency conflicts.\u003c/p\u003e\n"]]],[],null,["# Production ML systems: Deployment testing\n\nYou're ready to deploy the unicorn model that predicts unicorn appearances!\nWhen deploying, your machine learning (ML) pipeline should run, update, and\nserve without a problem. If only deploying a model were as easy as pressing\na big **Deploy** button. Unfortunately, a full machine learning system\nrequires tests for:\n\n- Validating input data.\n- Validating feature engineering.\n- Validating the quality of new model versions.\n- Validating serving infrastructure.\n- Testing integration between pipeline components.\n\nMany software engineers favor test-driven development (TDD). In TDD, software\nengineers write tests *prior* to writing the \"real\" source code.\nHowever, TDD can be tricky in machine learning.\nFor example, before training your model, you can't write a test to validate\nthe loss. Instead, you must first discover the achievable loss during model\ndevelopment and *then* test new model versions against the achievable loss.\n\nAbout the unicorn model\n-----------------------\n\nThis section refers to the **unicorn model**. Here's what you need to know:\n\u003e You are using machine learning to build a classification model that predicts\n\u003e unicorn appearances. Your dataset details 10,000 unicorn appearances and\n\u003e 10,000 unicorn non-appearances. The dataset contains the location,\n\u003e time of day, elevation, temperature, humidity, tree cover, presence of a\n\u003e rainbow, and several other features.\n\nTest model updates with reproducible training\n---------------------------------------------\n\nPerhaps you want to continue improving your unicorn model. For example, suppose\nyou do some additional feature engineering on a certain feature and then\nretrain the model, hoping to get better (or at least the same) results.\nUnfortunately, it is sometimes difficult to reproduce model training.\nTo improve reproducibility, follow these recommendations:\n\n- Deterministically seed the random number generator.\n For details, see [randomization in data\n generation](/machine-learning/crash-course/production-ml-systems/monitoring#randomization)\n\n- Initialize model components in a fixed order to ensure the components get the\n same random number from the random number generator on every run.\n ML libraries typically handle this requirement automatically.\n\n- Take the average of several runs of the model.\n\n- Use version control, even for preliminary iterations, so that you can\n pinpoint code and parameters when investigating your model or pipeline.\n\nEven after following these guidelines, other sources of nondeterminism might\nstill exist.\n\nTest calls to machine learning API\n----------------------------------\n\nHow do you test updates to API calls? You could retrain your model, but\nthat's time intensive. Instead, write a unit test to generate random input data\nand run a single step of gradient descent. If this step completes without\nerrors, then any updates to the API probably haven't ruined your model.\n\nWrite integration tests for pipeline components\n-----------------------------------------------\n\nIn an ML pipeline, changes in one component can cause errors in other\ncomponents. Check that components work together by writing an\n**integration test** that runs the entire pipeline end-to-end.\n\nBesides running integration tests continuously, you should run integration tests\nwhen pushing new models and new software versions. The slowness of running the\nentire pipeline makes continuous integration testing harder. To run integration\ntests faster, train on a subset of the data or with a simpler model. The details\ndepend on your model and data. To get continuous coverage, you'd adjust your\nfaster tests so that they run with every new version of model or software.\nMeanwhile, your slow tests would run continuously in the background.\n\nValidate model quality before serving\n-------------------------------------\n\nBefore pushing a new model version to production, test for\nthe following two types of quality degradations:\n\n- **Sudden degradation.** A bug in the new version could cause significantly\n lower quality. Validate new versions by checking their quality\n against the previous version.\n\n- **Slow degradation.** Your test for sudden degradation might not detect a slow\n degradation in model quality over multiple versions. Instead, ensure your\n model's predictions on a validation dataset meet a fixed threshold. If your\n validation dataset deviates from live data, then update your validation\n dataset and ensure your model still meets the same quality threshold.\n\nValidate model-infrastructure compatibility before serving\n----------------------------------------------------------\n\nIf your model is updated faster than your server, then your model could have\ndifferent software dependencies from your server, potentially causing\nincompatibilities. Ensure that the operations used by the model are present in\nthe server by staging the model in a sandboxed version of the server.\n| **Key terms:**\n|\n| - [Training-serving skew](/machine-learning/glossary#training-serving-skew)\n- [Z-score normalization](/machine-learning/glossary#z-score-normalization) \n[Help Center](https://support.google.com/machinelearningeducation)"]]
