AWS تنشر قالب بحيرة بيانات لـ Bedrock: كل موجّه (prompt) وكل رمز (token) وسعره تحت الأنظار

قصة مألوفة: في نهاية الشهر تصل فاتورة Bedrock وقد ارتفع المبلغ، ولا يمكن الإجابة عن سؤال «من ولماذا». الإجمالي ظاهر، أما محتوى الاستدعاءات فلا. لا يُعرف أي موجّه أُرسل، وماذا أعاد النموذج، وكم رمزًا استهلك. تقترح AWS حلًا جاهزًا: بحيرة بيانات مركزية لجميع استدعاءات Bedrock في المؤسسة. قوالب CloudFormation وشيفرة Lambda واستعلامات SQL موجودة في مستودع AWS Sample Bedrock Invocation Data Lake.

ما هو متوفر افتراضيًا وما ينقص

يوفّر Bedrock ميزة model invocation logging. فهي تكتب أثرًا كاملًا للطلبات والردود في S3 أو CloudWatch. لكنها تُفعَّل بشكل منفصل في كل حساب، وتبقى البيانات هناك. وإذا كان لديك عشرة حسابات، فستحصل على عشر جزر معزولة. ومن الصعب مقارنة الفرق، أو العثور على موجّه مُبذِّر، أو تحليل ارتفاع مفاجئ في النفقات حسب الفريق.

كيف يعمل المسار

يتكوّن مسار كل استدعاء من خمس مراحل:

• يكتب Bedrock في الحساب المصدر السجل في مجموعة CloudWatch.
• يعمل subscription filter كقاعدة إعادة توجيه دائمة: يُرسَل كل حدث جديد إلى CloudWatch Logs destination في الحساب المركزي. ولا تحصل المصادر على صلاحيات على المسار المركزي، بل تسلّم الأحداث فقط.
• تقوم دالة Lambda صغيرة بفك حزم CloudWatch التي تصل مضغوطة ومشفّرة. وتستبعد الضجيج الخدمي مثل رسالة «Permissions are correctly set»، وترفع الحقل المتداخل الخاص بهوية المستدعي إلى المستوى الأعلى.
• يقوم Amazon Data Firehose بتخزين السجلات مؤقتًا، ويحوّل JSON إلى Parquet، ويضعها في S3 مرتبة حسب التاريخ (year/month/day).
• يشرح جدول Glue لـ Athena كيفية قراءة هذه الملفات، ثم تعمل لغة SQL العادية.

وفي النتيجة، يتوفر في جدول واحد لكل استدعاء: الموجّه، والرد، وعدد رموز الإدخال والإخراج، والنموذج، وسبب التوقف، والحساب، والوقت، ودور IAM. لم نعد نقول «أنفقنا X رمزًا»، بل «هذا ما كان في كل استدعاء».

ماذا نفعل بهذا عمليًا

إليكم بعض السيناريوهات من المنشور:

• التنقيح. تستخرج الموجّه والرد الدقيقين لاستدعاء بعينه دون التنقيب في السجلات الخام.
• الكفاءة. تقارن رموز الإدخال والإخراج بحسب الفرق والنماذج لتعرف أين تُهدر الرموز.
• هندسة الموجّهات. تبحث عن الردود ذات stop_reason = max_tokens: فقد بُترت، أي أن الموجّه أو الإعدادات تحتاج إلى تحسين.
• التكلفة. يُربط الجدول بتقرير AWS Cost and Usage Report 2.0 عبر IAM ARN، فتظهر النفقات حسب الفريق واليوم، وكذلك تكلفة أقل الاستدعاءات كفاءة.

وللعرض المرئي توجد لوحة معلومات في Quick Sight تُثبَّت بالأمر cid-cmd deploy. ويمكن إضافة بيانات وصفية عن المؤسسة إليها، مثل أسماء الفرق.

ويربط المؤلفون كل ذلك بمفهوم tokenomics: فبحسب قولهم، أُعلن عنه في مؤتمر FinOps Foundation عام 2026 مجالًا مستقلًا ضمن FinOps. والمنطق بسيط: لا يمكن تحسين الرموز قبل قياسها. والبحيرة توفّر هذه القاعدة تحديدًا.

القيود والمزالق

الخطر الرئيسي هو الأمن. فأنت تضع الموجّهات والردود الكاملة لجميع الفرق في حاوية واحدة، وقد تحتوي على بيانات شخصية (PII). الحاوية مشفّرة عبر KMS، لكن عليك تقييد الوصول إليها وإلى نتائج Athena بسياسات IAM بنفسك.

وهناك أيضًا ملاحظات تشغيلية:

• تسجيل Bedrock إعداد على مستوى الحساب، وليس مورد CloudFormation. يجب تفعيله باستدعاء API منفصل في كل مصدر، ومع التسليم إلى CloudWatch فقط.
• لا تظهر البيانات فورًا: يفرغ Firehose المخزن المؤقت بعد نحو دقيقة، وأحيانًا أكثر. هذا مقبول للتحقيقات، لكنه غير مناسب للتنبيهات الفورية.
• يُنشأ العرض (view) في Athena يدويًا: يجب تنفيذ الاستعلام المحفوظ مرة واحدة.
• يتم الربط بالتكلفة عبر IAM ARN. وإذا كانت جميع الفرق تصل إلى Bedrock بدور واحد، فسيكون التقسيم حسب الفرق تقريبيًا. وهذا استنتاجنا، ولا يناقشه المنشور مباشرة.
• عند الحذف، أفرغ الحاويات أولًا، ثم احذف Athena workgroup يدويًا.

الخلاصة

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