AWS وتكلفة الإجراء المعتمد على النموذج القابل للقبول

ملخص

• لا يُختبر AWS باتساع قائمة الذكاء الاصطناعي فحسب. بالنسبة لفرق المؤسسات التي تستخدم Amazon Bedrock وLambda وStep Functions وIAM وCloudWatch والخدمات ذات الصلة، فإن الوحدة الحاسمة هي الإجراء المقبول: طلب مدعوم بنموذج يستدعي الأدوات الصحيحة، ويحترم الأذونات، ويترك أدلة كافية، ويتعامل مع الفشل، ويكون جيدًا بما يكفي لقبوله من قبل الإنسان أو النظام اللاحق.
• أقوى ما يميز AWS هو التكامل. يجلب Bedrock الوصول المُدار إلى النماذج الأساسية والاسترجاع والحواجز الوقائية وتسجيل الاستدعاء وميزات التقييم إلى نفس البيئة السحابية التي تدير بالفعل الحوسبة والهوية والتخزين والعمليات. وهذا يقلل من بعض الأعمال غير المتمايزة، لكنه لا يزيل عبء العميل في تحديد السلطة واختبار مسارات الاستثناء ومراجعة المخرجات وقياس التكلفة.
• أنماط الفشل الرئيسية هي مشاكل السحابة والأتمتة العادية التي يصبح التعامل معها أقل تسامحًا بسبب عدم يقين النموذج: عدم تطابق IAM، استنفاد الحصة، اختناق Lambda، تنفيذ جزئي لـ Step Functions، استرجاع قديم، تسجيل غير كامل، حلقات إعادة المحاولة، إنفاق جامح، سلوك احتياطي غير واضح، وإرهاق المراجع.
• السؤال التجاري ليس ما إذا كان بإمكان AWS استضافة النظام. بل هو ما إذا كانت مكاسب سير العمل المُدار بالذكاء الاصطناعي تفوق رسوم المنصة ورسوم النماذج وتكلفة المراقبة وعمل التكامل والارتباط وعمل المرونة المكرر ووقت المراجعة البشرية عند حسابها لكل إجراء مقبول.

الإجراء المقبول هو المقام

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

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

AWS في وضع جيد لهذا الاختبار لأن خدمات الذكاء الاصطناعي الخاصة بها تقع داخل بيئة تشغيل سحابية ناضجة. يوفر Amazon Bedrock وصولاً مدارًا إلى النماذج الأساسية والقدرات ذات الصلة. يحدد IAM الهوية والأذونات. يمكن لـ Lambda وStep Functions تنفيذ وتنسيق العمل. يمكن لـ CloudWatch وCloudTrail تسجيل الأدلة التشغيلية والتدقيقية. يمكن لـ S3 وقواعد البيانات وقوائم الانتظار وخدمات الأحداث الاحتفاظ بالبيانات وربط الأنظمة. بالنسبة لشركة ملتزمة بالفعل بـ AWS، فإن هذا الاتساع يعد ميزة حقيقية مقارنة بواجهة برمجة تطبيقات نموذجية مباشرة مثبتة على مجموعة تشغيل منفصلة.

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

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

هذه المقالة تدور حول Amazon Web Services ككيان سحابي AWS وخدمات AWS المُدارة للذكاء الاصطناعي وسير العمل السحابي. لا تتعلق بأمازون للتجزئة أو أمازون للروبوتات أو الشركات التابعة الإقليمية الفردية لـ AWS أو جودة منتج تطبيق العميل الخاص. يمكن لـ AWS توفير الوصول إلى النماذج والآلات السحابية المحيطة بها. لا يزال العميل يملك التعريف التشغيلي لكلمة "مقبول".

يجلب AWS اختيار النموذج إلى مستوى التحكم في السحابة

يمنح Amazon Bedrock AWS نقطة انطلاق قوية لأنه يجعل اختيار النموذج الأساسي قدرة سحابية مُدارة بدلاً من تكامل بائع منفصل. تصف وثائق Bedrock الحالية خدمة مُدارة بالكامل مع إمكانية الوصول إلى أكثر من 100 نموذج أساسي من مزودين متعددين وأنماط API تتضمن Converse وInvoke وResponses وChat Completions. الأهمية ليست فقط عدد النماذج. بل هي أن العميل يمكنه وضع اختيار النموذج ورمز التطبيق والهوية وتخزين البيانات والتسجيل والفواتير داخل نفس نموذج التشغيل السحابي.

هذا مهم عندما تنتقل الفرق إلى ما بعد التجربة. في العرض التوضيحي، يكون النموذج غالبًا هو النجم. في العمل المتكرر، النموذج هو مجرد مكون واحد. تحتاج الفريق إلى تحديد أي نموذج مسموح به لأي مهمة، وأي البيانات يمكن إرسالها إليه، وأي هوية مستخدم أو خدمة تدفع مقابل الاستدعاء، وأي مخرجات تتطلب مراجعة، وأي نتيجة يمكن أن تؤدي إلى أداة، وأي دليل يجب تخزينه. يساعد Bedrock لأن هذه الخيارات يمكن ربطها بحسابات AWS والمناطق وأدوار IAM وحصص الخدمة وCloudWatch Logs ودلاء S3 وأدوات التكلفة.

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

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

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

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

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

التنسيق هو عندما تصبح الطلاقة مسؤولية

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

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

لدى AWS القطع لتقييد هذا. يمكن لـ Lambda عزل العمل القابل للتنفيذ في وظائف. يمكن لـ Step Functions جعل التنسيق متعدد الخطوات واضحًا. يمكن لـ IAM تحديد الدور الذي يمكنه استدعاء أي خدمة. يمكن أن ينشئ تسجيل Bedrock وCloudTrail مسارات أدلة. يمكن للحواجز الوقائية وطبقات السياسة حظر فئات مختارة من السلوك غير الآمن. هذا أفضل من السماح لنموذج باستدعاء واجهات برمجة تطبيقات داخلية عشوائية من سكريبت غير خاضع للرقابة.

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

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

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

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

تصميم الأذونات جزء من موثوقية النموذج

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

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

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

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

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

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

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

المراقبة متوفرة، ولكنها ليست دليلاً آليًا

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

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

ومع ذلك، يوجد التسجيل في طبقات. يمكن لـ CloudTrail تسجيل نشاط API وأحداث البيانات المحددة. يمكن لـ CloudWatch الاحتفاظ بالسجلات والمقاييس والتنبيهات. يمكن لـ S3 الاحتفاظ بالسجلات الأكبر. يمكن لسجلات التطبيق التقاط القرارات التجارية. يمكن لأنظمة المراجعة التقاط القبول والرفض. القصة الكاملة تتطلب محاذاة هذه السجلات. إذا تم تمكين سجلات استدعاء النموذج ولكن لم يتم ربط استدعاءات الأدوات، يمكن للمراجع رؤية الإجابة ولكن ليس الإجراء. إذا سجل CloudTrail استدعاء API ولكن ليس السبب التجاري، يظهر التدقيق أن شيئًا ما حدث ولكن ليس ما إذا كان مبررًا. إذا تم الاحتفاظ بالسجلات لفترة قصيرة جدًا، تختفي الأدلة قبل مراجعة ربع سنوية.

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

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

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

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

الحصص وإعادة المحاولات تحدد السعة الحقيقية

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

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

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

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

يمنح AWS الفرق المكونات لإدارة هذا: منطق إعادة المحاولة والالتقاط في Step Functions، وقوائم الانتظار، ومسارات الرسائل الميتة، ووجهات Lambda، ومفاتيح التماثل في رمز التطبيق، وتنبيهات CloudWatch، وأدوات التكلفة. العبء هو كتابة قواعد التشغيل. يجب أن يعرف النظام المباشر أي حالات الفشل عابرة، وأيها نهائية، وأيها تتطلب مراجعة بشرية، وأيها يجب أن يتوقف فورًا لتجنب التكلفة أو الضرر. يجب أيضًا تسجيل المحاولات الفاشلة كجزء من المقام. سير العمل الذي ينتج 10,000 استدعاء نموذج و 6,000 إجراء مقبول ليس نظامًا بـ 10,000 إجراء. الـ 4,000 إخفاق تشرح الاقتصاديات الحقيقية.

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

المراجعة هي مركز التكلفة الخفي

غالبًا ما تُصاغ الحالة التجارية لسير عمل الذكاء الاصطناعي في AWS على أنها تسريع هندسي. هذا معقول. المواد المنشورة من AWS تشير إلى أن Thomson Reuters استخدمت Bedrock لتوسيع الوصول إلى النماذج داخل منصة Open Arena الخاصة بها، وقللت وقت نشر النموذج من أيام أو أسابيع إلى دقائق أو ساعات لفرق التطوير. حساب آخر منشور من AWS عن Thomson Reuters يصف أتمتة الهندسة الأساسية مع التحقق البشري للعمليات الحساسة ويبلغ عن نتائج مختارة مثل زيادة الإنتاجية بمقدار 15 ضعفًا ومعدل أتمتة بنسبة 70% عند الإطلاق الأول.

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

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

يجب على المشتري قياس دقائق المراجع لكل إجراء مقبول، وليس فقط معدل الأتمتة. النظام الذي يؤتمت 70% من الطلبات قد يكون ممتازًا إذا تم توجيه الـ 30% المتبقية بشكل نظيف وسريعة المراجعة. قد يكون سيئًا إذا كان كل إجراء مقبول يحتاج إلى مهندس كبير لقراءة تتبع طويل. وبالمثل، النظام الذي يرفض العديد من الإجراءات قد يكون قيمًا إذا منع الضرر، لكنه مكلف إذا كانت الرفوض ناتجة عن استرجاع ضعيف أو تعليمات غير واضحة أو مرشحات واسعة جدًا.

يمكن لتكامل مستوى التحكم في AWS تقليل عبء المراجعة من خلال تسهيل جمع الأدلة. يمكن لسجلات استدعاء النموذج إظهار الهوية وعدد الرموز. يمكن لـ CloudTrail إظهار نشاط API. يمكن للحواجز الوقائية إنتاج إشارات حول المخرجات المحجوبة أو المؤرضة. يمكن لـ Step Functions إظهار انتقالات الحالة. يمكن لـ IAM إظهار حدود الأدوار. يمكن أن تتضمن قواعد المعرفة الاستشهادات. لكن المراجع لا يزال بحاجة إلى عرض قبول موجز. السجلات الخام المنتشرة عبر الخدمات هي أدلة، وليس حكمًا.

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

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

يجب قراءة التسعير كمجموعة، وليس كبند واحد

تسعير Bedrock ليس رقمًا واحدًا. تعرض AWS التسعير حسب مزود النموذج والطريقة ومستوى الخدمة، مع خيارات مثل المستويات القياسية والمرنة والأولوية والمحجوزة ورسوم إضافية خاصة بالميزات. تستخدم خدمات وقت التشغيل والتحكم الأحدث في Bedrock أيضًا تسعيرًا قائمًا على الاستهلاك. يمكن أن تساهم CloudWatch وS3 وStep Functions وLambda ومعالجة أحداث CloudTrail ونقل البيانات والتخزين وعمل التقييم جميعًا. النتيجة هي تكلفة مجموعة، وليست تكلفة نموذج.

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

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

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

يجب أن يكون المقام هو الإجراءات المقبولة، وليس الطلبات. لنفترض أن فريقًا يقدم 100,000 طلب. إذا أصبح 70,000 إجراءً مقبولاً، و20,000 يتطلب إعادة عمل يدوي، و10,000 يفشل أو يُهجر، فإن التكلفة الحقيقية ليست فاتورة النموذج مقسومة على 100,000. إنها تكلفة المجموعة الكاملة بالإضافة إلى إعادة العمل مقسومة على 70,000، مع فهم حالات الفشل كعيوب. إذا كان الإجراء المقبول يحل محل عمل خبير باهظ الثمن، فقد يظل جذابًا. إذا كان يحل محل مهمة رخيصة موجودة في البرمجيات كخدمة، فقد لا يكون.

يمنح الحجم المالي لـ AWS حوافز وموارد قوية. أعلنت أمازون عن مبيعات قطاع AWS بقيمة 128.7 مليار دولار لعام 2025 و 37.6 مليار دولار للربع الأول من عام 2026، مع دخل تشغيلي للربع الأول من AWS بقيمة 14.2 مليار دولار. يساعد هذا الحجم في تفسير لماذا يمكن لـ AWS الاستثمار عبر الوصول إلى النماذج والرقائق والتنسيق والحوكمة والمراقبة ودعم المؤسسات. كما يعني أن AWS هو بائع منصة استراتيجي، وليس أداة محايدة. يجب أن يتوقع العملاء فوائد تكامل قوية وضغوط ارتباط كبيرة.

الارتباط ليس سيئًا تلقائيًا. إذا كانت تكلفة الإجراء المقبول أقل على AWS لأن البيانات والهوية والعمليات والمطورين موجودون بالفعل هناك، فقد يكون البقاء داخل AWS عقلانيًا. لكن يجب على المشتري معرفة ما سيكون من الصعب نقله: سياسات IAM، تعريفات Step Functions، وظائف Lambda، التسجيل الخاص بـ Bedrock، تكوين قاعدة المعرفة، قواعد الحواجز الوقائية، بيانات التقييم، لوحات معلومات CloudWatch، ودفاتر التشغيل التشغيلية. خطة الخروج القابلة للتصديق لا تحتاج إلى أن تكون رخيصة. تحتاج إلى أن تكون مفهومة.

أدلة العملاء واعدة ولكنها منتقاة

تدعم أدلة العملاء الخاصة بـ AWS الادعاء بأن المؤسسات تنقل العمل الحقيقي إلى مجموعة الذكاء الاصطناعي الخاصة بها. Thomson Reuters مثال قوي لأنها شركة معلومات وعمل متطورة، وليست حالة استخدام مبتكرة. تقول AWS إن Thomson Reuters استخدمت Bedrock لتوسيع الوصول إلى النماذج، ودعم التجربة، وبناء Checkpoint Edge مع CoCounsel، وهو تطبيق ذكاء اصطناعي توليدي لأبحاث الضرائب مع استشهادات داخلية. تشير الحالة إلى أن Bedrock يمكن أن يساعد مؤسسة كبيرة في جعل الوصول إلى النماذج أكثر أمانًا وتكرارًا.

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

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

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

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

البدائل الواقعية تُبقي AWS صادقة

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

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

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

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

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

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

ما يجب مراقبته

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

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

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

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

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

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

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

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