UrbanDS: A Graph-Guided LLM Multi-Agent System for Data-Intensive Urban Tasks
تقترح الورقة البحثية UrbanDS، وهو نظام متعدد الوكلاء يعتمد على النماذج اللغوية الكبيرة والموجهة بالرسوم البيانية، والذي يقوم ببناء رسم بياني موحد للبيانات لتنظيم المهارات والعلاقات من أجل استرجاع ومعالجة البيانات، مما يعالج بفعالية تحديات المهام الحضرية كثيفة البيانات ويتفوق على الأساليب الحالية في كل من التقييمات المعيارية والنشر في العالم الحقيقي.
المؤلفون الأصليون:Zhilun Zhou, Jianghao Yu, Yuming Lin, yongjun yang, Sun Yongquan, Depeng Jin, Yong Li
تخيل عالماً تصبح فيه الحواسيب بارعة حقاً في التحدث إلينا، وفهم أسئلتنا، وحتى كتابة الأكواد البرمجية لحل المشكلات. تُسمى هذه الحواسيب الذكية "نماذج اللغات الكبيرة" (LLMs)، وهي تعمل كمساعدين فائقين القوة. لكن هناك عقبة: فبينما هي بارعة في الدردشة، فإنها غالباً ما تعاني عندما يُطلب منها القيام بعمل حقيقي في علم البيانات، خاصة عندما تكون البيانات فوضوية، وضخمة، ومتناثرة في كل مكان. تخيل الأمر كأنك تطلب من أمين مكتبة عبقري أن يجد حقيقة محددة، ولكن بدلاً من مكتبة مرتبة، قمت برميها في مستودع عملاق حيث تتراكم ملايين الصناديق بشكل عشوائي، وأنت لا تعرف أي صندوق يحتوي على الإجابة. قد يعرف أمين المكتبة كيف يقرأ، لكنه لا يستطيع العثور على الكتاب الصحيح بدون خريطة. هذه هي المشكلة الكبيرة التي يحاول الباحثون حلها: كيف نعلم مساعدي الذكاء الاصطناعي هؤلاء ليس فقط الإجابة على الأسئلة، بل البحث فعلياً عن المعلومات الصحيحة من محيط فوضوي من البيانات، وفهم كيفية ترابط القطع المختلفة مع بعضها البعض، ثم إجراء العمليات الحسابية لإعطائنا إجابة حقيقية؟
إليك UrbanDS، وهو نظام جديد وذكي صُمم ليكون "المحقق البياني" الأمثل للمشكلات المتعلقة بالمدن. أدرك الباحثون وراء هذا المشروع أن بيانات المدن هي نوع خاص من الفوضى؛ فهي تأتي من كل مكان — مستشعرات المرور، سجلات السكان، الخرائط، وسجلات الأعمال — وكل هذه القطع مرتبطة ببعضها بطرق معقدة (مثل كيفية ارتباط موقع طريق ما بالسكان الذين يعيشون بالقرب منه). تفشل أدوات الذكاء الاصطناعي الحالية هنا لأنها تتوقع أن تُقدم لها البيانات على طبق من فضة. يغير UrbanDS قواعد اللعبة من خلال العمل كفريق من الوكلاء المتخصصين الذين يعملون معاً. أولاً، يقومون ببناء "خريطة" ضخمة وحية (رسم بياني/Graph) لكل البيانات. يقوم فريق من الوكلاء بالمرور على كل ملف، وقراءته، وكتابة "سيرة ذاتية" له، تصف ما بداخله وكيف يتصل بالملفات الأخرى. يقوم فريق آخر برسم خطوط بين هذه السير الذاتية لإظهار أي قطع البيانات هي جيران لبعضها البعض من حيث الزمان، أو المكان، أو المعنى.
عندما يطرح إنسان سؤالاً، مثل "أين تحدث اختناقات مرورية بالقرب من المدارس الآن؟"، ينظر وكيل "المخطط" (Planner) إلى هذه الخريطة. وبدلاً من التخمين، يتبع الخطوط للعثور على بيانات المرور والمدارس الدقيقة التي يحتاجها. بعد ذلك، يقوم فريق من وكلاء "التنفيذ" (Execution) بكتابة وتشغيل الكود لمعالجة الأرقام، حيث يتشاركون تقدمهم مثل مجموعة من الأصدقاء يعملون في مشروع جماعي. أخيراً، يقوم وكيل "المُقرر" (Reporter) بكتابة النتائج. اختبر الفريق هذا النظام في تحدٍ هائل يسمى UrbanDS-Bench، والذي تضمن 94 مجموعة بيانات مختلفة من 10 مدن صينية كبرى وما يقرب من 500 مهمة مختلفة. كانت النتائج مبهرة: حل UrbanDS هذه الألغاز الصعبة المتعلقة بالبحث عن البيانات بشكل أفضل بكثير من غيره من أدوات الذكاء الاصطناعي الرائدة، حيث حقق حوالي 70% من الإجابات الصحيحة مقارنة بـ 63% للأداة التالية الأفضل. حتى أنهم اختبروه في العالم الحقيقي في مدينة ووهان، حيث ساعد مخططي المدن على تحليل بيانات بلدية فعلية، مما أثبت أن هذا النهج "الموجه بالخريطة" لا يعمل فقط في المختبر، بل في شوارع مدينة حقيقية.
ملخص تقني: UrbanDS
بيان المشكلة
أظهرت وكلاء النماذج اللغوية الكبيرة (LLM) إمكانات واعدة في أتمتة سير عمل علوم البيانات، ومع ذلك تواجه الأساليب الحالية قيودًا كبيرة في السيناريوهات كثيفة البيانات. تعتمد النهج الحالية عادةً على مجموعة محدودة من مجموعات البيانات المقدمة مباشرة مع المهمة. ومع ذلك، فإن التطبيقات الواقعية، لا سيما في الحوسبة الحضرية، تتضمن مستودعات ضخمة وغير متجانسة تحتوي على آلاف الملفات عبر مجالات متنوعة (مثل التنقل، والنقل، واستخدام الأراضي، والاقتصاد).
التحدي الجوهري مزدوج:
اكتشاف مجموعات البيانات: يجب على الوكلاء تحديد مجموعات البيانات ذات الصلة من حوض ضخم حيث غالبًا ما تكون أسماء الملفات غامضة أو مجهولة المصدر، ومعظم البيانات غير ذات صلة بالاستعلام المحدد.
التكامل المعقد: تُظهر مجموعات البيانات الحضرية علاقات مكانية وزمانية ودلالية معقدة. يجب ألا يكتفي الوكلاء بإيجاد البيانات فحسب، بل يجب عليهم أيضًا فهم كيفية ربط وتكامل هذه المصادر غير المتجانسة (على سبيل المثال، مطابقة region_id في مجموعة بيانات السكان مع id في مجموعة بيانات الحدود) لإجراء تحليل لاحق.
توفر الاختبارات المرجعية الحالية عادةً مجموعات البيانات اللازمة مسبقًا، مما يفشل في تقييم قدرة الوكيل على اكتشاف وربط مصادر البيانات داخل مستودع كبير وضوضائي.
المنهجية: إطار عمل UrbanDS
لمعالجة هذه التحديات، يقترح المؤلفون UrbanDS، وهو نظام متعدد الوكلاء موجه بالرسوم البيانية (graph-guided) ومصمم خصيصًا لمهام البيانات الحضرية كثيفة البيانات. يعمل النظام في مرحلتين متميزتين: بناء رسم بياني لمجموعات البيانات و تنفيذ المهمة.
1. بناء الرسم البياني لمجموعات البيانات
قبل تنفيذ أي مهمة محددة، يقوم UrbanDS بتنظيم مستودع البيانات الخام في رسم بياني معرفي مهيكل (G=(V,E)) لتجنب تكلفة فحص كل ملف لكل استعلام.
وكيل توصيف البيانات (Data Profiling Agent): يستكشف هذا الوكيل كل مجموعة بيانات مرة واحدة باستخدام كود Python لإنشاء مهارة مجموعة بيانات (Dataset Skill) قابلة لإعادة الاستخدام. تلخص هذه المهارة محتوى مجموعة البيانات، ومخططها (schema)، وإحصائياتها، وتغطيتها المكانية والزمانية، وتعليمات الاستخدام.
وكيل العلاقات (Relation Agent): يحدد هذا الوكيل العلاقات بين مجموعات البيانات لتشكيل حواف الرسم البياني (E). يقوم بنمذجة ثلاثة أنواع من العلاقات:
العلاقات المكانية والزمانية: يتم تحديدها عبر التغطية الجغرافية المتداخلة والنطاقات الزمنية الموجودة في مهارات مجموعات البيانات.
العلاقات الدلالية: يتم تحديدها عبر مدونة رموز دلالية (Semantic Codebook). يبني النظام مدونة رموز تراكمية لمعرفات الكيانات (مثل معرفات المناطق - region IDs) أثناء عملية التوصيف. ثم يقوم وكيل العلاقات بالتحقق من الاتصالات بين الحقول المسندة إلى نفس الرمز، لتحديد ما إذا كان يمكن دمجها رغم اختلاف أسماء الحقول.
النتيجة: رسم بياني لمجموعات البيانات حيث تمثل العقد مجموعات البيانات (مع مهاراتها) وتمثل الحواف الاتصالات المكانية أو الزمانية أو الدلالية.
2. تنفيذ المهمة
عند تلقي استعلام المستخدم، ينفذ النظام سير العمل التالي:
وكيل التخطيط (Planner Agent): يسترجع مجموعات البيانات ذات الصلة من الرسم البياني. وهو يستخدم استراتيجية الاسترجاع التدريجي:
يقوم أولاً بمراجعة الأسماء والأوصاف القصيرة لاختيار المرشحين الواعدين.
ثم يقرأ مهارات مجموعات البيانات الكاملة للمرشحين.
يتتبع حواف الرسم البياني لاكتشاف مجموعات البيانات المجاورة التي قد تكون ذات صلة، والتحقق من كل اختيار مقابل مهارته قبل وضع خطة تحليل (Analysis Plan) نهائية.
وكلاء التنفيذ (Execution Agents): يعمل عدة وكلاء بشكل تعاوني لتنفيذ الخطة. يتعامل كل وكيل مع مهمة فرعية محددة عن طريق كتابة وتشغيل الكود. يتشاركون ذاكرة مشتركة تحتوي على تقدم التنفيذ، والنتائج الوسيطة، والسجلات، مما يسمح للوكلاء اللاحقين بإعادة استخدام المخرجات دون إعادة الحساب. إذا كانت الخطة الأولية تفتقر إلى بيانات كافية، يمكن للوكلاء استرجاع مجموعات بيانات إضافية من الرسم البياني.
وكلاء التقارير والمراجعة (Report & Revision Agents): يقوم وكيل التقارير بتلخيص سجلات التجربة في تقرير نهائي. ويسمح وكيل المراجعة بالتحسين التكراري بناءً على ملاحظات المستخدم، وتحديث التقرير أو النواتج دون إعادة بدء المهمة بأكملها.
المساهمات الرئيسية
نظام UrbanDS: اقتراح نظام متعدد الوكلاء ينظم مجموعات البيانات الحضرية واسعة النطاق في رسم بياني من المهارات والعلاقات القابلة لإعادة الاستخدام، مما يتيح الاكتشاف التلقائي لمجموعات البيانات، والتخطيط، والتنفيذ، وإعداد التقارير.
UrbanDS-Bench: بناء اختبار مرجعي شامل لعلوم البيانات الحضرية. يتضمن:
94 مجموعة بيانات من 10 مدن صينية كبرى (تغطي البيانات الجغرافية المكانية، والحركية، والاجتماعية والاقتصادية).
450 مهمة تحليل بيانات (مكانية، وزمانية، ومكانية-زمانية) و 8 مهام لنمذجة البيانات.
"حوض بيانات مسطح" حيث يتم جعل مجموعات البيانات مجهولة المصدر، مما يجبر الوكلاء على الاعتماد على فحص المحتوى بدلاً من أسماء الملفات.
التحقق التجريبي: تجارب مكثفة تثبت أن UrbanDS يتفوق على وكلاء علوم البيانات والبرمجة العامة الحاليين في السيناريوهات كثيفة البيانات.
النشر في العالم الحقيقي: النشر الناجح في منصة العمليات الحضرية لمنطقة دونغ-شي في مدينة ووهان، لدعم التحليل العملي لبيانات بلدية حقيقية.
النتائج التجريبية
قيم المؤلفون UrbanDS مقابل خطوط الأساس بما في ذلك DS-Agent، و Data Interpreter، و DeepAnalyze، و AutoGen، و Claude Code على كل من UrbanDS-Bench و CoDA-Bench.
الأداء على UrbanDS-Bench: حقق UrbanDS دقة إجمالية بلغت 70.0%، متفوقًا على أقوى خط أساس (Claude Code بنسبة 62.9%) بفارق 11.2%. وقد تصدر في جميع فئات الاستدلال: المكانية (65.7%)، والزمانية (83.6%)، والمكانية-الزمانية (73.9%).
الأداء على CoDA-Bench: حقق UrbanDS دقة بنسبة 46.2%، بزيادة قدرها 10.0% عن Claude Code، مما يثبت فعاليته في مهام اكتشاف البيانات العامة.
نمذجة البيانات: حقق UrbanDS أفضل النتائج في جميع مهام نمذجة البيانات الثمانية. والجدير بالذكر أنه بالنسبة للتنبؤ بتسجيل الوصول في نقاط الاهتمام (POI)، حقق معامل تحديد (R2) قدره 0.464، بينما أنتجت جميع خطوط الأساس قيم R2 سالبة، مما يشير إلى قدرته الفائقة على الاستفادة من مجموعات البيانات المساعدة لبناء النماذج.
دراسة الاستئصال (Ablation Study): أدى حذف علاقات مجموعات البيانات إلى تقليل الدقة الإجمالية بمعدل 13.3%، مما يسلط الضوء على أهمية الاكتشاف الموجه بالرسم البياني. أما حذف مهارات مجموعات البيانات فقد تسبب في انخفاض أكبر (بمتوسط 20.6%)، خاصة في المهام المكانية والزمانية، مما يؤكد أن المعرفة المهيكلة لمحتوى البيانات أمر بالغ الأهمية للتكامل الصحيح.
القابلية للتوسع: انخفض أداء جميع الطرق مع زيادة عدد مجموعات البيانات المطلوبة (المهام التي تتطلب 4 مجموعات بيانات أو أكثر شهدت دقة أقل من 53% لجميع الطرق)، ومع ذلك حافظ UrbanDS على أعلى أداء نسبي.
الأهمية والادعاءات
يزعم البحث أن UrbanDS يعالج فجوة حرجة في أبحاث وكلاء النماذج اللغوية الكبيرة الحالية: وهي القدرة على العمل في البيئات كثيفة البيانات حيث لا يكمن العائق الأساسي في توليد الكود، بل في اكتشاف البيانات وتكاملها.
ما وراء المدخلات المحددة مسبقًا: على عكس الاختبارات المرجعية السابقة التي توفر مجموعات البيانات اللازمة، يقوم UrbanDS-Bench بتقييم قدرة الوكيل على التنقل داخل مستودع ضخم وغير متجانس للعثور على "الإبرة في كومة القش".
الكفاءة الموجهة بالرسم البياني: يثبت النظام أن تنظيم البيانات مسبقًا في رسم بياني من المهارات والعلاقات يقلل بشكل كبير من عبء نافذة السياق (context window) على النماذج اللغوية الكبيرة ويحسن دقة اختيار مجموعات البيانات.
المنفعة العملية: يشير النشر في ووهان والدراسة المستخدمة (التي أظهرت تسريعًا في وقت التحليل بمقدار 5.6 ضعفًا) إلى أن النظام ليس مجرد تحسين نظري، بل هو أداة قابلة للتطبيق لتسريع تحليل البيانات الحضرية في العالم الحقيقي.
القيود: يشير المؤلفون بتواضع إلى أن النظام يركز حاليًا على تنفيذ الطلبات المحددة من قبل المستخدم. وهو لا يمتلك بعد القدرة على استكشاف المستودعات بنشاط دون أسئلة محددة مسبقًا أو اقتراح فرضيات بحثية جديدة من أنماط البيانات. يهدف العمل المستقبلي إلى توسيع النظام نحو هذه القدرات الأكثر انفتاحًا.