استدلال التعلم الآلي داخل طلب المزايدة: جلب السمات والتجميع في دفعات وسعر الاحتياط

النموذج الذي يحسب احتمال النقر والتحويل داخل مسار المزايدة يُحكَم عليه بساعة لا يملكها. فمنصة التبادل تكفّ عن الإصغاء عند مهلتها النهائية، والتنبؤ الذي يصل بعد تلك اللحظة ليس إجابة بطيئة: إنه لا إجابة، والحوسبة أُنفقت بالفعل.

يصل المتطلب عادةً في صورة هدف لزمن استجابة الاستدلال. لكنه يعمل أفضل في صورة عملية طرح: ما يتبقى من مهلة المزاد بعد الشبكة وتحليل الطلب وعمليات البحث عن السمات، وبماذا يزايد المزايد حين لا يتبقى شيء.

المهلة النهائية تصل داخل الطلب، والاستدلال يحصل على ما يتبقى

في OpenRTB 2.6، الـ tmax هو أقصى زمن بالميلي ثانية تسمح به منصة التبادل لاستقبال المزايدات، شاملًا زمن الاستجابة عبر الإنترنت، وهو يَجُبّ أي إرشاد قدّمته منصة التبادل مسبقًا. والميزانية ليست إعدادًا في خدمتك: إنها تنتقل مع كل طلب.

يقول توثيق Google Authorized Buyers، المحدَّث في أغسطس 2026، إن المهلة النهائية في BidRequest.tmax تتراوح عادةً من 80 إلى 1000 ms، وتغطي زمن الشبكة حتى موقع التداول إضافةً إلى الزمن الذي يستغرقه مزايدك لتوليد الرد. ويشترط أن تقع 85 في المئة من الردود داخل المهلة كما تُرى من موقع التداول، ويخنق المزايدين الذين لا يستطيعون تحقيق ذلك باستمرار.

فالمهلة النهائية إذن مجموع، والنموذج يملك حدًّا واحدًا منه:

• الرحلة ذهابًا وإيابًا إلى منصة التبادل، ولا يقصّرها أي عمل على النموذج
• تحليل الطلب واختيار المرشّحين عبر عوامل تصفية الاستهداف والميزانية والتكرار
• جلب سمات المستخدم والسياق، وهو عادةً استدعاء شبكي له ذيله الخاص
• تقييم المرشّحين الناجين، ثم التسعير وترميز الرد
• هامش لتباين كل ما سبق، يُقرأ من مدرّجاتك التكرارية أنت لكل منصة تبادل لا من متوسط

اختم الطلب لحظة وصوله بمهلة نهائية مطلقة، مشتقة من tmax ناقص زمن الشبكة الذي تقيسه لمنصة التبادل تلك، ومرّر إلى كل مرحلة الزمن المتبقي بدل مهلة انتظار ثابتة. ويصف توثيق gRPC الآلية نفسها: المهلة النهائية المُمرَّرة تتحول إلى مهلة انتظار (timeout) خُصم منها الزمن المنقضي مسبقًا، ويبقى تطبيق الخادم مسؤولًا عن إيقاف العمل الذي أطلقه.

حين يكون المتبقي أصغر من أن يكفي للتقييم، أجب مبكرًا. يقدّم OpenRTB 2.6 شكلين للـ no-bid: ردًا فارغًا مع HTTP 204، أو رد مزايدة يحمل رمز سبب في nbr، ويشجّع على رمز السبب. والإجابة المتأخرة تكلّف أكثر: نظام حصص الاستدعاءات (callout quota) لدى Google يرسل استدعاءات أقل إلى المزايد الذي لا يستجيب في الوقت المحدد، ويتكيّف خلال دقائق.

جلب السمات وتقييم النموذج يفشلان بطريقتين مختلفتين، لذا يحصل كل منهما على ميزانية منفصلة

مرحلتان تختبئان تحت كلمة الاستدلال. جلب السمات عملية إدخال/إخراج: إشارات السجل التاريخي والتكرار والسياق من مخزن بعيد، بذيل تتحكم فيه الشبكة وذلك المخزن. أما التقييم فحوسبة، تمرير أمامي أو اجتياز للأشجار، بذيل يتحكم فيه التنازع على CPU داخل عمليتك أنت.

قيمة p99 التي تخلط الاثنين لا تقول أيهما يجب إصلاحه، لذا احتفظ بمدرّجين تكراريين لكل منصة تبادل وصنّف السمات حسب مكان وجودها:

• سمات الطلب، المقروءة من طلب المزايدة نفسه: مجانية، وهي الفئة الوحيدة التي لا يمكن أن تصل متأخرة
• سمات الحملة والمادة الإعلانية، المحفوظة في ذاكرة العملية والمُعاد بناؤها خارج المسار الساخن، فإعادة البناء البطيئة تكلّف حداثة البيانات لا مزايدة
• سمات المستخدم والسجل التاريخي من مخزن بعيد: الذيل الأكبر، وأول مجموعة تُقتطع حين تضيق الميزانية
• السمات المتقاطعة المحسوبة لكل طلب، والتي تنمو كلفتها مع عدد المرشّحين

الجلب المقيَّد بمهلة نهائية يحتاج إلى نموذج يتوقع الإجابة الغائبة: درّبه مع غياب مجموعة السمات المتأخرة في حصة من الأمثلة، أو احتفظ بنموذج ثانٍ بدونها، كي يحرّك البحث الملغى التنبؤَ بطريقة سبق أن قستها.

وصف Dean وBarroso الطلبات التحوّطية (hedged requests) في The Tail at Scale عام 2013: بعد تأخير قصير، أرسل الطلب نفسه مرة ثانية إلى نسخة متماثلة أخرى واستخدم الإجابة التي تصل أولًا أيًّا كانت. وفي اختبار الأداء الذي أجرياه على BigTable، خفّض طلب تحوّطي أُرسل بعد 10 ms زمن الاستجابة عند المئين 99.9 لاسترجاع 1,000 قيمة من 1,800 ms إلى 74 ms، مع إرسال طلبات أكثر بنسبة 2 في المئة. وداخل المزاد، يجب أن يأتي تأخير الطلب التحوّطي من الحصة المتبقية للجلب.

اختر صيغة النموذج بحسب ما يعمل داخل عمليتك دون قفزة شبكية

قرار الـ runtime هو في الغالب قرار بشأن مكان حدوث التقييم. فخادم الاستدلال المنفصل يضيف رحلة ذهاب وإياب وطابورًا إلى كل طلب يُقيَّم؛ أما التقييم داخل عملية المزايد فلا يضيف أيًّا منهما، ويسلّمك بدلًا من ذلك ذاكرته وخيوطه. أربعة خيارات شائعة:

• الانحدار اللوجستي على سمات متناثرة، أي مجموع على الأوزان النشطة: النموذج أحادي الطبقة الذي وصفه McMahan وزملاؤه للتنبؤ بالنقر على إعلانات Google في KDD 2013
• مجموعات الأشجار المُصرَّفة مسبقًا: يحوّل TL2cgen، من مشروع dmlc، الغابات العشوائية ونماذج التعزيز المتدرج إلى شيفرة C تُوزَّع في صورة ملف ثنائي أصلي
• شبكة عصبية صغيرة في ONNX Runtime، يكون مجمّع intra-op فيها افتراضيًا خيطًا واحدًا لكل نواة فعلية مع تفعيل الـ spinning: وحيث تشغل معالجات الطلبات كل نواة أصلًا، اضبط حجمه على قدر الطلب لا على قدر الجهاز
• خادم منفصل مثل Triton أو TensorFlow Serving، حين يحتاج النموذج إلى مسرِّع أو إلى دورة إصدار خاصة به

التكميم هو الرافعة الأخرى على CPU، وله كلفتان يذكرهما توثيق ONNX Runtime نفسه: التكميم الخطي بـ 8 بت ليس تحويلًا بلا فقد، وكلفته الإضافية تجعل تراجع الأداء على الأجهزة القديمة أمرًا غير نادر. وفي نموذج CTR تشمل الدقةُ المعايرةَ، فقارن المعدلات المتنبأ بها والمرصودة قبل التكميم وبعده.

التجميع في دفعات عبر الطلبات يُنفق المورد الأشحّ لدى المزايد

تجميع مرشّحي الطلب الواحد في دفعة لا يكلّف أي انتظار، لأنها موجودة أصلًا. أما التجميع الديناميكي عبر الطلبات فيرفع الإنتاجية بجعل الطلبات تنتظر من ينضم إليها، وهذا عكس ما تطلبه مهلة المزاد، وخوادم الاستدلال نفسها تقول ذلك:

• يحدّ TensorFlow Serving انتظار الدفعة غير الممتلئة بواسطة batch_timeout_micros، الذي يُستخدم لكبح زمن استجابة الذيل، ويقترح للأنظمة التي تعمل على CPU وحده أن يبدأ عند 0، مع مراعاة أن 0 قد تكون القيمة المثلى
• مُجمِّع الدفعات الديناميكي في NVIDIA Triton لا يستبقي الدفعة إلا ما دام لم ينتظر أي طلب أطول من حد أقصى مضبوط لتأخير الطابور، ويقترح دليله رفع ذلك التأخير حتى تُتجاوز ميزانية زمن الاستجابة
• سياسة الطابور في Triton تستطيع رفض الطلبات التي تنتظر في الطابور بعد انقضاء مهلة أو تأجيلها، فتحوّل الدرجة المتأخرة إلى فشل مبكر يستطيع المزايد التصرف بناءً عليه

تُظهر ورقة Wide & Deep من Google، المنشورة عام 2016، جانب المقايضة داخل الطلب الواحد لخدمة تهدف إلى تقديم كل طلب في حدود 10 ms. فتقييم كل المرشّحين في دفعة واحدة على خيط واحد استغرق 31 ms؛ وتقسيم الدفعة إلى دفعات أصغر على خيوط متوازية خفّض زمن الاستجابة من جانب العميل إلى 14 ms، بما في ذلك الكلفة الإضافية للتقديم.

يحدد Clipper، نظام تقديم التنبؤات من Berkeley الذي قُدِّم في NSDI 2017، حجم الدفعات وفق المهلة النهائية لا وفق العتاد: يكبّر الدفعة بزيادات جمعية حتى تتجاوز معالجتها هدف زمن الاستجابة، ثم يتراجع بنسبة 10 في المئة. والدرس للمزايد في الترتيب: ثبّت هدف زمن الاستجابة أولًا، ثم خذ أي دفعة تتسع تحته، ولو كانت دفعة من عنصر واحد.

الاختيار بين CPU والمسرِّع يحسمه حجم الدفعة وكلفة النقل

المسرِّع يستحق مكانه على الدفعات الكبيرة، ودفعة طلب المزايدة ليست سوى مرشّحيه الناجين. ووجدت DeepRecSys، وهي دراسة من Harvard وFacebook قُدِّمت في ISCA 2020، أن وحدات GPU تتفوق على وحدات CPU عند أحجام الدفعات الأكبر، وأن تحميل المدخلات من CPU إلى GPU استغرق في المتوسط من 60 إلى 80 في المئة من زمن الاستدلال على GPU من الطرف إلى الطرف لكل نموذج درسته.

ولم يختر مجدولها جهازًا واحدًا: فتقسيم الاستعلامات الكبيرة إلى دفعات أصغر على أنوية CPU متوازية وحدها ضاعف الإنتاجية تحت أهداف صارمة لزمن استجابة الذيل عبر ثمانية نماذج تمثل الصناعة، ونقلُ الاستعلامات التي تتجاوز عتبة حجم فقط إلى GPU رفعها أكثر. وبالنسبة للمزايد، تبقى الدفعات الصغيرة لكل طلب على CPU، وعلى المسرِّع أن يسترد كلفة النقل والطابور.

التنبؤ المتأخر أسوأ من تنبؤ بسيط، لذا يُصمَّم الاحتياط أولًا

تقوم آلية Clipper لتخفيف أثر المتلكئات (straggler mitigation) على خيار تصميمي يستحق النسخ: تقديم تنبؤ متأخر أسوأ من تقديم تنبؤ غير دقيق. فعند المهلة النهائية كانت طبقة اختيار النموذج فيه تجمع التنبؤات التي وصلت وتستبدل المفقودة منها بقيمتها المتوسطة. ومقابل ذلك في المزايد سُلّم، وكل درجة فيه يجب أن تعطي سعرًا يستطيع المزاد التعايش معه:

• النموذج الكامل، حين يعود الجلب ضمن حصته
• نموذج مصغَّر مدرَّب دون مجموعة السمات المتأخرة، حين يُلغى الجلب
• تنبؤ مخزَّن مؤقتًا بمفتاح من سياق إجمالي مثل الموضع الإعلاني والمادة الإعلانية والشريحة، مع حد أقصى لعمره، حين يضيق الوقت على التقييم
• احتمال قبلي معايَر لكل موضع إعلاني ومادة إعلانية، حين لا يتوفر شيء مما سبق
• no-bid مع رمز سبب، حين يكون حتى الاحتمال القبلي تخمينًا

حين يكون الهدف تحويلًا، فالقيمة المتوقعة لكل ظهور هي احتمال النقر مضروبًا في احتمال التحويل بعد النقر مضروبًا في قيمة التحويل، لذا فالدرجة التي تميل تقديراتها إلى الارتفاع تزايد بأكثر مما يساويه الظهور: في مزاد السعر الأول تدفع أكثر من اللازم عند كل فوز، وفي مزاد السعر الثاني تفوز بمرات ظهور كان ينبغي أن تخسرها. وكتب McMahan وزملاؤه أن التنبؤات الدقيقة وجيدة المعايرة ضرورية لتشغيل المزاد، وعدّوا السمات الخفية غير المتاحة وقت التدريب أو وقت التقديم من أسباب الانحياز المنهجي؛ والجلب الملغى يجعل السمة غير متاحة وقت التقديم.

وضع الظل أولًا، ثم canary بحدٍّ للإنفاق

النموذج الجديد يغيّر زمن الاستجابة والسعر معًا، والاثنان يفشلان على ساعتين مختلفتين: زمن الاستجابة خلال دقائق، والسعر على امتداد نافذة التحويل. فاطرحه على خطوتين تفصلان بينهما:

• التقييم في وضع الظل على حركة منسوخة وعلى نسخ تشغيل منفصلة، لا داخل العملية التي تقيس كلفتها أبدًا
• مقارنة على طلبات متطابقة: توزيعات التنبؤ، ومعدلات السمات المفقودة، وزمن التقييم لكل مرشّح، والسعر الذي كان كل نموذج سيزايد به
• نشر canary على حصة صغيرة من الحركة الحية، مع إصدار النموذج في كل سجل مزايدة كي تُقسَم مرات الفوز والإنفاق والتحويلات حسب الإصدار
• سقف للإنفاق وتراجع تلقائي يُطلقه زمن الاستجابة أو معدل اللجوء إلى الاحتياط أو الانحياز، لأن مزايدات canary تشتري مرات ظهور حقيقية

يعرّف كتاب Google SRE Workbook نشر canary بأنه نشر جزئي ومحدود زمنيًا لتغيير في خدمة ما مع تقييمه، ويحذّر من أنه في الأنظمة ذات الاستعلامات المتنوعة لا يعطي canary يُنهى بعد حفنة من الاستعلامات أي إشارة مفيدة. وفي نموذج التحويل تُعدّ الحفنة بالتحويلات، لذا يستمر canary مدةً لا تقل عن نافذة التحويل.

راقب النموذج والساعة على لوحة واحدة

مراقبة زمن الاستجابة تقول هل أجاب النموذج؛ ومراقبة النموذج تقول هل كانت الإجابة تستحق السعر. والمزايد يحتاج إلى الاثنتين، مقسّمتين لكل منصة تبادل ولكل إصدار نموذج:

• زمن الجلب وزمن التقييم في مدرّجات تكرارية منفصلة لـ p99 وp99.9، بجوار معدل اللجوء إلى الاحتياط حسب السبب
• انحياز التنبؤ، الذي وصفه Sculley وزملاؤه في Google عام 2015 بأنه تطابق توزيع التسميات المتنبأ بها مع توزيع التسميات المرصودة: النموذج الذي يتنبأ بالمتوسط يجتازه، لذا قسّمه، بما في ذلك حسب نطاقات الاحتمال المتنبأ به
• انحراف التدريب عن التقديم (training-serving skew): تنص Rules of Machine Learning من Google على تسجيل السمات المستخدمة وقت التقديم والتدريب عليها، لجزء صغير على الأقل
• عمر النموذج: وجدت ورقة Facebook لعام 2014 عن التنبؤ بالنقر أن التدريب اليومي بدل الأسبوعي خفّض الإنتروبيا المعيارية (normalized entropy) بنحو 1 في المئة، واعتبرت إعادة التدريب اليومية جديرة بكلفتها
• حدود للإجراءات على سعر المزايدة والإنفاق، وهي ما تقترحه ورقة 2015 للأنظمة التي تتصرف في العالم الحقيقي، والمزايدة من بين أمثلتها

التنبؤ الذي يصل بعد tmax لم ينتج مزايدة أبطأ. بل أنتج انتهاء مهلة، وسببًا لخنقك، وفاتورة CPU، بينما حسم المزادَ المزايدون الذين أجابوا.

الشركة التي تبني هذا تطلب تقرير انتهاء المهلة قبل النموذج

النصف الثاني من السؤال، من يبني خطوط استدلال مدمجة في المزايدين، له اختبار لا يحتاج قائمة مورّدين. فالشركة التي تقوم بهذا العمل تسأل عن الميزانية قبل أن تعرض نموذجًا:

• تطلب توزيع tmax، وتقرير انتهاء المهلة لكل منصة تبادل، وعدد المرشّحين الذين يجتازون الاستهداف
• تدوّن تقسيم المهلة النهائية - الشبكة، والتحليل، والجلب، والتقييم، والهامش - وتسمّي المرحلة التي تتوقع أن تكون مسؤولة عن الذيل قبل أن تقترح runtime
• تضع سُلّم الاحتياط ومعدلًا مستهدفًا للجوء إلى الاحتياط في المستند نفسه الذي فيه النموذج
• تعامل المعايرة بوصفها معيار قبول إلى جانب مقياس الترتيب، وتسأل أين سُجِّلت سمات التدريب
• تأتي بخطة لوضع الظل على نسخ تشغيل منفصلة وبنشر canary بسقف للإنفاق وتراجع تلقائي، وتستطيع تزويد مسار المزايدة بالكوادر بعد الإطلاق

كل بند مستند يمكنك طلبه في المحادثة الأولى، والإجابة الغامضة تعني أن الميزانية لم تُقسَّم بعد.

لذا فالسؤال الأول ليس أي نموذج تقدّم. بل كم يتبقى من tmax بعد الشبكة وجلب السمات على منصة التبادل التي تنتهي عندها المهلة، وبماذا يزايد المزايد حين ينفد ذلك المتبقي.

ما تستطيع amBrain إثباته علنًا: amBrain شركة تطوير برمجيات متخصصة في منصات التداول ومحركات المطابقة وأنظمة المزايدة الفورية وهندسة منصات الكازينو. وتبني amBrain البرمجيات منذ 2019، وما نبنيه في AdTech هو تطوير DSP ومنصات المزايدة الفورية وهندسة منصات تبادل الإعلانات. ونعمل بثلاث صيغ: تسليم كامل، أو فريق مخصص، أو مهندسون مدمجون في فريقك.