ระบบ ML เวอร์ชันที่ใช้งานจริง: การทดสอบการติดตั้งใช้งาน
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
คุณพร้อมที่จะทําให้โมเดลยูนิคอร์นที่คาดการณ์การปรากฏตัวของยูนิคอร์นใช้งานได้แล้ว
เมื่อทําการนําไปใช้งานไปป์ไลน์แมชชีนเลิร์นนิง (ML) ควรทํางาน อัปเดต และให้บริการได้โดยไม่มีปัญหา หากการทําให้โมเดลใช้งานได้ง่ายเหมือนการกดปุ่มทําให้ใช้งานได้ ขออภัย ระบบแมชชีนเลิร์นนิงแบบสมบูรณ์จำเป็นต้องมีการทดสอบสิ่งต่อไปนี้
- การตรวจสอบข้อมูลอินพุต
- การตรวจสอบการสร้างฟีเจอร์
- ตรวจสอบคุณภาพของโมเดลเวอร์ชันใหม่
- กำลังตรวจสอบโครงสร้างพื้นฐานการแสดงโฆษณา
- การทดสอบการผสานรวมระหว่างคอมโพเนนต์ของไปป์ไลน์
วิศวกรซอฟต์แวร์จํานวนมากชอบการพัฒนาที่ขับเคลื่อนโดยทดสอบ (TDD) ใน TDD วิศวกรซอฟต์แวร์จะเขียนการทดสอบก่อนเขียนซอร์สโค้ด "จริง"
อย่างไรก็ตาม TDD อาจใช้ยากในแมชชีนเลิร์นนิง
ตัวอย่างเช่น คุณจะเขียนการทดสอบเพื่อตรวจสอบการสูญเสียไม่ได้ก่อนที่จะฝึกโมเดล แต่คุณต้องค้นหาการสูญเสียที่ทำได้ในระหว่างการพัฒนาโมเดลก่อน แล้วจากนั้นทดสอบโมเดลเวอร์ชันใหม่เทียบกับการสูญเสียที่ทำได้
เกี่ยวกับรูปแบบยูนิคอร์น
ส่วนนี้กล่าวถึงโมเดลยูนิคอร์น สิ่งที่จำเป็นต้องทราบมีดังนี้
คุณกำลังใช้แมชชีนเลิร์นนิงเพื่อสร้างโมเดลการจัดประเภทที่คาดการณ์ลักษณะของยูนิคอร์น ชุดข้อมูลของคุณมีรายละเอียดเกี่ยวกับ Unicorn ที่ปรากฏ 10,000 รายการและ Unicorn ที่ไม่ปรากฏ 10,000 รายการ ชุดข้อมูลประกอบด้วยสถานที่ เวลาของวัน ความสูง อุณหภูมิ ความชื้น ต้นไม้ ปรากฏการณ์รุ้ง และองค์ประกอบอื่นๆ อีกมากมาย
ทดสอบการอัปเดตโมเดลด้วยการฝึกที่ทําซ้ำได้
หรือคุณอาจต้องการปรับปรุงโมเดล Unicorn ต่อไป ตัวอย่างเช่น สมมติว่าคุณทําวิศวกรรมด้านฟีเจอร์เพิ่มเติมในฟีเจอร์หนึ่ง แล้วฝึกโมเดลอีกครั้งโดยหวังว่าจะได้ผลลัพธ์ที่ดีขึ้น (หรืออย่างน้อยก็เหมือนเดิม)
ขออภัย บางครั้งการฝึกโมเดลอาจทำซ้ำได้ยาก
ทําตามคําแนะนําต่อไปนี้เพื่อปรับปรุงความสามารถในการทำซ้ำ
กำหนดค่าเริ่มต้นให้กับโปรแกรมสร้างตัวเลขสุ่มอย่างมีเหตุผล
โปรดดูรายละเอียดที่หัวข้อการสุ่มตัวอย่างในการสร้างข้อมูล
เริ่มต้นคอมโพเนนต์ของโมเดลตามลําดับที่กําหนดเพื่อให้คอมโพเนนต์ได้รับตัวเลขสุ่มเดียวกันจากเครื่องสร้างตัวเลขสุ่มทุกครั้งที่เรียกใช้
โดยปกติแล้วไลบรารี ML จะจัดการข้อกําหนดนี้โดยอัตโนมัติ
นำค่าเฉลี่ยของการเรียกใช้โมเดลหลายครั้ง
ใช้การควบคุมเวอร์ชันแม้กระทั่งกับการทำซ้ำขั้นต้น เพื่อให้คุณระบุโค้ดและพารามิเตอร์ได้เมื่อตรวจสอบรูปแบบหรือไปป์ไลน์
แม้ว่าจะปฏิบัติตามหลักเกณฑ์เหล่านี้แล้ว แต่แหล่งที่มาอื่นๆ ของความไม่แน่นอนก็อาจยังคงอยู่
ทดสอบการเรียก API การเรียนรู้ของเครื่อง
คุณทดสอบการอัปเดตการเรียก API อย่างไร คุณสามารถฝึกโมเดลใหม่ได้ แต่วิธีนี้ใช้เวลานาน แต่ให้เขียนการทดสอบหน่วยเพื่อสร้างข้อมูลอินพุตแบบสุ่มและเรียกใช้ขั้นตอนเดียวของการลดเชิงลาดแทน หากขั้นตอนนี้เสร็จสมบูรณ์โดยไม่มีข้อผิดพลาด การอัปเดต API ใดๆ ก็ไม่น่าจะทำลายโมเดลของคุณ
เขียนการทดสอบการผสานรวมสําหรับคอมโพเนนต์ไปป์ไลน์
ในไปป์ไลน์ ML การเปลี่ยนแปลงในคอมโพเนนต์หนึ่งอาจทำให้เกิดข้อผิดพลาดในคอมโพเนนต์อื่นๆ ตรวจสอบว่าคอมโพเนนต์ทํางานร่วมกันโดยเขียนการทดสอบการผสานรวมที่เรียกใช้ไปป์ไลน์ทั้งหมดตั้งแต่ต้นจนจบ
นอกจากการทดสอบการผสานรวมอย่างต่อเนื่องแล้ว คุณควรทำการทดสอบการผสานรวมเมื่อมีการพุชโมเดลใหม่และซอฟต์แวร์เวอร์ชันใหม่ การทำงานที่ช้าของไปป์ไลน์ทั้งระบบทำให้การทดสอบการผสานรวมอย่างต่อเนื่องทำได้ยากขึ้น หากต้องการเรียกใช้การทดสอบการผสานรวมได้เร็วขึ้น ให้ฝึกโมเดลด้วยชุดข้อมูลย่อยหรือโมเดลที่ง่ายขึ้น โดยรายละเอียดจะขึ้นอยู่กับโมเดลและข้อมูลของคุณ หากต้องการให้ครอบคลุมอย่างต่อเนื่อง คุณจะต้องปรับการทดสอบที่เร็วขึ้นเพื่อให้ทํางานกับโมเดลหรือซอฟต์แวร์เวอร์ชันใหม่ทุกเวอร์ชัน
ในระหว่างนี้ การทดสอบที่ช้าจะทำงานอย่างต่อเนื่องในเบื้องหลัง
ตรวจสอบคุณภาพโมเดลก่อนแสดง
ก่อนพุชโมเดลเวอร์ชันใหม่ไปยังเวอร์ชันที่ใช้งานจริง ให้ทดสอบการลดลงของคุณภาพ 2 ประเภทต่อไปนี้
คุณภาพลดลงอย่างฉับพลัน ข้อบกพร่องในเวอร์ชันใหม่อาจทำให้คุณภาพลดลงอย่างมาก ตรวจสอบเวอร์ชันใหม่โดยตรวจสอบคุณภาพเทียบกับเวอร์ชันก่อนหน้า
การเสื่อมสภาพช้า การทดสอบการลดลงอย่างฉับพลันอาจไม่ตรวจพบการลดลงอย่างช้าๆ ในคุณภาพของโมเดลในหลายเวอร์ชัน แต่ให้ตรวจสอบว่าการคาดการณ์ของรูปแบบในชุดข้อมูลที่ใช้ตรวจสอบเป็นไปตามเกณฑ์ที่กำหนดไว้ หากชุดข้อมูลที่ใช้ตรวจสอบเบี่ยงเบนจากข้อมูลจริง ให้อัปเดตชุดข้อมูลที่ใช้ตรวจสอบและตรวจสอบว่าโมเดลยังคงเป็นไปตามเกณฑ์คุณภาพเดิม
ตรวจสอบความเข้ากันได้ของโมเดลกับโครงสร้างพื้นฐานก่อนแสดง
หากโมเดลอัปเดตเร็วกว่าเซิร์ฟเวอร์ โมเดลอาจมีการพึ่งพาซอฟต์แวร์แตกต่างจากเซิร์ฟเวอร์ ซึ่งอาจทําให้ใช้งานร่วมกันไม่ได้ ตรวจสอบว่าการดำเนินการที่โมเดลใช้มีอยู่ในเซิร์ฟเวอร์โดยการจัดเตรียมโมเดลในเซิร์ฟเวอร์เวอร์ชันที่ใช้แซนด์บ็อกซ์
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ 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)"]]
