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. ليس عن أمازون للتجزئة، أو Amazon Robotics، أو فروع AWS الإقليمية الفردية، أو جودة منتج تطبيق العميل نفسه. يمكن لـ AWS توفير الوصول إلى النموذج والآلية السحابية المحيطة به. لا يزال العميل يمتلك التعريف التشغيلي لـ "مقبول".

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

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

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

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

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

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

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

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

التنسيق هو حيث تصبح الطلاقة عبئاً

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

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

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

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

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

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

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

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

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

تقييم سياسة AWS IAM يجعل هذه مشكلة رسمية. توضح وثائق 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 حصص لحجم الطلب، والتنفيذات المفتوحة، وتشغيلات الخرائط (Map Runs)، ومدة مهمة 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 الخاصة بها وخفضت وقت نشر النموذج من أيام أو أسابيع إلى دقائق أو ساعات لفرق التطوير. يصف حساب آخر من Thomson Reuters منشور من AWS أتمتة هندسة المنصة مع تحقق بشري للعمليات الحساسة ويبلغ عن نتائج مختارة مثل زيادة إنتاجية 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، مع فهم الإخفاقات على أنها عيوب. إذا استبدل الإجراء المقبول عملاً خبيراً مكلفاً، فقد يظل ذلك جذاباً. إذا استبدل مهمة SaaS رخيصة موجودة، فقد لا يكون كذلك.

يمنحها حجم 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 بعدة بدائل، وليس فقط بعدم فعل شيء. أحد البدائل هو العمل اليدوي. العمل اليدوي بطيء ومكلف، لكنه يمكن أن يكون مرناً وقابلاً للمساءلة وسهل الإيقاف المؤقت. إذا كان حجم المهمة منخفضاً أو المخاطرة عالية، فقد تتفوق المراجعة اليدوية بقوائم تدقيق أفضل على سير عمل معقد للذكاء الاصطناعي.

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

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

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

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

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

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

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

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

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

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

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

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

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

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