LangChain Blogآخر تحديث

هندسة السياق: كيف تتذكر الوكلاء العميقون

النقاط الرئيسية يحدث "تسوس السياق" عندما تراكم الوكلاء طويلة الأمد سياقًا أكثر مما يستطيع النموذج استيعابه، مما يؤدي إلى تراجع الدقة. يستخدم Deep Agents، وهو إطار عمل الوكلاء مفتوح المصدر من LangChain

مصدر الصورة · LangChain Blog

النقاط الرئيسية

  • يحدث "تسوس السياق" عندما تراكم الوكلاء طويلة الأمد سياقًا أكثر مما يستطيع النموذج استيعابه، مما يؤدي إلى تراجع الدقة.
  • يستخدم Deep Agents، وهو إطار عمل الوكلاء مفتوح المصدر من LangChain، خمس تقنيات لنقل السياق إلى خارج النافذة النشطة (دون حذفه) لمنع تسوس السياق.
  • ذاكرة الوكيل في Deep Agents تُخزَّن كملفات نصية عادية في تخزين تتحكم فيه أنت، بحيث يمكنك تغيير النموذج أو المزود مع الاحتفاظ بكل ما تعلمه.

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

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

في عالم هندسة الوكلاء، نسمي هذا تسوس السياق. تتناول هذه المدونة تقنيات لإدارة نافذة سياق وكيلك وكيف يستخدم إطار عمل Deep Agents مفهومًا يسمى middleware لحقنها في تشغيل وكيلك.

‍

فهم تقنيات هندسة السياق

للتبسيط، الوكيل ليس سوى نموذج يحتضنه إطار عمل من حوله.

الإطار = يحتضن النموذج (LLM)

تقع تقنيات هندسة السياق المتاحة للوكيل لمعالجة تسوس السياق أساسًا في فئتين:

  • منع المعلومات غير الضرورية من الدخول إلى نافذة السياق
  • إدارة وتصفية ما هو موجود بالفعل في نافذة السياق

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

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

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

  1. التفريغ (Offloading): يتم حفظ نتائج الأدوات الكبيرة ورسائل المستخدم إلى نظام الملفات، ويرى النموذج معاينة فقط.
  2. التلخيص (Summarization): عندما يقترب الحوار من حد السياق، تُكثَّف الرسائل الأقدم في ملخص.
  3. المهارات (Skills): لا تُحمَّل المعرفة الخاصة بالمهمة إلا عندما يقرر النموذج أنها ذات صلة.
  4. الوكلاء الفرعيون (Subagents): يعمل العمل المشوش في نافذة سياق منفصلة، ولا يعود إلا النتيجة.
  5. الذاكرة طويلة الأمد: يُحفظ ما يتعلمه الوكيل في ملف يُنقل إلى الحوار التالي.

‍

تطبيق هندسة السياق على حالات استخدام شائعة

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

  1. سحب تصدير لبيانات السوق الخاصة بالشركة A (عشرات آلاف الصفوف)
  2. البحث في الأخبار، وقراءة بعض المقالات، وتدوين الملاحظات
  3. التكرار بالنسبة للشركات B حتى E
  4. صياغة التقرير، ومراجعته بناءً على ملاحظاتك، وتنسيقه

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

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

‍

كيفية تنفيذ هذه التقنيات: الوسائط البرمجية (middleware)

يعمل الوكيل (agent) في حلقة: يقرر النموذج ما يجب فعله، ويستدعي أداة، ويقرأ النتيجة، ويكرر ذلك حتى تكتمل المهمة. الوسيط (Middleware) هو شيفرة تتصل بنقاط محددة في تلك الحلقة: مثلًا قبل بدء الوكيل، أو حول كل استدعاء للنموذج، أو حول كل استدعاء لأداة.

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

‍

التفريغ (Offloading): إبقاء المحتوى خارج نافذة السياق

لا يحتاج وكيلنا دائمًا إلى رؤية كل البيانات التي تُعاد من كل استدعاء أداة أو رسالة بشرية، خاصة إذا كانت بحجم كبير.

على سبيل المثال، يُعيد كل استدعاء لأداة pull_market_report تصدير بيانات كاملًا (آلاف الصفوف)؛ ومع ذلك، لا يحتاج الوكيل سوى بضعة أرقام منها، لذا يمكن حصر النموذج في رؤية تلك الصفوف فقط.

عملية تفريغ نتائج الأدوات (متحركة)

يعمل FilesystemMiddleware في كل مرة تُستدعى فيها أداة:

  1. عندما تتجاوز نتيجة أداة ما حوالي 20,000 رمز (token)، تُكتب النتيجة الكاملة إلى /large_tool_results/{tool_call_id} قبل دخولها إلى المحادثة.
  2. لا يرى النموذج سوى معاينة قصيرة (أول وآخر بضعة أسطر) بالإضافة إلى مسار الملف.
  3. وعندما يحتاج الوكيل لاحقًا إلى إيرادات الشركة B ربع السنوية، يتصفح الملف باستخدام read_file.

أما رسائل المستخدم/البشرية الضخمة، مثل نسخة مكالمة ملصوقة، فتُعامل بالمثل عند حد أعلى (50,000 رمز) وتُحفظ في /conversation_history/.

‍

التلخيص (Summarization): ضغط ما هو موجود أصلًا

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

التفريغ يوقف الارتفاعات الصغيرة، بينما يعيد التلخيص "تصفير" الصعود الإجمالي
  • الارتفاعات هي نتائج أدوات كبيرة/رسائل بشرية تصل؛ ويستبدل التفريغ كل واحدة منها بمعاينة قصيرة قبل أن يراها النموذج، لذا لا ينمو السياق إلا قليلًا.
  • يتولى التلخيص الصعود البطيء: بمجرد أن تصل نسبة الاستخدام إلى 85%، تُكثَّف الرسائل الأقدم في ملخص وينخفض السياق مجددًا.

يفحص SummarizationMiddleware استخدام الرموز مباشرة قبل كل استدعاء للنموذج:

  1. بمجرد أن يتجاوز الاستخدام عتبة معينة (85% من نافذة سياق النموذج افتراضيًا)، يُكثّف استدعاء LLM منفصل الرسائل الأقدم في ملخص واحد
  2. تُزال الرسائل الأقدم من نافذة السياق بينما تُحتفظ بالرسائل الأحدث حرفيًا كما هي.
  3. يرى النموذج الآن الملخص أولًا، ثم الرسائل الأحدث (حتى لا يُعاد صياغة أي شيء حديث).

تفصيلان مهمان:

  • إنه قابل للاستعادة. تُكتب الرسائل الملخصة إلى /conversation_history/{session_id}.md. وإذا احتاج الوكيل إلى تفصيل من بحث الشركة A أثناء كتابة المسودة، يمكنه قراءته مرة أخرى.
  • إنه دوري. مع استمرار التشغيل، يرتفع الاستخدام مجددًا، ويتضمن الملخص التالي الملخص السابق.

يمكنك أيضًا التلخيص عند تغير الموضوع, وليس فقط عند حد معين من الرموز (tokens). قد يكون من المفيد تخصيص مطالبة التلخيص.

منشورنا حول إدارة السياق لوكلاء Deep Agents يتناول كلا الأمرين بمزيد من التفصيل.

المهارات: تحميل المعلومات فقط عند الحاجة إليها

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

المهارة هي مجلد من التعليمات (مع نصوص برمجية ووثائق مرجعية اختيارية) يمنح الوكيل ما يحتاجه لمهمة متخصصة.

بنية مجلد المهارة

يرى الوكيل وصفاً موجزاً في البداية ويحمّل التعليمات الكاملة لـ qbr-report فقط عند ظهور مراجعة أعمال فصلية (QBR) (ولا تحملها المهام الأخرى أبداً).

تُحمّل المهارات السياق على طبقات، لذلك يبقى النافذة صغيرة حتى يصبح شيء ما ذا صلة فعلًا. ويُسمّى هذا الإفصاح التدريجي: يرى النموذج "قائمة" في البداية ويسحب الوصفة الكاملة عندما يحتاج إليها، فتكلف عشر مهارات ما يقارب سياق عشر سطرات من سطر واحد.

الإفصاح التدريجي (متحرك)

تشير الوكيل إلى مهاراتك، ويستخدم SkillsMiddleware خطافين (hooks):

  1. قبل أن يبدأ الوكيل، يمسح مجلد المهارات ويقرأ فقط الترويسة من كل ملف SKILL.md.
  2. في كل نداء للنموذج، يضيف تلك الأسماء والأوصاف إلى موجه النظام (system prompt).

لا تدخل التعليمات الكاملة السياق إلا عندما يقرر النموذج أن إحدى المهارات ذات صلة (ويقرؤها بأداة read_file)، لذا يجري وكيلنا بحثه دون القالب ولا يحمّله إلا عندما يحين وقت تنسيق مراجعة أعمال ربع سنوية (QBR).

‍

الوكلاء الفرعيون: عزل العمل المزعج

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

يتيح لنا SubAgentMiddleware تخصيص موجه النظام والأدوات المتاحة لوكلائنا الفرعيين.

market_researcher = {
    "name": "market-researcher",
    "description": "Researches a company and returns the 3 most notable developments.",
    "system_prompt": "Use pull_market_report, then return 3 short bullet points. Do not return the raw report.",
    "tools": [pull_market_report],
}

agent = create_deep_agent(model=model, subagents=[market_researcher])

في حالتنا، يسلّم الوكيل الرئيسي كل شركة إلى الوكيل الفرعي "باحث السوق".

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

‍

الذاكرة طويلة الأمد: الاستمرار عبر المحادثات

بحلول النهاية، سيكون وكيلك قد تعلّم الكثير. بعضه مفيد، وبعضه لا.

قل مثلًا لوكيلك: "استخدم نقاطًا نقطية في الملخص، لا فقرات." بدون ذاكرة، قد تجد نفسك تكرر ذلك كل أسبوع. في Deep Agents، الذاكرة طويلة الأمد هي ملف markdown. تشير الوكيل إليه بمعامل واحد، ويتولى MemoryMiddleware الباقي:

  1. التحميل: يُقرأ الملف في بداية كل تشغيل.
  2. الحقن: تُضاف محتوياته إلى موجه النظام في كل نداء للنموذج.
  3. التحديث: عندما يتعلّم الوكيل شيئًا يستحق الحفظ، مثل تفضيلك في التنسيق، يحدّث الملف.

‍

بدّل النموذج واحتفظ بالذاكرة

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

agent = create_deep_agent(
    model="openai:gpt-6",  # different provider, same memory
    memory=["/memories/AGENTS.md"],
    backend=backend,
    store=store,
)

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

استراتيجيات هندسة السياق التي يجدر تذكّرها

سواء بُنيت على Deep Agents، أو استخدمت منصة أخرى، أو بنيت واحدة بنفسك، إليك بعض الأمور التي يجب الانتباه لها:

  • المدخلات الكبيرة ينبغي تفريغها، لا اقتطاعها. الاقتطاع مُفقِد للمعلومات؛ بينما التفريغ يحافظ على إمكانية استرجاعها.
  • يجب أن يكون الضغط (Compaction) قابلًا للاستعادة. بعد التلخيص، لا يزال بإمكان الوكيل استعادة التفاصيل التي يحتاجها.
  • المعرفة العملية ينبغي تُحمّل عند الطلب. التعليمات الخاصة بكل مهمة في موجه النظام تستهلك سياقًا في كل استدعاء.
  • يجب عزل العمل المزعج (الضوضائي). الوكلاء الفرعيون الذين يمتلكون سياقهم الخاص يحافظون على تركيز الوكيل الرئيسي.
  • يجب أن تملك أنت الذاكرة. الذاكرة في وحدة تخزين تتحكم بها تنجو من تبديل النموذج أو المزوّد.
  • ينبغي أن تكون الإعدادات الافتراضية قابلة للتخصيص. العتبات التي تناسب مهمة واحدة نادرًا ما تناسب كل مهمة.

جرّبه

uv add deepagents

تريد التعلم أكثر من مدرّب مباشر؟ سأغطي هذا في 3 نوفمبر: سجّل هنا!

للتعمق أكثر في هندسة السياق، تفضل بزيارة دورة Deep Agents المجانية ذاتية السرعة على LangChain Academy.

المصدر الأصلي

LangChain Blog

ملاحظات المحتوى

النشر الأصلي والحقوق تعود إلى المصدر.

ترجمة آلية · يُرجى الرجوع إلى الأصل