هندسة السياق بدل هندسة البرومبت في أنظمة الذكاء الاصطناعي الحديثة

عندما بدأت تطبيقات الذكاء الاصطناعي التوليدي بالانتشار، كان التركيز الأكبر على سؤال بسيط: كيف نكتب Prompt أفضل؟

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

لكن عند الانتقال من محادثة تجريبية إلى نظام حقيقي يعتمد على بيانات متغيرة، ومستخدمين متعددين، وصلاحيات مختلفة، ووثائق داخلية، وأدوات خارجية، يصبح تحسين صياغة الـ Prompt وحده غير كافٍ.

المشكلة لم تعد:

كيف أكتب تعليمات أكثر ذكاءً؟

بل أصبحت:

ما المعلومات التي يجب أن يعرفها النموذج الآن؟ وما المعلومات التي يجب استبعادها؟ وما المصادر التي يمكن الوثوق بها؟ وما الأدوات التي يستطيع استخدامها؟ وما الحدود التي لا يجوز له تجاوزها؟

هنا يظهر مفهوم هندسة السياق Context Engineering.

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

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

---

لماذا لم تعد هندسة البرومبت وحدها كافية؟

يمكن للـ Prompt أن يوضح للنموذج ما تريد منه القيام به، لكنه لا يضمن أن يمتلك المعلومات الصحيحة لتنفيذ المهمة.

تخيل نظام دعم فني يعتمد على نموذج لغوي. قد تكتب تعليمات ممتازة مثل:

أنت مهندس دعم تقني خبير. أجب بدقة، ولا تخمّن، واعتمد على الوثائق الرسمية فقط.

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

يمكن أن يكون الـ Prompt ممتازًا، ومع ذلك تكون النتيجة ضعيفة بسبب:

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

لهذا فإن جودة النظام لا تعتمد على جودة التعليمات فقط، بل على جودة المعلومات والقيود التي تحيط بالتعليمات.

---

ما الفرق بين Prompt Engineering وContext Engineering؟

من المفيد النظر إلى الفرق بهذه الطريقة:

الـ Prompt هو جزء من السياق، لكنه ليس السياق كله.

يمكن تبسيط الصورة كالتالي:

السياق النهائي المرسل إلى النموذج
│
├── تعليمات النظام
├── قواعد المنتج
├── طلب المستخدم
├── حالة المستخدم الحالية
├── المعلومات المسترجعة
├── الذاكرة ذات الصلة
├── نتائج الأدوات
├── الصلاحيات والقيود
└── تنسيق النتيجة المطلوبة

كل عنصر من هذه العناصر قد يؤثر في جودة الإجابة.

---

ما هي هندسة السياق؟

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

المهم هنا هو كلمة اختيار.

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

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

يجب أن تجيب قبل كل طلب عن أسئلة مثل:

1. ما المهمة الفعلية؟
2. ما المعلومات الضرورية لهذه المهمة؟
3. ما مصدر كل معلومة؟
4. هل المعلومات حديثة؟
5. هل يملك المستخدم صلاحية الوصول إليها؟
6. هل توجد معلومات متعارضة؟
7. ما الذي يمكن حذفه دون التأثير في الجودة؟
8. هل يحتاج النموذج إلى أداة أم إلى معلومات فقط؟
9. كيف سنعرف أن السياق أدى إلى نتيجة جيدة؟

---

مكونات السياق في أنظمة LLM الحديثة

السياق القوي لا يتكون من مصدر واحد. غالبًا ما يكون نتيجة دمج عدة طبقات.

1. تعليمات النظام System Instructions

هذه هي القواعد الثابتة التي تحدد دور النظام وحدوده وسلوكه العام.

قد تتضمن:

• الهدف الأساسي للتطبيق.
• نوع الإجابات المطلوبة.
• أسلوب الكتابة.
• قواعد التعامل مع المعلومات غير المؤكدة.
• الحالات التي يجب فيها رفض الطلب.
• متى يجب طلب توضيح.
• متى يجب استخدام أداة.
• كيفية عرض المصادر.

مثال مبسط:

أنت مساعد دعم فني.

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

لكن تعليمات النظام ليست بديلًا عن الحماية البرمجية.

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

لا تحذف البيانات إلا بعد موافقة المستخدم.

يجب أن تكون أداة الحذف نفسها محمية بصلاحيات وقواعد تحقق مستقلة.

---

2. طلب المستخدم User Request

طلب المستخدم هو نقطة البداية، لكنه قد يكون ناقصًا أو غامضًا.

على سبيل المثال:

لماذا فشل النشر؟

هذه الجملة لا تحتوي على معلومات كافية لمعرفة:

• أي مشروع يقصد المستخدم؟
• هل النشر على Vercel أو Cloudflare أو منصة أخرى؟
• ما رسالة الخطأ؟
• هل المشكلة في Build أو Environment Variables أو Runtime؟
• هل الخطأ حدث في الإنتاج أم في Preview؟

بدل إرسال السؤال وحده إلى النموذج، قد يحتاج النظام إلى إضافة:

• هوية المشروع.
• آخر سجل بناء.
• البيئة المستخدمة.
• التغييرات الأخيرة.
• حالة النشر.
• الوثائق ذات الصلة.

وهنا يتحول الطلب القصير إلى سياق عملي قابل للتحليل.

---

3. المعلومات المسترجعة Retrieval

الاسترجاع هو عملية البحث عن المعلومات الأكثر ارتباطًا بالسؤال ثم إضافتها إلى السياق.

يستخدم عادة في أنظمة RAG — Retrieval-Augmented Generation.

مثال:

يسأل المستخدم:

كيف أغيّر إعدادات التخزين في النظام؟

قد يقوم النظام بالخطوات التالية:

1. تحليل السؤال.
2. تحديد المؤسسة أو المشروع.
3. البحث داخل الوثائق المصرح بها.
4. استرجاع أفضل خمس فقرات.
5. إعادة ترتيب النتائج.
6. حذف النتائج الضعيفة.
7. إرسال المعلومات المختارة إلى النموذج.

مثال مبسط:

const documents = await retrieveRelevantDocs({
  query: userMessage,
  tenantId: session.tenantId,
  limit: 10
});

const rankedDocuments = await rerankDocuments({
  query: userMessage,
  documents,
  limit: 5
});

الاسترجاع الجيد لا يعني الحصول على أكبر عدد من الوثائق، بل الحصول على الوثائق الأكثر صلة.

---

4. الذاكرة Memory

الذاكرة تختلف عن الاسترجاع.

الاسترجاع يبحث عادة في قاعدة معرفة أو مجموعة وثائق، بينما الذاكرة تحفظ معلومات أو تفضيلات أو قرارات سابقة مرتبطة بالمستخدم أو الجلسة.

قد تشمل الذاكرة:

• لغة المستخدم المفضلة.
• إعدادات المشروع.
• قرارات سابقة.
• معلومات متكررة يحتاجها النظام.
• ملخص المحادثة.
• حالة مهمة لم تكتمل.

لكن الاحتفاظ بتاريخ المحادثة كاملًا ليس دائمًا أفضل طريقة لبناء الذاكرة.

إذا أرسلت جميع الرسائل السابقة مع كل طلب، فقد تواجه:

• ارتفاع التكلفة.
• زيادة زمن الاستجابة.
• إدخال معلومات قديمة لم تعد مهمة.
• تضارب بين قرارات قديمة وحديثة.
• صعوبة معرفة ما الذي أثّر في الإجابة.

لذلك يفضل غالبًا استخدام ذاكرة منتقاة ومختصرة.

مثال:

const memory = {
  preferredLanguage: "ar",
  currentProject: "documentation-platform",
  recentDecision: "Use PostgreSQL for production",
  activeTask: "Improve retrieval quality"
};

---

5. حالة التطبيق Application State

بعض المعلومات لا تنتمي إلى الذاكرة ولا إلى قاعدة المعرفة، لكنها ضرورية لفهم الوضع الحالي.

مثل:

• حالة الطلب.
• المرحلة الحالية من Workflow.
• رقم المشروع.
• نوع الاشتراك.
• البيئة الحالية.
• نتائج عملية سابقة.
• حالة الموافقة البشرية.

مثال:

const applicationState = {
  deploymentStatus: "failed",
  environment: "production",
  buildNumber: 184,
  lastSuccessfulBuild: 183
};

هذه المعلومات قد تكون أكثر أهمية من تاريخ محادثة طويل.

---

6. الأدوات Tool Calls

في بعض الحالات لا يحتاج النموذج إلى مزيد من النصوص، بل يحتاج إلى تنفيذ عملية أو الحصول على بيانات حديثة.

مثل:

• البحث في الوثائق.
• قراءة سجل بناء.
• فحص حالة خدمة.
• البحث في قاعدة بيانات.
• إنشاء تقرير.
• إرسال طلب موافقة.
• تنفيذ إجراء محدود.

الأداة جزء من السياق لأنها توسع ما يستطيع النظام معرفته أو فعله.

لكن منح النموذج أدوات كثيرة دون حدود قد يخلق مخاطر تشغيلية. لذلك يجب تحديد:

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

للمزيد حول بناء وكلاء الذكاء الاصطناعي بحدود واضحة، راجع:

دليل نشر AI Agents في بيئات الإنتاج بدون كوارث تشغيلية

---

هل RAG هو نفسه Context Engineering؟

لا.

RAG جزء مهم من هندسة السياق، لكنه ليس النظام كاملًا.

يمكن النظر إلى العلاقة هكذا:

Context Engineering
│
├── System Instructions
├── User Request
├── RAG / Retrieval
├── Memory
├── Application State
├── Tools
├── Permissions
├── Context Compression
├── Token Budget
└── Evaluation

RAG يحل مشكلة مهمة:

كيف نحصل على معلومات خارج معرفة النموذج ونضيفها إلى السياق؟

لكنه لا يحل وحده مشكلات مثل:

• من يملك حق الوصول إلى المعلومات؟
• هل يجب استخدام أداة؟
• ما المعلومات التي يجب الاحتفاظ بها في الذاكرة؟
• كيف نتعامل مع المعلومات المتعارضة؟
• كيف نحد من تكلفة السياق؟
• كيف نقيس جودة النتائج؟
• ماذا نفعل إذا لم نجد إجابة؟

لذلك فإن بناء نظام RAG لا يعني تلقائيًا أنك بنيت نظام Context Engineering جيدًا.

---

المشكلة: لماذا تفشل أنظمة LLM بسبب ضعف السياق؟

تحسين الـ Prompt وحده لا يكفي عندما يعتمد النظام على بيانات متغيرة، وصلاحيات مختلفة، وأدوات خارجية.

المشكلة ليست في صياغة الجملة فقط، بل في ما يعرفه النموذج لحظة الإجابة.

بدون هندسة سياق جيدة قد تظهر مشكلات مثل:

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

⚠️ تنبيه تقني: لا تعتمد على النموذج ليحترم الصلاحيات وحده. يجب تطبيق فلترة الصلاحيات داخل طبقة التطبيق قبل الاسترجاع وقبل تنفيذ Tool Calls.

---

كيف تبني سياقًا قويًا خطوة بخطوة؟

الخطوة الأولى: حدد المهمة بدقة

لا تبدأ من السؤال:

ما أفضل Prompt؟

ابدأ من:

ما القرار أو النتيجة التي يجب أن ينتجها النظام؟

مثال ضعيف:

أجب عن أسئلة العملاء.

مثال أوضح:

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

كلما كانت المهمة أوضح، أصبح من السهل تحديد المعلومات المطلوبة.

---

الخطوة الثانية: حدد مصادر السياق

لكل مهمة، اكتب مصادر المعلومات التي يمكن استخدامها.

مثال:

هذا يمنع الاعتماد على مصدر واحد لكل شيء.

---

الخطوة الثالثة: طبق الصلاحيات قبل الاسترجاع

يجب ألا تسترجع بيانات غير مصرح بها ثم تطلب من النموذج تجاهلها.

الترتيب الصحيح:

هوية المستخدم
↓
التحقق من المؤسسة والصلاحيات
↓
تقييد نطاق البحث
↓
استرجاع الوثائق المسموح بها
↓
إرسال النتائج إلى النموذج

مثال:

const allowedDocumentIds = await getAllowedDocuments({
  userId: session.userId,
  tenantId: session.tenantId
});

const documents = await retrieveRelevantDocs({
  query: userMessage,
  allowedDocumentIds,
  limit: 8
});

لا تجعل النموذج مسؤولًا عن الفصل بين بيانات المستخدمين.

---

الخطوة الرابعة: استرجع المعلومات ذات الصلة فقط

قد تعثر عملية البحث على عشرات الوثائق، لكن هذا لا يعني إرسالها كلها.

استخدم مراحل مثل:

1. البحث الأولي.
2. الفلترة حسب الصلاحيات.
3. حذف الوثائق القديمة أو غير المناسبة.
4. إعادة الترتيب Reranking.
5. اختيار عدد محدود من النتائج.
6. ضغط النصوص الطويلة عند الحاجة.

مثال:

const candidates = await retrieveRelevantDocs({
  query: userMessage,
  tenantId: session.tenantId,
  limit: 20
});

const relevantDocuments = await rerankDocuments({
  query: userMessage,
  documents: candidates,
  limit: 5
});

الهدف هو زيادة صلة السياق وليس زيادة حجمه.

---

الخطوة الخامسة: أضف مصدر كل معلومة

إذا كانت الإجابة تعتمد على وثائق، فاحتفظ بمعرف المصدر ووقت تحديثه.

مثال:

const contextItems = relevantDocuments.map((document) => ({
  id: document.id,
  title: document.title,
  updatedAt: document.updatedAt,
  content: document.content
}));

يمكن استخدام هذه البيانات من أجل:

• عرض المصادر للمستخدم.
• مراجعة سبب الإجابة.
• اكتشاف الوثائق القديمة.
• تحليل جودة الاسترجاع.
• إعادة إنتاج الخطأ لاحقًا.

---

الخطوة السادسة: ضع ميزانية للسياق

كل نموذج يمتلك حدًا للسياق، لكن الوصول إلى الحد الأقصى لا يعني أن عليك استخدامه.

ضع ميزانية لكل نوع من المعلومات:

يمكنك تطبيق حد تقريبي:

const contextBudget = {
  systemInstructions: 1500,
  memory: 1000,
  retrievedDocuments: 7000,
  toolResults: 3000,
  responseReserve: 2500
};

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

---

الخطوة السابعة: اضغط السياق بدل حذفه عشوائيًا

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

يمكنك:

• استخراج الفقرات المرتبطة بالسؤال.
• تلخيص الأجزاء القديمة.
• الاحتفاظ بالقرارات النهائية فقط.
• إزالة التكرار.
• استبدال تاريخ المحادثة بملخص منظم.

مثال:

ملخص الحالة:

- المشروع يستخدم Next.js.
- المشكلة بدأت بعد تغيير إعدادات Cache.
- آخر نشر ناجح كان قبل التعديل.
- تم استبعاد مشكلة Environment Variables.
- المطلوب الآن تحليل سبب فشل إعادة التحقق.

هذا أكثر فائدة من إرسال عشرات الرسائل القديمة.

---

مثال عملي: بناء سياق لتطبيق دعم فني

لنفترض أن المستخدم كتب:

التطبيق لا يرسل رسائل البريد بعد آخر تحديث.

يمكن للنظام بناء السياق كالتالي:

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

طلب المستخدم:
- التطبيق لا يرسل رسائل البريد بعد آخر تحديث.

حالة الحساب:
- الخطة: Business.
- المؤسسة: tenant-42.
- البيئة: Production.

المعلومات المسترجعة:
- وثائق إعداد البريد للإصدار الحالي.
- سجل التغييرات الأخير.
- دليل تشخيص أخطاء SMTP.

نتائج الأدوات:
- آخر محاولة إرسال فشلت برمز 535.
- خدمة البريد متاحة.
- بيانات الاعتماد غير صالحة.

الصلاحيات:
- المستخدم يستطيع عرض السجلات.
- لا يستطيع تعديل إعدادات البريد.

النتيجة المطلوبة:
- شرح السبب المحتمل.
- خطوات تشخيص.
- عدم تنفيذ أي تغيير تلقائي.

لاحظ أن جودة الإجابة لا تأتي من Prompt واحد طويل، بل من تجميع معلومات صحيحة ومحددة.

---

لا ترسل تاريخ المحادثة كاملًا مع كل طلب

من أكثر الأخطاء شيوعًا إرسال جميع الرسائل السابقة إلى النموذج.

قد يبدو هذا حلًا سهلًا، لكنه يؤدي إلى:

• زيادة عدد الرموز Tokens.
• ارتفاع التكلفة.
• بطء الاستجابة.
• إدخال تعليمات قديمة.
• تضارب المعلومات.
• صعوبة معرفة ما هو مهم.

بدلًا من ذلك، استخدم استراتيجية مثل:

السياق الحالي:
- الهدف النشط.
- القرار الأخير.
- القيود المهمة.
- حالة المهمة.
- آخر رسالتين أو ثلاث رسائل ذات صلة.

مثال برمجي:

const recentMessages = messages.slice(-4);

const conversationSummary = await getConversationSummary({
  conversationId,
  maxTokens: 800
});

const context = {
  summary: conversationSummary,
  recentMessages
};

---

الذاكرة ليست سجل محادثة

هناك فرق بين:

History

و:

Memory

سجل المحادثة يحفظ ما قيل، بينما الذاكرة تحفظ ما يجب أن يستمر تأثيره.

مثال:

سجل محادثة

المستخدم: أستخدم Next.js.
المساعد: ما الإصدار؟
المستخدم: الإصدار 15.
المساعد: هل تستخدم App Router؟
المستخدم: نعم.

ذاكرة مفيدة

المشروع يستخدم Next.js 15 مع App Router.

الذاكرة الجيدة تكون:

• مختصرة.
• قابلة للتحديث.
• مرتبطة بالمهمة.
• قابلة للحذف.
• واضحة المصدر.

---

كيف تتعامل مع المعلومات المتعارضة؟

قد تسترجع وثيقتين تحتويان على تعليمات مختلفة.

مثلًا:

• وثيقة قديمة تقول إن الإعداد يتم من صفحة معينة.
• وثيقة حديثة تقول إن الصفحة تغيرت.

لا يجب إرسال الوثيقتين دون معلومات إضافية.

أضف بيانات مثل:

المصدر الأول:
الإصدار: 2.1
آخر تحديث: يناير 2025

المصدر الثاني:
الإصدار: 3.0
آخر تحديث: يونيو 2026

ثم ضع قاعدة:

عند وجود تعارض، أعطِ الأولوية للمصدر الأحدث والمرتبط بالإصدار الحالي، واذكر عدم اليقين إذا لم يمكن حسم التعارض.

---

متى يحتاج النظام إلى أداة بدل معلومات إضافية؟

لا تحاول حل كل شيء بإضافة نصوص إلى السياق.

إذا كان السؤال يحتاج إلى حالة حديثة، فقد تكون الأداة أفضل.

مثال:

السؤال:

هل الخدمة تعمل الآن؟

إرسال وثائق تشغيل الخدمة لن يجيب عن السؤال.

يحتاج النظام إلى:

أداة فحص الحالة
↓
نتيجة مباشرة
↓
إجابة مبنية على الحالة الحالية

قاعدة عملية:

• إذا كانت المعلومة ثابتة نسبيًا: استخدم Retrieval.
• إذا كانت المعلومة متغيرة باستمرار: استخدم أداة أو API.
• إذا كانت المعلومة مرتبطة بالمستخدم: استخدم حالة التطبيق أو قاعدة البيانات.
• إذا كانت المعلومة قرارًا سابقًا: استخدم الذاكرة.
• إذا كانت العملية حساسة: استخدم أداة محمية مع موافقة عند الحاجة.

---

هندسة السياق في AI Agents

تزداد أهمية السياق عندما يتحول النموذج من مساعد يجيب عن الأسئلة إلى Agent يستطيع استخدام أدوات وتنفيذ خطوات متعددة.

قد يحتاج Agent إلى معرفة:

• المهمة الحالية.
• الهدف النهائي.
• الخطوات المنجزة.
• الأدوات المتاحة.
• نتائج الأدوات السابقة.
• حدود الوقت.
• عدد المحاولات.
• الصلاحيات.
• متى يجب التوقف.
• متى يحتاج إلى موافقة بشرية.

إذا كانت هذه المعلومات غير منظمة، فقد تظهر مشكلات مثل:

• تكرار استدعاء الأداة نفسها.
• تنفيذ خطوة بعد تغير الحالة.
• الدخول في حلقة Retry.
• استخدام نتيجة قديمة.
• محاولة تنفيذ عملية غير مصرح بها.

لهذا يجب أن يكون السياق التشغيلي واضحًا:

const agentContext = {
  task: "analyze_deployment_failure",
  status: "running",
  completedSteps: [
    "read_build_log",
    "check_environment"
  ],
  allowedTools: [
    "readBuildLog",
    "checkDeploymentStatus"
  ],
  maxToolCalls: 5,
  requireHumanApproval: false
};

لمزيد من التفاصيل، راجع:

دليل نشر AI Agents في بيئات الإنتاج بدون كوارث تشغيلية

---

الصلاحيات يجب أن تكون خارج النموذج

من الأخطاء الخطيرة كتابة تعليمات مثل:

لا تسمح للمستخدم بحذف البيانات إلا إذا كان مديرًا.

هذه التعليمات مفيدة لتوجيه السلوك، لكنها ليست نظام صلاحيات.

التصميم الأفضل:

طلب المستخدم
↓
التحقق من الهوية
↓
التحقق من الصلاحية
↓
إتاحة الأداة أو رفضها
↓
إرسال المعلومات اللازمة للنموذج

مثال:

if (!session.permissions.includes("projects.delete")) {
  throw new ForbiddenError(
    "You do not have permission to delete this project."
  );
}

await deleteProject({
  projectId
});

لا تجعل النموذج هو نقطة الحماية الوحيدة.

---

كيف تقلل تكلفة السياق؟

قد تصبح تكلفة تطبيقات LLM مرتفعة بسبب:

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

لتقليل التكلفة:

استخدم الاسترجاع الانتقائي

لا ترسل جميع الوثائق، بل اختر الأكثر ارتباطًا.

اختصر الذاكرة

احتفظ بالقرارات والحالة بدل النص الكامل.

استخدم النماذج حسب المهمة

لا تحتاج كل عملية إلى النموذج الأكبر.

فعّل التخزين المؤقت

إذا تكرر السؤال أو السياق، قد يكون Cache مفيدًا.

ضع حدودًا للأدوات

حدد عدد الاستدعاءات ومدة التنفيذ.

راقب تكلفة كل ميزة

لا تكتفِ بمتوسط تكلفة التطبيق.

مثال:

const usageMetrics = {
  feature: "support-assistant",
  inputTokens,
  outputTokens,
  toolCalls,
  estimatedCost
};

---

كيف تقيس جودة السياق؟

لا يكفي سؤال المستخدم:

هل الإجابة جيدة؟

يجب قياس النظام عبر مؤشرات متعددة.

1. دقة الاسترجاع Retrieval Precision

هل الوثائق المسترجعة مرتبطة فعلًا بالسؤال؟

2. اكتمال الاسترجاع Retrieval Recall

هل تم العثور على المعلومات المهمة، أم تم إغفالها؟

3. ارتباط الإجابة بالسياق

هل استخدم النموذج المعلومات المتاحة، أم تجاهلها؟

4. صحة الإجابة

هل النتيجة صحيحة عند مراجعتها؟

5. الاستناد إلى المصادر

هل يمكن تتبع الادعاءات إلى وثائق واضحة؟

6. معدل الهلوسة

كم مرة أضاف النظام معلومات غير مدعومة؟

7. زمن الاستجابة

هل أدى تحسين السياق إلى بطء غير مقبول؟

8. التكلفة

كم تبلغ تكلفة كل طلب أو مهمة؟

9. التدخل البشري

كم مرة احتاج النظام إلى مراجعة أو تصحيح؟

يمكن بناء تقرير مثل:

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

---

أنشئ مجموعة تقييم قبل توسيع النظام

اجمع مجموعة من الأسئلة الواقعية تشمل:

• أسئلة سهلة.
• أسئلة تحتاج أكثر من مصدر.
• أسئلة غامضة.
• أسئلة لا توجد لها إجابة.
• أسئلة تتضمن معلومات قديمة.
• أسئلة تخص مستخدمين مختلفين.
• أسئلة تحاول تجاوز الصلاحيات.
• أسئلة تحتاج إلى أداة.

مثال:

{
  "question": "كيف أغير إعدادات التخزين؟",
  "expectedSources": [
    "storage-settings-v3"
  ],
  "expectedBehavior": "answer_with_steps",
  "mustNotDo": [
    "invent_missing_steps",
    "access_other_tenant_data"
  ]
}

بعد ذلك قارن أي تغيير جديد بالنتائج السابقة.

---

أخطاء شائعة في هندسة السياق

1. إرسال كل شيء إلى النموذج

السياق الأكبر ليس دائمًا أفضل.

قد يؤدي إلى:

• تشتيت النموذج.
• زيادة التكلفة.
• إدخال معلومات متعارضة.
• بطء الاستجابة.

الحل: استرجاع وانتقاء وضغط المعلومات.

---

2. استخدام Prompt طويل لإخفاء ضعف البيانات

قد تكتب تعليمات مثل:

كن دقيقًا جدًا، ولا تخطئ، ولا تخمّن، وفكر بعمق، وتحقق من كل شيء.

لكن هذه التعليمات لن توفر للنموذج بيانات غير موجودة.

الحل: حسّن مصادر المعلومات والاسترجاع قبل زيادة طول الـ Prompt.

---

3. خلط بيانات مستخدمين مختلفين

هذه مشكلة أمنية خطيرة.

قد تحدث بسبب:

• عدم تمرير tenantId.
• البحث في قاعدة معرفة مشتركة دون فلترة.
• استخدام Cache غير معزول.
• إعادة استخدام سياق جلسة أخرى.

الحل: تطبيق العزل قبل الاسترجاع.

---

4. تجاهل حداثة المعلومات

قد تكون الوثيقة صحيحة، لكنها تخص إصدارًا قديمًا.

الحل:

• حفظ تاريخ التحديث.
• ربط الوثائق بالإصدارات.
• إعطاء أولوية للمعلومات الحديثة.
• الإشارة إلى عدم اليقين عند الحاجة.

---

5. عدم تسجيل الوثائق المستخدمة

إذا لم تسجل معرفات المصادر، فقد يصعب معرفة سبب الإجابة.

الحل:

logger.info({
  requestId,
  retrievedDocumentIds,
  model,
  inputTokens,
  outputTokens
});

مع تجنب تسجيل بيانات حساسة أو نصوص غير ضرورية.

---

6. الاعتماد على النموذج لحماية الصلاحيات

التعليمات ليست بديلًا عن التحكم البرمجي.

الحل: طبقات مصادقة وتفويض مستقلة.

---

7. تجاهل الحالات التي لا توجد لها إجابة

يجب أن يكون النظام قادرًا على قول:

لا توجد معلومات كافية في المصادر المتاحة.

بدل اختراع إجابة.

---

إطار عملي لبناء Context Pipeline

يمكن تنظيم العملية بهذا الشكل:

1. فهم المهمة
        ↓
2. التحقق من الهوية والصلاحيات
        ↓
3. تحديد مصادر المعلومات
        ↓
4. استرجاع المرشحين
        ↓
5. إعادة الترتيب والفلترة
        ↓
6. إضافة الذاكرة وحالة التطبيق
        ↓
7. ضغط السياق ضمن الميزانية
        ↓
8. تنفيذ النموذج
        ↓
9. استخدام الأدوات عند الحاجة
        ↓
10. التحقق من النتيجة
        ↓
11. تسجيل المقاييس والمصادر

هذا أفضل من بناء Prompt ضخم ثم إرسال كل البيانات إليه دفعة واحدة.

---

مثال مبسط لبناء السياق برمجيًا

async function buildContext({
  userMessage,
  session
}: {
  userMessage: string;
  session: {
    userId: string;
    tenantId: string;
  };
}) {
  const permissions = await getUserPermissions({
    userId: session.userId
  });

  const memory = await getRelevantMemory({
    userId: session.userId,
    query: userMessage
  });

  const documents = await retrieveRelevantDocs({
    query: userMessage,
    tenantId: session.tenantId,
    permissions,
    limit: 10
  });

  const rankedDocuments = await rerankDocuments({
    query: userMessage,
    documents,
    limit: 5
  });

  return {
    systemInstructions: [
      "استخدم المصادر المتاحة فقط.",
      "لا تخمّن عند غياب المعلومات.",
      "اذكر عدم اليقين بوضوح."
    ],
    userMessage,
    memory,
    documents: rankedDocuments,
    permissions
  };
}

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

---

كيف ترتبط هندسة السياق بإنتاجية المطور؟

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

بدل كتابة Prompt جديد مثل:

هذا مشروع Next.js يستخدم TypeScript، ولدينا مشكلة في...

يمكن تنظيم سياق المشروع ليشمل:

• بنية المشروع.
• قواعد الكود.
• الملفات المرتبطة بالمهمة.
• الاختبارات المطلوبة.
• القيود المعمارية.
• القرارات السابقة.

هذا يجعل أدوات AI جزءًا من Workflow منظم بدل أن تكون نافذة منفصلة تحتاج إلى إعادة شرح كل شيء.

راجع أيضًا:

كيفية بناء AI Productivity Stack عملي للمطورين

و:

أنظمة تركيز للمطورين في بيئات البرمجة المدعومة بالذكاء الاصطناعي

---

العلاقة بين هندسة السياق والأتمتة

في الأنظمة الآلية، قد يؤدي سياق ناقص إلى تنفيذ خاطئ.

مثلًا، إذا كان Workflow يحتاج إلى:

• حالة الطلب.
• هوية العميل.
• نتيجة التحقق.
• حالة الموافقة.
• العملية السابقة.

فإن فقدان أحد هذه العناصر قد يؤدي إلى تكرار أو تنفيذ غير صحيح.

لذلك يجب أن تكون حالة الـ Workflow جزءًا واضحًا من السياق التشغيلي.

لمزيد من التفاصيل، راجع:

كيف تبني Automation موثوق بدون فوضى تشغيلية

---

قائمة فحص قبل نشر نظام يعتمد على السياق

تصميم المهمة

• هل المهمة محددة بوضوح؟
• هل نعرف المعلومات المطلوبة؟
• هل نعرف ما الذي لا يحتاجه النموذج؟

مصادر البيانات

• هل لكل معلومة مصدر معروف؟
• هل يتم تسجيل تاريخ تحديث المعلومات؟
• هل توجد آلية للتعامل مع التعارض؟

الاسترجاع

• هل يتم تطبيق الصلاحيات قبل البحث؟
• هل يتم استرجاع المعلومات الأكثر صلة؟
• هل توجد مرحلة إعادة ترتيب؟
• هل يتم حذف النتائج الضعيفة؟

الذاكرة

• هل الذاكرة مختصرة؟
• هل يمكن تحديثها أو حذفها؟
• هل تختلف عن سجل المحادثة؟

التكلفة والأداء

• هل توجد ميزانية للسياق؟
• هل يتم تجنب إرسال البيانات المكررة؟
• هل يتم قياس عدد Tokens؟
• هل يتم قياس زمن الاستجابة؟

الأمان

• هل الصلاحيات مطبقة خارج النموذج؟
• هل بيانات المؤسسات معزولة؟
• هل الأدوات مقيدة؟
• هل العمليات الحساسة تحتاج موافقة؟

التقييم

• هل توجد مجموعة أسئلة واقعية؟
• هل يتم قياس جودة الاسترجاع؟
• هل يتم قياس صحة الإجابات؟
• هل يتم اختبار الحالات التي لا توجد لها إجابة؟
• هل يتم اختبار محاولات تجاوز الصلاحيات؟

---

الخلاصة

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

في التطبيقات الحديثة، لا تحدد جودة الإجابة صياغة التعليمات فقط، بل تحددها أيضًا:

• المعلومات التي تم اختيارها.
• جودة مصادر البيانات.
• طريقة الاسترجاع.
• الذاكرة المستخدمة.
• حالة التطبيق.
• الصلاحيات.
• الأدوات المتاحة.
• ترتيب المعلومات.
• ميزانية السياق.
• آليات التقييم والمراقبة.

النظام الجيد لا يرسل كل شيء إلى النموذج، ولا يفترض أن النموذج سيعرف ما هو مهم تلقائيًا.

بدلًا من ذلك، يبني سياقًا:

• مناسبًا للمهمة.
• محدودًا بما يلزم.
• موثوق المصدر.
• حديثًا.
• معزولًا حسب الصلاحيات.
• قابلًا للتتبع.
• قابلًا للقياس والتحسين.

ولهذا فإن السؤال الأكثر أهمية لم يعد:

كيف أكتب Prompt أفضل؟

بل أصبح:

كيف أصمم المعلومات والقيود والأدوات التي يحتاجها النموذج لاتخاذ القرار الصحيح في الوقت الصحيح؟

---

اقرأ أيضًا

• دليل نشر AI Agents في بيئات الإنتاج بدون كوارث تشغيلية
• كيف تبني Automation موثوق بدون فوضى تشغيلية
• كيفية بناء AI Productivity Stack عملي للمطورين
• أنظمة تركيز للمطورين في بيئات البرمجة المدعومة بالذكاء الاصطناعي