量子位

٦٨ عامًا، مدير التقنية المسؤول في أمازون: لا تدع الخوف يتحكم في قرارات الذكاء الاصطناعي للشركة

لا يوجد خوارزمية لتقليل الخبرة

مصدر الصورة · 量子位

جين ليهي، من شنتشن

كوانتوم بيت | الحساب العام QbitAI

الخوف هو طريقة سيئة للغاية لاتخاذ القرارات.

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

الآن، تظهر نماذج جديدة كل أسبوع، ويزداد القلق مع كل يوم، خوفًا من التباطؤ في الخطوة الواحدة. رغبة أكبر وأكبر في تحسين الكفاءة والابتكار، لكن ما يمكن أن تفعله التقنيات في النهاية، لم يتم فهمه بشكل كامل.

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

لكن هذا الكلام الذي يُقال من فم ويرنر، يحمل قدرًا من التباين.

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

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

ربما يمكن لحادثة قاعدة البيانات التي تحدث عنها أن تفسر هذا الموقف الذي يبدو متناقضًا.

مخاطر قيد استخدام قاعدة البيانات، هل يجب على الذكاء الاصطناعي أن يخضع لها مرة أخرى؟

في 12 ديسمبر 2004، كانت أمازون في نقطة حاسمة من موسم التسوق للعيد الميلادي. في ذلك الوقت، كان المستخدمون يستمتعون بتوصيل مجاني عند شراء مبلغ 25 دولارًا، لكن النقل يحتاج إلى وقت، وإذا تم الطلب متأخرًا، قد لا تصل الطرود قبل عيد الميلاد.

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

جاء مزود قاعدة البيانات لاحقًا، كان ويرنر يعتقد أن الطرف الآخر سيعتذر بجدية، لكن ما سمعه كان “يجب عليكم القيام بالاختبارات بشكل جيد”.

إذا كان هناك مشكلة في المنتج الخاص بنا، فلماذا نلوم العميل؟

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

لذلك، بدأ الفريق في التحقيق في مشكلة أساسية أكثر أهمية. كيف يستخدم أمازون قاعدة البيانات؟

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

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

بما أن الطلب كذلك، هل يمكن للفريق اختيار طريقة تنفيذ مختلفة؟ إذا فكرنا في طريقة الزيارات الحقيقية، فقد بنوا نظام تخزين القيم والكلمات Dynamo، وهو ما كان سببًا في تطور DynamoDB.

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

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

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

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

وعلاوة على ذلك، قام فيرنر بحساب هذه المبالغ، منذ أكثر من عشرين عامًا.

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

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

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

في عصر الذكاء الاصطناعي، ظهر مشروع جديد في هذا العمليه.

مثلما عندما يتم سؤال الكواركات، "لماذا أصبح نسيان الذكاءات مشكلة هندسية مهمة؟"، يقول فيرنر بصراحة أنه إذا كان الذكاء يتحقق من كل شيء يعرفه قبل كل عمل، فإن تكلفة النظام ستكون كبيرة؛ ويحتاج المطورون إلى إيجاد طريقة لجعل الذكاء يحتفظ بالمحتوى الذي هو مهم حقًا للمهمة.

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

لذلك، بالإضافة إلى مدى ذكاء النموذج، يجب على المطورين التساؤل عن كم من الجهد العديم الفائدة قام به النموذج مرارًا وتكرارًا لإنجاز مهمة معينة.

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

ما الذي يجب استخدامه، وكيفية الاستخدام، وكم يكلف الأمر، هذه المشاكل القديمة لا تزال تُواجه الشركات عند دخول الذكاء الاصطناعي.

من سيخلف الوكيل في أخطائه؟

حتى لو حسبت الشركات تكاليفها بدقة، هناك مشكلة أخرى تنتظر فريق التطوير.

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

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

و هذا التمسك بالحدود، تم ذكره في قصة Nitro التي يرويها.

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

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

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

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

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

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

لكن هل يمكن أن تؤثر هذه القيود على كفاءة العميل؟ في مواجهة هذا السؤال، تحدث ويرنر أولاً عن ذلك.المسؤولية。

إذا بنيته، فأنت مسؤول عنه. (If you build it, you own it.)

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

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

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

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

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

لتفريد العملاء المختلفين، كانت الأجهزة الخاصة التي استخدمتها لامبادا في البداية كبيرة جدًا بالنسبة لمهام الدوال، وتكلفتها عالية. لاحقًا، قام الفريق بتحويل وحدات العزل إلى أجهزة خفيفة جدًا من نوع micro VMs باستخدام Firecracker، مما زاد من كفاءة استخدام الموارد.

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

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

ويرنر يطلق على هذه الأعمال “ابتكار الهندسة غير المرئية” (Invisible Engineering).

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

لا يوجد خوارزمية لتقليل الخبرة

عندما يبدأ العميل في كتابة الكود، تعود هذه المشاكل مرة أخرى إلى فريق التطوير نفسه.

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

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

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

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

لكن، سرعة إنتاج الذكاء الاصطناعي للكود قد تزايدت، وسرعة الفريق في فهم وفحص الكود قد لا تواكب ذلك.

ذكر ويرنر مفهومًا يستحق أن تهتم به الفريق التطويري، وهو التحقق من الديون.

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

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

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

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

لا يوجد خوارزمية لتقليل حجم التجربة.

كانت كلمات ويرنر هذه مناسبة جدًا للرد على قلق المطورين.

لكن عندما تحدث عن رحلته إلى الصين، تحدث عن مثال آخر جعله أكثر تفاؤلاً بشأن تطبيقات الذكاء الاصطناعي. وقد قضى الكثير من الوقت في شرح تجاربه مع “الأرز والدخن”.

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

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

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

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

قال فيرنر إن أفضل أعمال المطورين غالبًا ما تكمن في أماكن لا يستطيع الآخرون رؤيتها.

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

المصدر الأصلي

量子位

ملاحظات المحتوى

النشر الأصلي والحقوق تعود إلى المصدر.

ترجمة آلية · يُرجى الرجوع إلى الأصل