تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
لإعداد خطوط أنابيب تعلُّم الآلة للإنتاج، عليك تنفيذ ما يلي:
توفير موارد حسابية لخطوط الإنتاج
تنفيذ التسجيل والمراقبة والتنبيه
توفير موارد الحوسبة
يتطلّب تشغيل خطوط أنابيب تعلُّم الآلة موارد حوسبة، مثل ذاكرة الوصول العشوائي (RAM) ووحدات المعالجة المركزية (CPU) ووحدات معالجة الرسومات (GPU) أو وحدات معالجة الموتّرات (TPU). بدون قدرة حوسبة كافية، لا يمكنك تشغيل خطوط الأنابيب. لذلك، احرص على الحصول على حصة كافية لتوفير الموارد اللازمة التي تحتاجها خطوط الإنتاج لتنفيذها في بيئة الإنتاج.
عمليات عرض الإعلانات وتدريب النماذج والتحقّق من صحة البيانات تتطلّب هذه المسارات وحدات TPU أو وحدات معالجة الرسومات أو وحدات المعالجة المركزية. واستنادًا إلى حالة الاستخدام، يمكنك التدريب والتقديم على أجهزة مختلفة أو استخدام الأجهزة نفسها. على سبيل المثال، قد يتم إجراء التدريب على وحدات المعالجة المركزية، ولكن قد تستخدم عملية العرض وحدات TPU، أو العكس. بشكل عام، من الشائع التدريب على أجهزة أكبر حجمًا ثم العرض على أجهزة أصغر حجمًا.
عند اختيار الأجهزة، ضَع في اعتبارك ما يلي:
هل يمكن التدريب على أجهزة أقل تكلفة؟
هل سيؤدي التبديل إلى جهاز مختلف إلى تحسين الأداء؟
ما هو حجم النموذج وما هي الأجهزة التي ستعمل على تحسين أدائه؟
ما هي الأجهزة المثالية استنادًا إلى بنية النموذج؟
مسارات البيانات: تتطلّب مسارات نقل البيانات حصة من ذاكرة الوصول العشوائي ووحدة المعالجة المركزية عليك تقدير مقدار الحصة التي يحتاجها مسار البيانات لإنشاء مجموعات بيانات التدريب والاختبار.
قد لا يتم تخصيص حصة لكل مسار. بدلاً من ذلك، يمكنك تخصيص حصة مشتركة بين خطوط الإنتاج. في مثل هذه الحالات، تأكَّد من توفّر حصة كافية لتشغيل جميع مسارات البيانات، واضبط إعدادات المراقبة والتعديل لمنع مسار بيانات واحد خاطئ من استهلاك كل الحصة.
تقدير الحصة
لتقدير الحصة التي ستحتاج إليها لخطوط نقل البيانات والتدريب، ابحث عن مشاريع مشابهة تستند إليها في تقديراتك. لتقدير حصة العرض، حاوِل توقّع عدد الطلبات في الثانية التي تتلقّاها الخدمة. توفّر هذه الطرق مرجعًا أساسيًا. عندما تبدأ في إنشاء نموذج أوّلي للحل خلال مرحلة التجربة، ستبدأ في الحصول على تقدير أكثر دقة للحصة.
عند تقدير الحصة، تذكَّر أن تأخذ في الاعتبار الحصة المخصّصة ليس فقط لخطوط إنتاجك، ولكن أيضًا للتجارب الجارية.
التحقّق من فهمك
عند اختيار أجهزة لتقديم التوقّعات، يجب دائمًا اختيار أجهزة أكثر فعالية من تلك التي تم استخدامها لتدريب النموذج.
خطأ
إجابة صحيحة. عادةً ما يتطلّب التدريب أجهزة أكبر من العرض.
True
التسجيل والمراقبة والتنبيه
يُعدّ تسجيل سلوك نموذج الإنتاج ومراقبته أمرًا بالغ الأهمية. تؤكّد البنية الأساسية القوية للمراقبة أنّ نماذجك تقدّم توقعات موثوقة وعالية الجودة.
تساعد ممارسات التسجيل والمراقبة الجيدة في تحديد المشاكل بشكل استباقي في مسارات البيانات الخاصة بالتعلم الآلي والحد من التأثير المحتمل في الأنشطة التجارية. وعند حدوث مشاكل، ترسل التنبيهات إشعارات إلى أعضاء فريقك، وتسهّل السجلات الشاملة عملية تشخيص السبب الأساسي للمشكلة.
يجب تنفيذ عمليات التسجيل والمراقبة لرصد المشاكل التالية في مسارات تعلُّم الآلة:
مسار التعلّم
مراقب
جارٍ العرض
الانحرافات أو التغيّرات في بيانات العرض مقارنةً ببيانات التدريب
انحرافات أو تغيّرات في التوقعات
مشاكل في أنواع البيانات، مثل القيم المفقودة أو التالفة
مقدار استخدام الحصة
مقاييس جودة النموذج
البيانات
الانحرافات والتغيّرات في قيم الميزات
الانحرافات والتغيّرات في قيم التصنيفات
مشاكل في أنواع البيانات، مثل القيم المفقودة أو التالفة
معدّل استخدام الحصة
أوشكت على بلوغ الحدّ الأقصى للحصة المخصّصة لك
التدريب
وقت التدريب
أخطاء التدريب
مقدار استخدام الحصة
التحقّق من الصحة
الانحراف أو التغيّر في مجموعات بيانات الاختبار
ستحتاج أيضًا إلى تسجيل البيانات ومراقبتها وإرسال تنبيهات بشأن ما يلي:
وقت الاستجابة: كم من الوقت يستغرق عرض التوقّعات؟
الانقطاعات هل توقّف النموذج عن تقديم التوقعات؟
التحقّق من فهمك
أيّ مما يلي هو السبب الرئيسي لتسجيل ومراقبة مسارات تعلُّم الآلة؟
رصد المشاكل بشكل استباقي قبل أن تؤثر في المستخدمين
تتبُّع الحصة واستخدام الموارد
تحديد المشاكل المحتملة المتعلّقة بالأمان
كل ما سبق
إجابة صحيحة. يساعد تسجيل مسارات تعلُّم الآلة ومراقبتها في منع المشاكل وتشخيصها قبل أن تصبح خطيرة.
نشر نموذج
عند نشر النماذج، عليك توثيق ما يلي:
الموافقات المطلوبة لبدء عملية النشر وزيادة عدد المستخدمين الذين سيتم طرح التطبيق لهم
كيفية نشر نموذج واستخدامه
مكان نشر النموذج، مثلاً، إذا كانت هناك بيئات تجريبية أو بيئات إصدار تجريبي.
الإجراءات التي يجب اتّخاذها في حال تعذُّر نشر التطبيق
كيفية التراجع عن نموذج تم نشره.
بعد إعداد عملية التدريب الآلي للنموذج، عليك إعداد عملية آلية للتحقّق من الصحة والنشر. تؤدي عملية نشر التطبيقات آليًا إلى توزيع المسؤولية وتقليل احتمال أن يؤدي شخص واحد إلى تأخير عملية النشر. كما يقلّل من الأخطاء المحتملة، ويزيد من الكفاءة والموثوقية، ويتيح تناوب المناوبات وتقديم الدعم من فريق هندسة موثوقية الموقع (SRE).
عادةً ما يتم نشر النماذج الجديدة لمجموعة فرعية من المستخدمين للتأكّد من أنّ النموذج يعمل على النحو المتوقّع. في حال توفُّرها، يمكنك مواصلة عملية النشر. إذا لم يكن الأمر كذلك، عليك التراجع عن عملية النشر والبدء في تشخيص المشاكل وتصحيح أخطائها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eProduction ML pipelines require sufficient compute resources like RAM, CPUs, and GPUs/TPUs for serving, training, data processing, and validation.\u003c/p\u003e\n"],["\u003cp\u003eImplement robust logging, monitoring, and alerting to proactively detect data and model issues (e.g., data drift, prediction skews, quality degradation) across all pipeline stages.\u003c/p\u003e\n"],["\u003cp\u003eEstablish a clear model deployment strategy outlining approvals, procedures, environments, and rollback mechanisms, and aim for automated deployments for efficiency and reliability.\u003c/p\u003e\n"],["\u003cp\u003eEstimate quota needs based on similar projects and service predictions, and factor in resources for both production and ongoing experimentation.\u003c/p\u003e\n"]]],[],null,["To prepare your ML pipelines for production, you need to do the following:\n\n- Provision compute resources for your pipelines\n- Implement logging, monitoring, and alerting\n\nProvisioning compute resources\n\nRunning ML pipelines requires compute resources, like RAM, CPUs, and GPUs/TPUs.\nWithout adequate compute, you can't run your pipelines. Therefore, make sure\nto get sufficient quota to provision the required resources your pipelines\nneed to run in production.\n\n- **Serving, training, and validation pipelines**. These pipelines require\n TPUs, GPUs, or CPUs. Depending on your use case, you might train and serve\n on different hardware, or use the same hardware. For example, training might\n happen on CPUs but serving might use TPUs, or vice versa. In general, it's\n common to train on bigger hardware and then serve on smaller hardware.\n\n \u003cbr /\u003e\n\n When picking hardware, consider the following:\n - Can you train on less expensive hardware?\n - Would switching to different hardware boost performance?\n - What size is the model and which hardware will optimize its performance?\n - What hardware is ideal based on your model's architecture?\n\n | **Note:** When switching models between hardware, consider the time and effort to migrate the model. Switching hardware might make the model cheaper to run, but the engineering effort to do so might outweigh the savings---or engineering effort might be better prioritized on other work.\n- **Data pipelines**. Data pipelines require quota for RAM and CPU\n\n You'll need to estimate how\n much quota your pipeline needs to generate training and test datasets.\n\nYou might not allocate quota for each pipeline. Instead, you might\nallocate quota that pipelines share. In such cases, verify\nyou have enough quota to run all your pipelines, and set up monitoring and\naltering to prevent a single, errant pipeline from consuming all the quota.\n\nEstimating quota\n\nTo estimate the quota you'll need for the data and training pipelines, find\nsimilar projects to base your estimates on. To estimate serving quota, try to\npredict the service's queries per second. These methods provide a baseline. As\nyou begin prototyping a solution during the experimentation phase, you'll begin\nto get a more precise quota estimate.\n\nWhen estimating quota, remember to factor in quota not only for your production\npipelines, but also for ongoing experiments.\n\nCheck Your Understanding \nWhen choosing hardware to serve predictions, you should always choose more powerful hardware than was used to train the model. \nFalse \nCorrect. Typically, training requires bigger hardware than serving. \nTrue \n\nLogging, monitoring, and alerting\n\nLogging and monitoring a production model's behavior is critical. Robust\nmonitoring infrastructure confirms your models are serving reliable,\nhigh-quality predictions.\n\nGood logging and monitoring practices help proactively identify issues in ML\npipelines and mitigate potential business impact. When issues do occur, alerts\nnotify members of your team, and comprehensive logs facilitate diagnosing the\nproblem's root cause.\n\nYou should implement logging and monitoring to detect the following issues\nwith ML pipelines:\n\n| Pipeline | Monitor |\n|------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Serving | - Skews or drifts in the serving data compared to the training data - Skews or drifts in predictions - Data type issues, like missing or corrupted values - Quota usage - Model quality metrics Calculating a production model's quality is different than calculating a model's quality during training. In production, you won't necessarily have access to the ground truth to compare predictions against. Instead, you'll need to write custom monitoring instrumentation to capture metrics that act as a proxy for model quality. For example, in a mail app, you won't know which mail is spam in real time. Instead, you can monitor the percentage of mail users move to spam. If the number jumps from 0.5% to 3%, that signals a potential issue with the model. | Note that comparing the changes in | the proxy metrics is more insightful than their raw numbers. |\n| Data | - Skews and drifts in feature values - Skews and drifts in label values - Data type issues, like missing or corrupted values - Quota usage rate - Quota limit about to be reached |\n| Training | - Training time - Training failures - Quota usage |\n| Validation | - Skew or drift in the test datasets |\n\nYou'll also want logging, monitoring, alerting for the following:\n\n- **Latency**. How long does it take to deliver a prediction?\n- **Outages**. Has the model stopped delivering predictions?\n\nCheck Your Understanding \nWhich of the following is the main reason for logging and monitoring your ML pipelines? \nProactively detect issues before they impact users \nTrack quota and resource usage \nIdentify potential security problems \nAll of the above \nCorrect. Logging and monitoring your ML pipelines helps prevent and diagnose problems before they become serious.\n\nDeploying a model\n\nFor model deployment, you'll want to document the following:\n\n- Approvals required to begin deployment and increase the roll out.\n- How to put a model into production.\n- Where the model gets deployed, for example, if there are staging or canary environments.\n- What to do if a deployment fails.\n- How to rollback a model already in production.\n\nAfter automating model training, you'll want to automate\nvalidation and deployment. Automating deployments distributes\nresponsibility and reduces the likelihood of a deployment being bottlenecked by\na single person. It also reduces potential mistakes, increases efficiency and\nreliability, and enables on-call rotations and SRE support.\n\nTypically you deploy new models to a subset of users to check that the model is\nbehaving as expected. If it is, continue with the deployment. If it's not,\nyou rollback the deployment and begin diagnosing and debugging the issues."]]
