تحسين سياق الذكاء الاصطناعي: إنجاز أكثر بموارد أقل

باختصار

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

ما هي نافذة السياق فعلاً

النموذج اللغوي لا «يتذكّر» شيئاً بين طلبين. في كل طلب، يتلقّى كتلة من النص مقسّمة إلى رموز (tokens)، ويجيب انطلاقاً منها فقط. هذه الكتلة هي السياق، وحجمها الأقصى هو نافذة السياق.

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

ما الذي يملأ السياق فعلاً

في جلسة عمل حقيقية مع وكيل، هذا ما يشغل النافذة، بالترتيب الذي أراه يكبر به:

1. تعليمات النظام الخاصة بالأداة نفسها، والتي لا تراها.
2. تعريفات الأدوات: كل أداة متاحة (قراءة ملف، تشغيل أمر، البحث في الويب) توصف للنموذج مع معاملاتها.
3. ملفات تعليمات المشروع (AGENTS.md وCLAUDE.md) والذاكرة الدائمة.
4. سجلّ المحادثة: رسائلك وردوده.
5. نتائج الأدوات: محتوى الملفات المقروءة، ومخرجات الأوامر، وصفحات الويب المزورة. وهي في الغالب البند الأثقل.
6. المستندات التي يلصقها المستخدم.

ملف واحد من 2000 سطر يُقرأ كاملاً، أو أمر يعرض سجلّ أخطاء طويلاً، أو صفحة ويب كاملة، قد تزن أكثر من بقية المحادثة كلها.

ما الذي يكلّفه سياق مزدحم

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

زمن الاستجابة. على النموذج أن يقرأ السياق كله قبل أن يكتب الكلمة الأولى. كلما طال، طال الانتظار.

الجودة. وهي النقطة الأكثر مخالفة للبديهة، وموثّقة جيداً:

• أظهرت دراسة Lost in the Middle (Liu وزملاؤه، المنشورة في مجلة Transactions of the Association for Computational Linguistics) أن النماذج تسترجع المعلومة الموجودة في بداية السياق الطويل أو نهايته أفضل من تلك الموجودة في وسطه، بما فيها النماذج المصمّمة للسياقات الطويلة (arXiv 2307.03172).
• في يوليو 2025، اختبر فريق البحث في Chroma ثمانية عشر نموذجاً، وخلص إلى أن أداءها يصبح أقل موثوقية كلما طال المُدخل، حتى في المهام البسيطة، وبشكل غير منتظم (Context Rot).
• تلخّص Anthropic المبدأ في مقالها عن هندسة السياق: يجب التعامل مع السياق كمورد محدود ذي عوائد متناقصة (Effective context engineering for AI agents).

نافذة السياق الكبيرة قدرة، وليست هدفاً. السياق الجيد هو أصغر مجموعة من المعلومات تسمح للنموذج بإنجاز المهمة جيداً.

الوسائل، من الأبسط إلى الأكثر تقدّماً

1. تعليمات قصيرة ومنظّمة ودقيقة

إنها الوسيلة الأكثر مردودية، ولا تكلّف شيئاً.

متى تستعملها: دائماً.

ما الذي ينجح:

• اذكر الهدف في جملة، ثم السياق المفيد (لا القصة كلها)، ثم القيود، ثم صيغة الإخراج المنتظرة.
• عوّض الشروح الطويلة بقوائم وأمثلة قصيرة.
• احذف ما لا يغيّر الجواب: المجاملات المتكرّرة، وتاريخ المشروع، والتفاصيل المضافة «احتياطاً».
• اطلب صراحةً جواباً قصيراً حين يكون ذلك ممكناً: الإخراج مفوتر أيضاً، ويعود إلى السياق في الدورة التالية.

مثال: بدل لصق ملف كامل وكتابة «انظر ما المشكلة»، ألصق الدالة المعنية ورسالة الخطأ بنصّها وجملة واحدة: «هذا الاختبار يفشل منذ إضافة التخزين المؤقت؛ جد السبب واقترح أصغر تصحيح ممكن.» تطبّق مكتبة الأوامر هذه البنية على 30 حالة شائعة.

2. ملف تعليمات للمشروع

بدل إعادة شرح المشروع في كل جلسة، تكتبه مرة واحدة في ملف يحمّله الوكيل تلقائياً: AGENTS.md (صيغة مفتوحة، انظر agents.md)، أو CLAUDE.md لـ Claude Code (توثيق ذاكرة Claude Code)، أو ما يعادلهما.

متى تستعمله: ما إن يدوم المشروع أكثر من جلسة واحدة.

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

الفخّ: ملف التعليمات الطويل جداً يُضعف نفسه، ويُعاد قراءته في كل جلسة. صفحة أو صفحتان تكفيان. ينتج مولّد ملف التعليمات أساساً نظيفاً مع تقييم للجودة.

3. تقسيم المهام واستعمال الوكلاء الفرعيين

جلسة واحدة تقوم بـ«إعادة هيكلة الموقع كله» تنتهي مشبعة بنتائج أدوات لم تعد مفيدة. عدّة جلسات قصيرة، لكل منها هدف واضح، تحافظ على سياق نظيف.

متى تستعمله: لكل مهمة تمسّ أكثر من بضعة ملفات، أو تخلط البحث بالتعديل.

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

من تجربتي: لكتابة أدلة هذا المختبر، أسندت كل دليل إلى وكيل مستقل مع دفتر تحمّلات دقيق. لم يتلقَّ الوكيل الرئيسي إلا تقرير كل واحد: عدد الكلمات، والمصادر المتحقَّق منها، والحدود. لولا هذا التقسيم لغرقت الجلسة الرئيسية في عمليات البحث على الويب.

4. التخزين المؤقت للأوامر

حين يتكرّر جزء كبير من السياق من طلب إلى آخر (تعليمات النظام، تعريفات الأدوات، مستند مرجعي)، تتيح كبريات الشركات الاحتفاظ به في ذاكرة مؤقتة. الطلبات اللاحقة التي تبدأ بالبداية نفسها تُعالَج حينئذ أسرع وتُفوتر أقل.

كيف يعمل، حسب التوثيق الرسمي:

المصادر: OpenAI، Anthropic، Google. الأسعار الدقيقة تتغيّر كثيراً: تطبّق حاسبة كلفة الواجهات التخفيضات المنشورة مع تاريخ التحقق منها.

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

الفخاخ:

• تاريخ أو معرّف جلسة في أعلى الأمر يكسر التخزين المؤقت في كل طلب.
• تغيير قائمة الأدوات أو ترتيبها يُبطل التخزين لدى Anthropic ويُضعف إعادة الاستعمال لدى OpenAI.
• لكل شركة حدّ أدنى للحجم لا يُخزَّن ما دونه شيء، دون أي رسالة خطأ. تحقّق في حقول الاستهلاك ضمن الجواب من أن التخزين يُستعمل فعلاً.

متى تستعمله: روبوتات المحادثة ذات التعليمات الطويلة، والمساعدون الذين يستعلمون دائماً المستند نفسه، والوكلاء الذين يتسلسلون في طلبات كثيرة.

5. البحث بدل لصق كل شيء (RAG والقراءة عند الحاجة)

لصق التوثيق كله في الأمر «للاطمئنان» هو الخطأ الأكثر شيوعاً. هناك بديلان:

• التوليد المعزّز بالاسترجاع (RAG). تُقسَّم المستندات وتُفهرَس مسبقاً، ومع كل سؤال لا يتلقّى النموذج إلا بضعة مقاطع هي الأكثر صلة. صاغ Lewis وزملاؤه هذه المقاربة (arXiv 2005.11401).
• القراءة عند الحاجة. هذا ما يفعله وكلاء البرمجة: بدل تحميل كل شيء، يحتفظون بمراجع (مسارات ملفات، استعلامات) ويقرؤون المحتوى لحظة الحاجة إليه بأدوات البحث. تصف Anthropic المقاربتين ومقايضاتهما: القراءة عند الحاجة أبطأ، ومن هنا المقاربات الهجينة.

متى تستعمله: ما إن تتجاوز قاعدة المعرفة ما كنت ستعيد قراءته بنفسك للإجابة عن سؤال. يمكن لصق أسئلة شائعة من صفحتين، أما كتالوج من 3000 منتج أو مستودع شيفرة كامل فلا.

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

لربط ذكاء اصطناعي بمستنداتك وأدواتك وأجهزتك (واجهات برمجية، MCP، وكلاء)، انظر الدليل المرافق ربط الذكاء الاصطناعي بأدواتك وأجهزتك.

6. تلخيص الجلسات الطويلة وضغطها

حين تقترب المحادثة من حدّ النافذة، تضغطها الأدوات الحديثة: تستبدل السجلّ بملخّص وتنطلق منه من جديد. وصيغة أخفّ هي حذف نتائج الأدوات القديمة التي لم تعد مفيدة.

هذا ضروري للجلسات الطويلة، وفيه أيضاً تختبئ أخبث الخسائر.

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

ما يحدّ من الأضرار:

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

7. الذاكرة الدائمة وملاحظات المشروع

الملاحظات المكتوبة خارج نافذة السياق، ثم المقروءة عند الحاجة، هي أمتن أشكال الذاكرة. تصف Anthropic هذه التقنية بتدوين ملاحظات منظّمة: يكتب الوكيل بانتظام ملاحظات محفوظة خارج السياق ويعيد تحميلها لاحقاً.

ما أحتفظ به في الملاحظات لكل مشروع:

• مسارات الخادم وخدماته وأوامره؛
• القرارات المتّخذة وسببها («لماذا لا نفعل كذا»)؛
• الفخاخ التي صادفناها وحلّها؛
• تفضيلات الشخص الذي أعمل معه.

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

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

8. ميزانيات الرموز

آخر وسيلة، وهي أكثر تقنية: حدّد سقفاً واختر ما يدخل فيه.

• حدّد طول الأجوبة حين لا تحتاج إلى رواية.
• اقتطع مخرجات الأدوات: آخر 50 سطراً من سجلّ ما تكفي غالباً.
• لائم السياق مع النموذج: النموذج المحلي الصغير له نافذة أقصر ويتأثّر أسرع بالسياق المثقل. تُظهر حاسبة عتاد الذكاء الاصطناعي المحلي أيضاً كم من الذاكرة يستهلك السياق نفسه (ذاكرة KV المؤقتة).

قياس ما نفقده

لماذا «يبدو» الملخّص جيداً

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

إعادة قراءة الملخّص لا تكفي، لأنك تقارنه بما تتذكّره، لا بالمصدر.

طريقة أسئلة الاختبار

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

1. اكتب من 10 إلى 30 سؤالاً دقيقاً: «أيّ ترويسة تحمل مفتاح عدم التكرار؟»، «ما هو الفرع الافتراضي؟»، «أيّ صلاحية تنقص الرمز؟».
2. دوّن الجواب الدقيق مع موضعه في المصدر.
3. اطرح الأسئلة على النموذج مع الملخّص، ثم دون أي سياق: الفرق يُظهر ما يضيفه الملخّص فعلاً.
4. احسب الأجوبة الصحيحة والخاطئة و«لا أعرف». الجواب الخاطئ المقدَّم بثقة هو أسوأ الحالات.

إنها فكرة خطط الاختبار نفسها في مصمّم المساعد الذكي، مطبّقة على السياق. توجد أدوات تقيس الضغط أو الملخّص بالأسئلة، مثل طريقة التقييم بالمسابير التي نشرتها Factory، ومقياس التلخيص في DeepEval، ومقياس الأمانة في Ragas: إنها طرق ومقاييس، لا صيغ ملفات.

HCS: مشروعي مفتوح المصدر حول هذه المشكلة

اصطدامي بهذه الحدود هو ما دفعني إلى إطلاق HCS (Holographic Context Standard)، وهو مشروع مفتوح المصدر بترخيص MIT (github.com/Oufrid/HCS، ومعروض ضمن مشاريع المختبر).

الفكرة: ملف سياق تذكر فيه كل معلومة مصدرها، ويعرف متى يصبح خاطئاً.

• قابل للتتبّع: كل معلومة تشير إلى مقطع محدّد (دالة، صنف، عنوان، مجال أسطر).
• قابل للتحقّق: كل استشهاد يحمل بصمة رقمية (hash) للنص المستشهَد به. يكشف الأمر hcs check، دون ذكاء اصطناعي، المعلومات التي تغيّر مصدرها؛ ويتجاهل مجرّد إعادة التنسيق ويتتبّع الشيفرة التي انتقلت فقط. ويمكنه إيقاف التكامل المستمر.
• مقيس: يتضمّن الملف أسئلة اختبار يُتحقَّق من جوابها حرفياً في المصدر، ويحسب hcs score درجة أمانة لنموذج معيّن مع مجال ثقة ومقارنة دون سياق.
• متاح عبر MCP: يتيح خادم مدمج للنموذج قراءة المعلومات المختصرة أولاً، ثم فتح المصدر الدقيق عند الحاجة.

ما يجب معرفته بصدق:

• HCS تجريبي (الإصدار 0.2). الصيغة والتحقّق دون ذكاء اصطناعي وخادم MCP مكتملة ومختبَرة.
• الوظائف التي تستعمل الذكاء الاصطناعي (بناء الملف، قياس الأمانة) مطوَّرة ومختبَرة على خوادم محاكاة، لكنها لم تُقَس بعد على نماذج حقيقية. ستُنشر النتائج مع بياناتها الخام، لا كوعود.
• لا فكرة من أفكاره جديدة بمفردها. يجمعها HCS في صيغة قابلة للنقل، ويكمّل الصيغ الموجودة (AGENTS.md وCLAUDE.md وllms.txt) وأدوات تجميع المستودعات مثل Repomix وخريطة المستودع في Aider وكاشفات انحراف التوثيق، بدل أن يحلّ محلّها.

إن كان الموضوع يهمّك، فالملاحظات والتصحيحات مرحّب بها على المستودع.

جدول تلخيصي

الأخطاء الشائعة

• لصق كل شيء «للاطمئنان». يضيع النموذج في الوسط وترتفع الفاتورة.
• تاريخ في أعلى الأمر. يضيع التخزين المؤقت في كل طلب.
• ملف تعليمات من عشر صفحات. يُضعف نفسه ويكلّف في كل جلسة.
• الثقة في ملخّص لأنه مكتوب جيداً. سهولة القراءة ليست أمانة.
• ترك جلسة تمتدّ لساعات دون كتابة حالة العمل أبداً.
• وضع أسرار في ملاحظات المشروع، التي تُقرأ في كل جلسة.
• اختيار النموذج ذي النافذة الأكبر لتعويض سياق سيّئ التنظيم.

قائمة التحقق

1. هل تتّسع تعليمتي للهدف والسياق المفيد والقيود والصيغة؟
2. هل لمشروعي ملف تعليمات قصير ومحدَّث؟
3. هل يمكن تقسيم هذه المهمة أو إسنادها إلى وكيل فرعي؟
4. هل المحتوى الثابت في بداية الأمر والمتغيّر في نهايته؟
5. هل تحقّقت في حقول الاستهلاك من أن التخزين المؤقت يعمل؟
6. هل ألصق مستنداً كاملاً بينما يكفي البحث؟
7. قبل جلسة طويلة، هل خطّطت لملف حالة؟
8. بعد الضغط، هل يتحقّق الوكيل في الملفات؟
9. هل ملاحظات مشروعي صحيحة وخالية من الأسرار؟
10. هل اختبرت ملخّصي أو نظام RAG بأسئلة أعرف أجوبتها؟

الأسئلة الشائعة

هل تحلّ نافذة سياق أكبر المشكلة؟

لا. إنها تؤخّر الحدّ، لكن الأبحاث تُظهر أن النماذج تستفيد أقل من المعلومات المغمورة في سياق طويل، خاصة في وسطه. النافذة الكبيرة مفيدة للحالات التي تتطلّبها، لا كذريعة لعدم تنظيم السياق.

هل يغيّر التخزين المؤقت جواب النموذج؟

لا. إنه يتفادى فقط إعادة معالجة بداية أمر مطابقة. يتلقّى النموذج المحتوى نفسه، ولا يتغيّر إلا الكلفة والمدة.

هل أحتاج إلى RAG لموقع صغير أو أسئلة شائعة قليلة؟

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

كيف أعرف إن كان وكيلي قد فقد معلومات بعد الضغط؟

اطرح عليه أسئلة دقيقة عن القرارات والفوارق المهمة في المشروع، وقارن بملاحظاتك. والأفضل: قبل الضغط، اجعله يكتب حالة العمل في ملف، واطلب منه الرجوع إليه.

هل HCS جاهز للاستعمال في الإنتاج؟

ليس بعد. التحقّق دون ذكاء اصطناعي وخادم MCP مختبَران، لكن وظائف البناء والقياس لم يُتحقَّق منها بعد على نماذج حقيقية. إنه مشروع تجريبي يُجرَّب عن دراية.

هل تتأثّر النماذج المحلية الصغيرة أكثر بالسياق الطويل؟

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

هل تحسين السياق مسألة كلفة فقط؟

لا. الكلفة هي الأوضح، لكن المكسب الأهم غالباً هو الجودة: السياق النظيف يقلّل الالتباس والنسيان والأجوبة المختلَقة.

---

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