كنا نعتقد سابقًا أن بناء أنظمة ذكاء اصطناعي أفضل يعتمد بشكل أساسي على كتابة أفضل Prompt ممكن.
ربما سمعت من قبل عن هندسة الأوامر (Prompt Engineering).
لكن مع تطور نماذج اللغة الكبيرة (Large Language Models - LLMs) ووكلاء الذكاء الاصطناعي (AI Agents)، بدأنا ننتقل تدريجيًا من Prompt Engineering إلى مفهوم آخر يُسمى Context Engineering.
دعونا نعرّف هذا المصطلح.
Context Engineering هي عملية تنظيم وتحسين المعلومات التي يتم تمريرها عمدًا إلى LLM أو AI Agent، بهدف الحصول على مخرجات أكثر دقة وارتباطًا بالمهمة.
ولنربط هذا بالطريقة التي نعمل بها نحن البشر.
هل شعرت يومًا بالإرهاق عندما تحاول القيام بعدة مهام في الوقت نفسه، وانتهى بك الأمر بإنجاز أقل مما كنت تتوقع؟
تشير الأبحاث الحديثة إلى أننا قادرون على الاحتفاظ ومعالجة حوالي 3 إلى 5 معلومات فقط لمدة تقارب 20 ثانية في المرة الواحدة.
هذه هي الذاكرة العاملة (Working Memory) لدينا، ولهذا فإن الحمل المعرفي الزائد (Cognitive Overload) الذي نشعر به أحيانًا عند القيام بعدة مهام في الوقت نفسه أمر منطقي.
ولتقليل هذا الحمل، نميل إلى تقسيم المعلومات إلى أجزاء (Chunking) وإنشاء مهام فرعية (Subtasks) أصغر.
وهذا يشبه إلى حد كبير الطريقة التي تتعامل بها نماذج الذكاء الاصطناعي مع كميات كبيرة من المعلومات.
في هذا الفيديو، سنشرح ما هي Context Engineering، وما الذي يجعل السياق جيدًا، ولماذا هو مهم، بالإضافة إلى مثال عملي.
Prompt Engineering تدور حول سؤال:
كيف أصيغ التعليمات للحصول على النتيجة التي أريدها من LLM؟
أما Context Engineering فتركز على بيئة المعلومات الكاملة (Information Environment) التي يتم تقديمها للنموذج.
لذلك، يمكن اعتبار Prompt Engineering مجرد جزء واحد من Context Engineering.
وهذا الفرق يصبح مهمًا جدًا عند بناء AI Agents، لأن الوكيل لا يجيب عن سؤال واحد فقط.
بل يقوم بعملية استدلال (Reasoning) عبر عدة خطوات.
ويستخدم الأدوات (Tools).
ويقوم بـاسترجاع المعلومات (Information Retrieval).
ويحدّث الذاكرة (Memory) لاتخاذ القرارات.
وكما أن Working Memory لدينا محدودة، فإن Context الخاص بنموذج الذكاء الاصطناعي محدود أيضًا.
قد تتساءل:
أليست النماذج الحديثة تدعم الآن نوافذ سياق ضخمة (Large Context Windows)؟
أعني، مع أكثر من 2 Million Tokens، هل نحتاج فعلًا إلى أن نكون حريصين بشأن المعلومات التي نقدمها للنموذج وكميتها؟
الحقيقة أن المزيد من Context لا يعني بالضرورة أداءً أفضل.
بل في الواقع، قد ينخفض الأداء كلما زاد حجم الـContext.
ويطلق الباحثون أحيانًا على هذه الظاهرة اسم Context Rot.
فوجود كمية كبيرة من المعلومات غير ذات الصلة، أو البيانات غير المنظمة، أو المعلومات الناقصة، يمكن أن يؤدي إلى ضعف الاستدلال (Poor Reasoning) وزيادة الهلوسة (Hallucinations).
تخيل الأمر بهذه الطريقة:
إذا أعطيتك صفحة واحدة تحتوي على تعليمات واضحة لمهمة عشوائية، مثل تهيئة موظف جديد للعمل (Onboarding a New Coworker)، فمن المحتمل أن تفهم المطلوب بسرعة وسهولة.
لكن تخيل أنني أعطيتك بدلًا من ذلك 4000 صفحة من رسائل Slack ورسائل البريد الإلكتروني والملاحظات العشوائية.
ستجد صعوبة في معرفة ما هو مهم فعلًا بالنسبة للمهمة، ومن أين يجب أن تبدأ.
ولهذا السبب تحديدًا Context Engineering مهمة.
فالهدف ليس إعطاء النموذج المزيد من المعلومات، وإنما إعطاؤه المعلومات الصحيحة بالتنسيق الصحيح (The Right Information in the Right Format).
Context هو كل ما يراه النموذج أثناء Inference Time.
وبالنسبة إلى LLM، يتضمن الـContext:
- System Prompt
- User Query
أي مستندات أو معلومات يتم استرجاعها من مصادر خارجية، مثل Vector Database أو Document Store.
سجل التفاعلات والردود السابقة بين الـLLM والمستخدم.
مخرجات الأنظمة الإضافية مثل Tool Outputs وAPIs أو Other Agents.
حسنًا، هذه كمية كبيرة من المعلومات التي يجب تقديمها إلى الـAgent.
فكيف يبدو Good Context؟
هناك عدة خصائص أساسية.
أولًا: Relevance — الصلة بالمهمة
يجب أن تساعد كل معلومة يتم تضمينها النموذج على إتمام المهمة.
ثانيًا: Structure — التنظيم
يجب تنظيم المعلومات بشكل واضح، وغالبًا باستخدام Labels أو Formatting يساعد النموذج على التمييز بين أنواع المعلومات المختلفة.
ثالثًا: Timing — التوقيت
خصوصًا في Agentic Systems، يجب تقديم الـContext عندما تكون هناك حاجة إليه فقط.
رابعًا: Compression — ضغط المعلومات
فبدلًا من إغراق الـPrompt بالبيانات الخام، نقوم غالبًا بتلخيص المعلومات أو تصفيتها والاحتفاظ فقط بالتفاصيل الأكثر فائدة.
هذه الخطوات تساعد على إنتاج Usable Context، ويُطلق على هذه العملية اسم Context Processing.
Context Management
بعد ذلك تأتي الخطوة التالية، وهي Context Management.
وهي العملية المستمرة للحفاظ على المعلومات الموجودة في Model Context وإدارتها عبر التفاعلات ومع مرور الوقت.
ومن الأفكار الأساسية هنا تحديد ما الذي يجب الاحتفاظ به وما الذي يجب التخلص منه (Retain vs. Discard)، بحيث تظل المعلومات المهمة موجودة، بينما تتم إزالة المعلومات غير الضرورية أو القديمة أو تقليلها.
هناك أيضًا ضرورة للحفاظ على Continuity عبر التفاعلات المتعددة.
في Conversational Systems، يعني ذلك تتبع مدخلات المستخدم المهمة، وSystem Instructions، والردود السابقة، حتى يتمكن النموذج من تقديم إجابات متسقة ومدركة للسياق.
كما يجب علينا Prioritize Information.
فليست كل المعلومات متساوية في الأهمية.
لذلك تقوم Context Management بتحديد أولوية بعض البيانات بناءً على:
- Relevance
- Recency
- Task Importance
الخطوة التالية هي التعامل مع Information Life Cycle.
وهذا يعني تحديث الـContext عند توفر معلومات جديدة، وInvalidating Outdated Data، والتأكد من أن السياق يعكس أحدث وأدق حالة للمعرفة.
وهذا مهم بشكل خاص في Dynamic Environments التي تتغير فيها المعلومات بمرور الوقت.
وأخيرًا، من الضروري الحفاظ على Consistency and Coherence، بحيث يتم دمج المعلومات المسترجعة بطريقة صحيحة، ويظل الـOverall Context منطقيًا ومفهومًا.
مثال عملي على Context Engineering
دعونا نلقي نظرة على مثال واقعي لـContext Engineering أثناء العمل.
تخيل أنك تبني AI Assistant لصالح أحد مقدمي خدمات الرعاية الصحية، وتتمثل مهمته في مساعدة المرضى على Schedule Appointments.
في الخلفية، يعتمد هذا النظام على Multiple Data Sources وConstraints مختلفة وTool Outputs من أجل اتخاذ القرارات.
من دون هذه العناصر، قد يكون الـPrompt بسيطًا جدًا، مثل:
- Schedule an appointment for this patient.
هذا هو User Prompt.
لكن هذا الطلب يترك مساحة كبيرة جدًا للخطأ.
فالنموذج لا يعرف، على سبيل المثال، Clinic's Rules.
ولا يعرف Doctor's Availability.
ولا يعرف حتى Patient's Medical History.
والآن دعونا نضيف Context Engineering.
بدلًا من مجرد إرسال Prompt، يقوم النظام بتزويد النموذج بـClinic's Scheduling Policies، مثل Appointment Types وAppointment Durations.
ويقدم له أيضًا Doctor's Real-Time Availability.
بالإضافة إلى Patient Preferences، مثل تفضيله للمواعيد الصباحية فقط.
وكذلك Medical History إذا كان ذا صلة بالزيارة.
بل وحتى Tool Outputs، مثل مواعيد الحجز المتاحة التي يتم الحصول عليها من خلال Scheduling API.
والآن، عندما يقوم النموذج بإنشاء الرد، فهو لا يخمّن.
بل يقوم بـReasoning اعتمادًا على Complete Structured Context.
فبدلًا من أن يقول:
- Here are some available slots.
يمكنه أن يقول:
"You're due for a follow-up visit, and Dr. So-and-so is available on Wednesday at 10 a.m., which matches your preference for morning appointments. Would you like me to book that?"
أفضل بكثير، أليس كذلك؟
إذًا...
سواء كنت تبني AI Agents، أو تجرب Workflows مختلفة، أو تحاول فقط فهم الاتجاه الذي يتجه إليه هذا المجال، فإن Context Engineering أصبحت واحدة من أهم المهارات التي يجب فهمها.
