(انقر على الصورة أعلاه لمشاهدة فيديو هذا الدرس)
فهم تعقيدات التطبيق الذي تبني له وكيل ذكاء اصطناعي أمر مهم لصنع وكيل موثوق. نحتاج إلى بناء وكلاء ذكاء اصطناعي يديرون المعلومات بفعالية لتلبية الاحتياجات المعقدة تتجاوز الهندسة التصريحية.
في هذا الدرس، سننظر في ماهية هندسة السياق ودورها في بناء وكلاء الذكاء الاصطناعي.
سيغطي هذا الدرس:
• ما هي هندسة السياق ولماذا تختلف عن هندسة الإرشادات.
• استراتيجيات هندسة السياق الفعالة، بما في ذلك كيفية كتابة، اختيار، ضغط، وعزل المعلومات.
• الإخفاقات الشائعة في السياق التي يمكن أن تعطل وكيل الذكاء الاصطناعي وكيفية إصلاحها.
بعد إكمال هذا الدرس، ستفهم كيف:
• تعريف هندسة السياق والتمييز بينها وبين هندسة الإرشادات.
• تحديد المكونات الرئيسية للسياق في تطبيقات نماذج اللغة الكبيرة (LLM).
• تطبيق استراتيجيات الكتابة، الاختيار، الضغط، وعزل السياق لتحسين أداء الوكيل.
• التعرف على إخفاقات السياق الشائعة مثل التسمم، التشتت، الالتباس، والتعارض، وتنفيذ تقنيات التخفيف.
بالنسبة لوكلاء الذكاء الاصطناعي، السياق هو ما يحفز تخطيط الوكيل لاتخاذ إجراءات معينة. هندسة السياق هي ممارسة التأكد من أن وكيل الذكاء الاصطناعي يمتلك المعلومات الصحيحة لإكمال الخطوة التالية من المهمة. نافذة السياق محدودة الحجم، لذا كمنشئي وكيل نحتاج إلى بناء أنظمة وعمليات لإدارة إضافة، إزالة، وتكثيف المعلومات في نافذة السياق.
تركز هندسة الإرشادات على مجموعة واحدة من التعليمات الثابتة لتوجيه وكلاء الذكاء الاصطناعي بمجموعة من القواعد بشكل فعال. بينما هندسة السياق هي كيفية إدارة مجموعة ديناميكية من المعلومات، بما في ذلك الموجه الأساسي، لضمان أن الوكيل يملك ما يحتاجه بمرور الوقت. الفكرة الرئيسية حول هندسة السياق هي جعل هذه العملية قابلة للتكرار وموثوقة.
من المهم أن نتذكر أن السياق ليس شيئًا واحدًا فقط. يمكن أن تأتي المعلومات التي يحتاجها وكيل الذكاء الاصطناعي من مجموعة متنوعة من المصادر المختلفة ويقع على عاتقنا ضمان أن لدى الوكيل وصول إلى هذه المصادر:
أنواع السياق التي قد يحتاج وكيل الذكاء الاصطناعي لإدارتها تشمل:
• التعليمات: تشبه “قواعد” الوكيل – الإرشادات، رسائل النظام، أمثلة قليلة (توضح للذكاء الاصطناعي كيفية فعل شيء ما)، ووصف الأدوات التي يمكنه استخدامها. هنا يتقاطع تركيز هندسة الإرشادات مع هندسة السياق.
• المعرفة: تشمل الحقائق، المعلومات المسترجعة من قواعد البيانات، أو الذكريات طويلة الأمد التي جمعها الوكيل. يشمل ذلك دمج نظام التوليد المعزز بالاسترجاع (RAG) إذا كان الوكيل يحتاج الوصول إلى مخازن المعرفة المختلفة وقواعد البيانات.
• الأدوات: هي تعريفات الدوال الخارجية، واجهات برمجة التطبيقات (APIs)، وخوادم MCP التي يمكن للوكيل استدعاؤها، بالإضافة إلى الملاحظات (النتائج) التي يحصل عليها من استخدامها.
• تاريخ المحادثة: الحوار الجاري مع المستخدم. مع مرور الوقت تصبح هذه المحادثات أطول وأكثر تعقيدًا مما يعني أنها تأخذ مساحة في نافذة السياق.
• تفضيلات المستخدم: المعلومات التي يتم تعلمها حول ما يحبه أو يكرهه المستخدم مع مرور الوقت. يمكن تخزين هذه المعلومات واستدعاؤها عند اتخاذ قرارات هامة لمساعدة المستخدم.
تبدأ هندسة السياق الجيدة بتخطيط جيد. إليك نهج يساعدك على البدء في التفكير حول كيفية تطبيق مفهوم هندسة السياق:
التخطيط مهم لكن بمجرد تدفق المعلومات إلى نافذة سياق وكيلنا، نحتاج إلى استراتيجيات عملية لإدارتها:
بينما يتم إضافة بعض المعلومات إلى نافذة السياق تلقائيًا، هندسة السياق تعنِي اتخاذ دور أكثر نشاطًا في هذه المعلومات، وهذا يمكن تنفيذه من خلال عدة استراتيجيات:
دفتر ملاحظات الوكيل يسمح لوكيل الذكاء الاصطناعي بتدوين ملاحظات عن المعلومات ذات الصلة بالمهام الحالية وتفاعلات المستخدم خلال جلسة واحدة. يجب أن يكون هذا خارج نافذة السياق في ملف أو كائن وقت التشغيل يمكن للوكيل استرداده لاحقًا خلال الجلسة إذا لزم الأمر.
الذكريات دفاتر الملاحظات جيدة لإدارة المعلومات خارج نافذة السياق لجلسة واحدة. الذكريات تمكّن الوكلاء من تخزين واسترجاع المعلومات ذات الصلة عبر جلسات متعددة. يمكن أن تشمل ملخصات، تفضيلات المستخدم، وتعليقات لتحسينات مستقبلية.
ضغط السياق عندما تكبر نافذة السياق وتقترب من الحد الأقصى، يمكن استخدام تقنيات مثل التلخيص والتقليم. يتضمن هذا إما الاحتفاظ فقط بالمعلومات الأكثر صلة أو إزالة الرسائل الأقدم.
أنظمة متعددة الوكلاء تطوير نظام متعدد الوكلاء هو شكل من أشكال هندسة السياق لأن لكل وكيل نافذة سياق خاصة به. كيفية مشاركة هذا السياق وتمريره إلى وكلاء مختلفين هو أمر آخر يجب تخطيطه عند بناء هذه الأنظمة.
بيئات الحماية (Sandbox) إذا احتاج الوكيل لتشغيل بعض الأكواد أو معالجة كميات كبيرة من المعلومات في وثيقة، يمكن أن يتطلب ذلك كمية كبيرة من الرموز لمعالجة النتائج. بدلاً من تخزين كل هذا في نافذة السياق، يمكن للوكيل استخدام بيئة حماية قادرة على تشغيل هذا الكود وقراءة النتائج وغيرها من المعلومات ذات الصلة فقط.
كائنات حالة وقت التشغيل يتم ذلك عن طريق إنشاء حاويات للمعلومات لإدارة الحالات التي يحتاج فيها الوكيل الوصول إلى معلومات معينة. بالنسبة لمهمة معقدة، سيمكن هذا الوكيل من تخزين نتائج كل خطوة فرعية خطوة بخطوة، مما يسمح لسياق أن يبقى مرتبطًا فقط بتلك المهمة الفرعية المحددة.
بعد تطبيق إحدى هذه الاستراتيجيات، من المفيد التحقق مما تلقاه الاستدعاء التالي للنموذج فعليًا. سؤال تصحيح أخطاء مفيد هو:
هل قام الوكيل بتحميل سياق زائد، أو السياق الخاطئ، أو فاتته سياقات كان يحتاجها؟
لا تحتاج إلى تسجيل الإرشادات الخام، مخرجات الأدوات، أو محتويات الذاكرة للإجابة عن هذا السؤال. في بيئة الإنتاج، يُفضل سجلات تفتيش سياق صغيرة تلتقط العدادات، المعرفات، التجزئات، وتسميات السياسات:
الهدف ليس الاحتفاظ بسياق أكثر. بل هو ترك ما يكفي من الأدلة ليتمكن المطور من معرفة أي استراتيجية سياق تم تشغيلها وما إذا كانت غيّرت استدعاء النموذج التالي بالطريقة المقصودة.
لنفترض أننا نريد من وكيل الذكاء الاصطناعي أن “يحجز لي رحلة إلى باريس.”
• وكيل بسيط يستخدم فقط هندسة الإرشادات قد يرد ببساطة: “حسنًا، متى ترغب في الذهاب إلى باريس؟” إنه ببساطة يعالج سؤالك المباشر في وقت طلب المستخدم.
• وكيل يستخدم استراتيجيات هندسة السياق التي تم تغطيتها سيفعل أكثر من ذلك بكثير. قبل الرد، قد:
◦ يتحقق من جدولك للبحث عن تواريخ متاحة (استرجاع بيانات الوقت الحقيقي).
◦ يستدعي التفضيلات السابقة للسفر (من الذاكرة طويلة الأمد) مثل شركة الطيران المفضلة، الميزانية، أو تفضيل الرحلات المباشرة.
◦ يحدد الأدوات المتاحة للحجز الرحلات والطيران والفنادق.
ما هو: عندما تدخل هلوسة (معلومات خاطئة مولدة من قبل نموذج LLM) أو خطأ إلى السياق ويتم الرجوع إليه مرارًا وتكرارًا، مما يجعل الوكيل يسعى لهدف مستحيل أو يطور استراتيجيات غير منطقية.
ماذا تفعل: نفذ التحقق من صحة السياق والعزل. تحقق من صحة المعلومات قبل إضافتها إلى الذاكرة طويلة الأمد. إذا تم الكشف عن تسمم محتمل، ابدأ خيوط سياق جديدة لمنع انتشار المعلومات السيئة.
مثال حجز السفر: الوكيل يخيل له وجود رحلة مباشرة من مطار محلي صغير إلى مدينة دولية بعيدة لا تقدم فعليًا رحلات دولية. يتم حفظ هذه المعلومة الخاطئة في السياق. لاحقًا، عندما تطلب من الوكيل الحجز، يستمر بمحاولة العثور على تذاكر لهذا المسار المستحيل مما يؤدي إلى أخطاء متكررة.
الحل: نفذ خطوة للتحقق من وجود الرحلة والمسارات باستخدام API في الوقت الحقيقي قبل إضافة تفاصيل الرحلة إلى سياق عمل الوكيل. إذا فشل التحقق، يتم “عزل” المعلومات الخطأ وعدم استخدامها أكثر.
ما هو: عندما يصبح السياق كبيرًا للغاية بحيث يركز النموذج كثيرًا على التاريخ المتراكم بدلاً من استخدام ما تعلمه خلال التدريب، مما يؤدي إلى أفعال متكررة أو غير مفيدة. قد تبدأ النماذج في ارتكاب أخطاء حتى قبل أن تمتلئ نافذة السياق.
ماذا تفعل: استخدم تلخيص السياق. اضغط المعلومات المتراكمة بشكل دوري إلى ملخصات أقصر، تحافظ على التفاصيل المهمة مع إزالة التاريخ المكرر. يساعد هذا على “إعادة ضبط” التركيز.
مثال حجز السفر: كنت تناقش وجهات السفر الحلم المختلفة لفترة طويلة، بما في ذلك سرد تفصيلي لرحلتك بحقيبة الظهر منذ سنتين. عندما تسأل أخيرًا “ابحث لي عن رحلة رخيصة لشهر القادم”، يتم إغراق الوكيل في التفاصيل القديمة وغير ذات الصلة ويستمر في السؤال عن معدات حقيبة الظهر أو خطط الرحلات السابقة متجاهلًا طلبك الحالي.
الحل: بعد عدد معين من التبديلات أو عندما يكبر السياق كثيرًا، يجب على الوكيل تلخيص الأجزاء الأخيرة والأكثر صلة من المحادثة – مع التركيز على تواريخ السفر والوجهات الحالية – واستخدام هذا الملخص المكثف للاستدعاء التالي للنموذج، متجاهلًا الدردشة التاريخية الأقل صلة.
ما هو: عندما يسبب السياق غير الضروري، غالبًا على شكل عدد كبير من الأدوات المتاحة، أن يولد النموذج ردودًا ضعيفة أو يستدعي أدوات غير ذات صلة. النماذج الأصغر معرضة بشكل خاص لهذا.
ماذا تفعل: طبق إدارة تحميل الأدوات باستخدام تقنيات RAG. خزّن أوصاف الأدوات في قاعدة بيانات متجهية واختر فقط الأدوات الأكثر صلة لكل مهمة محددة. تظهر الأبحاث ضرورة حصر اختيار الأدوات بأقل من 30.
مثال حجز السفر: لدى وكيلك الوصول إلى العشرات من الأدوات: book_flight, book_hotel, rent_car, find_tours, currency_converter, weather_forecast, restaurant_reservations، إلخ. تسأل، “ما أفضل طريقة للتنقل في باريس؟” بسبب العدد الكبير من الأدوات، يُربك الوكيل ويحاول استدعاء book_flight داخل باريس، أو rent_car رغم أنك تفضل النقل العام، لأن أوصاف الأدوات قد تتداخل أو لا يمكنه التمييز بين الأفضل.
الحل: استخدم RAG على أوصاف الأدوات. عند سؤالك عن التنقل في باريس، يسترجع النظام فقط الأدوات الأكثر صلة مثل rent_car أو public_transport_info بناءً على استفسارك، مقدمًا “حمولة” مركزة من الأدوات للنموذج.
ما هو: عندما توجد معلومات متضاربة داخل السياق، مما يؤدي إلى استدلالات متناقضة أو ردود نهائية سيئة. يحدث هذا غالبًا عندما تصل المعلومات على مراحل، تبقى الافتراضات الخاطئة المبكرة في السياق.
ماذا تفعل: استخدم تقليم السياق والتفريغ. التقليم يعني إزالة المعلومات القديمة أو المتضاربة مع وصول تفاصيل جديدة. التفريغ يعطي النموذج مساحة “دفتر ملاحظات” منفصلة لمعالجة المعلومات دون إرباك السياق الرئيسي.
مثال حجز السفر: في البداية تخبر وكيلك، “أريد السفر بالدرجة الاقتصادية.” لاحقًا في المحادثة، تغير رأيك وتقول، “في الواقع، لهذه الرحلة، دعنا نذهب بدرجة رجال الأعمال.” إذا بقي كلا التعليمين في السياق، قد يتلقى الوكيل نتائج بحث متضاربة أو يشعر بالحيرة حول أي تفضيل يجب أن يعطيه الأولوية.
الحل: تنفيذ تقليص السياق. عندما يتعارض تعليم جديد مع تعليم قديم، يتم إزالة التعليم الأقدم أو تغطيته صراحة في السياق. بدلاً من ذلك، يمكن للوكيل استخدام لوح ملاحظات لتوفيق التفضيلات المتضاربة قبل اتخاذ القرار، مما يضمن أن التعليم النهائي والمتسق فقط هو الذي يوجه أفعاله.
انضم إلى Microsoft Foundry Discord للتواصل مع متعلمين آخرين، حضور ساعات المكتب، والحصول على إجابات لأسئلة وكلاء الذكاء الاصطناعي لديك.
الذاكرة لوكلاء الذكاء الاصطناعي
تنويه: تمت ترجمة هذا المستند باستخدام خدمة الترجمة بالذكاء الاصطناعي Co-op Translator. بينما نسعى للدقة، يرجى العلم أن الترجمات الآلية قد تحتوي على أخطاء أو عدم دقة. يجب اعتبار المستند الأصلي بلغته الأصلية المصدر الرسمي والمعتمد. للمعلومات الهامة، يُنصح بالاستعانة بترجمة بشرية محترفة. نحن غير مسؤولين عن أي سوء فهم أو تفسير ناتج عن استخدام هذه الترجمة.