VK تستعرض DataCopilot: نظام متعدد الوكلاء للبيانات والوثائق المؤسسية

كشفت VK عن DataCopilot، وهو مساعد AI داخلي للعمل مع مستودع البيانات المؤسسي والوثائق المتخصصة. ولم ينشأ المشروع من موضة LLM، بل من تحليل طلبات فعلية لمحللين ومديرين ومهندسين يقضون وقتًا كل يوم في الإجابة عن أسئلة متكررة.

من أين بدأ الفريق

لم يبدأ الفريق باختيار نموذج أو بتصميم مخطط RAG جديد. فقد درست VK أولًا الأعمال الروتينية المحيطة بـ Data Office ومنصة البيانات: ما الأسئلة التي تصل إلى الدعم، وما الذي يُسأل عنه في الدردشات أكثر من غيره، وأين يضيّع الموظفون وقتهم في البحث عن واجهة تحليلية (vitrine) معينة أو وصف حقل أو إجراء اعتماد مطلوب. وأعطى هذا التدقيق قائمة واضحة بالمهام التي يمكن أتمتتها دون إعادة بناء مستودع البيانات (DWH) بالكامل، ودون محاولة صنع «ذكاء شامل» يغطي كل الحالات دفعة واحدة.

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

لماذا ليس RAG

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

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

ماذا يستطيع النظام

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

• يساعد في العثور على الواجهة التحليلية المطلوبة وفهم البيانات الموجودة فيها
• يشرح أين تُخزَّن المعلومات تحديدًا وكيف ترتبط بكيانات أخرى
• يرشد إلى كيفية تقديم طلب الصلاحيات دون الحاجة إلى مراجعة الدعم
• يجيب عن الأسئلة المحددة المتعلقة بالوثائق الداخلية وقواعد العمل مع DWH
• يكتب سكربتات يمكن إدراجها في عمليات ETL وتعديلها بما يناسب خط المعالجة (pipeline) الخاص بالمستخدم

والنقطة المهمة هنا أن النظام يعمل عند تقاطع المعرفة والفعل. فهو لا يكتفي بتلخيص الوثائق، بل يساعد في الخطوة التالية: تحضير استعلام، أو وضع أساس لسكربت، أو اختصار الطريق إلى الجدول المطلوب. وهذا بالضبط ما يميّز عادةً الـ AI المؤسسي المفيد عن مجرد «بحث ذكي» آخر. ومع ذلك تبقى مسؤولية التطبيق النهائي للنتيجة على الإنسان، خاصة عند التعامل مع الصلاحيات وترحيل البيانات والكود الخاص بعمليات ETL في بيئة الإنتاج.

ما معنى ذلك

تُظهر تجربة DataCopilot الاتجاه الفعلي للـ AI المؤسسي: لا نحو روبوت دردشة واحد يعرف كل شيء، بل نحو مجموعة من الوكلاء المتخصصين حول مسار عمل محدد. وبالنسبة للفرق التي تمتلك DWH وكتالوج واجهات تحليلية ولوائح وسيلًا من الأسئلة المتكررة، قد يعطي هذا النهج فائدة أكبر بكثير من RAG مجرّد يُطبَّق على جميع الوثائق دفعة واحدة.