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

وكلاء الذكاء الاصطناعي المرتبطون بـ Power BI يعالجون هذه الحلقة تحديدًا: المستخدم يسأل بلغته، والوكيل يترجم السؤال لاستعلام، وينفّذه، ويرجّع الجواب. والفكرة تُساء فهمها كثيرًا، وفيما يلي تفصيلها من الأساس.

ما هو MCP ولماذا غيّر المعادلة

Model Context Protocol بروتوكول مفتوح يعرّف كيف يتحدث نموذج الذكاء الاصطناعي مع أدوات ومصادر بيانات خارجية بشكل منظّم وآمن. قبله، كل ربط بين نموذج ونظام كان تكاملًا مخصصًا يُبنى من الصفر.

المصطلحات الثلاثة التي ستراها في كل توثيق:

  • المضيف (Host): البيئة التي تعمل فيها. مثل VS Code.
  • العميل (Client): المكوّن الذي يتصل بالخوادم ويستهلك قدراتها. مثل Copilot.
  • الخادم (Server): برنامج محلي أو بعيد يعرض الأدوات والموارد. مثل خادم Power BI.

أهمية هذا التقسيم عملية لا نظرية: أي عميل يدعم البروتوكول يستطيع استخدام أي خادم يدعمه. تبني التكامل مرة واحدة، ويعمل مع Claude وCopilot وغيرهما.

كيف تبدو الدورة فعليًا

لنأخذ سؤالًا واقعيًا: «كم عدد التذاكر المفتوحة أكثر من 30 يومًا لكل إدارة؟» ما يحدث خلف الكواليس:

  • الوكيل يقرأ مخطط النموذج الدلالي: الجداول والأعمدة والعلاقات والمقاييس المعرَّفة.
  • يحدد الجداول ذات الصلة ويبني استعلام DAX مناسبًا.
  • ينفّذ الاستعلام عبر نقطة نهاية XMLA الخاصة بالنموذج.
  • يستقبل النتيجة الخام ويصيغها بلغة طبيعية مفهومة.

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

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

الخيارات الرسمية من مايكروسوفت

الخيارماذا يفعلمتى تستخدمه
خادم MCP البعيداستعلام النماذج الدلالية بالمحادثة وتوليد DAXتحليل واستكشاف البيانات
خادم MCP المحليتأليف وتعديل النماذج الدلاليةبناء الجداول والمقاييس والعلاقات
Power BI Agenticحزمة مهارات وأدوات تُثبَّت في وكيلك البرمجيتطوير النماذج والتقارير بأفضل الممارسات
Fabric Data Agentوكيل محادثة فوق عدة مصادر بياناتواجهة سؤال وجواب لغير التقنيين

Fabric Data Agent بالتفصيل

هذا الخيار الأقرب لفكرة «وكيل يتصل بكل أنظمتي». يربط حتى خمسة مصادر لكل وكيل بأي تركيبة: Lakehouse وWarehouse ونماذج Power BI وقواعد KQL وOntologies وMicrosoft Graph.

آلية عمله: يحلل السؤال، يحدد المصدر الأنسب من بين المتصلة، يولّد الاستعلام المناسب لنوع المصدر (SQL أو KQL أو DAX) وينفّذه ويصيغ النتيجة.

حدوده التي يجب معرفتها قبل البناء:

  • خمسة مصادر كحد أقصى لكل وكيل. للتغطية الأوسع تُنشئ عدة وكلاء متخصصين.
  • الردود محدودة بـ25 صفًا و25 عمودًا. مصمَّم للرؤى لا لتصدير مجموعات بيانات.
  • يتطلب سعة Fabric بحجم F2 أو أعلى.
  • يوفّر نقطة نهاية API تُستدعى من Copilot Studio وMicrosoft Foundry وتطبيقاتك.

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

أدوات مفتوحة المصدر

الخوادم الرسمية تغطي الأساسيات، والمجتمع يغطي الفجوات. خاصة في الحوكمة وتحرير التقارير.

المشروعما يضيفه
sulaiman013/powerbi-mcpحوكمة: إخفاء PII قبل وصولها للنموذج، حجب أو تجزئة أعمدة، سجل تدقيق مقاوم للتلاعب، ووضع قراءة فقط. وللمشرفين: جرد كل مساحات العمل ورصد النماذج بلا تصنيف حساسية
mateuscbrito/powerbi-serverتحكم برمجي في تقارير PBIR: إنشاء وتعديل المقاييس، بناء العلاقات، إنشاء أدوار RLS، وقائمة بأثقل الأعمدة استهلاكًا للذاكرة

وضع القراءة فقط يتيح للوكيل الاطلاع دون التعديل، ويُفعّل عادة في أي تجربة أولى.

الترتيب الصحيح للبناء

أكبر سوء فهم في هذا المجال: أن الوكيل «يتصل بكل الأنظمة». الوكيل لا يتصل بشيء. بل يستعلم عن طبقة بيانات موحّدة يجب أن تكون موجودة أصلًا.

الترتيب الذي يعمل:

  • تكامل البيانات: جمع أنظمتك المتفرقة في مستودع أو Lakehouse موحّد.
  • نموذج دلالي نظيف: أسماء أعمال واضحة، أوصاف، مترادفات، وعلاقات صحيحة.
  • مقاييس معرَّفة مسبقًا: عرّف «معدل الإنجاز» و«التذاكر المتأخرة» كمقاييس، لا تترك الوكيل يخترعها.
  • وكيل فوق الطبقة الجاهزة، بوضع قراءة فقط أولًا.
  • توسيع تدريجي بعد قياس الدقة على أسئلة حقيقية.

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

أين تفشل هذه المشاريع

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

محاذير موثّقة رسميًا

التوثيق نفسه ينبّه بوضوح: النموذج اللغوي قد ينتج نتائج غير متوقعة أو غير دقيقة تؤدي لتغييرات غير مقصودة في النموذج الدلالي. كما قد يكشف معلومات حساسة (بيانات أو بيانات وصفية) في السجلات أو الردود.

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