بيانات استدعاء الأدوات بالعربية (2026): ما المتاح للعموم، وكيف تفحص مسارات الوكلاء قبل شرائها
معظم البيانات العربية العامة لاستخدام الأدوات تعلّم النموذج خطوة واحدة: أن يختار دالة ويملأ معاملاتها. يقارن هذا الدليل المجموعات المتاحة، ويبيّن أين تتعثر القيم العربية، ويقدّم قائمة فحص لمسارات الوكلاء متعددة الخطوات قبل أن تشتريها أو تقبل تسليمها، مع ما يهم الفرق في السعودية والإمارات تحديدًا.
باختصار: نعم، توجد مجموعات بيانات عربية عامة لاستدعاء الدوال والأدوات (function/tool calling)، وقد رُفعت المجموعات الكبيرة منها على Hugging Face أول مرة بين نوفمبر 2025 ومايو 2026. أكبرها HeshamHaroon/Arabic_Function_Calling (50,810 عينة مولّدة بـ GPT-4o) ومجموعة المهمة المشتركة AISA-ArabicFC (10,550 استعلامًا للتدريب)، وكلتاهما تعلّم خطوة واحدة: هل يلزم استدعاء أداة، ثم أي دالة، وما معاملات JSON. وحيث تصف هذه المصادر بيانات عربية متعددة الجولات (multi-turn) أو الخطوات، فهي مترجمة آليًا من الإنجليزية أو مجموعة اختبار صغيرة مكتوبة يدويًا. ولا يصف أيّ من المصادر أدناه مسارات وكلاء عربية أصلية تسجّل ما أعادته الأدوات وتصحيحات المستخدم، ثم تقيس النجاح بفحص الحالة الناتجة.
- المجال حديث. وصفت مراجعة لبيانات ما بعد التدريب العربية على Hugging Face عام 2025 موارد استدعاء الدوال العامة بأنها غير موجودة، ووصلت أول مجموعة كبيرة في نوفمبر 2025.
- مجموعة واحدة بأسماء كثيرة. أربع قوائم أخرى على الأقل تذكر مجموعة HeshamHaroon المولّدة بـ GPT-4o مصدرًا لها أو تعيد استخدام بطاقتها. احسبها مرة واحدة.
- المعاملات هي الجزء الصعب. في نتائج خط الأساس (baseline) التجريبية للمهمة المشتركة، تبلغ دقة اختيار الدالة 0.982، بينما لا تتجاوز المطابقة التامة (exact match) للمعاملات (arguments) 0.541.
- المسارات هي الفجوة. لا يصف أي مصدر هنا مسارات عربية أصلية متعددة الخطوات فيها ملاحظات وتصحيحات وفحص للحالة.
ما بيانات استدعاء الأدوات العربية المتاحة للعموم؟
حتى خريف 2025 كانت هذه البيانات شبه غائبة. حلّلت مراجعة لمجموعات بيانات ما بعد التدريب العربية على Hugging Face (الإصدار الثاني، 30 سبتمبر 2025) 366 مجموعة في 12 مجالًا، ووصفت استدعاء الدوال بأنه «غير موجود حاليًا» في موارد ما بعد التدريب العربية العامة. يلخّص الجدول التالي أبرز ما ظهر منذ ذلك الوقت تقريبًا. كل خلية منقولة من البطاقة أو الورقة المرتبطة كما هي في أكتوبر 2026، و«غير مذكور» يعني أن المصدر لا يقول، لا أن الخاصية غائبة.
| المورد | الحجم | التنويعات (كما وردت) | المصدر والبنية | الرخصة |
|---|---|---|---|---|
| HeshamHaroon/Arabic_Function_Calling | 50,810 عينة (45,734 تحتاج استدعاءً و5,076 لا تحتاج)؛ 8 مجالات وأكثر من 36 دالة | من عينات الاستدعاء: الفصحى 30.8%، الخليجية 26.1%، المصرية 23.9%، الشامية 15.1%، المغاربية 4.1% | توسيع بـ GPT-4o لـ 500 مثال أولي (seed) مكتوب يدويًا، وتقول البطاقة إنها غير مترجمة من الإنجليزية؛ استعلام واحد ودالة واحدة ومعاملاتها، دون مخرجات الأدوات | Apache 2.0 |
| AISA-ArabicFC (ArabicNLP 2026) | تدريب 10,550، تطوير 545، واختبار مخفي؛ 27 أداة و4 أدوات مرشحة لكل استعلام | الفصحى 58.3%، الشامية 16.9%، المصرية 12.2%، الخليجية 11.3%، المغاربية 1.3% | المصدر غير مذكور في البطاقة؛ هل يلزم استدعاء أم لا، ثم الدالة ومعاملات JSON، وتُقاس دقة الدالة والمطابقة التامة للمعاملات | Apache 2.0 |
| QCRI Arabic Glaive and xLAM | تدريب Glaive: 37,684 باستدعاءات و38,678 دونها؛ xLAM: 58,999 و19,361 | غير مذكورة في الجدول 1 | مترجمة آليًا بـ Gemini-2.5-Flash؛ Glaive متعددة الأدوار لكنها قُيّمت دورًا دورًا | غير مذكورة؛ المجموعة المرتبطة لا تضم عناصر |
| arabic-agent-eval v0.1.0 | 51 عنصرًا؛ 22 أداة | 32 فصحى، 10 خليجية، 4 شامية، 3 مصرية، 2 مغاربية | كتبها يدويًا مطوّر واحد يتولى صيانتها؛ تتضمن 7 عناصر متعددة الخطوات و6 عناصر للتعافي من الأخطاء، وتُقيَّم مقابل الاستدعاءات المتوقعة | CC BY 4.0 (البيانات) |
| Paired MSA–Saudi tool-use test set (جامعة الطائف) | 150 سجلًا في 75 زوجًا؛ 5 أدوات محاكاة حتمية؛ أحدث إصدار 1.0.3، 4 أغسطس 2026 | الفصحى واللهجة السعودية | مجموعة اختبار لاختيار الأداة وملء المعاملات والتنفيذ والرد، مع ملفات البيئة | CC BY 4.0 |
وحيث تذكر المصادر الكبيرة أصل بياناتها، فهي مولّدة بـ GPT-4o أو مترجمة آليًا بـ Gemini، والمجموعة الوحيدة الموصوفة بأنها مكتوبة يدويًا بالكامل تضم 51 عنصرًا. ونسب اللهجات غير متسقة: الخليجية 26.1% من مجموعة HeshamHaroon لكنها 11.3% من AISA-ArabicFC، ولا تفصّل أيّ من البطاقتين الخليجية حسب البلد، فلا تعرف منها كم سجلًا سعوديًا أو إماراتيًا لديك. أما اللهجة السعودية تحديدًا، فمجموعة جامعة الطائف مخصّصة للاختبار فقط، لا للتدريب. المصادر الكاملة، ومنها نسخ أخرى للمجموعة الأولى ومعايير مترجمة، في النسخة الإنجليزية من هذا الدليل.
استدعاء الدالة ومسار الوكيل: ما الفرق؟
سجل استدعاء الدالة يربط طلبًا واحدًا باستدعاء واحد متوقع. أما المسار فيسجّل كل ما فعله الوكيل حتى أنجز المهمة، ثم يتحقق من النتيجة. المثال التالي توضيحي، كتبناه لهذا الدليل ولم نأخذه من أي مجموعة بيانات. طلب حجز بلهجة سعودية: «أبي أحجز موعد عند الدكتور بكرة الساعة ٤ العصر».
| الحقل | سجل استدعاء دالة من دور واحد (توضيحي) |
|---|---|
| الاستعلام | أبي أحجز موعد عند الدكتور بكرة الساعة ٤ العصر |
| الدالة | book_appointment |
| المعاملات | {"date": "2026-10-02", "time": "16:00"} |
لا تصبح «بكرة» 2 أكتوبر 2026 إلا إذا حمل السجل وقتًا مرجعيًا ومنطقة زمنية. موجّه AISA-ArabicFC يتضمن الوقت الحالي، أما مخطط HeshamHaroon فلا يتضمن حقلًا كهذا. والآن الطلب نفسه في صورة مسار، بوقت مرجعي 1 أكتوبر 2026 الساعة 20:00 بتوقيت الرياض (Asia/Riyadh):
- الطلب كما سبق.
- استدعاء أداة: search_slots(date="2026-10-02", after="15:00"). الملاحظة: الساعة 16:00 محجوزة، و16:30 و18:00 متاحتان.
- رسالة الوكيل: يعرض 16:30 أو 18:00. قواعد المهمة تشترط التأكيد، فلا يُحجز شيء بعد.
- تصحيح المستخدم: «طيب، الساعة ٦».
- استدعاء أداة: book_appointment(date="2026-10-02", time="18:00"). الملاحظة: رقم الحجز.
- الرسالة الأخيرة تؤكد الحجز الساعة السادسة مساءً.
- فحص الحالة: لدى المستخدم حجز واحد فقط، في 2 أكتوبر 2026 الساعة 18:00 بتوقيت الرياض، ولا حجز له الساعة 16:00 أو 16:30، وحجز المريض الآخر الساعة 16:00 لم يتغير.
يقيّم المعيار الإنجليزي τ-bench الوكيل بمقارنة حالة قاعدة البيانات في نهاية المحادثة بحالة هدف موسومة مسبقًا، ولا يصف أيّ من الموارد العربية أعلاه فحصًا من هذا النوع.
أين تتعثر القيم العربية في المعاملات؟
في نتائج خط الأساس التجريبية لـ AISA-ArabicFC، يحقق نموذج بحجم 270M خضع للضبط الدقيق (fine-tuning) ومعزَّز بالاستدلال دقة 0.982 في اختيار الدالة، لكنه لا يتجاوز 0.541 في المطابقة التامة للمعاملات، ويحقق GPT-4o دون أمثلة (zero-shot) 0.927 و0.070. تصف البطاقة استخراج المعاملات بأنه العقبة الرئيسية، ولا تذكر ما إذا كانت هذه النتائج قد أُعيد حسابها بعد تحديث يونيو 2026. وتوضح السجلات التالية من أول 100 صف تدريب في مجموعة HeshamHaroon السبب:
| السجل | الطلب | المعامل المخزّن | المشكلة |
|---|---|---|---|
| gen_42234 | محتاج أحجز طيران من القاهرة لدبي بكرة | "date": "tomorrow" | كلمة إنجليزية بدل تاريخ |
| gen_38605 | وين أقدر ألاقي فنادق في جدة من ١٥ ل ٢٠ أكتوبر؟ | "check_in": "2023-10-15" | سنة لم يذكرها المستخدم |
| gen_34030 | أريد فندق بمكة قرب الحرم | "check_in": "2023-10-20" | تواريخ ليست في الطلب أصلًا |
وتنبّه البطاقة إلى أن بعض القيم المولّدة قد تكون متخيَّلة. وتُظهر مصادر أخرى أنماط الإخفاق نفسها:
- القيمة نفسها بكتابة مختلفة. منذ تحديث يونيو 2026، يوحّد مقيّم AISA-ArabicFC صيغة التنبؤ والإجابة المرجعية قبل المقارنة، فيعدّ «٥٠٠٠» مساويًا لـ 5000، و«الإمارات» مساوية لـ«الامارات»، و«٤ بيتزا» لـ«اربع بيتزا»، و«ريال سعودي» لـ SAR.
- قيم افتراضية مخترعة. سياسة التوسيم في البطاقة نفسها لا تضع معاملًا إلا إذا ذكره المستخدم أو أمكن استنتاجه دون لبس، وتحذف المعرّفات مثل رقم IBAN ما لم يذكرها المستخدم. والسجلان gen_38605 وgen_34030 أعلاه يفعلان العكس.
- قيم بلغة خاطئة. في عينة QCRI من 249 خطأً في المعاملات، كان السبب الأول للأخطاء في مجموعات الاختبار العربية أن تكون القيمة المتوقعة بلغة والمُخرَجة بلغة أخرى (53.1% من الأخطاء العربية).
- JSON الصالح ليس الهدف. تذكر ورقة AISA-AR-FunctionCall (إعادة هيكلة لمجموعة HeshamHaroon) أن الضبط الدقيق خفّض أخطاء تحليل الصيغة (parse failures) من 87% إلى أقل من 1%، وانتقلت الأخطاء المتبقية من البنية إلى المعنى.
كيف تفحص مسارات الوكلاء العربية قبل قبولها؟
لا تفيد مجموعة المسارات إلا إذا أظهر كل سجل ما فعله الوكيل فعلًا وما تغيّر نتيجة لذلك. قبل أن ترخّص مجموعة أو تقبل تسليمًا، اطلب مسارًا نموذجيًا وافحص هذه الحقول الثمانية. الرسالة الأخيرة الطليقة لا تثبت شيئًا وحدها؛ يجب أن يسمح السجل بإعادة بناء الإجراء والتحقق من النتيجة.
| الحقل | ما الذي تفحصه | علامة الخطر |
|---|---|---|
| المهمة والصلاحيات | الطلب والقواعد، والأدوات المسموح بها، والإجراءات التي تحتاج موافقة المستخدم | لا قواعد مهمة مؤرخة، ولا قائمة بالإجراءات المسموح بها |
| إصدار البيئة | الواجهة البرمجية المحاكية أو قاعدة البيانات أو البيئة المعزولة (sandbox) التي نُفّذ فيها المسار، بإصدار يمكنك طلبه | «محاكاة» دون إصدار أو ملفات بيئة |
| الحالة الابتدائية | السجلات الموجودة قبل الخطوة الأولى، مع الوقت المرجعي والمنطقة الزمنية | لا حالة ابتدائية أو لا وقت مرجعي، فلا يمكن تحويل «بكرة» إلى تاريخ |
| استدعاءات الأدوات | كل استدعاء بالترتيب، بمعاملات بالصيغة المتفق عليها (قيم عربية أو رموز، ونظام الأرقام) | الاحتفاظ بالاستدعاء الأخير فقط، أو معاملات بالإنجليزية بينما يخزّن نظامك العربية |
| الملاحظات | ما أعادته كل أداة، بما في ذلك الأخطاء والنتائج الفارغة | استدعاءات بلا نتيجة مسجلة، أو نتائج تبدو مكتوبة يدويًا |
| التأكيد والتحويل | أين سأل الوكيل قبل التنفيذ، وأين حوّل الطلب إلى موظف | حجز أو دفع أو إلغاء نُفّذ قبل موافقة المستخدم |
| الحالة النهائية | السجلات بعد الخطوة الأخيرة، أو الفرق عن الحالة الابتدائية | الحكم بالنجاح من الرسالة الأخيرة وحدها |
| فحص النجاح وفئة الإخفاق | فحص يقرأ الحالة النهائية، ووسم للمسارات الفاشلة أو التي تعافت | كل السجلات ناجحة، أو حُذفت الإخفاقات بدل وسمها |
مثال توضيحي مع عنصرَي ضبط سلبي
هذا المثال توضيحي: كتبناه لهذا الدليل استكمالًا لمثال الحجز أعلاه، وليس مأخوذًا من أي مجموعة عامة أو من مجموعات Bayanat Labs. الوقت المرجعي 1 أكتوبر 2026 الساعة 20:00 بتوقيت الرياض.
| الجزء | المحتوى (توضيحي) |
|---|---|
| الحالة الابتدائية | تقويم العيادة ليوم 2 أكتوبر 2026: الساعة 16:00 محجوزة لمريض آخر، و16:30 و18:00 متاحتان. لا حجوزات للمستخدم. |
| القاعدة | لا يُنفَّذ book_appointment إلا بعد أن يؤكد المستخدم وقتًا محددًا. |
| الحالة النهائية المتوقعة | للمستخدم حجز واحد فقط، في 2 أكتوبر 2026 الساعة 18:00 بتوقيت الرياض. حجز المريض الآخر الساعة 16:00 لم يتغير، و16:30 ما زالت متاحة. |
| فحص النجاح | عُدّ حجوزات المستخدم (يجب أن يكون له حجز واحد فقط، الساعة 18:00)، وقارن كل سجل آخر بالحالة الابتدائية (لا تغييرات أخرى)، وتأكد من سجل الاستدعاءات أن book_appointment لم يُنفَّذ إلا بعد أن أكد المستخدم الوقت. |
| عنصر الضبط السلبي 1 | المحادثة نفسها بعد حذف خطوة book_appointment، مع بقاء الرسالة الأخيرة تؤكد الحجز الساعة السادسة. يجب أن يصنّفها الفحص فاشلة. |
| عنصر الضبط السلبي 2 | يحجز الوكيل 16:30 قبل أن يرد المستخدم، ثم يلغي ذلك الحجز ويحجز 18:00. الحالة النهائية مطابقة، لكن القاعدة كُسرت؛ يجب أن يصنّفها الفحص فاشلة لمخالفة قاعدة التأكيد. |
شغّل عنصرَي الضبط السلبي أولًا. إذا صنّف فحص المورّد العنصر الأول ناجحًا، فوسوم النجاح لديه تقيّم الرد لا الحالة، وكل سجل «ناجح» في المجموعة يحتاج مراجعة ثانية. ويبيّن العنصر الثاني لماذا لا تكفي الحالة النهائية وحدها حين تتضمن المهمة قواعد تأكيد: يجب أن يقرأ الفحص ترتيب الاستدعاءات أيضًا.
أعد تشغيل عينة قبل التوسّع
- اسحب عينة عشوائية من كل سير عمل وكل تنويعة عربية في المجموعة، بما فيها المسارات الفاشلة والتي تعافت.
- أعد البيئة إلى الحالة الابتدائية المسجلة، بالإصدار المسجل.
- أعد تشغيل الاستدعاءات المسجلة وقارن نتيجة كل أداة بالملاحظة المسجلة. باستثناء الحقول المولّدة مثل أرقام الحجز والطوابع الزمنية، يعني أي اختلاف أن الملاحظة عُدّلت أو أن البيئة تغيّرت.
- شغّل فحص النجاح وعنصرَي الضبط السلبي، وقارن النتيجة بوسم السجل نفسه.
- اقرأ العربية مع متحدث أصلي بالتنويعة نفسها: يجب أن يبدو الطلب وأسئلة الوكيل والرسالة الأخيرة كلام مستخدمين حقيقيين وموظفين حقيقيين بتلك اللهجة.
ما الذي تضيفه الفرق في السعودية والإمارات إلى المواصفات؟
قائمة الفحص أعلاه تنطبق على أي مشترٍ. وإن كان وكيلك يخدم مستخدمين في السعودية أو الإمارات أو كليهما، فأضف إلى طلب العرض أو مواصفات التسليم ما يلي:
- المنطقة الزمنية في كل سجل. توقيت الرياض (Asia/Riyadh) هو UTC+3، وتوقيت دبي (Asia/Dubai) هو UTC+4، ولا يطبّق أيّ منهما التوقيت الصيفي. اطلب حقل المنطقة الزمنية في الحالة الابتدائية لكل مسار، وأمثلة يذكر فيها المستخدم مدينة في بلد آخر، حتى لا يُحجز موعد بفارق ساعة.
- اللهجة حسب البلد لا «الخليجية» فقط. البطاقات العامة تجمع الخليج في فئة واحدة. اطلب وسم التنويعة لكل سجل (سعودية، إماراتية، فصحى) ونسبة كل منها، ونسبة الطلبات المختلطة بالإنجليزية. يشرح دليل اللهجات السعودية للذكاء الاصطناعي لماذا لا تكفي فئة واحدة.
- صيغ القيم المحلية. اتفق مسبقًا على صيغة المبالغ (ريال سعودي أو درهم إماراتي، أو الرموز SAR وAED)، ونظامَي الأرقام (٤ و4)، والأرقام المكتوبة بالكلمات، والأسماء والمعرّفات بالحرف اللاتيني، وأي القيم تبقى بالعربية.
- مكان معالجة البيانات وتخزينها. إن كانت المسارات تُبنى حول أنظمتك الداخلية أو بيانات عملائك، فحدّد مكان الاستضافة والوصول في العقد. يشرح دليل نظام حماية البيانات الشخصية وتوطين البيانات الأسئلة التي يطرحها فريقك القانوني، ويبقى القرار له.
- حقوق التدريب وإعادة التوزيع. اذكر كلًا منهما صراحةً وبشكل منفصل، واعزل عناصر الاختبار عن بيانات التدريب.
لماذا بيانات لابز (Bayanat Labs) هي الشريك الأفضل لبيانات الوكلاء العربية؟
المجموعات العامة أعلاه تعلّم الاستدعاء الأول. وبيانات لابز هي الشريك الأفضل لما يأتي بعده: مسارات فيها ملاحظات الأدوات وتصحيحات المستخدم، تُقيَّم بالحالة الناتجة، وهو ما لا يصفه أيّ من المصادر هنا.
- المسارات والبيئات في مكان واحد. ترخّص Bayanat Agents مسارات وكلاء عربية، وتبني بيئات مخصصة لاستخدام الأدوات بتعريف المهام والأمثلة التوضيحية وأمثلة الإخفاق والتحقق من الحالة الناتجة. والمسارات الجاهزة والمهام القابلة للتنفيذ حول واجهاتك البرمجية عرضان منفصلان.
- التقييم بالحالة لا بالاستدعاء المتقن. مختبر موثوقية الوكلاء بالعربية (Arabic Agent Reliability Lab) نسخة تجريبية من منهجية تقييم تعتمد الحالة النهائية وإيصالات الأدلة. في سيناريو الاختبار BARL-COM-005 من بيئته التجارية الاصطناعية، ادّعت المحاولة الأولى أن الإلغاء نجح بعد أن استدعت get_order فقط، بينما بقيت حالة الطلب في النظام «مُجهَّز للشحن» (packed). حالة النظام أثبتت العكس. والمختبر منهجية بحثية، لا شهادة.
- متحدثون أصليون وخبراء يغطّون أكثر من 25 تنويعة عربية. متحدثون أصليون ولغويون ومختصون مرخّصون في مجالاتهم، يجتازون فحص اللهجة والتخصص، ويُعايَر عملهم مقابل إجابات مرجعية، مع تحكيم للخلافات وسجل تدقيق لكل مهمة.
- داخل المنطقة ومحايدون تجاه النماذج. الاستضافة داخل المنطقة افتراضيًا، مع خيارات التشغيل في مقرّك أو في سحابة خاصة. نعمل في البيانات فقط ولا ننافس نموذجك.
- الدليل قبل التوسّع. مشروع تجريبي محدد النطاق على مهمة وكيلك نفسها، مع ضبط جودة بإجابات مرجعية وتقرير جودة، يُنجز عادةً خلال أسبوعين.
ومع Bayanat Agents يمكنك أن تبدأ هذه الفحوص قبل الالتزام: تتوفر الإصدارات والأعداد ومخططات الأدوات عند الطلب، ويمكنك طلب مسار نموذجي (الطلب واستدعاءات الأدوات والملاحظات والنتيجة) قبل أن تختار مجموعة. وإن كنت تختبر وكيلًا بنيته بالفعل ولا تشتري بيانات، فابدأ بـ Bayanat Bench ودليل تقييم النماذج اللغوية العربية.
أسئلة شائعة
هل توجد مجموعة بيانات عربية لاستدعاء الدوال على Hugging Face؟
نعم. حتى أكتوبر 2026، أكبرها HeshamHaroon/Arabic_Function_Calling (50,810 عينة) ومجموعة المهمة المشتركة AISA-ArabicFC (10,550 استعلامًا للتدريب و545 للتطوير)، وكلتاهما تذكر رخصة Apache 2.0 في بطاقتها. وعدة قوائم أخرى منسوخة من المجموعة الأولى، فتحقق من مصدر البطاقة قبل أن تعدّها بيانات جديدة.
ما الفرق بين بيانات استدعاء الدوال ومسارات الوكلاء؟
سجل استدعاء الدالة يربط طلبًا واحدًا باستدعاء واحد متوقع. أما مسار الوكيل (trajectory) فيسجّل كل ما فعله الوكيل حتى إنجاز المهمة: الطلب، وكل استدعاء أداة، وما أعادته الأداة، ورسائل الوكيل إلى المستخدم وتصحيحات المستخدم، ثم يتحقق من الحالة النهائية. والمسارات هي ما يعلّم الوكيل التصرف عبر خطوات متعددة والتعافي من محاولة فاشلة.
كيف أفحص مجموعة مسارات وكلاء عربية قبل شرائها؟
اطلب مسارًا نموذجيًا وتأكد أنه يسجّل قواعد المهمة والصلاحيات، وإصدار البيئة، والحالة الابتدائية مع الوقت المرجعي والمنطقة الزمنية، وكل استدعاء وملاحظة (observation)، والتأكيدات، والحالة النهائية، وفحص نجاح يقرأ تلك الحالة. ثم اختبر الفحص بعنصر ضبط سلبي (negative control): سجل تؤكد رسالته الأخيرة النجاح بينما لم تتغير الحالة يجب أن يُصنَّف فاشلًا.
لماذا تهم المنطقة الزمنية في بيانات الوكلاء للسعودية والإمارات؟
لأن كلمات مثل «بكرة» و«العصر» لا تتحول إلى تاريخ ووقت إلا بوقت مرجعي ومنطقة زمنية. توقيت الرياض (Asia/Riyadh) هو UTC+3، وتوقيت دبي (Asia/Dubai) هو UTC+4، ولا يطبّق أيّ منهما التوقيت الصيفي. وكيل يخدم البلدين دون تسجيل المنطقة الزمنية في كل سجل قد يحجز موعدًا بفارق ساعة.
هل AISA-ArabicFC مجموعة تدريب أم معيار تقييم؟
الاثنان معًا. هي مجموعة بيانات المهمة المشتركة AISA-ArabicFC في مؤتمر ArabicNLP 2026، المنعقد مع EMNLP 2026 في بودابست بين 24 و29 أكتوبر 2026. تذكر البطاقة قسم تدريب عامًا من 10,550 صفًا وقسم تطوير من 545، ومجموعة اختبار مخفية الإجابات (blind test) صدرت في 20 يوليو 2026.