💬 NLP

Structured Context Engineering for File-Native Agentic Systems: Evaluating Schema Accuracy, Format Effectiveness, and Multi-File Navigation at Scale

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

المؤلفون الأصليون: Damon McMillan

نُشر 2026-02-13

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Damon McMillan

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

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

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

إليك تفاصيل نتائجهم، مترجمة إلى لغة بسيطة:

1. الطريقتان لتسليم المكتبة

اختبر الباحثون استراتيجيتين رئيسيتين لكيفية حصول المساعد على المعلومات:

طريقة "إلقاء المكتبة بأكملها" (هندسة الأوامر - Prompt Engineering): أنت تعطي المساعد فهرس المكتبة بأكملها في كومة ضخمة من الأوراق في البداية. ويتعين عليه قراءة كل شيء للعثور على ما يحتاجه.
طريقة "أمين المكتبة مع كشاف ضوئي" (الوكلاء الأصليون للملفات - File-Native Agents): أنت تعطي المساعد كشافاً ضوئياً وخريطة. المكتبة ضخمة جداً، لذا يستخدم المساعد أداة (مثل grep) للبحث عن كلمات مفتاحية محددة، ويستخرج فقط الصفحات التي يحتاجها، واحدة تلو الأخرى.

المفاجأة الكبرى:

بالنسبة للمساعدين "العباقرة" (النماذج الرائدة مثل Claude و GPT-5): كانت طريقة "الكشاف الضوئي" أفضل. فهذه المساعدات الذكية بارعة في البحث واستخراج ما تحتاجه بالضبط، لذا لم تشعر بالارتباك بسبب كومة الأوراق الضخمة.
بالنسبة للمساعدين "الأذكياء ولكن الجدد" (النماذج مفتوحة المصدر): طريقة "الكشاف الضوئي" في الواقع أضرتهم. فهذه المساعدات ارتبكت بسبب عملية البحث. لقد كان أداؤهم أفضل عندما تعطيها كومة الأوراق كاملة لتقرأها دفعة واحدة.
- تشبيه: الأمر يشبه إعطاء لاعب شطرنج عظيم خريطة لإيجاد نقلة معينة (سيحب ذلك)، لكن إعطاء مبتدئ خريطة سيجعله يصاب بالذعر ويخسر اللعبة.

2. هل نوع "الخط" أو "نوع الورق" يهم؟ (التنسيق)

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

YAML: مثل قائمة مرتبة ومنظمة بمسافات بادئة.
Markdown: مثل تدوينة تحتوي على عناوين ونصوص عريضة.
JSON: مثل كود برمجي صارم يمكن للحاسوب قراءته.
TOON: كود مختصر جداً مصمم لتوفير المساحة.

النتيجة:
بشكل عام، لم يكن الأمر يهم كثيراً أي تنسيق استخدمت. فقد كانت المساعدات تصل إلى الإجابة الصحيحة بنسبة 75% بغض النظر عن التنسيق.

ومع ذلك، كان لبعض المساعدات تفضيلات قوية. فقد يكره أحدها التنسيق "المختصر" (TOON) ويفضل أسلوب "التدوينة" (Markdown)، بينما قد يفضل آخر العكس.
الخلاصة الرئيسية: لا تبالغ في الاهتمام بالتنسيق لزيادة الدقة. بدلاً من ذلك، اختر التنسيق الأسهل للبشر في الصيانة أو الذي يوفر أكثر في تكلفة "الورق" (الرموز/Tokens).

3. فجوة "القدرة الذهنية" هائلة

العامل الأكبر في نجاح المساعد لم يكن تنظيم المكتبة أو التنسيق، بل كان مدى ذكاء المساعد في الأصل.

كانت النماذج "العبقرية" أكثر دقة بنسبة 21% من نماذج "المصادر المفتوحة"، بغض النظر عما فعلته.
تشبيه: إذا قدمت لطالب دكتوركت وطالب ثانوي نفس اختبار الرياضيات الصعب، فإن طالب الدكتوراه سيفوز في كل مرة، بغض النظر عما إذا كان الاختبار مطبوعاً بخط Comic Sans أو Times New Roman. استثمر في نموذج أذكى أولاً؛ ثم اهتم بتنسيق الملف لاحقاً.

4. التوسع: مشكلة الـ 10,000 جدول

ماذا يحدث عندما تنمو المكتبة من 10 كتب إلى 10,000؟

المشكلة: إذا احتفظت بالمكتبة بأكملها في ملف واحد ضخم، فسيضيع المساعد.
الحل: قام الباحثون بتقسيم المكتبة إلى أقسام (مثل "روايات"، "تاريخ"، "علوم").
النتيجة: حتى مع وجود 10,000 جدول، إذا كانت المكتبة مقسمة جيداً، فإن طريقة "الكشاف الضوئي" تعمل بشكل مثالي. المساعد ببساطة يبحث في قسم "التاريخ" عندما يُسأل عن التاريخ، متجاهلاً الباقي.

5. "ضريبة البحث" (التكلفة الخفية لكونك شديد الاختصار)

هذا اكتشاف مذهٍ حول الكفاءة.

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

ملخص: ماذا يجب أن تفعل؟

إذا كنت تبني نظام ذكاء اصطناعي لإدارة البيانات، فإليك "ورقة الغش" من البحث:

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

الخلاصة: لا توجد "خلطة سحرية" واحدة تناسب الجميع. يجب عليك مطابقة استراتيجية تنظيم مكتبتك مع مستوى ذكاء المساعد الذي توظفه.

إليك ملخص تقني مفصل للورقة البحثية بعنوان "هندسة السياق المهيكلة للأنظمة الوكيلية ذات الطبيعة الملفية" (Structured Context Engineering for File-Native Agentic Systems) بقلم ديمون مكميلان.

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

مع تزايد تفاعل وكلاء النماذج اللغوية الكبيرة (LLM agents) مع الأنظمة الخارجية عبر واجهات برمجية، يفتقر الممارسون إلى توجيه تجريبي حول كيفية هيكلة السياق الذي يستهلكه هؤلاء الوكلاء. وتحديداً، هناك فجوة في فهم:

ما إذا كانت البنى ذات الطبيعة الملفية (حيث يسترجع الوكلاء معلومات المخطط عبر أدوات مثل grep و read) تتفوق على هندسة الأوامر التقليدية (تضمين المخططات الكاملة في أمر النظام).
كيف تؤثر تنسيقات تمثيل المخطط (YAML، Markdown، JSON، TOON) على الدقة والكفاءة.
كيف تؤثر فئات قدرة النموذج (النماذج الرائدة مقابل النماذج مفتوحة المص المصدر) على فعالية هذه الخيارات المعمارية.
كيف تتوسع هذه الأنظمة لتشمل مخططات ضخمة (تصل إلى 10,000 جدول) وما إذا كانت التنسيقات "الموجزة" تقلل بالفعل من تكاليف وقت التشغيل.

2. المنهجية

الدراسة هي تقييم تجريبي منهجي واسع النطاق يتضمن 9,649 تجربة عبر 11 نموذجاً، و4 تنسيقات، وبنيتين معماريتين، ومخططات تتراوح من 10 إلى 10,000 جدول.

المهمة: توليد SQL من النص باستخدام معيار TPC-DS كبديل لعمليات الوكيل البرمجية.
البنى المعمارية التي تمت مقارنتها:
- الوكيل الملفي (File Agent): يستخدم الوكلاء أدوات ملفية أصلية (grep و read) لاسترجاع أقسام المخطط ذات الصلة عند الطلب.
- الأساس المعتمد على الأوامر (Prompt Baseline): يتم تضمين المخطط الكامل (حوالي 6,000 توكن) مباشرة في أمر النظام دون الوصول إلى الأدوات.
التنسيقات المختبرة:
- YAML: هرمي، وصديق لعملية grep.
- Markdown: بأسلوب التوثيق، ولغة طبيعية.
- JSON: قابل للتحليل آلياً، ومسهب.
- TOON (Token-Oriented Object Notation): تنسيق موجز مخصص (~أصغر بنسبة 25% من YAML) يستخدم كلمات مفتاحية مختصرة.
النماذج: 11 نموذجاً عبر ثلاث فئات:
- الرائدة (Frontier): Claude Opus، GPT-5، Gemini Pro.
- المختبرات الرائدة (Frontier Lab): Claude Haiku، GPT-5 Mini، Gemini Flash.
- مفتوحة المصدر (Open Source): DeepSeek، Kimi، متغيرات Llama، Qwen.
مقاييس التقييم:
- الدقة: تشابه جاكارد (Jaccard similarity) بين النتائج المولدة من الوكيل والنتائج الحقيقية (العتبة $\ge$ 0.9).
- الكفاءة: استهلاك التوكنات، عدد استدعاءات الأدوات، وتكلفة وقت التشغيل.
- التوسع: دقة التنقل عبر مستويات التعقيد (L1-L5) وأحجام المخططات (S0-S9، حتى 10 آلاف جدول).

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

النطاق المنهجي: أكبر دراسة من نوعها، تغطي 9,649 تجربة عبر نماذج متنوعة وأحجام مخططات مختلفة.
التحقق من البنية المعمارية: أثبتت أن الاسترجاع ذو الطبيعة الملفية ليس ممارسة فضلى عالمية؛ ففعاليته تعتمد كلياً على النموذج المستخدم.
رؤى التنسيق: حددت أنه بينما الدقة الإجمالية لا تختلف باختلاف التنسيق، فإن النماذج الفردية (خاصة مفتوحة المصدر) تظهر حساسية كبيرة تجاه التنسيقات.
إثبات التوسع: أكدت أن الوكلاء ذوي الطبيعة الملفية يمكنهم التنقل في مخططات مكونة من 10,000 جدول بدقة عالية باستخدام مخططات مقسمة حسب المجال.
ظاهرة "ضريبة الـ grep": اكتشفت أن التنسيقات الموجزة أو الجديدة (مثل TOON) يمكن أن تفرض تكاليف توكن أعلى أثناء التشغيل بسبب كثافة المخرجات وعدم إلمام النموذج بأنماط البحث، مما يناقض الافتراض بأن حجم الملف الأصغر يعني تكلفة أقل.

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

أ. فعالية البنية المعمارية (R1)

النماذج الرائدة: أدى الاسترجاع ذو الطبيعة الملفية إلى تحسين الدقة بشكل ملحوظ بمقدار +2.7% ( $p=0.029$ ) مقارنة بهندسة الأوامر.
النماذج مفتوحة المصدر: أظهر الاسترجاع ذو الطبيعة الملفية نتائج متباينة إلى سلبية. انخفضت الدقة الإجمالية بمقدار -7.7% ( $p<0.001$ $p < 0.001$ ).
- المحركات: أداء Qwen (-21.9%) و Llama Maverick (-13.9%) كان أسوأ بكثير مع الوكلاء الملفيين، بينما أظهرت Kimi و Llama Scout فروقات ضئيلة.
الاستنتاج: يجب تخصيص اختيار البنية المعمارية بناءً على قدرة النموذج.

ب. تأثير التنسيق على الدقة (R2)

الإجمالي: لا يوجد فرق معنوي في الدقة عبر التنسيقات (Chi-squared $p=0.484$ ).
الحساسية الفردية: أظهرت النماذج مفتوحة المصدر تفاوتات كبيرة في الأداء (9.8%–20.1%) بين التنسيقات، بينما كانت النماذج الرائدة مستقرة (1.6%–5.4%).
التفضيل: كان YAML هو الأفضل لـ 5 نماذج، و Markdown لـ 4، و JSON لـ 2، و TOON لـ 0.

ج. هيمنة قدرة النموذج (R3)

الفجوة: فئة النموذج هي العامل المهيمن. حققت النماذج الرائدة دقة بنسبة 86.0%، بينما حققت النماذج مفتوحة المصدر 64.6% (فجوة قدرها 21 نقطة مئوية).
التعقيد: أدت جميع النماذج أداءً جيداً في الاستعلامات البسيطة (L1)، لكن النماذج الرائدة حافظت على دقة 64% في الاستدلال المعقد (L5)، بينما انخفضت النماذج مفتوحة المصدر إلى 27%.

د. التوسع إلى 10,000 جدول (R4)

الملف الواحد: ظلت الدقة قريبة من المثالية حتى 1,000 جدول.
التقسيم: باستخدام التقسيم القائم على المجال (~250 جدولاً لكل مجال)، حافظ الوكلاء على دقة تنقل عالية عند 10,000 جدول. ظل سياق كل استعلام محدوداً بغض النظر عن إجمالي حجم المخطط.

هـ. الكفاءة و"ضريبة الـ grep" (R5)

كفاءة التوكن: خلافاً لحجم الملف، كان YAML هو التنسيق الأكثر كفاءة في التوكن (متوسط 12,729 توكن).
- كان Markdown أكثر تكلفة بنسبة +60% بسبب تنسيق الجداول المعتمد على الخطوط الرأسية المسهب.
- كان TOON أكثر تكلفة بنسبة +38% من YAML رغم أنه أصغر بنسبة 25% في حجم الملف.
آلية ضريبة الـ grep:
1. كثافة التوكن: التنسيقات الموجزة تضغط محتوى أكثر في السطر الواحد، مما يزيد من عدد التوكنات في عملية grep واحدة.
2. عدم الإلمام بالنمط: النماذج غير المعتادة على الكلمات المفتاحية المخصصة (مثل TABLE و COL في TOON) تمر عبر دورات من أنماط البحث الخاطئة (مثل محاولة البحث عن صيغ DDL أو JSON) قبل العثور على النمط الصحيح، مما يزيد من استدعاءات الأدوات واستخدام التوكنات.
- مثال: في إحدى الحالات، تطلب نموذج 16 محاولة grep لتنسيق TOON مقابل 3 محاولات لـ YAML.

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

تنقل هذه الورقة النموذج من "النهج الموحد لجميع النماذج" في هندسة السياق إلى استراتيجيات مدركة للنموذج.

اختيار البنية المعمارية:
- النماذج الرائدة: استخدم الوكلاء الملفيين (الاسترجاع عند الطلب).
- النماذج مفتوحة المصدر: استخدم هندسة الأوامر (تضمين المخطط) لتجنب عدم كفاءة استخدام الأدوات.
اختيار التنسيق:
- أعطِ الأولوية لـ YAML لكفاءة التوكن وسهولة الاستخدام مع grep.
- تجنب التنسيقات الجديدة أو الموجزة (مثل TOON) ما لم يتم تقديم إرشادات صريحة في الأمر (prompt) للتخفيف من "ضريبة الـ grep".
استراتيجية التوسع:
- للمخططات ذات الحجم المؤسسي (أكثر من 1,000 جدول)، قم بتنفيذ مخططات مقسمة حسب المجال لإبقاء السياق محدوداً.
مبدأ التصميم:
- استثمر في قدرة النموذج أولاً؛ فتحسين التنسيق يعطي عوائد متناقصة مقارنة باختيار فئة النموذج الصحيحة.
- إذا كنت تستخدم تنسيقات موجزة، فقدم أمثلة صريحة لأنماط grep في أمر النظام لمنع تكرار الأنماط الخاطئة.

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