🤖 AI

GRAIL: AI translation for scientists application workflow on satellite data

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

المؤلفون الأصليون: Zhuocheng Shang, Ahmed Eldawy

نُشر 2026-05-26

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Zhuocheng Shang, Ahmed Eldawy

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل فريقاً من العلماء العباقرة، خبراء في دراسة الأرض من الفضاء. لديهم مكتبة ضخمة من صور الأقمار الصناعية (مثل Landsat وSentinel) التي يمكن أن تساعدهم في حل مشكلات تتعلق بتغير المناخ، والزراعة، والكوارث. ومع ذلك، هناك عقبة: هذه الصور ضخمة جداً لدرجة أن أدوات العلماء المعتادة تشبه محاولة شرب المحيط باستخدام قشة.

يكتب العلماء تحليلاتهم بلغة Python، وهي لغة برمجة شهيرة. إنها رائعة للتجارب الصغيرة، ولكن عندما يحاولون معالجة تيرابايتات من بيانات الأقمار الصناعية، تتعطل أجهزتهم أو تستغرق وقتاً طويلاً جداً.

لحل هذه المشكلة، يحتاجون إلى محرك فائق القوة يسمى Apache Spark (والذي يمكنه معالجة البيانات عبر مئات الحواسيب في وقت واحد). ولكن هناك مشكلة: Spark يتحدث عادةً لغة مختلفة (Scala) ويتطلب منحنى تعلم صعباً. الأمر يشبه مطالبة طاهٍ يعرف فقط الطبخ بملعقة خشبية بأن يبدأ فجأة في استخدام ذراع مطبخ روبوتية عالية التقنية. معظم العلماء ليس لديهم الوقت أو الرغبة في تعلم اللغة الجديدة.

إليك GRAIL.

ما هو GRAIL؟

فكر في GRAIL كـ مترجم ذكي وثنائي اللغة يعمل كجسر بين العلماء وبين المطبخ الروبوتي.

المدخلات: يكتب العالم نصاً بسيطاً بلغة Python (أو حتى مجرد جملة باللغة الإنجليزية العادية) تصف ما يريد القيام به، مثل: "احسب متوسط الغطاء الشجري لكل مقاطعة في الولايات المتحدة".
السحر: يأخذ GRAIL هذا الطلب ويقوم تلقائياً بترجمته إلى برنامج Scala معقد وعالي السرعة يعمل على Spark.
النتيجة: يحصل العالم على الإجابة في دقائق بدلاً من أيام، دون الحاجة أبداً لتعلم اللغة الجديدة أو القواعد المعقدة للمطبخ الروبوتي.

كيف يعمل؟ (حلقة "الإصلاح")

قد تعتقد: "هل يمكن للذكاء الاصطناعي ببساطة كتابة الكود بشكل مثالي من المرة الأولى؟" يوضح البحث أن الذكاء الاصطناعي القياسي غالباً ما يصاب بالارتباك لأن المكتبة التي يترجم إليها (RDPro) هي مكتبة جديدة وليس لديها أمثلة كافية في بيانات تدريب الذكاء الاصطناعي.

لذا، يستخدم GRAIL استراتيجية ثلاثية الخطوات لجعل الترجمة ناجحة:

الخطوة 1: "الدليل الجاهز للذكاء الاصطناعي" (التوثيق المهيكل)
تخيل لو أن دليل تعليمات المكتبة كُتب بنثر شعري غامض للبشر. يقوم GRAIL بإعادة كتابة هذا الدليل إلى قائمة مراجعة صارمة بنقاط محددة مصممة خصيصاً للذكاء الاصطناعي. إنه يقول بوضوح: "إذا كنت تريد القيام بـ X، استخدم الوظيفة Y مع هذه المدخلات المحددة". هذا يزيل التخمين.
الخطوة 2: "المترجم المستعار" (أسماء API المستعارة)
أحياناً يحاول الذكاء الاصطناعي استخدام الكلمات الخاطئة لأنه اعتاد على مكتبة Python القديمة (مثل استدعاء وظيفة open بينما النظام الجديد يسميها load). يضيف GRAIL وظائف "مستعارة" (Alias) — مثل قابس محول عالمي. إذا قال الذكاء الاصطناعي open ، يقوم النظام بهدوء بترجمتها إلى أمر load الصحيح خلف الكواليس، ليعمل الكود فوراً.
الخطوة 3: "ورشة الإصلاح" (سجلات الأخطاء)
إذا تعطل الكود، قد تظهر رسالة خطأ عادية تقول فقط "Error: 404". نظام GRAIL أذكى من ذلك؛ فهو يلتقط الخطأ، وينظر في المشكلة المحددة، ويعطي الذكاء الاصطناعي تلميحاً محدداً حول كيفية إصلاحها (على سبيل المثال: "لقد حاولت دمج عدد عشري مع عدد صحيح؛ قم بتغيير العدد الصحيح إلى عدد عشري"). ثم يحاول الذكاء الاصطناعي مجدداً، ويقوم بإصلاح هذا الجزء المعطل فقط، بدلاً من إعادة كتابة البرنامج بأكمله من الصفر.

سير العمل في الواقع

يتم تقسيم العملية إلى خط إنتاج، مثل خط التجميع:

التحليل: يقرأ النظام طلب العالم ويحدد الخطوات اللازمة.
التخطيط: يبني هيكلاً (Scaffold) للبرنامج، ويقرر الأجزاء المطلوبة (مثل تحميل البيانات، أو التحقق من الأخطاء، أو دمج الخرائط).
التوليد: يكتب الكود جزءاً بجزء، ويتحقق من عمله أثناء التقدم.
التحقق والإصلاح: يقوم بتشغيل الكود. إذا فشل، يستخدم تلميحات "ورشة الإصلاح" لإصلاح الجزء المعطل تحديداً.
المخرجات: بمجرد اجتياز جميع الفحوصات، ينتج البرنامج النهائي عالي السرعة.

نتائج من العالم الحقيقي

اختبر البحث هذا باستخدام مثال من الواقع: تحليل استخدام الأراضي في بوسطن.

الاختبار: طلبوا من النظام ترجمة نص Python كان يحسب نسب استخدام الأراضي.
المقارنة: قاموا بتشغيل نفس المهمة باستخدام طريقة Python الأصلية وطريقة GRAIL الجديدة (المعتمدة على Scala).
النتيجة:
- الصحة: كانت النتائج متطابقة. لم يرتكب الذكاء الاصطناعي أي أخطاء في المنطق.
- السرعة: بالنسبة للمساحات الصغيرة، كان أسرع قليلاً. ولكن بالنسبة لمجموعات البيانات الضخمة (مثل حدود العالم بأكائه)، استغرقت طريقة Python 8 ساعات، بينما أنهت طريقة GRAIL المهمة في أقل من ساعة.

لماذا يهم هذا؟

يخلص البحث إلى أنك لست بحاجة لإجبار العلماء على أن يصبحوا خبراء في الحوسبة الموزعة. بدلاً من ذلك، يمكنك جعل الأدوات "جاهزة للذكاء الاصطناعي". من خلال تنظيم توثيق المكتبة، وإضافة أسماء مستعارة مفيدة، وتزويد الذكاء الاصطناعي بتغذية راجعة أفضل حول الأخطاء، يتيح GRAIL للعلماء الاستمرار في استخدام الأدوات البسيطة التي يحبونها (Python) بينما تعمل أسرارهم على الحواسيب العملاقة التي يحتاجونها (Spark).

باختصار: يسمح GRAIL للعلماء بالتحدث بلغتهم الخاصة بينما يقوم الكمبيوتر بالعمل الشاق بلغة لا يحتاجون لمعرفتها.

ملخص تقني: GRAIL – تطبيق ترجمة الذكاء الاصطناً لتدفقات عمل العلماء في معالجة بيانات الأقمار الصناعية

1. بيان المشكلة

يعتمد علماء المجالات المتخصصة، لا سيما في مجالات مثل الزراعة والهيدرولوجيا وعلوم المناخ، بشكل متزايد على سكربتات بايثون (Python) التي تستخدم مكتبات أحادية الجهاز (مثل Rasterio وGeoPandas) لتحليل صور الأقمار الصناعية. ورغم فعاليتها في مرحلة النمذذج الأولية، إلا أن هذه السكربتات تفتقر إلى القابلية للتوسع للتعامل مع الأحجام الهائلة من البيانات التي تولدها مهمات مثل Landsat وSentinel وMODIS.

تقدم الحلول القابلة للتوسع حالياً، مثل Apache Sedona وGeoTrellis ومكتبة RDPro القائمة على لغة Scala، قوة الحوسبة الموزعة اللازمة، لكنها تفرض عائقاً كبيراً أمام التبني؛ فهي تتطلب من العلماء تعلم أطر عمل جديدة، ومفاهيم الحوسبة الموزعة، وغالباً لغة Scala أو Java. وقد تضمنت المحاولات السابقة لسد هذه الفجوة نقل النماذج المعقدة يدوياً إلى Spark (وهو أمر يصعب تكراره) أو بناء أغلفة (wrappers) مخصصة بلغة بايثون (مما يتطلب جهداً هندسياً كبيراً).

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

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

2. المنهجية: نظام GRAIL

GRAIL هو نظام ترجمة وكيل (agentic translation system) مصمم لتحويل تدفقات العمل الجيومكانية بلغة بايثون (أو الأوصاف النصية البسيطة) إلى برامج قابلة للتنفيذ وقابلة للتوسع تعتمد على Spark باستخدام مكتبة RDPro. وبدلاً من إعادة ضبط (fine-tuning) نموذج لغوي متخصص، يقوم GRAIL بتكييف المكتبة نفسها لتصبح "جاهزة للنماذج اللغبية الكبيرة" (LLM-ready) ويستخدم مسار عمل متعدد المراحل ومنظم.

2.1 مسار الترجمة

يعمل النظام عبر مسار LangGraph الذي يفكك عملية توليد الكود إلى أربع مراحل متميزة:

تحليل المهمة: يحول المدخلات (سكربت بايثون أو نص) إلى تمثيل وسيط مهيكل لالتقاط أنواع المهام والعمليات الجيومكانية المطلوبة، مما يقلل من خطر الخطأ في ترجمة استدعاءات الدوال.
تخطيط الأقسام: يقوم المخطط بتحليل المهمة واختيار الأقسام ذات الصلة من التوثيق الجاهز للنماذج اللغبية الكبيرة. ويقوم بإنشاء هيكل (scaffold) يحدد البنية العامة لمهمة جيومكانية، والتي تتضمن ست مراحل منطقية: LoadData (تحميل البيانات)، TypeCheck (التحقق من النوع)، SpatialCheck (التحقق المكاني)، Transform (التحويل)، RasterVectorJoin (الربط بين الراستر والمتجه)، و Analytics (التحليلات). ويتم استبعاد الأقسام غير ذات الصلة.
التوليد قسماً بقسم: يتم توليد الكود بالتتابع داخل حلقة LangGraph. ويتضمن كل "مطالبة" (prompt) ما يلي:
- أجزاء من توثيق واجهة برمجة التطبيقات (API) ذات الصلة.
- عقد القسم (section contract) الذي يحدد استدعاءات الـ API المطلوبة، المدخلات، المخرجات، والأنماط المحظورة.
- حالة الهيكل الحالية (ملخصات المتغيرات من الأقسام السابقة).
التحقق والإصلاح: بعد توليد قسم مرشح، يطبق النظام أربع طبقات من التحقق: فحص النطاق، فحص العقد الحتمي، المراجعة الدلالية بواسطة النموذج اللغبي الكبير، وتجميع (compilation) كامل لـ Spark. إذا فشلت أي طبقة، يتم تجميع ملاحظات الإصلاح المستهدفة وحقنها في المطالبة التالية لإعادة المحاولة في القسم الفاشل فقط (حتى خمس جولات). وتجري مراجعة نهائية للبرنامج بأكمله للتحقق من الثوابت عبر الأقسام قبل الإخراج النهائي.

2.2 تعديلات المكتبة لتصبح جاهزة للنماذج اللغبية الكبيرة

لضمان موثوقية الكود المولد، قام المؤلفون بتعديل مكتبة RDPro عبر ثلاث تحسينات محددة:

التوثيق المهيكل: أعيد تصميم التوثيق من أمثلة فضفاضة إلى تنسيق متسق يحتوي على أسماء الدوال، الأوصاف، معاملات المدخلات مع الأنواع/القيود، دلالات المخرجات، وأمثلة تنفيذية دنيا. وهذا يسمح للنموذج اللغبي الكبير بالاستنتاج بناءً على مواصفات دقيقة.
دوال الأسماء المستعارة (API Alias Functions): لسد الفجوة بين بيانات تدريب النماذج اللغبية الكبيرة (اصطلاحات بايثون) والمكتبة المستهدفة (Scala/RDPro)، تمت إضافة دوال مستعارة. تقوم هذه الدوال بربط الأسماء الشائعة بأسلوب بايثون (مثل open, read, mask) بما يعادلها الصحيح في RDPro (مثل raptorJoin)، مما يسم يسمح للكود المولد بالتنفيذ بشكل صحيح دون الحاجة للإصلاح الفوري.
إرسال تقارير الأخطاء الموجهة للإصلاح: تم تعزيز رسائل الخطأ بملاحظات إصلاح قابلة للتنفيذ. فبدلاً من أخطاء وقت التشغيل العامة، يوفر النظام سبب الفشل واقتراحاً للإصلاح (مثل تصحيحات عدم تطابق النوع). يتم تغذية هذه الملاحظات في حلقة التوليد كـ "سياق"، مما يسمح بإجراء إصلاحات مستهدفة دون الحاجة لإعادة تحليل تتبع الخطأ بالكامل.

3. المساهمات الرئيسية

نظام ترجمة وكيل (Agentic Translation System): تقديم GRAIL، وهو نظام يترجم تدفقات العمل الجيومكانية بلغة بايثون إلى برامج قابلة للتوسع بلغة Scala/Spark دون الحاجة لتعلم العلماء للإطار الأساسي.
استراتيجية تكييف المكتبة: نهج مبتكر لجعل المكتبة (RDPro) جاهزة للنماذج اللغبية الكبيرة من خلال التوثيق المهيكل، والأسماء المستعارة للـ API، وسجلات الأخطاء المعززة، بدلاً من إعادة ضبط النموذج اللغبي الكبير نفسه.
مسار عمل مهيكل: مسار عمل قائم على LangGraph يفكك الترجمة إلى تخطيط، وتوليد قسم بقسم، وإصلاح تكراري، مما يضمن الاتساق عبر الأقسام.
التحقق التجريبي: إثبات فعالية النظام على تدفقات عمل واقعية، بما في ذلك تصنيف استخدام الأراضي والإحصاءات المناطقية على مجموعات بيانات عالمية.

4. النتائج والأداء

قيم المؤلفون GRAIL باستخدام سيناريوهين رئيسيين:

السيناريو 1: استخدام الأراضي في بوسطن (الترجمة من بايثون إلى Scala)

نجح النظام في ترجمة سكربت بايثون يحسب نسب استخدام الأراضي في أحياء بوسطن إلى لغة Scala.
أنتج كود Scala المولد نتائج متسقة مع الحقيقة الأرضية لبايثون (تحديد "المناطق المطورة، متوسطة الكثافة" كفئة مهيمنة).
تتيح الواجهة للمستخدمين تصور السكربت الأصلي، والكود المولد، ومقارنات النتائج جنباً إلى جنب.

السيناريو 2: القابلية للتوسع والأداء

السرعة: تفوق الكود المولد بواسطة GRAIL بشكل كبير على خطوط الأساس في بايثون (Rasterio) في مهام الإحصاءات المناطقية، خاصة مع زيادة حجم مجموعة البيانات.
- لمقاطعات الولايات المتحدة: سرعة أكبر بمقدار 1.4x.
- لولايات الولايات المتحدة: سرعة أكبر بمقدار 2.2x.
- للحدود العالمية: سرعة أكبر بمقدار 8.8x (استغرق بايثون حوالي 8 ساعات؛ بينما استغرق GRAIL حوالي 3,277 ثانية).
- لقطاعات التعداد السكاني في الولايات المتحدة: سرعة أكبر بمقدار 4.7x.
الآلية: يُعزى هذا الربح في الأداء إلى أن الخلفية البرمجية لـ Spark تقرأ كل بلاطة (tile) من الراستر مرة واحدة بالضبط وتعالج جميع الميزات المتداخلة في تمريرة تدفق واحدة، بينما يقوم خط الأساس في بايثون بقراءة البلاطات بشكل متكرر لكل ميزة متداخلة.

السيناريو 3: مقارنة نمط المدخلات
قارن المؤلفون ثلاث استراتيجيات توليد:

NL-Scala: لغة طبيعية $\leftarrow$ تحليل مهيكل $\leftarrow$ كود.
Python-NL-Scala: لغة طبيعية $\leftarrow$ بايثون وسيط $\leftarrow$ تحليل مهيكل $\leftarrow$ كود.
Python-Scala: سكربت بايثون $\leftarrow$ ترجمة مباشرة (بدون تحليل مهيكل للمهمة).

النتائج:

حقق أسلوب NL-Scala نسبة نجاح 100% (5/5) في كل من مهام الراستر فقط ومهام الراستر-المتجه مع أقل عدد من دورات الإصلاح (1.0–1.6).
كان أسلوب Python-NL-Scala منافساً ولكنه تطلب المزيد من دورات الإصلاح (2.4–2.6)، مما يشير إلى أن توليد سكربت بايثون وسيط قد يؤدي إلى غموض.
فشل أسلوب Python-Scala تماماً (نسبة نجاح 0/5)، مما يؤكد أن الترجمة الخام دون تحليل مهيكل للمهمة غير كافية للترجمة المعقدة عبر الأنظمة البيئية المختلفة.

5. الأهمية والادعاءات

يزعم البحث أن GRAIL يمثل مساراً قابلاً للتطبيق لجعل مكتبات بيانات الأقمار الصناعية المتخصصة والقابلة للتوسع متاحة لعلماء المجالات غير التقنيين. تكمن أهميته في نقل عبء التكيف من المستخدم (تعلم Scala/Spark) ومن النموذج (إعادة الضبط) إلى البنية التحتية للمكتبة. فمن خلال جعل المكتبة "جاهزة للنماذج اللغبية الكبيرة" عبر التوثيق المهيكل، والأسماء المستعارة، وتلميحات الخطأ، يمكن للنظام تمكين الوكلاء الحاليين من توليد كود صحيح وقابل للتوسع.

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