Amazon تستعرض بنية للتحليلات الوكيلية مبنية على SageMaker وAthena وQuick

عرضت AWS بنية يحوّل فيها المساعد الوكيلي Amazon Quick التحليلات على lakehouse إلى خدمة ذاتية لفرق الأعمال. تجمع البنية بين S3 وSageMaker وAWS Glue وAthena، ليتمكن المستخدم من طرح أسئلة على البيانات بلغة طبيعية بدلاً من SQL.

كيف تعمل البنية

في العرض التوضيحي تستخدم AWS مجموعة بيانات TPC-H وتبني فوقها lakehouse من عدة طبقات. تُخزَّن البيانات في Amazon S3، وتُدار البيانات الوصفية عبر AWS Glue، وتصبح Amazon Athena طبقة SQL موحدة للاستعلام عن صيغ تخزين مختلفة. ويستخدم المثال في الوقت نفسه جداول CSV خارجية عادية، وجداول Iceberg بصيغة Parquet، وجداول S3 Tables المُدارة.

لم يُعتمد هذا النهج لأجل جمال البنية فحسب؛ فالشركة تُظهر أن السؤال التجاري نفسه يمكن توجيهه إلى مصادر متباينة دون تجميع يدوي لواجهات بيانات (data marts) خاصة بكل سيناريو.

وفوق ذلك تُبنى في Amazon Quick طبقة المستخدم:

• مجموعات بيانات في SPICE لإجابات ولوحات معلومات سريعة
• Topic كطبقة دلالية للمصطلحات التجارية
• لوحة معلومات تقبل الاستعلامات بلغة طبيعية
• Knowledge Base مبنية على الوثائق والمواصفات
• Quick Space وchat agent كواجهة موحدة

ماذا يفعل الوكيل

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

داخل Quick تُحمَّل البيانات أولاً إلى SPICE، ولذلك ينبغي أن تعمل لوحات المعلومات والإجابات عن الأسئلة النمطية بسرعة حتى مع نمو الـ lakehouse المصدر. وبالنسبة للمجموعات الكبيرة، توصي AWS بدمج الجداول مسبقاً في Athena عبر Custom SQL، ثم تمرير النتيجة المسطّحة إلى Quick.

ولكي لا تقتصر إجابات الوكيل على الأرقام، تضيف AWS إلى الجداول المهيكلة سياقاً غير مهيكل. فتُحمَّل مواصفات TPC-H بصيغة PDF إلى Knowledge Base عبر زاحف ويب (web crawler)، ويُجمع في Quick Space كلٌّ من Topic وقاعدة المعرفة ولوحة المعلومات الجاهزة. بعد ذلك يحصل chat agent على إطار معرفة واحد خاضع للإدارة: يمكنه الإجابة عن أسئلة الإيرادات وحالات الطلبات، كما يستخرج من الوثائق تعريفات الحقول ومنطق الاستعلامات ومعنى استعلامات benchmark. والفكرة بسيطة: واجهة واحدة بدلاً من مجموعة شاشات BI وصفحات wiki متفرقة.

أين يكمن الأثر

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

وتؤكد AWS بصورة خاصة أن هذا النموذج غير مصمم لوضع العرض التوضيحي (demo) فقط: فالوصول مقيَّد بالأدوار، وحدود الرؤية موروثة من IAM وLake Formation. أي أن الموظف لا يرى إلا الجداول والأعمدة والمصادر التي يملك بالفعل أذونات للوصول إليها.

غير أن المنشور يُظهر في الوقت نفسه ثمن هذه الراحة. فقبل التشغيل ينبغي إعداد فهرس Glue، وأذونات Lake Formation، والاتصال بـ Athena، والتحميل إلى SPICE، وTopic وSpace ولوحة المعلومات، ووكيلاً مستقلاً. أي أن AWS لا تَعِد بسحر جاهز من الصندوق: فالتحليلات الوكيلية تظهر حيث توجد lakehouse جاهزة ونماذج وصول ودلالات بيانات مضبوطة. وفي المقابل تحصل الشركة على مسار أقصر من السؤال إلى الجواب وعمل يدوي أقل على جانب المحللين.

ماذا يعني ذلك

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