การทดสอบ
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
การทดสอบช่วยให้โปรเจ็กต์มีความเป็นไปได้ สมมติฐานเหล่านี้เป็นสมมติฐานที่ทดสอบได้และทําซ้ำได้ เมื่อทำการทดสอบ เป้าหมายคือปรับปรุงอย่างต่อเนื่องโดยประเมินสถาปัตยกรรมและฟีเจอร์ต่างๆ ของโมเดล สิ่งที่ควรทําเมื่อทดสอบมีดังนี้
กําหนดประสิทธิภาพพื้นฐาน เริ่มต้นด้วยการสร้างเมตริกพื้นฐาน ข้อมูลพื้นฐานจะทำหน้าที่เป็นไม้วัดเพื่อเปรียบเทียบการทดสอบ
ในบางกรณี โซลูชันที่ไม่ใช่ ML ปัจจุบันอาจให้เมตริกพื้นฐานแรกได้ หากยังไม่มีโซลูชัน ให้สร้างโมเดล ML ที่มีสถาปัตยกรรมแบบง่าย ฟีเจอร์ 2-3 รายการ และใช้เมตริกของโมเดลเป็นพื้นฐาน
ทําการเปลี่ยนแปลงเล็กๆ น้อยๆ เพียงครั้งเดียว เปลี่ยนแปลงเพียงครั้งละ 1 รายการเล็กๆ เท่านั้น เช่น เปลี่ยนไฮเปอร์พารามิเตอร์ สถาปัตยกรรม หรือฟีเจอร์ หากการเปลี่ยนแปลงปรับปรุงโมเดลได้ เมตริกของโมเดลนั้นจะกลายเป็นฐานใหม่เพื่อเปรียบเทียบกับการทดสอบในอนาคต
ต่อไปนี้เป็นตัวอย่างการทดสอบที่ทําการเปลี่ยนแปลงเล็กๆ เพียงครั้งเดียว
- รวมฟีเจอร์ X
- ใช้ Dropout 0.5 ในเลเยอร์ที่ซ่อนอยู่เลเยอร์แรก
- ใช้การเปลี่ยนรูปแบบเชิงลอกของฟีเจอร์ Y
- เปลี่ยนอัตราการเรียนรู้เป็น 0.001
บันทึกความคืบหน้าของการทดสอบ คุณอาจต้องทําการทดสอบหลายครั้ง การทดสอบที่มีคุณภาพการคาดการณ์ไม่ดี (หรือเป็นกลาง) เมื่อเทียบกับเส้นฐานยังคงมีประโยชน์ต่อการติดตาม ข้อมูลเหล่านี้จะบ่งชี้ว่าแนวทางใดใช้ไม่ได้ เนื่องจากโดยทั่วไปแล้วความคืบหน้าจะไม่เป็นไปตามลําดับ จึงจําเป็นต้องแสดงให้เห็นว่าคุณกําลังพยายามแก้ไขปัญหาโดยไฮไลต์วิธีทั้งหมดที่คุณพบว่าไม่ได้ผล นอกเหนือจากความคืบหน้าในการปรับปรุงคุณภาพพื้นฐาน
เนื่องจากการฝึกแบบเต็มแต่ละครั้งในชุดข้อมูลในชีวิตจริงอาจใช้เวลาหลายชั่วโมง (หรือหลายวัน) ให้ลองทำการทดสอบอิสระหลายรายการพร้อมกันเพื่อสำรวจพื้นที่ทำงานอย่างรวดเร็ว เมื่อทำซ้ำไปเรื่อยๆ คุณก็น่าจะเข้าใกล้ระดับคุณภาพที่ต้องการสำหรับเวอร์ชันที่ใช้งานจริงมากขึ้นเรื่อยๆ
สัญญาณรบกวนในการทดสอบ
โปรดทราบว่าคุณอาจพบสัญญาณรบกวนในผลการทดสอบที่ไม่ได้มาจากการเปลี่ยนแปลงโมเดลหรือข้อมูล ซึ่งทําให้ตัดสินได้ยากว่าการเปลี่ยนแปลงที่คุณทํานั้นช่วยปรับปรุงโมเดลได้จริงหรือไม่ ตัวอย่างของสิ่งที่อาจทำให้เกิดสัญญาณรบกวนในการทดสอบมีดังนี้
การสับข้อมูล: ลําดับที่นําเสนอข้อมูลต่อโมเดลอาจส่งผลต่อประสิทธิภาพของโมเดล
การจัดเตรียมตัวแปร: วิธีที่ระบบจัดเตรียมตัวแปรของโมเดลอาจส่งผลต่อประสิทธิภาพของโมเดลด้วย
การทำงานแบบขนานแบบไม่พร้อมกัน: หากโมเดลได้รับการฝึกโดยใช้การทำงานแบบขนานแบบไม่พร้อมกัน ลำดับการอัปเดตส่วนต่างๆ ของโมเดลก็อาจส่งผลต่อประสิทธิภาพของโมเดลได้เช่นกัน
ชุดการประเมินขนาดเล็ก: หากชุดการประเมินมีขนาดเล็กเกินไป ก็อาจไม่ได้แสดงถึงประสิทธิภาพโดยรวมของโมเดล ซึ่งจะทําให้คุณภาพของโมเดลมีความผันผวนไม่สม่ำเสมอ
การทดสอบหลายครั้งจะช่วยยืนยันผลลัพธ์การทดสอบ
ปรับแนวทางปฏิบัติการทดสอบให้สอดคล้องกัน
ทีมของคุณควรเข้าใจความหมายของ "การทดสอบ" อย่างชัดเจน โดยมีชุดแนวทางปฏิบัติและอาร์ติแฟกต์ที่กําหนดไว้ คุณจะต้องมีเอกสารที่ระบุข้อมูลต่อไปนี้
อาร์ติแฟกต์ อาร์ติแฟกต์สําหรับการทดสอบคืออะไร ในกรณีส่วนใหญ่ การทดสอบคือสมมติฐานที่ทดสอบแล้วซึ่งสามารถทําซ้ำได้ โดยปกติแล้วคือการบันทึกข้อมูลเมตา (เช่น ฟีเจอร์และไฮเปอร์พารามิเตอร์) ที่ระบุการเปลี่ยนแปลงระหว่างการทดสอบและผลกระทบต่อคุณภาพของโมเดล
แนวทางการเขียนโค้ด ทุกคนจะใช้สภาพแวดล้อมการทดสอบของตนเองไหม
การนำงานของทุกคนมารวมไว้ในคลังที่ใช้ร่วมกันทำได้ยาก (หรือง่าย) เพียงใด
ความสามารถในการทำซ้ำและการติดตาม มาตรฐานของการทําซ้ำมีอะไรบ้าง เช่น ทีมควรใช้ไปป์ไลน์ข้อมูลและแนวทางการกำหนดเวอร์ชันเดียวกัน หรือจะแสดงเฉพาะผังก็ได้ ระบบจะบันทึกข้อมูลการทดสอบอย่างไร เป็นการค้นหา SQL หรือสแนปชอตโมเดล บันทึกบันทึกจากการทดสอบแต่ละรายการไว้ที่ใด ในเอกสาร สเปรดชีต หรือ CMS สำหรับจัดการการทดสอบ
การคาดคะเนที่ไม่ถูกต้อง
ไม่มีโมเดลในโลกแห่งความเป็นจริงที่สมบูรณ์แบบ ระบบจะจัดการกับการคาดการณ์ที่ไม่ถูกต้องอย่างไร
เริ่มคิดหาวิธีจัดการกับปัญหาตั้งแต่เนิ่นๆ
กลยุทธ์แนวทางปฏิบัติแนะนำจะกระตุ้นให้ผู้ใช้ติดป้ายกำกับการคาดการณ์ที่ไม่ถูกต้องอย่างถูกต้อง
เช่น แอปอีเมลจะบันทึกอีเมลที่จัดประเภทไม่ถูกต้องโดยการบันทึกอีเมลที่ผู้ใช้ย้ายไปยังโฟลเดอร์จดหมายขยะ รวมถึงการย้ายกลับจากโฟลเดอร์จดหมายขยะ การบันทึกป้ายกำกับข้อมูลที่ได้จากการสังเกตการณ์จากผู้ใช้จะช่วยให้คุณออกแบบลูปความคิดเห็นอัตโนมัติสําหรับการเก็บรวบรวมข้อมูลและการฝึกโมเดลใหม่ได้
โปรดทราบว่าแม้ว่าแบบสํารวจที่ฝังใน UI จะเก็บความคิดเห็นของผู้ใช้ แต่โดยทั่วไปข้อมูลจะเป็นเชิงคุณภาพและไม่สามารถรวมไว้ในข้อมูลการฝึกใหม่ได้
ใช้โซลูชันแบบครบวงจร
ขณะที่ทีมของคุณกำลังทดสอบโมเดล คุณควรเริ่มสร้างบางส่วนของไปป์ไลน์สุดท้าย (หากมีทรัพยากร)
การสร้างส่วนต่างๆ ของไปป์ไลน์ เช่น การรับข้อมูลและการเทรนโมเดลอีกครั้ง จะช่วยให้ย้ายโมเดลสุดท้ายไปยังเวอร์ชันที่ใช้งานจริงได้ง่ายขึ้น เช่น การมีไปป์ไลน์ตั้งแต่ต้นจนจบสำหรับการส่งผ่านข้อมูลและแสดงการคาดการณ์จะช่วยให้ทีมเริ่มผสานรวมโมเดลเข้ากับผลิตภัณฑ์และเริ่มการทดสอบผู้ใช้ระยะแรกได้
การแก้ปัญหาโปรเจ็กต์ที่หยุดชะงัก
คุณอาจอยู่ในสถานการณ์ที่ความคืบหน้าของโปรเจ็กต์หยุดชะงัก ทีมของคุณอาจทําการทดสอบที่ดูเหมือนจะประสบความสําเร็จ แต่ปรับปรุงรูปแบบไม่สําเร็จเป็นเวลาหลายสัปดาห์ คุณควรทำอย่างไร แนวทางที่เป็นไปได้มีดังนี้
เชิงกลยุทธ์ คุณอาจต้องปรับมุมมองปัญหาใหม่ หลังจากใช้เวลาในเฟสการทดสอบแล้ว คุณน่าจะเข้าใจปัญหา ข้อมูล และวิธีแก้ปัญหาที่เป็นไปได้มากขึ้น เมื่อมีความรู้เกี่ยวกับโดเมนมากขึ้น คุณอาจระบุปัญหาได้แม่นยำยิ่งขึ้น
ตัวอย่างเช่น ตอนแรกคุณอาจต้องการใช้การถดถอยเชิงเส้นเพื่อคาดการณ์ค่าตัวเลข แต่ข้อมูลไม่เพียงพอที่จะฝึกโมเดลการหาค่าสัมประสิทธิ์การถดถอยเชิงเส้นที่ใช้งานได้ การวิเคราะห์เพิ่มเติมอาจแสดงให้เห็นว่าปัญหาแก้ไขได้ด้วยการคาดคะเนว่าตัวอย่างอยู่เหนือหรือต่ำกว่าค่าที่เจาะจง วิธีนี้ช่วยให้คุณจัดเฟรมปัญหาใหม่เป็นการแยกประเภทแบบ 2 กลุ่ม
หากความคืบหน้าช้ากว่าที่คาดไว้ ก็อย่าเพิ่งหมดหวัง การปรับปรุงอย่างต่อเนื่องเมื่อเวลาผ่านไปอาจเป็นวิธีเดียวในการแก้ปัญหา ดังที่กล่าวไว้ก่อนหน้านี้ อย่าคาดหวังว่าความคืบหน้าจะเท่ากันทุกสัปดาห์ การสร้างโมเดลเวอร์ชันที่พร้อมใช้งานจริงมักใช้เวลานาน
การปรับปรุงโมเดลอาจไม่สม่ำเสมอและคาดเดาไม่ได้ ระยะเวลาที่ความคืบหน้าช้าอาจตามด้วยการปรับปรุงที่เพิ่มขึ้นอย่างรวดเร็ว หรือในทางกลับกัน
เทคนิค ใช้เวลาในการวินิจฉัยและวิเคราะห์การคาดการณ์ที่ไม่ถูกต้อง ในบางกรณี คุณสามารถค้นหาปัญหาได้โดยแยกการคาดคะเนที่ไม่ถูกต้อง 2-3 รายการออก แล้ววิเคราะห์ลักษณะการทํางานของโมเดลในอินสแตนซ์เหล่านั้น เช่น คุณอาจพบปัญหาเกี่ยวกับสถาปัตยกรรมหรือข้อมูล ส่วนในกรณีอื่นๆ การรวบรวมข้อมูลเพิ่มเติมอาจช่วยได้ คุณอาจได้รับสัญญาณที่ชัดเจนขึ้นซึ่งบ่งบอกว่าคุณมาถูกทางแล้ว หรืออาจทำให้เกิดสัญญาณรบกวนมากขึ้น ซึ่งบ่งบอกว่ามีประเด็นอื่นๆ เกิดขึ้นในแนวทางนี้
หากกำลังแก้ปัญหาที่ต้องอาศัยชุดข้อมูลที่ติดป้ายกำกับโดยมนุษย์ คุณอาจหาชุดข้อมูลที่ติดป้ายกำกับสำหรับการประเมินโมเดลได้ยาก ค้นหาแหล่งข้อมูลเพื่อรับชุดข้อมูลที่จำเป็นสำหรับการประเมิน
อาจเป็นเพราะไม่มีวิธีแก้ปัญหา กําหนดเวลาสําหรับแนวทางของคุณ โดยหยุดหากไม่ได้รับความคืบหน้าภายในกรอบเวลา อย่างไรก็ตาม หากคุณมีข้อความที่แสดงถึงปัญหาอย่างชัดเจน ก็อาจจำเป็นต้องหาวิธีแก้ปัญหา
ทดสอบความเข้าใจ
สมาชิกในทีมพบชุดค่าผสมของไฮเปอร์พารามิเตอร์ที่ช่วยปรับปรุงเมตริกโมเดลพื้นฐาน สมาชิกคนอื่นๆ ในทีมควรทำอย่างไร
อาจใช้ไฮเปอร์พารามิเตอร์ 1 รายการ แต่ทำการทดสอบต่อไป
ถูกต้อง หากไฮเปอร์พารามิเตอร์รายการใดรายการหนึ่งดูเป็นตัวเลือกที่เหมาะสม ให้ลองใช้ อย่างไรก็ตาม ตัวเลือกไฮเปอร์พารามิเตอร์บางรายการอาจไม่เหมาะสมในบริบทการทดสอบบางบริบท
เปลี่ยนไฮเปอร์พารามิเตอร์ทั้งหมดในการทดสอบปัจจุบันให้ตรงกับของเพื่อนร่วมงาน
ไฮเปอร์พารามิเตอร์ที่ปรับปรุงโมเดลหนึ่งไม่ได้หมายความว่าจะปรับปรุงโมเดลอื่นด้วย สมาชิกคนอื่นๆ ในทีมควรทำการทดสอบต่อไป ซึ่งอาจช่วยปรับปรุงฐานบรรทัดฐานได้มากขึ้นในภายหลัง
เริ่มสร้างไปป์ไลน์จากต้นทางถึงปลายทางที่จะนําไปใช้ติดตั้งใช้งานโมเดล
การที่โมเดลปรับปรุงเส้นฐานไม่ได้หมายความว่าโมเดลนั้นจะเป็นโมเดลที่จะนำไปใช้งานจริง จึงควรทำการทดสอบต่อไป ซึ่งอาจช่วยปรับปรุงเส้นฐานให้ดียิ่งขึ้นได้ในอนาคต
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 UTC
[null,null,["อัปเดตล่าสุด 2025-07-27 UTC"],[[["\u003cp\u003eExperiments involve making single, small, iterative changes to model features, architecture, or hyperparameters to improve performance compared to a baseline.\u003c/p\u003e\n"],["\u003cp\u003eIt's crucial to track all experimental results, including unsuccessful ones, to understand which approaches work and which don't.\u003c/p\u003e\n"],["\u003cp\u003eTeams should establish clear experimentation practices, including defining artifacts, coding standards, reproducibility measures, and tracking methods.\u003c/p\u003e\n"],["\u003cp\u003ePlan for handling wrong predictions early on, potentially by incorporating user feedback for model improvement.\u003c/p\u003e\n"],["\u003cp\u003eConsider building parts of the final pipeline alongside experimentation to facilitate a smoother transition to production.\u003c/p\u003e\n"]]],[],null,["# Experiments drive a project toward viability. They are testable and\nreproducible hypotheses. When running experiments, the\ngoal is to make continual, incremental improvements by evaluating a variety of\nmodel architectures and features. When experimenting, you'll want to do\nthe following:\n\n- **Determine baseline performance.** Start by establishing a\n [baseline](/machine-learning/glossary#baseline) metric. The baseline\n acts as a measuring stick to compare experiments against.\n\n In some cases, the current non-ML solution can provide the first baseline\n metric. If no solution currently exists, create a ML model with a simple\n architecture, a few features, and use its metrics as the baseline.\n- **Make single, small changes.** Make only a single, small change at a time,\n for example, to the hyperparameters, architecture, or features. If the\n change improves the model, that model's metrics become the new baseline to\n compare future experiments against.\n\n The following are examples of experiments that make a single, small change:\n - include feature *X*.\n - use 0.5 dropout on the first hidden layer.\n - take the log transform of feature *Y*.\n - change the learning rate to 0.001.\n- **Record the progress of the experiments.** You'll most likely need to do\n lots of experiments. Experiments with poor (or neutral) prediction quality\n compared to the baseline are still useful to track. They signal which\n approaches won't work. Because progress is typically non-linear, it's\n important to show that you're working on the problem by highlighting all\n the ways you found that don't work---in addition to your progress at\n increasing the baseline quality.\n\nBecause each full training on a real-world dataset can take hours (or days),\nconsider running multiple independent experiments concurrently to explore the\nspace quickly. As you continue to iterate, you'll hopefully get closer and\ncloser to the level of quality you'll need for production.\n\n### Noise in experimental results\n\nNote that you might encounter noise in experimental results that aren't from\nchanges to the model or the data, making it difficult to determine if a change\nyou made actually improved the model. The following are examples of things that\ncan produce noise in experimental results:\n\n- Data shuffling: The order in which the data is presented to the model can\n affect the model's performance.\n\n- Variable initialization: The way in which the model's\n variables are initialized can also affect its performance.\n\n- Asynchronous parallelism: If the model is trained using asynchronous\n parallelism, the order in which the different parts of the model are updated\n can also affect its performance.\n\n- Small evaluation sets: If the evaluation set is too small, it may\n not be representative of the overall performance of the model, producing\n uneven variations in the model's quality.\n\nRunning an experiment multiple times helps confirm experimental results.\n\n### Align on experimentation practices\n\nYour team should have a clear understanding of what exactly an \"experiment\" is,\nwith a defined set of practices and artifacts. You'll want documentation that\noutlines the following:\n\n- **Artifacts.** What are the artifacts for an experiment? In most cases, an\n experiment is a tested hypothesis that can be reproduced, typically by\n logging the metadata (like the features and hyperparameters) that indicate\n the changes between experiments and how they affect model quality.\n\n- **Coding practices.** Will everyone use their own experimental environments?\n How possible (or easy) will it be to unify everyone's work into shared\n libraries?\n\n- **Reproducibility and tracking.** What are the standards for\n reproducibility? For instance, should the team use the same data pipeline\n and versioning practices, or is it OK to show only plots? How will\n experimental data be saved: as SQL queries or as model snapshots? Where will\n the logs from each experiment be documented: in a doc, a spreadsheet, or a\n CMS for managing experiments?\n\nWrong predictions\n-----------------\n\nNo real-world model is perfect. How will your system handle wrong predictions?\nBegin thinking early on about how to deal with them.\n\nA best-practices strategy encourages users to correctly label wrong predictions.\nFor example, mail apps capture misclassified email by logging the mail users\nmove into their spam folder, as well as the reverse. By capturing ground truth\nlabels from users, you can design automated feedback loops for data collection\nand model retraining.\n\nNote that although UI-embedded surveys capture user feedback, the data is\ntypically qualitative and can't be incorporated into the retraining data.\n\nImplement an end-to-end solution\n--------------------------------\n\nWhile your team is experimenting on the model, it's a good idea to start\nbuilding out parts of the final pipeline (if you have the resources to do so).\n\nEstablishing different pieces of the pipeline---like data intake and model\nretraining---makes it easier to move the final model to production. For\nexample, getting an end-to-end pipeline for ingesting data and serving\npredictions can help the team start integrating the model into the product and\nto begin conducting early-stage user testing.\n\nTroubleshooting stalled projects\n--------------------------------\n\nYou might be in scenarios where a project's progress stalls. Maybe your\nteam has been working on a promising experiment but hasn't had success\nimproving the model for weeks. What should you do? The following are some\npossible approaches:\n\n- **Strategic.** You might need to reframe the problem. After spending time in\n the experimentation phase, you probably understand the problem, the data,\n and the possible solutions better. With a deeper knowledge of the domain,\n you can probably frame the problem more precisely.\n\n For instance, maybe you initially wanted to use linear regression to predict\n a numeric value. Unfortunately, the data wasn't good enough to train a\n viable linear regression model. Maybe further analysis reveals the problem\n can be solved by predicting whether an example is above or below a specific\n value. This lets you reframe the problem as a binary classification one.\n\n If progress is slower than expected, don't give up. Incremental improvements\n over time might be the only way to solve the problem. As noted earlier,\n don't expect the same amount of progress week over week. Often, getting a\n production-ready version of a model requires substantial amounts of time.\n Model improvement can be irregular and unpredictable. Periods of slow\n progress can be followed by spikes in improvement, or the reverse.\n- **Technical.** Spend time diagnosing and analyzing wrong predictions. In\n some cases, you can find the issue by isolating a few wrong predictions and\n diagnosing the model's behavior in those instances. For example, you might\n uncover problems with the architecture or the data. In other cases,\n getting more data can help. You might get a clearer signal that suggests\n you're on the right path, or it might produce more noise, indicating other\n issues exist in the approach.\n\n If you're working on a problem that requires human-labeled datasets,\n getting a labeled dataset for model evaluation might be hard to obtain. Find\n resources to get the datasets you'll need for evaluation.\n\nMaybe no solution is possible. Time-box your approach, stopping if you haven't\nmade progress within the timeframe. However, if you have a strong problem\nstatement, then it probably warrants a solution.\n\n### Check Your Understanding\n\nA team member found a combination of hyperparameters that improves the baseline model metric. What should the other members of the team do? \nMaybe incorporate one hyperparameter, but continue with their experiments. \nCorrect. If one of their hyperparameters seems like a reasonable choice, try it. However, not all hyperparameter choices make sense in every experimental context. \nChange all their hyperparameters in their current experiment to match their co-worker's. \nHyperparameters that improved one model doesn't mean they'll also improve a different model. The other teammates should continue with their experiments, which might actually improve the baseline even more later on. \nStart building an end-to-end pipeline that will be used to implement the model. \nA model that improves the baseline doesn't mean it's the model that will ultimately be used in production. They should continue with their experiments, which might actually improve the baseline even more later on.\n| **Key Terms:**\n|\n| - [baseline](/machine-learning/glossary#baseline)"]]
