← 返回首页

تجاوز تكلفة كلود بمقدار 1.8 مليون دولار لدى أمازون: كيف تمنع انفلات الإنفاق على الذكاء الاصطناعي

وفقًا للتقارير، بلغت الفاتورة التراكمية لأحد المشاريع الداخلية في أمازون الذي يستخدم Claude Sonnet من Anthropic 1.8 مليون دولار، متجاوزة الميزانية المخططة بنسبة 860%، دون أن يتم اكتشاف ذلك لمدة خمسة أشهر.

发布于 2026年8月5日•general•GEO 评分: 0•11 次阅读

选择语言

العربيةDeutschEnglishEspañolFrançaisItaliano日本語한국어PortuguêsРусский中文
صورة بخلفية زرقاء داكنة، على يسارها عبارة 'Claude 3.7'، وفي الزاوية اليمنى العلوية علامة تحذير بعلامة تعجب حمراء. في الوسط يظهر نص كبير بعنوان 'Amazon’s $1.8M Claude Cost Overrun'، وتحته نص صغير 'How to Prevent Runaway AI Spending'. على اليسار يوجد رسم بياني أزرق يعرض 'Monthly Spend $1,823,756 ↑32% vs Budget'. وعلى اليمين توجد علامة 'Budget Control Active'. الصورة مرتبطة بمحتوى المقال الذي يستعرض مشروع أمازون الداخلي الذي استخدم Claude Sonnet بتكلفة 1.8 مليون دولار، وتجاوز الميزانية بنسبة 860% دون اكتشافه لمدة خمسة أشهر، ويناقش كيفية منع انفلات الإنفاق على وكلاء الذكاء الاصطناعي، وتعمل كعنصر بصري إرشادي.

تكلفة كلود البالغة 1.8 مليون دولار في أمازون: كيف تمنع الإنفاق الجامح على الذكاء الاصطناعي

مقدمة

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

بدت المهمة نفسها اعتيادية: مطابقة معلومات المؤلفين مع قوائم المنتجات على منصة أمازون للتجارة الإلكترونية.

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

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

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

ما حدث داخل أمازون

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

ووفقًا للتقارير، فإن هذا النشر:

  • كلّف 1.8 مليون دولار
  • تجاوز الميزانية المخصصة بنسبة 860%
  • استغرق اكتشافه خمسة أشهر
  • لم يصل إلى بيئة الإنتاج

وصف مهندسون كبار بعض الأخطاء البرمجية المرتبطة بالذكاء الاصطناعي بأنها "باهظة الثمن بشكل كارثي".

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

قد تكون كلتا النقطتين صحيحتين.

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

العيب البرمجي الدقيق لم يُكشف عنه بعد

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

هذا التفسير منطقي، لكنه لم يُؤكد بعد في التقارير العامة الحالية.

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

  • الكود المصدري
  • العيب الدقيق
  • ما إذا كانت العملية حلقة لا نهائية
  • عدد استدعاءات النموذج
  • عدد رموز الإدخال أو الإخراج
  • ما إذا كان النموذج قد استُخدم مباشرة أو عبر Amazon Bedrock
  • إصدار النموذج
  • إعدادات استخدام الأدوات
  • مكونات البنية التحتية التي تولّد التكاليف

الاستنتاج الأكثر أمانًا هو الأكثر تحفظًا: نشر فاشل لنموذج Claude Sonnet أنتج فاتورة ضخمة، ولم تكتشف أنظمة أمازون الرقابية المشكلة خلال خمسة أشهر.

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

ليست هذه مشكلة التكلفة الوحيدة

تجاوزات في التكاليف

يُزعم أن التقرير الداخلي نفسه ناقش حالتين أخريين على الأقل.

المشروع التكاليف غير المتوقعة المبلغ عنها
أداة التدقيق المالي حوالي 541,000 دولار
مشروع لوجستي يهدف إلى تحسين سرعة التوصيل حوالي 134,000 دولار

يُزعم أن اكتشاف التجاوز اللوجستي استغرق أكثر من أسبوعين.

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

قد تتعطل وظائف المعالجة الدفعية التقليدية أو يستنفد الذاكرة أو تفشل في اجتياز الاختبارات.

أما عمليات الذكاء الاصطناعي فقد تظل سليمة تقنيًا بينما تكون منهارة اقتصاديًا.

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

لماذا تختلف أعطال تكاليف الذكاء الاصطناعي

ترتبط تكاليف التطبيقات التقليدية عادة بوحدات مألوفة نسبيًا:

  • وقت الخوادم
  • سعة قواعد البيانات
  • التخزين
  • نقل الشبكة
  • ساعات العمل البشري

أما سير عمل الذكاء الاصطناعي فيمكنه إضافة طبقات متعددة محسوبة حسب الاستهلاك في آن واحد:

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

وينتج عن ذلك تأثير مضاعف.

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

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

نموذج تكلفة بسيط لسير عمل الذكاء الاصطناعي

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

النموذج المبسط كما يلي:

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

المقياس الأساسي ليس مجرد تكلفة الرمز الواحد.

بل هو:

التكلفة الإجمالية لكل نتيجة أعمال مكتملة بنجاح

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

وبالمثل، قد يؤدي نموذج أقوى إلى تكلفة إجمالية أقل إذا أنجز المهمة في خطوات أقل.

الضابط الأول: تعيين مسؤول مالي لكل مهمة ذكاء اصطناعي

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

يجب أن يكون هذا المسؤول على دراية بما يلي:

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

عندما يستمر عامل واحد في إرسال الطلبات دون توقف، لا تكفي الميزانيات الغامضة على مستوى المشروع.

يجب أن توجد الميزانيات على مستويات متعددة:

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

توفر المستويات الأدنى آلية الكبح الأسرع والأكثر فاعلية.

وضع حدود صارمة داخل التطبيق

تنبيهات الفوترة السحابية مهمة، لكنها لا تغني عن الضوابط على مستوى التطبيق.

يجب أن يتوقف التطبيق عن العمل أو يطلب موافقة عند وصوله إلى الحدود المحددة.

الحدود المفيدة تشمل:

  • الحد الأقصى لعدد الطلبات لكل مهمة
  • الحد الأقصى لخطوات الوكيل
  • الحد الأقصى لعدد إعادة المحاولات
  • الحد الأقصى لرموز الإدخال
  • الحد الأقصى لرموز الإخراج
  • الحد الأقصى لطول السياق
  • الحد الأقصى لعدد استدعاءات الأدوات
  • الحد الأقصى لعدد العمال المتوازيين
  • الحد الأقصى للوقت المستغرق
  • الحد الأعلى بالدولار لكل مهمة
  • الحد الأقصى لعدد السجلات التي تتم معالجتها قبل المراجعة

ينبغي أن تكون هذه الضوابط مغلقة افتراضيًا.

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

استخدام مفتاح إيقاف طارئ مستقل عن الوكيل

لا ينبغي أن يمتلك الوكلاء المستقلون الصلاحية النهائية للإنفاق.

يجب أن تكون هناك خدمة مستقلة قادرة على:

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

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

اختبره في بيئة ما قبل الإنتاج.

الضوابط التي لم تُستخدم أبدًا هي مجرد نظرية.

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

يمكن للمؤسسات التي تستخدم Amazon Bedrock تفعيل سجلات استدعاء النموذج لاستدعاءات bedrock-runtime المدعومة.

تقول AWS إن هذه السجلات قد تتضمن بيانات الطلب والاستجابة، وبيانات وصفية، ومعرفات النموذج، ومعرفات الطلب، ومعلومات الهوية، واستخدام الرموز. يمكن أن تشمل وجهات السجلات Amazon CloudWatch Logs وAmazon S3.

سجلات الاستدعاء معطلة افتراضيًا.

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

على الأقل، يجب أن تتضمن سجلات مراقبة التكاليف:

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

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

استخدام AWS Budgets لتتبع تكاليف Claude على Bedrock

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

من السهل تجاهل تفصيل مهم خاص بـ AWS.

توثق AWS Cost Anomaly Detection أن الخدمة لا تراقب منتجات الطرف الثالث المباعة عبر AWS Marketplace، بما في ذلك نماذج اللغة من الطرف الثالث المقدمة عبر Amazon Bedrock مثل Anthropic Claude.

تظل هذه التكاليف ظاهرة في Cost Explorer والفواتير، لكن AWS توصي باستخدام AWS Budgets للتنبيه على هذه الرسوم.

يمكن استخدام مرشحات كيان الفوترة في الميزانيات لتتبع رسوم Marketplace بدقة أكبر.

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

لا تتعامل مع AWS Budgets كقاطع دائرة فوري

توثق AWS أن حالة الميزانية تتحدث عدة مرات يوميًا.

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

هذا يعني أن AWS Budgets مفيدة للحوكمة المالية، لكن استخدامها بمفردها قد لا يكون سريعًا بما يكفي لإيقاف وكيل عالي الإنتاجية.

يجب أن تحتوي مجموعة الضوابط على:

  1. عدادات على مستوى الطلب داخل التطبيق
  2. مقاييس استخدام قريبة من الوقت الفعلي
  3. حدود قصوى صارمة لكل مهمة وكل جلسة
  4. تنبيهات ميزانية سحابية
  5. إجراءات ميزانية آلية عند الاقتضاء
  6. مراجعة مالية يومية للإصدارات عالية المخاطر

كلما زادت سرعة إنفاق سير العمل للأموال، كلما اقتربت الضوابط من نقطة الاستدعاء.

استخدام كشف الشذوذ للتكاليف ضمن تغطية الخدمة

يستخدم AWS Cost Anomaly Detection نماذج تعلم آلي لتحديد أنماط الإنفاق غير المعتادة والمساعدة في تحديد الأسباب الجذرية المحتملة.

تقول AWS إن الخدمة تقيّم بيانات الفوترة المعالجة حوالي ثلاث مرات يوميًا.

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

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

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

التعامل مع Service Quotas كحدود أمان وليس كميزانيات

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

يمكن أن تمنع الحصص الإنتاجية غير المحدودة، لكنها ليست مصممة لتكون ميزانيات مالية دقيقة.

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

لذلك، يجب أن تتطلب تغييرات الحصص:

  • مبرر تجاري
  • توقعات تكلفة محدثة
  • موافقة باسم شخص محدد
  • حدود تنبيه محدثة
  • خطة تراجع
  • مراجعة بعد زيادة حركة المرور

يجب التعامل مع حدود المعدل والرموز كجزء من تصميم مخاطر النظام، وليس مجرد عوائق أمام التوسع.

تتبع استخدام وتكاليف Anthropic مباشرة عند الاقتضاء

للتطبيقات التي تستدعي Anthropic مباشرة، توفر وحدة تحكم Anthropic تقارير عن التكاليف والاستخدام.

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

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

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

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

البدء بعينة تمثيلية صغيرة

يُذكر أن مشروعًا في Amazon حاول تنفيذ مهمة مطابقة بيانات واسعة النطاق.

نمط النشر الأكثر أمانًا هو:

  1. تشغيل 100 سجل تمثيلي.
  2. قياس الدقة والتكلفة.
  3. تشغيل 1000 سجل.
  4. فحص الأخطاء وتوزيع الرموز.
  5. اختبار أسوأ حالات الإدخال.
  6. تأكيد ضوابط الإيقاف.
  7. تقدير الإنفاق للمعالجة الكاملة.
  8. طلب الموافقة قبل معالجة مجموعة البيانات الكاملة.

لا تستند إلى متوسط السجلات فقط.

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

استخدم تقديرات النسب المئوية مثل تكلفة P50 وP95 وP99 لكل مهمة.

تحديد سقف أقصى للتكلفة لكل نتيجة صالحة

يجب أن يتوقف سير العمل عندما لا تكون استدعاءات النموذج الإضافية مبررة اقتصاديًا.

بالنسبة لنظام مطابقة المؤلفين، يمكن أن تشمل المقاييس المفيدة:

  • التكلفة لكل مطابقة مؤلف ناجحة
  • التكلفة لكل سجل يتم مراجعته يدويًا
  • النسبة المئوية للسجلات التي تم حلها تلقائيًا
  • معدل المطابقة الخاطئة
  • تكلفة المطابقات الخاطئة
  • التوفير مقارنة بالمعالجة اليدوية
  • عدد استدعاءات النموذج المطلوبة لكل نتيجة مقبولة

قد تبدو العملية التي تكلف 0.02 دولار لكل طلب رخيصة.

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

توجيه المهام البسيطة إلى طرق أرخص

ليست كل سجل يتطلب نموذجًا متطورًا.

يمكن أن تستخدم خط أنابيب واعٍ بالتكلفة:

  1. المطابقة الدقيقة
  2. روابط قاعدة البيانات
  3. القواعد
  4. تشابه التضمينات
  5. نماذج أصغر
  6. استخدام نموذج أقوى فقط في الحالات الغامضة
  7. مراجعة بشرية للقرارات عالية المخاطر

بالنسبة لمشاريع مطابقة البيانات، قد يحل البرنامج التقليدي معظم الحالات بتكلفة أقل وبطريقة أكثر حتمية.

يجب استخدام LLM فقط عندما تكون هناك حاجة فعلية للغموض اللغوي، وليس تلقائيًا لكل سطر.

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

منع إعادة المحاولة غير المحدودة

تعد إعادة المحاولة مصدرًا شائعًا للإنفاق الخفي.

قد يعيد طلب فاشل المحاولة من قبل التطبيق أو نظام قوائم الانتظار أو SDK أو البوابة أو مدير العمال أو الوكيل أو منسق سير العمل.

عندما تعيد طبقات متعددة المحاولة بشكل مستقل، قد تولد مهمة منطقية واحدة طلبات مدفوعة متعددة.

حدد استراتيجية إعادة محاولة موحدة تحتوي على:

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

بما في ذلك عدد مرات إعادة المحاولة

يجب ألا تخلق الأخطاء حلقة اقتصادية لا نهائية.

فصل بيانات الاعتماد بين بيئة التطوير والإنتاج

يجب ألا ترث سكربتات الاختبار حدودًا على مستوى الإنتاج.

استخدم حسابات أو مساحات عمل منفصلة ومفاتيح API وأدوار IAM وميزانيات وحصصًا وسجلات ومصادر بيانات وأذونات شبكة منفصلة.

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

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

مراجعة الكود المولّد بالذكاء الاصطناعي كمراجعة للبنية التحتية المالية الإنتاجية

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

المشكلة المهمة هي ما إذا كان الكود قد يؤدي إلى إنفاق أموال.

يجب أن يخضع أي مكوّن يمكنه إرسال طلبات نماذج مدفوعة للمراجعة التالية:

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

يجب أن تتضمن اختبارات الوحدة سيناريوهات الفشل الاقتصادي.

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

المسار الطبيعي الصحيح وظيفيًا ليس كافيًا بأي حال.

قائمة فحص ضبط تكاليف الذكاء الاصطناعي على مستوى الإنتاج

الملكية والتخطيط

  • [] مسؤول تقني معين مسؤول عن الإنفاق.

  • [] توثيق الاستخدام والتكلفة المتوقعة لكل نتيجة ناجحة.

  • [

[ ] بيئات التطوير والاختبار الأولي والإنتاج لها ميزانيات مستقلة.

  • المعالجة الكاملة النطاق تتطلب موافقة صريحة.

التحكم في التطبيق

  • لكل مهمة حد أقصى لعدد الطلبات والرموز والخطوات والمحاولات والوقت المستغرق.

  • لكل جلسة وكيل ميزانية بالدولار الأمريكي.

  • يمكن للخدمات غير المرتبطة بالوكيل إيقاف سير العمل.

  • يتم إيقاف المهمة مؤقتًا عند تعذر قراءة الميزانية المتبقية.

  • يتم منع العمل المكرر من خلال خاصية التطابق (Idempotency).

المراقبة

  • كل استدعاء نموذج يُنسب إلى الفريق والمشروع والمستخدم والمهمة.

  • يتم تسجيل استخدام المدخلات والمخرجات وذاكرة التخزين المؤقت والأدوات وإعادة المحاولات.

  • يتم ضبط التنبيهات على كل من معدل الإنفاق وإجمالي الإنفاق.

  • يتم تفعيل المراجعة اليومية أثناء الإطلاق الأولي للإنتاج.

  • تدرك الفرق بنود التكاليف غير المشمولة في كشف الحالات الشاذة.

الجودة والاقتصاد

  • يتم قياس التكلفة مقابل كل نتيجة أعمال ناجحة.

  • يتم استخدام التعليمات البرمجية التقليدية والنماذج الأصغر عند الاقتضاء.

  • تم اختبار أسوأ الحالات والتكاليف عند النسب المئوية العليا.

  • تشمل التكاليف تكلفة المراجعة البشرية.

  • يتوقف سير العمل عندما لا تعود الاستدعاءات الإضافية ذات قيمة.

الحوكمة

  • تخضع التعليمات البرمجية المولدة بالذكاء الاصطناعي للمراجعة البشرية.

  • تتطلب زيادات الميزانية والحصص موافقة.

  • تم اختبار مفتاح الإيقاف الطارئ.

  • يشمل الاستجابة للحوادث أصحاب المصلحة الماليين والتقنيين.

  • تراجع الفرق الإنفاق بعد كل تغيير رئيسي في النموذج أو موجه.

الدروس المستفادة من استجابة أمازون

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

هذا هو الاتجاه

الصحيح، ولكن الأتمتة يجب أن تعمل على مستويات متعددة.

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

كما أزالت الشركة سابقًا لوحة تصدر داخلية كانت تشجع الموظفين على زيادة استخدامهم لأداة التطوير "Kiro" الخاصة بهم. وفقًا لتقرير صحيفة فاينانشال تايمز، ساهمت اللوحة في ظاهرة "زيادة الرموز" (tokenmaxxing)، حيث يرفع الموظفون استهلاكهم من الرموز لتحسين ترتيبهم.

هذا تذكير مفيد: الحوافز قد تقوض ضبط التكاليف.

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

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

عدد الرموز هو مقياس إدخال، وليس مقياسًا للإنتاجية.

الأسئلة الشائعة

هل أنفقت أمازون فعلًا 1.8 مليون دولار على Claude Sonnet؟

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

لماذا لم يتم اكتشاف تجاوز التكاليف خلال خمسة أشهر؟

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

هل كانت المشكلة ناتجة عن حلقات ذكاء اصطناعي لا نهائية؟

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

هل لدى أمازون حالات أخرى لتجاوز تكاليف الذكاء الاصطناعي؟

نعم. يُزعم أن نفس العرض التقديمي الداخلي تضمن أيضًا تكاليف غير متوقعة لمشروع تدقيق مالي بقيمة حوالي 541 ألف دولار، وتكاليف مشروع لوجستي بقيمة 134 ألف دولار.

هل يمكن لخدمة AWS Cost Anomaly Detection مراقبة تكاليف Claude على Amazon Bedrock؟

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

هل يمكن لـ AWS Budgets إيقاف الإنفاق الجامح للذكاء الاصطناعي فورًا؟

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

هل حدود المعدل تعادل حدود الإنفاق؟

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

ما هو أهم ضابط للوكلاء الذكيين؟

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

الأدوات ذات الصلة

  • AWS Budgets: يتتبع التكاليف والاستخدام مقارنة بالعتبات ويطلق إشعارات أو إجراءات ميزانية مُهيأة.
  • AWS Cost Anomaly Detection: يكتشف أنماط إنفاق AWS غير طبيعية في فئات الفوترة المدعومة.
  • AWS Cost Explorer: يساعد الفرق على تحليل التكاليف والاستخدام التاريخيين عبر خدمات AWS وأبعاد الفوترة.
  • سجلات استدعاء نماذج Amazon Bedrock: يسجل استدعاءات النماذج المدعومة والبيانات الوصفية ذات الصلة في CloudWatch Logs أو Amazon S3.
  • حصص خدمة Amazon Bedrock: تعرض حدود النماذج ونقاط النهاية التي قد تحد من إنتاجية الاستدلال.
  • Anthropic Console: يوفر مفاتيح API وتقارير الاستخدام وتقارير التكاليف ومساحات العمل وضوابط على مستوى الحساب للاستخدام المباشر لواجهة Anthropic API.

الروابط ذات الصلة

com/bedrock/latest/userguide/model-invocation-logging.html): الدليل الرسمي لإعداد تسجيل استدعاءات النماذج ومعالجة البيانات في Bedrock.

ملخص

وفقًا للتقارير، أنفقت مشروع داخلي في أمازون يستخدم Claude Sonnet مبلغ 1.8 مليون دولار أمريكي، متجاوزًا الميزانية بنسبة 860%، دون أن يُكتشف ذلك لمدة خمسة أشهر، ولم يتم إطلاقه أبدًا. كما أشارت التقارير إلى أن مشاريع ذكاء اصطناعي أخرى أنتجت نفقات غير متوقعة بمئات الآلاف من الدولارات.

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

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

**

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