هندسة السياق
تتعلق هندسة المطالبات بالكلمات التي تختارها. أما هندسة السياق فتتعلق بـمساحة العمل التي تسلّمها للنموذج — ما الموجود فيها، وبأي ترتيب، وما الذي تركته خارجها عن قصد.
يهم هذا التمييز لأن نافذة السياق ليست دفتر ملاحظات. إنها مورد انتباهي محدود ومكلف. تغيّر طريقة ملئها ما يركّز عليه النموذج، وكم يكلفك ذلك، وما إذا كان سيبقى مفيدًا مع نمو الجلسات.
- ميّز هندسة السياق عن هندسة المطالبات — واعرف لماذا تحوّل المجال
- تعامل مع نافذة السياق كميزانية انتباه، لا كصندوق تخزين
- اكتشف تعفّن السياق وظاهرة الضياع في المنتصف قبل أن يفسدا جلسة طويلة
- ضع التعليمات حيث يقع الانتباه فعليًا — في الأعلى، وفي النهاية، ولا تدفنها في المنتصف أبدًا
- طبّق التكتيكات الثلاثة الأساسية: الضغط، وتدوين الملاحظات، والاسترجاع في الوقت المناسب
ميزانية السياق
لكل نموذج حجم سياق أقصى — سقف صارم يُقاس بالرموز. فكّر فيه كميزانية. تنفقها على:
- مطالبة النظام والتعليمات الثابتة لديك
- المستندات المسترجعة، ومقتطفات قاعدة الشيفرة، وتعريفات الأدوات
- سجل المحادثة
- مخرجات النموذج (التي تُحتسب أيضًا ضمن النافذة في الجلسات متعددة الأدوار)
عندما تنفد، لا بد أن يتنازل شيء ما. فإما أن يُسقَط محتوى قديم، أو تصطدم الجلسة بحائط.
تتعامل معظم الأدلة المبتدئة مع نافذة السياق على أساس أن "الأكثر أفضل." أما هندسة السياق فتتعامل معها كمورد يجب تخصيصه بعناية: أنفقها على ما يحتاجه النموذج فعليًا لهذه الدورة، لا على كل ما قد يكون ذا صلة. تؤطّر Anthropic المجال بأكمله كبحث عن "أصغر مجموعة ممكنة من الرموز عالية الإشارة" — فكل رمز تضيفه يتنافس على ميزانية انتباه محدودة، وهو نتيجة مباشرة لكيفية ربط المحوّل (transformer) كل رمز بكل رمز آخر.
تعفّن السياق وظاهرة "الضياع في المنتصف"
هناك ظاهرة موثّقة جيدًا في نماذج LLM ذات السياق الطويل: تولي النماذج انتباهًا غير متناسب للمحتوى القريب من بداية سياقها ونهايته، بينما يتدهور استرجاعها للمحتوى المدفون في المنتصف. أطلق الباحثون الذين درسوا هذا التأثير عليه اسم "الضياع في المنتصف."
والنتيجة العملية: إذا حشوت سياقًا من 100,000 رمز بالمستندات ودفنت أهم تعليمة عند الموضع 60,000، فقد يتجاهلها النموذج فعليًا — ليس لأنه عاجز عن القراءة إلى هذا الحد، بل لأن الانتباه ليس موزعًا بالتساوي عبر النافذة.
أما "تعفّن السياق" فهو النمط الأوسع: مع نمو الجلسة، تميل جودة الردود إلى الانحراف. تُخفَّف التعليمات المبكرة. ويزاحم الأخذ والرد المتكرر المهمة الأصلية. ويبدأ النموذج في التحفظ، أو تكرار نفسه، أو فقدان خيط ما طلبته فعليًا.
ليست هذه أخطاء يمكنك إصلاحها بالكامل بمطالبة أفضل. إنها خصائص بنيوية لكيفية عمل الانتباه على نطاق واسع. والاستجابة الهندسية هي إبقاء السياق أصغر وأكثر حدة، لا ملؤه والأمل في الأفضل.
الترتيب يهم
أين تضع المحتوى لا يقل أهمية عمّا تُدرجه. الممارسة الجيدة الراسخة:
| الموضع | ما يجب وضعه هناك |
|---|---|
| الأعلى تمامًا (مطالبة النظام) | تعليمات مستقرة ودائمة. الشخصية، القواعد، متطلبات التنسيق. |
| بعد مطالبة النظام | المهمة الحالية، بعبارات واضحة. |
| قبيل آخر دورة للمستخدم | السياق الأكثر أهمية وتحديدًا لهذا الطلب بالذات. |
| المنتصف | المستندات الداعمة، والمقاطع المسترجعة — مرتبة حسب الصلة، لا حسب التسلسل الزمني. |
| سجل المحادثة | فقط ما هو ضروري للاستمرارية. قلّمه بقوة. |
القاعدة العامة: كلما اقترب المحتوى من الدورة الحالية، حصل على انتباه أكبر. التعليمات الحرجة التي تعيش في منتصف سجل طويل فقط معرّضة للخطر.
"الارتفاع الصحيح" للتعليمات
يمكن أن تفشل مطالبة النظام بطريقتين متعاكستين. فإن كانت منخفضة جدًا، رمّزت منطقًا هشًا من نوع "إذا حدث هذا فافعل ذاك" ينكسر لحظة اختلاف الواقع. وإن كانت عالية جدًا، كتبت توجيهًا مبهمًا يفترض سياقًا لا يملكه النموذج. تسمي Anthropic الهدف "الارتفاع الصحيح" — منطقة المثالية التي هي "محددة بما يكفي لتوجيه السلوك بفعالية، ومرنة بما يكفي لتوفير استدلالات قوية." اِستهدف ذلك: قواعد وأمثلة ملموسة، لا شجرة قرارات، ولا مجرد انطباع.
الاسترجاع بدلًا من الحشو
الإغراء هو وضع كل شيء فيها: كل المستندات، وقاعدة الشيفرة كاملة، والمحادثة بأكملها. قاوم ذلك.
النهج الأفضل هو الاسترجاع الانتقائي: حدّد ما يحتاجه النموذج فعليًا لهذا الطلب المحدد، واحقن ذلك فقط. مقطع من 2,000 رمز جيد الاسترجاع من المستند الصحيح يتفوق على كومة من 40,000 رمز حيث تكون الإجابة في مكان ما بالمنتصف.
لهذا السبب يوجد التوليد المعزّز بالاسترجاع (RAG) — ليس فقط لتجاوز حدود السياق، بل لتحسين الجودة عبر إبقاء السياق منظمًا. النسخة الوكيلية منه هي الاسترجاع في الوقت المناسب: بدلًا من تحميل كل مستند مسبقًا، يحتفظ الوكيل بمعرّفات خفيفة (مسارات الملفات، والمعرّفات، والاستعلامات) ويسحب المحتوى الفعلي إلى السياق فقط في اللحظة التي يحتاجه فيها.
وللجلسات التفاعلية، ينطبق المنطق نفسه: بدلًا من تكديس كل شيء، اضغط أو امسح السجل دوريًا لإزالة المحتوى الذي لم يعد ذا صلة بالمهمة الحالية. إن أمري /compact و/clear في Claude Code هما أداتا هندسة سياق، لا مجرد إدارة جلسات. وعلى واجهة برمجة التطبيقات، يُؤتمت النمط نفسه عبر الذاكرة وتحرير السياق — تُقلَّم نتائج الأدوات القديمة من النافذة بينما يُكتب ما يهم إلى مخزن ذاكرة دائم.
التكتيكات الثلاثة الأساسية
للعمل طويل الأمد، تقوم ثلاث تقنيات بمعظم العبء الثقيل. وهي تتركّب — معظم الوكلاء الحقيقيين يستخدمون الثلاثة جميعًا.
- عندما تقترب الجلسة من حد النافذة، لخّصها وأعد تهيئتها بالنسخة المقطّرة. احفظ التفاصيل الحاملة — القرارات المعمارية، والأخطاء غير المحلولة، وخيارات التنفيذ الأساسية — وأسقط السرد اللحظي. هذا ما يفعله /compact في Claude Code.
- اجعل الوكيل يكتب الحقائق الدائمة إلى ذاكرة خارجية (ملف، أو ورقة شطب، أو CLAUDE.md) ويعيد قراءتها لاحقًا. يمنح هذا ذاكرة دائمة بأقل عبء داخل النافذة — تعيش الملاحظات خارج الميزانية حتى الحاجة إليها.
- لا تحشُ كل مستند مسبقًا. احتفظ بمراجع خفيفة وحمّل المحتوى الفعلي وقت التشغيل، فقط للخطوة التي تحتاجه. سحب موجّه من 2,000 رمز يتغلب على كومة من 40,000 رمز.
زاوية التكلفة
الرموز التي ترسلها هي رموز تدفع ثمنها — مالًا وزمن استجابة. حشو السياق بمادة ذات صلة فضفاضة يضخّم كليهما. هندسة السياق وكفاءة التكلفة هما المشكلة نفسها.
وبشكل أكثر تحديدًا:
- مطالبة نظام منتفخة تنسخها وتلصقها من قالب تُدفع في كل استدعاء على الإطلاق.
- سجل محادثة قديم تحمله معك لأنه "قد يكون مفيدًا" يُدفع في كل استدعاء على الإطلاق.
- مستندات تحقنها "تحسبًا" تُدفع في كل استدعاء على الإطلاق.
تقليم ما لا حاجة لوجوده أفضل للجودة وأرخص في التشغيل في آن معًا.
تكتيكات عملية لمستخدمي Claude
في Claude.ai:
- استخدم محادثات منفصلة لمهام منفصلة. لا تدع ظهيرة من الاستطرادات تلوّث سياق مشروع مركّز.
- لخّص الخيوط الطويلة قبل طرح سؤال معقّد يعتمد عليها. غالبًا ما يكون الملخص الصريح أكثر فائدة من السجل الخام.
- ضع الشيء المحدد الذي تريده في نهاية رسالة طويلة، لا مدفونًا في المنتصف.
في Claude Code:
- أبقِ ملف
CLAUDE.mdرشيقًا. فكل سطر فيه يُحقن في كل جلسة. انظر CLAUDE.md وإدارة السياق. - استخدم
/clearعند التحول إلى مهمة مختلفة حقًا. واستخدم/compactعندما تريد المتابعة لكن الجلسة تنمو. - أشِر إلى الملفات بالمسار بدلًا من لصق محتوياتها عندما لا يكون الملف الكامل ضروريًا للخطوة الحالية.
على مستوى واجهة برمجة التطبيقات:
- صمّم مطالبات النظام لتحتوي فقط على ما يحتاجه كل طلب حقًا. انقل التعليمات الخاصة بالمهمة إلى دورة المستخدم.
- لحالات الاستخدام كثيفة المستندات، استرجع واحقن المقاطع ذات الصلة بدلًا من رفع متن كامل.
- هيكِل المطالبة بحيث تأتي البادئة المستقرة وقابلة لإعادة الاستخدام أولًا — وهذا يتيح أيضًا تخزين المطالبات مؤقتًا (prompt caching)، وهو رفيق طبيعي لهندسة السياق.
عندما تريد تسليم مستند طويل إلى Claude، تتغلب قاعدة الموضع على الحجم الخام في كل مرة:
التعليمات أولًا، مع إعادة ذكرها أخيرًا
المهمة: ابحث عن كل بند يحدّ فيه هذا العقد من مسؤوليتنا، واقتبس كل واحد منها حرفيًا مع رقم قسمه. [... الصق العقد الكامل المؤلف من 40 صفحة هنا ...] تذكير بالمهمة: اسرد كل بند يحدّ المسؤولية أعلاه، مقتبسًا تمامًا، مع أرقام الأقسام. وإن لم يوجد أي منها، فاذكر ذلك صراحةً.
تجلس التعليمة نفسها في الأعلى وفي الأسفل — الموضعان اللذان يفضّلهما الانتباه — فتنجو حتى من منتصف طويل جدًا.
التحول في العقلية
تسأل هندسة المطالبات: "ماذا ينبغي أن أقول؟" وتسأل هندسة السياق: "ماذا ينبغي أن يرى النموذج، وبأي ترتيب، وما الذي ينبغي أن أُبقيه خارجًا عن قصد؟"
السؤال الثاني أصعب، لكنه هو الذي يحدد فعليًا الجودة على نطاق واسع.
Check yourself
0/3- نافذة السياق ميزانية انتباه، لا تخزين — أنفقها على الرموز عالية الإشارة فقط.
- الموضع يتغلب على الحجم: التعليمات الحرجة تذهب إلى الأعلى وقبيل الدورة الأخيرة، ولا تُدفن في المنتصف أبدًا.
- الضغط، وتدوين الملاحظات، والاسترجاع في الوقت المناسب هي التكتيكات الثلاثة التي تُبقي الوكلاء طويلي الأمد متماسكين.
- تنظيم السياق هو نفس رافعة خفض التكلفة — رموز أقل، إجابات أفضل، فاتورة أدنى.