يصل الطلب في الساعة 4:20 مساءً؛ إذ يرغب أحد أصحاب المصلحة في الحصول على مؤشر أداء رئيسي (KPI) للإيرادات اليومية مصنّفاً حسب “القناة” (channel) عن الأيام التسعين الماضية، مع تسليم البيانات عبر منصة Slack قبل موعد الاجتماع اليومي السريع (standup) في اليوم التالي.
يمكن لمساعد الذكاء الاصطناعي صياغة مسودة أولية لاستعلام SQL بسرعة، لكن تظل أنت المسؤول عن الرقم النهائي المُقدَّم. فإذا تسبب الاستعلام في احتساب الإيرادات مرتين نتيجة لعملية ربط بيانات من نوع “متعدد-بمتعدد” (many-to-many join)، فإن الخطأ اللاحق يُحسب عليك أنت، وليس على النموذج. وتتمثل الخطوة المهنية السليمة في استخدام الذكاء الاصطناعي لتعزيز السرعة في الحالات التي لا يترتب فيها تكلفة كبيرة على الخطأ، مع الإبقاء على مراحل للتحقق والمراجعة في الحالات التي يكون فيها الخطأ مكلفاً.
استكشف الأجزاء الرئيسية لهذه العملية.
استخدم الذكاء الاصطناعي لإنشاء مسودات استعلامات SQL عندما تكون المخرجات قابلة للمراجعة والتحقق. تُعد مهام مثل إعداد هيكل الاستعلام، أو تحويل سؤال عملي إلى عبارة GROUP BY برمجية، أو إنشاء مجموعة من استعلامات التحقق، خياراتٍ مثالية؛ إذ يمكنك تشغيلها ومقارنة النتائج التي تنتج عنها.
إليك مثال عملي: لنفترض أن لديك جدول حقائق للطلبات (fact_orders) يحتوي على 12.4 مليون سجل تغطي الفترة من 2024-01-01 إلى 2024-06-30، وجدول أبعاد للقنوات (dim_channel) يعتمد على channel_id كمفتاح أساسي. والمطلوب هو معرفة “صافي الإيرادات اليومية حسب القناة خلال آخر 90 يوماً”. يمكن للذكاء الاصطناعي صياغة عمليات الربط (joins) ومرشحات التاريخ، بينما تتولى أنت التحقق من مستوى تفاصيل السجلات (row-grain) وطبيعة العلاقة بين الجداول (cardinality) قبل اعتماد الإجماليات.
تجنب استخدام الذكاء الاصطناعي في المهام التي تتطلب اتخاذ قرارات ذات سلطة ومسؤولية؛ فتعريف مؤشرات الأداء الرئيسية (KPIs)، وتحديد نطاق المقاييس، وصياغة قواعد العمل ليست مجرد مسائل صياغة تقنية، بل هي قرارات استراتيجية. صحيح أن الذكاء الاصطناعي يمكنه إعادة صياغة تعريفك، لكنك أنت من يقرر المعنى المقصود بكلمة “الإيرادات” (هل هي الإيرادات الإجمالية، أم الصافية بعد خصم المبالغ المستردة أو الخصومات، أم الإيرادات المحققة محاسبياً؟)، وأنت من يتحمل العواقب إذا تصرف أصحاب المصلحة بناءً على تعريف خاطئ.
قارن بين مستويات المخاطر المرتبطة بالمهام المختلفة.
ستستخدم سير عمل واحداً طوال هذه الدورة. تشير “مرحلة التحقق” (Verification gate) إلى خطوة لا يمكنك تجاوزها إلا بعد الحصول على دليل يثبت صحة الاستعلام (query) ومطابقته للتعريف المحدد.
ابدأ بمواصفات واضحة ومحددة؛ حيث تكتب تعريف المقياس، والنطاق الزمني، ومستوى التفاصيل (grain)، وأبعاد التقسيم بلغة بسيطة ومفهومة.
بعد ذلك، انتقل إلى مرحلة التوليد؛ إذ يقوم الذكاء الاصطناعي بصياغة كود SQL وكذلك إعداد اختبارات التحقق التي ستستخدمها لاختبار دقة النتائج. وعليك تنفيذ كافة العمليات بنفسك داخل مستودع البيانات (data warehouse).
لا تقتصر عملية التحقق على مجرد الحصول على نتائج (أي “إرجاع صفوف”)؛ بل يجب التحقق عبر أساليب متعددة (مثل المطابقة المتقاطعة أو التثليث). قارن النتائج برقم موثوق من لوحة البيانات (dashboard) ليوم واحد، وتحقق من المجاميع قبل وبعد عملية الربط (join)، وتأكد من مستوى التفاصيل (grain) عن طريق عد المفاتيح الفريدة (distinct keys). إذا تغيرت قيمة SUM(revenue) عند ربط الجدول بـ dim_channel، فهذا مؤشر خطر يستوجب المعالجة قبل مشاركة النتائج.
تُعد التوثيق جزءاً أساسياً من معايير الإنجاز؛ لذا احفظ كود SQL النهائي، والافتراضات، واستعلامات التحقق. إذا لم يتمكن محلل آخر من إعادة إنتاج نفس النتائج غداً، فهذا يعني أن العمل لم يكتمل بعد.
جرب سير العمل الذي ستتبعه في هذه الدورة.