💬 NLP

Both Ends Count! Just How Good are LLM Agents at "Text-to-Big SQL"?

تقدم هذه الورقة مقاييس تقييم مبتكرة لـ "النص إلى SQL الضخمة" (Text-to-Big SQL) لمعالجة أوجه القصور في المعايير المرجعية الحالية في تقييم وكلاء النماذج اللغوية الكبيرة (LLM) على مستوى الإنتاج، مما يثبت أن مقاييس "النص إلى SQL" التقليدية تفشل في استيعاب الآثار الحرجة المتعلقة بالتكلفة، وزمن الاستجابة، والكفاءة التي تنشأ عند التوسع إلى مجموعات بيانات ضخمة.

المؤلفون الأصليون: Germán T. Eizaguirre, Lars Tissen, Marc Sánchez-Artigas

نُشر 2026-03-09

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

CC BY 4.0

المؤلفون الأصليون: Germán T. Eizaguirre, Lars Tissen, Marc Sánchez-Artigas

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

تخيل أنك طاهٍ (الوكيل الذكي - AI Agent) تحاول طهي وجبة بناءً على طلب زبون مكتوب بلغة بسيطة (مشكلة تحويل النص إلى لغة SQL - Text-to-SQL).

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

لكن في العالم الحقيقي، لا تهتم المطاعم الكبرى (مثل أنظمة البيانات الضخمة - Big Data) بالطعم فحسب. بل تهتم أيضاً بـ تكلفة المكونات، والوقت المستغرق للطهي، والهدر الناتج.

هذه الورقة البحثية، بعنوان "!Both Ends Count" (كلا الطرفين مهمان!)، تجادل بأننا كنا نختبر طهاة الذكاء الاصطناعي بقواعد خاطئة. إليك التفاصيل بتبسيط شديد:

1. المشكلة: "القدر الصغير" مقابل "المرجل الصناعي"

في الماضي، تم اختبار الذكاء الاصطناعي على قواعد بيانات صغيرة (مثل خزانة مؤنة منزلية). إذا كتب الذكاء الاصطناعي استعلام SQL (تعليمات الطهي) بشكل خاطئ قليلاً، فكان الأمر يستغرق ثانية واحدة فقط لإصلاحه. كان الأمر رخيصاً وسريعاً.

لكن اليوم، تستخدم الشركات البيانات الضخمة (المراجل الصناعية الضخمة).

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

التشبيه:
تخيل أنك تطلب من روبوت: "أوجد لي سعر التفاح".

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

2. الحل الجديد: "Text-to-Big SQL"

يقول المؤلفون إننا بحاجة إلى طريقة جديدة لتقييم هؤلاء الطهاة الآليين. يسمونها "Text-to-Big SQL". فبدلاً من السؤال فقط "هل الإجابة صحيحة؟"، يسألون:

كم بلغت التكلفة؟ (هل قاد الروبوت الشاحنة دون داعٍ؟)
كم استغرق من الوقت؟ (هل قضى الروبوت 10 دقائق في التفكير قبل أن يبدأ الطهي؟)
هل كان فعالاً؟ (هل أحضر أشياء إضافية لم نكن بحاجة إليها؟)

لقد ابتكروا "شهادات تقييم" جديدة (مقاييس) تسمى VES* و VCES.

شهادة التقييم القديمة: "ناجح/راسب". (هل حصلت على الإجابة الصحيحة؟)
شهادة التقييم الجديدة: "ناجح/راسب + التكلفة + السرعة". (هل حصلت على الإجابة الصحيحة، وهل فعلت ذلك دون استنزاف الميزانية؟)

3. ما وجدوه (التحول المفاجئ)

اختبر الباحثون أذكى نماذج الذكاء الاصطناعي في العالم (مثل GPT-4o، وClaude Opus، وGemini) باستخدام هذه القواعد الجديدة. وإليكم ما اكتشفوه:

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

4. تأثير "الحجم"

تظهر الورقة أنه كلما كبر حجم البيانات، ارتفعت المخاطر.

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

وجد المؤلفون أن الاختبارات القياسية تغفل هذا تماماً. إنها تشبه الحكم على سيارة فورمولا 1 بناءً على كيفية قيادتها في موقف سيارات. مجرد عملها في الموقف لا يعني أنها لن تتحطم على الطريق السريع.

الملخص: الخلاصة

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

الطريقة القديمة: "هل سلمت الطرد؟" (نعم/لا)
الطريقة الجديدة: "هل سلمت الطرد، وهل استخدمت المسار الأكثر كفاءة في استهلاك الوقود، وهل وصلت في الوقت المحدد دون استنزاف الميزانية؟"

يجادل المؤلفون بأنه لجعل الذكاء الاصطناعي مفيداً للشركات الكبرى، نحتاج إلى التوقف عن تقييمهم بناءً على "الإجابات المثالية" والبدء في تقييمهم بناءً على الكفاءة، والتكلفة، والسرعة. إذا كان الذكاء الاصطنافي دقيقاً بنسبة 90% ولكنه يوفر لك 50% من أموالك، فهو طاهٍ أفضل من ذاك الذي دقيق بنسبة 100% ولكنه يفلس المطبخ.

إليك ملخص تقني مفصل لورقة البحث بعنوان: "!Both Ends Count! Just How Good are LLM Agents at Text-to-'Big SQL'؟" (كلا الطرفين مهمان! ما مدى جودة وكلاء النماذج اللغوية الكبيرة في تحويل النص إلى "SQL ضخمة"؟)

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

تعالج الورقة فجوة حرجة في تقييم أنظمة Text-to-SQL (تحويل النص إلى SQL) عند نشرها في بيئات البيانات الضخمة (Big Data). وبينما يعد مجال Text-to-SQL مجالاً ناضجاً مع معايير قياسية واسعة النطاق (مثل Spider وBIRD)، إلا أن هذه المعايير تركز بشكل أساسي على قواعد البيانات العلاقاتية التقليدية ذات أحجام البيانات المتوسطة. وهي تعتمد بشدة على مقاييس الصحة الثنائية (المطابقة التامة، ودقة التنفيذ) التي تعتبر أي انحراف عن استعلام SQL "الذهبي" بمثابة فشل كلي.

في سياقات البيانات الضخمة (مثل Amazon Athena أو Spark أو BigQuery)، يكون نموذج التقييم هذا غير كافٍ لأن:

تضخم التكلفة: الخطأ البسيط في الترجمة (مثل اختيار عمود غير ضروري) والذي قد يكون ضئيلاً في مجموعات البيانات الصغيرة، يمكن أن يؤدي إلى تكالوت حوسبة هائلة وتأخير في الاستجابة عند مسح تيرابايت من البيانات.
الحساسية لزمن الاستجابة (Latency): في التحليلات التفاعلية، يجب موازنة الوقت الذي يستغرقه وكيل النماذج اللغوية الكبيرة (LLM agent) في التفكير، وتنسيق الأدوات، وتوليد SQL مقابل وقت تنفيذ الاستعلام الفعلي. إذا كان التوليد بطيئاً جداً، يصبح النظام غير عملي.
الصحة الجزئية: المقاييس التقليدية تعاقب الاستعلامات التي تعيد نتائج صحيحة ولكن مع أعمدة إضافية. في البيانات الضخمة، يمكن للمستخدم غالباً حذف الأعمدة الإضافية يدوياً، مما يجعل مثل هذه الاستعلامات "صحيحة جزئياً" ولكنها مكلفة.

يجادل المؤلفون بأن المقاييس الحالية تفشل في التقاط المقايضات بين الدقة، وزمن الاستجناء، والتكلفة عند النطاقات الواسعة، مما يستدعي نموذجاً جديداً يطلقون عليه اسم "Text-to-Big SQL".

2. المنهجية

يقترح المؤلفون إطار عمل تقييمي مبتكر يعامل كل من توليد SQL (تفكير الوكيل) و تنفيذ SQL (أداء محرك البيانات الضخمة) كعناصر أساسية.

أ. بنية الوكيل (Agent Architecture)

إطار العمل: يستخدمون بنية وكيل ReAct (التفكير + الفعل) مبنية على LangGraph.
المكونات:
- المتحكم (Controller): نموذج لغوي كبير يتفكر في المهمة، ويقرر استخدام الأدوات، ويولد SQL النهائي.
- المنفذ (Executor): يدير حلقة التفاعل مع الأدوات الخارجية.
- الأدوات (Tools): أربع أدوات محددة لـ Spark SQL وهي: list_tables (سرد الجداول)، و get_schema (جلب المخطط)، و check_query (التحقق من صحة الصيغة)، و run_query (تشغيل الاستعلام).
القيود: يتم إنهاء الوكيل بعد أول تنفيذ لـ run_query لمنع الحلقات اللانهائية وتكاليف الفوترة المفرطة، مما يحاكي سيناريو الإنتاج "Zero-shot" دون حلقات التصحيح الذاتي التكرارية.

ب. مجموعات البيانات والنماذج

المعايير القياسية (Benchmarks):
- BIRD: تُستخدم لتقييم دقة الترجمة على قواعد بيانات واقعية.
- TPC-H: تُستخدم لتقييم الأداء عبر عوامل مقياس (Scale Factors - SF) متنوعة (10، 100، 1000) لمحاكاة نمو البيانات الضخمة.
النماذج: تم اختبار مجموعة متنوعة من النماذج الرائدة (مثل GPT-4o، و GPT-5، و Claude Opus 4.5/4.6، و Gemini 3 Flash/Pro، و GLM-5) باستخدام واجهات برمجة التطبيقات الرسمية الخاصة بها مع معايير موحدة للبارامترات.

ج. المقاييس المقترحة

تقدم الورقة ثلاثة مقاييس جديدة لتحل محل أو تعزز المقاييس التقليدية:

$VES^*$ (درجة الكفاءة الصالحة - النجمة): امتداد لدرجة الكفاءة الصالحة (VES). وهي تدمج دقة مستوى العمود ( $P$ ) لمعاقبة الأعمدة الزائدة دون استبعاد النتائج الصحيحة جزئياً.
$VES^* = \frac{1}{N} \sum \left( \mathbb{1}(V, \hat{V}) \cdot P(S, \hat{S}) \cdot \frac{T_{gold}}{T_{e2e}} \right)$
- $\mathbb{1}(V, \hat{V})$ : مؤشر ثنائي لصحة النتيجة.
- $P(S, \hat{S})$ : دقة الأعمدة المسترجعة (الحقيقة الأرضية مقابل المولد).
- $T_{e2e}$ : إجمالي الوقت من البداية للنهاية (تفكير LLM + استدعاء الأدوات + تنفيذ الاستعلام).
VCES (درجة كفاءة التكلفة الصالحة): مشتق من $VES^*$ يركز على التكلفة، حيث يأخذ في الاعتبار إجمالي تكلفة التنفيذ ( $C_{e2e}$ )، بما في ذلك استخدام الرموز (Tokens) ورسوم الحوسبة.
$VCES = \frac{1}{N} \sum \left( \mathbb{1}(V, \hat{V}) \cdot P(S, \hat{S}) \cdot \frac{T_{gold}}{T_{e2e} \cdot C_{e2e}} \right)$
CVQ (التكلفة لكل استعلام صالح): يحدد التكلفة المتوقعة للحصول على نتيجة صالحة تحت استراتيجية "أعد المحاولة حتى النجاح". وهو يبرز كيف تتضخم فجوات الدقة عند مقاييس البيانات الكبيرة.
$CVQ = \frac{C_{e2e}}{p}$
- حيث $p$ هو معدل الصلاحية من المحاولة الأولى.

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

إطار عمل تقييمي مبتكر: أول منهجية معيارية لـ Text-to-Big SQL تقيم بشكل مشترك تفاعل الوكيل، وزمن استجابة التفكير، وتكلفة تنفيذ الاستعلام.
مقاييس جديدة ( $VES^*$ ، $VCES$ ، $CVQ$ ): مقاييس تأخذ في الاعتبار الصحة الجزئية (الأعمدة الزائدة) والأثر الاقتصادي للأخطاء في بيئات البيانات الضخمة.
تحليل منهجي للنماذج: تقييم شامل لأحدث النماذج اللغوية الكبيرة يكشف أن الدقة العالية لا تعني دائماً الأداء الأفضل في إعدادات البيانات الضخمة.
رؤى واعية بالمقياس: إثبات أن حجم البيانات يغير بشكل جذري مشهد التحسين، حيث تصبح المقايضات بين زمن الاستجابة والتكلفة أمراً حاسماً.

4. النتائج الرئيسية

الدقة غير كافية: تفشل المقاييس القياسية (مثل دقة التنفيذ) في التمييز بين النماذج عندما تكون الدقة عالية. على سبيل المثال، حقق Claude Opus 4.6 دقة مثالية ولكنه استغرق وقتاً أطول بنسبة 92% في التنفيذ مقارنة بـ GPT-4o، مما يجعله أقل ملاءمة للتحليلات التفاعلية.
$VES^*$ يميز بشكل أفضل: نجح $VES^*$ في ترتيب النماذج عبر الجمع بين السرعة والصحة الجزئية. وقد برز GPT-4o كأفضل أداء نظراً لتوازنه بين السرعة والدقة، بينما عانت نماذج مثل Gemini 3 Pro و GLM-5 من تباين عالٍ في زمن الاستجابة.
المقايضة بين التكلفة وزمن الاستجابة:
- تم تحديد Gemini 3 Flash كأكثر النماذج كفاءة من حيث التكلفة بسبب انخفاض أسعار الرموز (Tokens)، رغم أنه أبطأ قليلاً من GPT-4o.
- كان GPT-4o الأسرع ولكنه كان أغلى ثمناً بشكل ملحوظ لكل استعلام، خاصة عند حساب المحاولات الفاشلة.
تأثير مقياس البيانات:
- عند المقاييس الصغيرة (SF 10)، يهيمن زمن تفكير الوكيل على إجمالي زمن الاستجابة.
- عند المقاييس الكبيرة (SF 1000)، يهيمن وقت تنفيذ الاستعلام على الزمن الإجمالي.
- تحليل CVQ: مع زيادة مقياس البيانات، تنفجر تكلفة الأخطاء. النموذج الذي لديه دقة أقل بنسبة 10% (مثلاً Opus 4.5 مقابل GPT-5.2) يصبح أكثر تكلفة بشكل أسّي عند SF 1000 مقارنة بـ SF 10، وهي تفصيلة لا تظهرها المقاييس التقليدية.
تصنيف الأخطاء: كشف تحليل 1,730 خطأ أن 38.9% منها كانت أخطاء "تنسيق المخرجات" (غال% معظمها أعمدة إضافية). تحت المقاييس التقليدية، تعتبر هذه أخطاء، ولكن تحت مقاييس Text-to-Big SQL المقترحة، يتم معاقبتها ولكن يتم الاعتراف بصحتها الجزئية.

5. الأهمية والتوجهات المستقبلية

تحول في النموذج الفكري: تجادل الورقة بأن تقييم Text-to-SQL يجب أن يتطور من "هل SQL صحيح؟" إلى "هل SQL صحيح، سريع، ورخيص عند النطاقات الكبيرة؟".
الصلة بالإنتاج: هذه النتائج حاسمة لنشر وكلاء الذكاء الاصطناي في مستودعات البيانات السحابية (مثل Snowflake، BigQuery، Athena) حيث تعتمد الفوترة على الاستخدام.
الفرص المستقبلية:
- التعيين الاستراتيجي للنماذج: استخدام نماذج مختلفة لمراحل مختلفة من الوكيل (مثلاً، نموذج "سريع/رخيص" لفحص المخطط ونموذج "ذكي" للتفكير المعقد).
- التحسين الواعي بالمقياس: الاستفادة من آثار التنفيذ التاريخية للتنبؤ بالتكاليف وإعادة كتابة الاستعلامات قبل التنفيذ.
- معالجة الاستعلامات التقريبية: دمج نية المستخدم للحصول على نتائج "سريعة" (مثل أخذ العينات) بدلاً من التنفيذ الدقيق.
- تكامل UDF (الدوال المعرفة من قبل المستخدم): التعامل مع الدوال المعرفة من قبل المستخدم والتي تشيع في البيانات الضخمة ولكن يصعب توليدها بواسطة مولدات SQL القياسية.

في الختام، تؤسس ورقة "!Both Ends Count!" لفكرة أن تقييم وكلاء النماذج اللغوية الكبيرة للبيانات الضخمة يتطلب رؤية شاملة لكامل عملية التدفق (Pipeline). إن تجاهل كلمة "الضخمة" (Big) في "Big SQL" يؤدي إلى أنظمة قد تكون دقيقة نظرياً ولكنها غير قابلة للاستخدام عملياً بسبب قيود التكلفة وزمن الاستجابة.