سیستم های ML تولید: آزمایش استقرار
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
شما آماده استقرار مدل اسب شاخدار هستید که ظاهر اسب شاخدار را پیش بینی می کند! هنگام استقرار، خط لوله یادگیری ماشین (ML) شما باید بدون مشکل اجرا، به‌روزرسانی و ارائه شود. اگر فقط استقرار یک مدل به آسانی فشار دادن یک دکمه Deploy بزرگ بود. متأسفانه، یک سیستم کامل یادگیری ماشینی به آزمایش هایی برای موارد زیر نیاز دارد:
- اعتبارسنجی داده های ورودی
- اعتبارسنجی مهندسی ویژگی
- تایید کیفیت نسخه های مدل جدید.
- اعتبار سنجی زیرساخت های خدمات رسانی
- تست یکپارچگی بین اجزای خط لوله
بسیاری از مهندسان نرم افزار از توسعه تست محور (TDD) حمایت می کنند. در TDD، مهندسان نرم افزار قبل از نوشتن کد منبع "واقعی" تست هایی را می نویسند. با این حال، TDD می تواند در یادگیری ماشینی مشکل باشد. به عنوان مثال، قبل از آموزش مدل خود، نمی توانید تستی برای تایید ضرر بنویسید. در عوض، ابتدا باید زیان قابل دستیابی را در طول توسعه مدل کشف کنید و سپس نسخه های مدل جدید را در برابر ضرر قابل دستیابی آزمایش کنید.
در مورد مدل تک شاخ
این بخش به مدل تک شاخ اشاره دارد. در اینجا چیزی است که شما باید بدانید:
شما از یادگیری ماشینی برای ساخت یک مدل طبقه بندی استفاده می کنید که ظاهر تکشاخ را پیش بینی می کند. مجموعه داده شما 10000 ظاهر تکشاخ و 10000 تکشاخ غیر ظاهری را نشان می دهد. مجموعه داده شامل مکان، زمان روز، ارتفاع، دما، رطوبت، پوشش درخت، وجود رنگین کمان و چندین ویژگی دیگر است.
به روز رسانی مدل تست با آموزش تکراری
شاید بخواهید به بهبود مدل تک شاخ خود ادامه دهید. برای مثال، فرض کنید مهندسی ویژگی های اضافی را روی یک ویژگی خاص انجام می دهید و سپس مدل را مجدداً آموزش می دهید، به امید اینکه نتایج بهتر (یا حداقل مشابه) بگیرید. متأسفانه، گاهی اوقات بازتولید آموزش مدل دشوار است. برای بهبود تکرارپذیری، توصیه های زیر را دنبال کنید:
به طور قطعی مولد اعداد تصادفی را بذر کنید. برای جزئیات، به تصادفی سازی در تولید داده مراجعه کنید
اجزای مدل را با یک ترتیب ثابت راه اندازی کنید تا اطمینان حاصل شود که اجزا در هر اجرا همان عدد تصادفی را از مولد اعداد تصادفی دریافت می کنند. کتابخانه های ML معمولاً این نیاز را به طور خودکار انجام می دهند.
میانگین چند اجرا مدل را در نظر بگیرید.
از کنترل نسخه حتی برای تکرارهای اولیه استفاده کنید تا بتوانید هنگام بررسی مدل یا خط لوله خود کد و پارامترها را مشخص کنید.
حتی پس از پیروی از این رهنمودها، ممکن است منابع دیگری از غیر جبرگرایی همچنان وجود داشته باشد.
تست تماس‌ها به API یادگیری ماشین
چگونه به‌روزرسانی‌های تماس‌های API را آزمایش می‌کنید؟ شما می توانید مدل خود را مجدداً آموزش دهید، اما این کار زمان بر است. در عوض، یک تست واحد بنویسید تا داده‌های ورودی تصادفی تولید کند و یک مرحله از گرادیان نزول را اجرا کنید. اگر این مرحله بدون خطا تمام شود، احتمالاً هر گونه به روز رسانی در API مدل شما را خراب نکرده است.
تست های یکپارچه سازی اجزای خط لوله را بنویسید
در خط لوله ML، تغییرات در یک جزء می تواند باعث ایجاد خطا در اجزای دیگر شود. با نوشتن یک تست یکپارچه سازی که کل خط لوله را از سر به انتها اجرا می کند، بررسی کنید که اجزا با هم کار کنند.
علاوه بر اجرای مداوم تست‌های یکپارچه‌سازی، باید تست‌های یکپارچه‌سازی را هنگام فشار دادن مدل‌های جدید و نسخه‌های نرم‌افزار جدید اجرا کنید. کندی اجرای کل خط لوله، آزمایش یکپارچه سازی مداوم را سخت تر می کند. برای اجرای سریعتر تست‌های یکپارچه‌سازی، روی زیرمجموعه‌ای از داده‌ها یا با یک مدل ساده‌تر آموزش دهید. جزئیات به مدل و داده های شما بستگی دارد. برای دریافت پوشش مداوم، آزمایش‌های سریعتر خود را طوری تنظیم کنید که با هر نسخه جدید مدل یا نرم‌افزار اجرا شوند. در همین حال، تست های آهسته شما به طور مداوم در پس زمینه اجرا می شوند.
قبل از سرو کیفیت مدل را تأیید کنید
قبل از اینکه یک نسخه مدل جدید را به تولید فشار دهید، دو نوع کاهش کیفیت زیر را آزمایش کنید:
تخریب ناگهانی یک اشکال در نسخه جدید می تواند باعث کاهش قابل توجه کیفیت شود. نسخه های جدید را با بررسی کیفیت آنها در برابر نسخه قبلی اعتبار سنجی کنید.
تخریب آهسته آزمایش شما برای تخریب ناگهانی ممکن است کاهش آهسته کیفیت مدل را در چندین نسخه تشخیص ندهد. درعوض، اطمینان حاصل کنید که پیش‌بینی‌های مدل شما در مجموعه داده اعتبارسنجی یک آستانه ثابت را برآورده می‌کند. اگر مجموعه داده اعتبارسنجی شما از داده‌های زنده منحرف می‌شود، سپس مجموعه داده اعتبارسنجی خود را به‌روزرسانی کنید و مطمئن شوید که مدل شما همچنان از آستانه کیفیت یکسانی برخوردار است.
پیش از ارائه، سازگاری مدل و زیرساخت را تأیید کنید
اگر مدل شما سریعتر از سرور شما به روز می شود، آنگاه مدل شما می تواند وابستگی های نرم افزاری متفاوتی از سرور شما داشته باشد که به طور بالقوه باعث ناسازگاری می شود. با قرار دادن مدل در یک نسخه sandbox شده سرور، اطمینان حاصل کنید که عملیات استفاده شده توسط مدل در سرور وجود دارد.
جز در مواردی که غیر از این ذکر شده باشد،محتوای این صفحه تحت مجوز Creative Commons Attribution 4.0 License است. نمونه کدها نیز دارای مجوز Apache 2.0 License است. برای اطلاع از جزئیات، به خطمشیهای سایت Google Developers مراجعه کنید. جاوا علامت تجاری ثبتشده Oracle و/یا شرکتهای وابسته به آن است.
تاریخ آخرین به‌روزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین به‌روزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[[["\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)"]]
