كيف استخدمت Medidata الاستدلال غير المتزامن لـ Amazon SageMaker لتسريع تنبؤات استدلال ML بما يصل إلى 30 مرة أسرع

تمت كتابة هذا المنشور بالاشتراك مع Rajnish Jain و Priyanka Kulkarni و Daniel Johnson من Medidata.

Medidata يقود التحول الرقمي لعلوم الحياة ، مما يخلق الأمل لملايين المرضى. تساعد Medidata في إنشاء الأدلة والرؤى لمساعدة شركات الأدوية والتكنولوجيا الحيوية والأجهزة الطبية والتشخيص وكذلك الباحثين الأكاديميين على تسريع القيمة وتقليل المخاطر وتحسين النتائج لحلولهم. أكثر من مليون مستخدم مسجل عبر أكثر من 1,900 عميل وشريك يمكنهم الوصول إلى النظام الأساسي الأكثر موثوقية في العالم للتطوير السريري ، والبيانات التجارية ، وبيانات العالم الحقيقي.

يجمع فريق الذكاء الاصطناعي في Medidata بين البيانات السريرية التي لا مثيل لها والتحليلات المتقدمة والخبرة الصناعية لمساعدة قادة علوم الحياة على إعادة تصور ما هو ممكن والكشف عن رؤى متطورة لاتخاذ قرارات واثقة ومتابعة الابتكار المستمر. يتم دعم مجموعة حلول الذكاء الاصطناعي من Medidata من قبل فريق متكامل من العلماء والأطباء والتقنيين والمسؤولين التنظيميين السابقين - تم بناؤه على منصة Medidata الأساسية التي تضم أكثر من 27,000 تجربة و 8 ملايين مريض.

الأمازون SageMaker هي عبارة عن نظام أساسي للتعلم الآلي (ML) مُدار بالكامل ضمن بيئة AWS الآمنة. باستخدام SageMaker ، يمكن لعلماء ومطوري البيانات إنشاء نماذج ML وتدريبها بسرعة وسهولة ، ثم نشرها مباشرةً في بيئة مستضافة جاهزة للإنتاج. لاستضافة نماذج ML المدربة ، تقدم SageMaker مجموعة واسعة من الخيارات. بناءً على نوع نمط حركة المرور ومتطلبات وقت الاستجابة ، يمكنك اختيار أحد هذه الخيارات المتعددة. فمثلا، الاستدلال في الوقت الحقيقي مناسب لأحمال العمل المستمرة بمتطلبات زمن انتقال ميلي ثانية ، وأحجام حمولة تصل إلى 6 ميجا بايت ، وأوقات معالجة تصل إلى 60 ثانية. مع الاستدلال بدون خادم، يمكنك نشر نماذج تعلم الآلة بسرعة للاستدلال دون الحاجة إلى تكوين البنية التحتية الأساسية أو إدارتها ، ولا تدفع إلا مقابل سعة الحوسبة المستخدمة لمعالجة طلبات الاستدلال ، وهو أمر مثالي لأعباء العمل المتقطعة. بالنسبة للطلبات ذات البيانات الكبيرة غير المهيكلة بأحجام حمولة تصل إلى 1 غيغابايت ، مع أوقات معالجة تصل إلى 15 دقيقة ، ومتطلبات تقارب وقت الاستجابة في الوقت الفعلي ، يمكنك استخدام الاستدلال غير المتزامن. تحويل دفعة مثالي للتنبؤات في وضع عدم الاتصال على مجموعات كبيرة من البيانات المتوفرة مسبقًا.

في هذا المنشور التعاوني ، نوضح كيف ساعدت AWS Medidata على الاستفادة من إمكانات الاستضافة المتنوعة داخل SageMaker لتجربة خيارات بنية مختلفة للتنبؤ بالنجاح التشغيلي للتجارب السريرية المقترحة. نحن نتحقق أيضًا من سبب اختيار Medidata للاستدلال غير المتزامن لـ SageMaker لتصميمه النهائي وكيف ساعدت هذه البنية النهائية Medidata في خدمة عملائها بتنبؤات أسرع بما يصل إلى 30 مرة مع الحفاظ على تكاليف البنية التحتية ML منخفضة نسبيًا.

تطور العمارة

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

في الأقسام التالية ، نناقش كيفية عمل Medidata مع AWS في التكرار على قائمة تصاميم معمارية محتملة قابلة للتطوير. نحن نركز بشكل خاص على رحلة التطور ، وخيارات التصميم ، والمفاضلات التي مررنا بها للوصول إلى الاختيار النهائي.

تحويل دفعة SageMaker

Medidata المستخدمة في الأصل تحويل دفعة SageMaker لاستدلال ML لتلبية المتطلبات الحالية وتطوير منتج قابل للتطبيق (MVP) لحل تنبؤي جديد بسبب الاستخدام المنخفض ومتطلبات الأداء الفضفاض للتطبيق. عندما تبدأ وظيفة تحويل الدُفعات ، يقوم SageMaker بتهيئة مثيلات الحساب وتوزيع الاستدلال أو المعالجة المسبقة لأحمال العمل فيما بينها. إنها طريقة عالية الأداء وعالية الإنتاجية لتحويل البيانات وإنشاء الاستدلالات. إنه مثالي للسيناريوهات التي تتعامل فيها مع مجموعات كبيرة من البيانات ، ولا تحتاج إلى زمن انتقال ثانوي ، وتحتاج إما إلى معالجة البيانات أو تحويلها أو استخدام نموذج مدرب لتشغيل تنبؤات الدُفعات عليها بطريقة موزعة. يستخدم أيضًا سير عمل تحويل دفعة Sagemaker خدمة تخزين أمازون البسيطة (Amazon S3) باعتبارها الطبقة الثابتة ، والتي تحدد أحد متطلبات البيانات لدينا.

في البداية ، نجح استخدام تحويل الدُفعات من SageMaker بشكل جيد مع MVP ، ولكن مع تطور المتطلبات واحتاجت Medidata إلى دعم عملائها في الوقت الفعلي تقريبًا ، لم يكن تحويل الدُفعات مناسبًا لأنه كان طريقة غير متصلة بالإنترنت ويحتاج العملاء إلى الانتظار في أي مكان بين 5 15 دقيقة للردود. تضمن ذلك في المقام الأول تكلفة بدء تشغيل مجموعة الحوسبة الأساسية في كل مرة يلزم فيها معالجة عبء عمل الدُفعة. تتطلب هذه البنية أيضًا التكوين الأمازون CloudWatch قواعد الحدث لتتبع تقدم وظيفة التنبؤات المجمعة جنبًا إلى جنب مع استخدام قاعدة بيانات مختارة لتتبع الحالات والبيانات الوصفية للوظيفة المطلقة. تظهر بنية MVP في الرسم البياني التالي.

تدفق هذه العمارة على النحو التالي:

1. تستمر الحمولة السائبة الواردة كمدخل إلى موقع S3. يؤدي هذا الحدث بدوره إلى تشغيل ملف AWS لامدا إرسال وظيفة.
2. تبدأ وظيفة الإرسال وظيفة تحويل مجموعة SageMaker باستخدام عميل وقت تشغيل SageMaker.
3. تعمل وظيفة الإرسال أيضًا على تحديث قاعدة بيانات تعقب البيانات الوصفية والحالة المختارة بمعرف الوظيفة وتعيين حالة الوظيفة إلى inProgress. تعمل الوظيفة أيضًا على تحديث معرّف الوظيفة بمعلومات البيانات الوصفية المقابلة لها.
4. تدور مجموعة الحوسبة العابرة (عند الطلب) المطلوبة لمعالجة الحمولة الصافية ، وتبدأ وظيفة تحويل دفعة SageMaker. في الوقت نفسه ، ترسل الوظيفة أيضًا إشعارات الحالة ومعلومات تسجيل أخرى إلى سجلات CloudWatch.
5. تلتقط قاعدة حدث CloudWatch حالة وظيفة التحويل الدفعي وترسل إشعارًا بالحالة إلى ملف خدمة إعلام أمازون البسيطة (Amazon SNS) تم تكوينه لالتقاط هذه المعلومات.
6. يتم الاشتراك في موضوع SNS بواسطة وظيفة Notification Lambda التي يتم تشغيلها في كل مرة يتم فيها تشغيل قاعدة حدث بواسطة CloudWatch وعندما تكون هناك رسالة في موضوع SNS.
7. تقوم وظيفة الإعلام بعد ذلك بتحديث حالة وظيفة التحويل للنجاح أو الفشل في قاعدة بيانات التتبع.

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

مع زيادة عدد العملاء وتضاعف الاستخدام ، أعطت Medidata الأولوية لتجربة المستخدم من خلال تشديد متطلبات الأداء. لذلك ، قررت Medidata استبدال سير عمل التحويل الدفعي ببديل أسرع. أدى ذلك إلى قيام Medidata بتجربة العديد من التصاميم المعمارية التي تتضمن الاستدلال في الوقت الحقيقي من SageMakerو Lambda و الاستدلال غير المتزامن لـ SageMaker. في الأقسام التالية ، نقارن هذه التصميمات التي تم تقييمها بعمق ونحلل الأسباب الفنية لاختيار واحد على الآخر لحالة استخدام Medidata.

الاستدلال في الوقت الحقيقي من SageMaker

يمكنك استخدام نقاط نهاية الوقت الفعلي من SageMaker لخدمة النماذج الخاصة بك للتنبؤات في الوقت الفعلي بزمن انتقال منخفض. يتطلب تقديم توقعاتك في الوقت الفعلي نموذج تقديم مكدس لا يحتوي فقط على نموذجك المدرب ، ولكن أيضًا مكدس استضافة لتتمكن من خدمة تلك التنبؤات. عادةً ما تتضمن حزمة الاستضافة نوعًا من الخادم الوكيل وخادم ويب يمكنه التفاعل مع رمز الخدمة الذي تم تحميله والنموذج المدرب. يمكن بعد ذلك أن تستهلك تطبيقات العميل نموذجك من خلال طلب استدعاء API في الوقت الفعلي. يتم توجيه حمولة الطلب التي يتم إرسالها عند استدعاء نقطة النهاية إلى موازن التحميل ثم يتم توجيهها إلى مثيل ML الخاص بك أو المثيلات التي تستضيف نماذجك للتنبؤ. يأتي الاستدلال في الوقت الحقيقي من SageMaker مع جميع المكونات المذكورة أعلاه ويجعل من السهل نسبيًا استضافة أي نوع من نماذج ML للاستدلال المتزامن في الوقت الفعلي.

يحتوي الاستدلال في الوقت الحقيقي من SageMaker على مهلة 60 ثانية لاستدعاء نقطة النهاية ، ويبلغ الحد الأقصى لحجم الحمولة النافعة للاستدعاء 6 ميجابايت. نظرًا لأن منطق الاستدلال في Medidata معقد ويتطلب في كثير من الأحيان أكثر من 60 ثانية ، لا يمكن أن يكون الاستدلال في الوقت الفعلي وحده خيارًا قابلاً للتطبيق للتعامل مع الطلبات المجمعة التي تتطلب عادةً إلغاء تسجيل ومعالجة العديد من المعرفات التشغيلية الفردية دون إعادة تصميم خط أنابيب ML الحالي. بالإضافة إلى ذلك ، يجب تغيير حجم نقاط نهاية الاستدلال في الوقت الفعلي للتعامل مع ذروة الحمل. قد يكون هذا أمرًا صعبًا لأن Medidata بها دفعات سريعة من حركة المرور العالية. من المحتمل أن يؤدي التحجيم التلقائي إلى حل هذه المشكلة ، ولكنه يتطلب ضبطًا يدويًا لضمان وجود موارد كافية للتعامل مع جميع الطلبات في أي وقت. بدلاً من ذلك ، يمكننا إدارة قائمة انتظار الطلبات للحد من عدد الطلبات المتزامنة في وقت معين ، ولكن هذا قد يؤدي إلى زيادة النفقات الإضافية.

لامدا

تعمل العروض التي لا تحتوي على خادم مثل Lambda على التخلص من متاعب التزويد بالخوادم وإدارتها ، وتهتم تلقائيًا بالتوسع استجابة لأعباء العمل المتنوعة. يمكن أن تكون أيضًا أرخص بكثير للخدمات ذات الحجم المنخفض لأنها لا تعمل على مدار الساعة طوال أيام الأسبوع. تعمل Lambda بشكل جيد مع أعباء العمل التي يمكنها تحمل البدايات الباردة بعد فترات من عدم النشاط. إذا لم يتم تشغيل وظيفة بدون خادم لمدة 24 دقيقة تقريبًا ، فإن الطلب التالي يواجه ما يُعرف بالبداية الباردة لأنه يجب توفير حاوية الوظيفة.

قامت Medidata ببناء العديد من التصاميم المعمارية لإثبات المفهوم (POC) لمقارنة Lambda مع البدائل الأخرى. كأول تطبيق بسيط ، تم تجميع كود استنتاج ML كصورة Docker ونشره كحاوية باستخدام Lambda. لتسهيل التنبؤات بشكل أسرع مع هذا الإعداد ، تتطلب وظيفة Lambda التي تم استدعاؤها مساحة كبيرة من الذاكرة المتوفرة. بالنسبة للحمولات الكبيرة ، يوجد حمل إضافي لضغط المدخلات قبل استدعاء نقطة نهاية Lambda Docker. هناك حاجة أيضًا إلى تكوينات إضافية لقواعد حدث CloudWatch لحفظ المدخلات والمخرجات ، وتتبع تقدم الطلب ، واستخدام قاعدة بيانات مختارة لتتبع الحالات الداخلية والبيانات الوصفية للطلبات التي تم إطلاقها. بالإضافة إلى ذلك ، هناك أيضًا عبء تشغيلي لقراءة البيانات وكتابتها إلى Amazon S3. قامت Medidata بحساب التكلفة المتوقعة لنهج Lambda بناءً على تقديرات الاستخدام وتقرر أنها ستكون أكثر تكلفة من SageMaker بدون أي فوائد إضافية.

الاستدلال غير المتزامن لـ SageMaker

يعد الاستدلال غير المتزامن أحد أحدث عروض الاستدلال في SageMaker الذي يستخدم قائمة انتظار داخلية للطلبات الواردة ويعالجها بشكل غير متزامن. يعد هذا الخيار مثاليًا للاستدلالات ذات الأحجام الكبيرة للحمولة الصافية (تصل إلى 1 جيجابايت) أو أوقات المعالجة الطويلة (حتى 15 دقيقة) التي تحتاج إلى المعالجة عند وصول الطلبات. يمكّنك الاستدلال غير المتزامن من توفير التكاليف عن طريق القياس التلقائي لعدد المثيلات إلى الصفر في حالة عدم وجود طلبات للمعالجة ، لذلك لا تدفع إلا عندما تقوم نقطة النهاية بمعالجة الطلبات.

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

يشبه إنشاء نقطة نهاية للاستدلال غير المتزامن إلى حد كبير إنشاء نقطة نهاية في الوقت الفعلي. يمكنك استخدام برنامج SageMaker الموجود لديك عارضات ازياء وتحتاج فقط إلى تحديد إضافية تكوين الاستدلال غير المتزامن المعلمات أثناء إنشاء تكوين نقطة النهاية الخاصة بك. بالإضافة إلى ذلك ، يمكنك إرفاق سياسة قياس تلقائي بنقطة النهاية وفقًا لمتطلبات القياس الخاصة بك. لاستدعاء نقطة النهاية ، تحتاج إلى وضع حمولة الطلب في Amazon S3 وتوفير مؤشر للحمولة كجزء من طلب الاستدعاء. عند الاستدعاء ، يقوم SageMaker بإدراج طلب المعالجة في قائمة الانتظار وإرجاع موقع الإخراج كاستجابة. عند المعالجة ، يضع SageMaker استجابة الاستنتاج في موقع Amazon S3 الذي تم إرجاعه مسبقًا. يمكنك اختياريًا اختيار تلقي إشعارات النجاح أو الخطأ عبر Amazon SNS.

استنادًا إلى التصميمات المعمارية المختلفة التي تمت مناقشتها سابقًا ، حددنا العديد من الاختناقات وتحديات التعقيد مع هذه البنى. مع إطلاق الاستدلال غير المتزامن واستنادًا إلى التجارب الشاملة وقياس الأداء ، قررت Medidata اختيار الاستدلال غير المتزامن من SageMaker لبنيتها النهائية للاستضافة نظرًا لعدد من الأسباب الموضحة سابقًا. تم تصميم SageMaker من الألف إلى الياء لدعم أحمال عمل ML ، في حين أن Lambda هي أكثر من أداة للأغراض العامة. بالنسبة لحالة الاستخدام المحددة ونوع عبء العمل ، يكون الاستدلال غير المتزامن لـ SageMaker أرخص من Lambda. أيضًا ، مهلة الاستدلال غير المتزامن لـ SageMaker أطول بكثير (15 دقيقة) مقارنةً بمهلة الاستدلال في الوقت الفعلي البالغة 60 ثانية. هذا يضمن أن الاستدلال غير المتزامن يمكنه دعم جميع أحمال عمل Medidata دون تعديل. بالإضافة إلى ذلك ، فإن الاستدلال غير المتزامن من SageMaker يصطف الطلبات أثناء الاندفاعات السريعة لحركة المرور بدلاً من إسقاطها ، وهو مطلب قوي وفقًا لحالة الاستخدام الخاصة بنا. يتم التعامل مع الاستثناءات ومعالجة الأخطاء تلقائيًا نيابة عنك. يسهل الاستدلال غير المتزامن أيضًا التعامل مع أحجام الحمولة الكبيرة ، وهو نمط شائع مع متطلبات الاستدلال لدينا. يظهر الرسم التخطيطي النهائي للهندسة المعمارية باستخدام الاستدلال غير المتزامن SageMaker في الشكل التالي.

تدفق هندستنا النهائية على النحو التالي:

1. تستقبل وظيفة الإرسال الحمولة المجمعة من تطبيقات المستهلك الأولية ويتم إعدادها لتكون مدفوعة بالأحداث. تقوم هذه الوظيفة بتحميل الحمولة إلى موقع Amazon S3 المحدد مسبقًا.
2. تستدعي وظيفة الإرسال بعد ذلك نقطة النهاية غير المتزامنة لـ SageMaker ، وتزودها بمؤشر Amazon S3 للحمولة التي تم تحميلها.
3. تعمل الوظيفة أيضًا على تحديث حالة الطلب إلى inProgress في قاعدة بيانات تعقب البيانات الوصفية والدولة.
4. تقرأ نقطة نهاية الاستدلال غير المتزامن من SageMaker المدخلات من Amazon S3 وتقوم بتشغيل منطق الاستدلال. عندما ينجح استنتاج ML أو يفشل ، تتم إعادة كتابة ناتج الاستنتاج إلى Amazon S3 ويتم إرسال الحالة إلى موضوع SNS.
5. تشترك وظيفة إعلام Lambda في موضوع SNS. يتم استدعاء الوظيفة كلما تم نشر إشعار تحديث الحالة للموضوع.
6. تقوم وظيفة الإعلام بتحديث حالة الطلب للنجاح أو الفشل في قاعدة بيانات تعقب البيانات الوصفية والحالة.

للتلخيص ، استغرقت بنية MVP لتحويل الدُفعات التي بدأنا بها من 5 إلى 15 دقيقة للتشغيل اعتمادًا على حجم الإدخال. مع التبديل إلى الاستدلال غير المتزامن ، يعمل الحل الجديد من النهاية إلى النهاية في غضون 10-60 ثانية. نرى تسريعًا أسرع بخمس مرات على الأقل للمدخلات الأكبر وما يصل إلى 30 مرة للمدخلات الأصغر ، مما يؤدي إلى رضا العملاء بشكل أفضل عن نتائج الأداء. تعمل البنية النهائية المنقحة على تبسيط البنية السابقة غير المتزامنة للتدفق / المروحة إلى حد كبير لأنه لا داعي للقلق بشأن تقسيم الحمولة الصافية الواردة ، وتوليد العمال ، وتفويض العمل وتوحيده بين وظائف Lambda العاملة.

وفي الختام

مع الاستدلال غير المتزامن من SageMaker ، يواجه عملاء Medidata الذين يستخدمون هذا التطبيق التنبئي الجديد الآن تسريعًا أسرع بما يصل إلى 30 مرة للتنبؤات. لا يتم إسقاط الطلبات أثناء ارتفاعات حركة المرور لأن نقطة نهاية الاستدلال غير المتزامن تصنف الطلبات بدلاً من إسقاطها. تمكن إشعار SNS المدمج من التغلب على إشعار سجل أحداث CloudWatch المخصص الذي أنشأته Medidata لإخطار التطبيق عند اكتمال المهمة. في هذه الحالة ، يكون نهج الاستدلال غير المتزامن أرخص من Lambda. يعد الاستدلال غير المتزامن من SageMaker خيارًا ممتازًا إذا كان فريقك يشغل أعباء عمل ثقيلة في تعلم الآلة مع حركة مرور سريعة أثناء محاولة تقليل التكلفة. يعد هذا مثالًا رائعًا على التعاون مع فريق AWS لتخطي الحدود واستخدام تقنية متطورة لتحقيق أقصى قدر من الكفاءة.

للحصول على خطوات تفصيلية حول كيفية إنشاء نقاط نهاية الاستدلال غير المتزامن واستدعاءها ومراقبتها ، يرجى الرجوع إلى توثيق، والذي يحتوي أيضًا على ملف نموذج دفتر الملاحظات لمساعدتك على البدء. للحصول على معلومات التسعير ، قم بزيارة الأمازون SageMaker التسعير. للحصول على أمثلة حول استخدام الاستدلال غير المتزامن مع البيانات غير المهيكلة مثل رؤية الكمبيوتر ومعالجة اللغة الطبيعية (NLP) ، يرجى الرجوع إلى قم بتشغيل استدلال رؤية الكمبيوتر على مقاطع الفيديو الكبيرة باستخدام نقاط النهاية غير المتزامنة لـ Amazon SageMaker و قم بتحسين البحث عالي القيمة باستخدام Hugging Face و Amazon SageMaker لنقاط نهاية الاستدلال غير المتزامن، على التوالي.

---

عن المؤلفين

راجنيش جين هو مدير أول للهندسة في Medidata AI ومقره في مدينة نيويورك. يترأس راجنيش قسم الهندسة لمجموعة من التطبيقات التي تستخدم التعلم الآلي على AWS لمساعدة العملاء على تحسين النجاح التشغيلي للتجارب السريرية المقترحة. إنه متحمس لاستخدام التعلم الآلي لحل مشاكل العمل.

بريانكا كولكارني مهندس برمجيات رائد في Acorn AI في Medidata Solutions. إنها تصمم وتطور الحلول والبنية التحتية لدعم تنبؤات ML على نطاق واسع. هي مهندسة تعتمد على البيانات وتؤمن ببناء حلول برمجية مبتكرة لنجاح العملاء.

دانيال جونسون هو مهندس برمجيات أول في Acorn AI في Medidata Solutions. قام ببناء واجهات برمجة التطبيقات لدعم تنبؤات ML حول جدوى التجارب السريرية المقترحة.

أرونبراساث شانكار هو مهندس حلول متخصص في الذكاء الاصطناعي / التعلم الآلي مع AWS ، مما يساعد العملاء العالميين على توسيع نطاق حلول الذكاء الاصطناعي الخاصة بهم بفعالية وكفاءة في السحابة. يستمتع Arun في أوقات فراغه بمشاهدة أفلام الخيال العلمي والاستماع إلى الموسيقى الكلاسيكية.

راغو راميشا هو مهندس حلول ML مع فريق Amazon SageMaker Service. إنه يركز على مساعدة العملاء في بناء ونشر وترحيل أعباء عمل إنتاج ML إلى SageMaker على نطاق واسع. وهو متخصص في مجالات التعلم الآلي والذكاء الاصطناعي ورؤية الكمبيوتر ، وهو حاصل على درجة الماجستير في علوم الكمبيوتر من جامعة UT Dallas. في أوقات فراغه يستمتع بالسفر والتصوير.