تلخيص المحادثات الطويلة باستخدام نماذج اللغة

1. تحدي "نافذة السياق" (Context Window)

لكي نفهم المشكلة، نحتاج أولاً إلى فهم مفهوم أساسي في نماذج اللغة الكبيرة يسمى "نافذة السياق" (Context Window).

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

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

ماذا يحدث عندما تتجاوز المحادثة حجم هذه النافذة؟
ببساطة، يبدأ النموذج في "نسيان" أقدم أجزاء المحادثة. يتم قطع الأجزاء الأولى من السجل لإفساح المجال للمعلومات الجديدة. هذا يؤدي إلى مشاكل مثل:

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

الصورة التالية توضح هذا الفرق بشكل ممتاز.

إذًا، كيف يمكننا إجراء محادثات طويلة جدًا دون أن يعاني وكيلنا من هذا النوع من "فقدان الذاكرة"؟

2. الحل: التلخيص كأداة للذاكرة

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

الفكرة هي كالتالي:

1. تجري المحادثة بشكل طبيعي لعدة تبادلات.
2. عندما يقترب سجل المحادثة من الامتلاء، نأخذ هذا السجل ونرسله إلى النموذج مع طلب بسيط: "لخّص هذه المحادثة".
3. نأخذ الملخص الذي يولده النموذج ونستبدل به سجل المحادثة الطويل.
4. في الجولة التالية من المحادثة، نرسل للنموذج الملخص + آخر بضع رسائل فقط.

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

3. استراتيجية تلخيص بسيطة وتطبيقها عمليًا

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

سنكتب دالة (function) يمكن للوكيل استدعاؤها قبل كل تفاعل للتحقق من طول سجل المحادثة وتلخيصه إذا لزم الأمر.

المنطق خطوة بخطوة:

1. نحتفظ بسجل المحادثة في قائمة (list) من النصوص.
2. قبل معالجة رسالة المستخدم الجديدة، نتحقق من الطول الإجمالي لسجل المحادثة.
3. إذا كان السجل طويلاً جدًا:
   أ. ندمج كل الرسائل في نص واحد كبير.
   ب. ننشئ طلبًا (prompt) جديدًا للنموذج، مثل: "لخّص المحادثة التالية بإيجاز مع الحفاظ على النقاط المهمة: [النص الكبير هنا]".
   ج. نستدعي واجهة برمجة التطبيقات الخاصة بالنموذج للحصول على الملخص.
   د. نستبدل قائمة سجل المحادثة الطويلة بقائمة جديدة تحتوي فقط على هذا الملخص.
4. إذا لم يكن السجل طويلاً: نتركه كما هو.

إليك كيف يمكن أن تبدو هذه الدالة في بايثون:

# لنفترض أن لدينا هذه الدوال من الدروس السابقة
# call_llm(prompt): دالة تستدعي واجهة برمجة تطبيقات النموذج اللغوي
# count_tokens(text): دالة تقدر عدد الرموز في النص

MAX_TOKENS = 3000  # الحد الأقصى للرموز التي نريد إرسالها

def manage_conversation_history(history: list) -> list:
    """
    تتحقق هذه الدالة من طول سجل المحادثة.
    إذا كان طويلاً، فإنها تلخصه.
    """
    
    # تحويل قائمة الرسائل إلى نص واحد لتقدير الطول
    full_conversation_text = "\n".join(history)
    token_count = count_tokens(full_conversation_text)
    
    print(f"Current token count: {token_count}") # لغرض التوضيح

    # إذا تجاوزنا 75% من الحد الأقصى، نقوم بالتلخيص
    if token_count > MAX_TOKENS * 0.75:
        print("--> History is too long. Summarizing...")
        
        # 1. إنشاء طلب التلخيص
        summarization_prompt = f"""
        لخّص المحادثة التالية بإيجاز، مع التركيز على القرارات الرئيسية والمعلومات المهمة التي تم تبادلها.

        المحادثة:
        {full_conversation_text}

        الملخص:
        """
        
        # 2. استدعاء النموذج اللغوي للحصول على الملخص
        summary = call_llm(summarization_prompt)
        
        # 3. إنشاء سجل محادثة جديد يحتوي على الملخص
        new_history = [f"ملخص المحادثة حتى الآن: {summary}"]
        
        print("--> Summarization complete.")
        return new_history
        
    else:
        # السجل ليس طويلاً، أعده كما هو
        return history

يمكن لوكيلنا الآن استخدام هذه الدالة manage_conversation_history كجزء من حلقة عمله الرئيسية (Perceive-Think-Act loop) لضمان عدم فقدان السياق أبدًا، بغض النظر عن مدة استمرار المحادثة.

4. مزايا وعيوب هذه الاستراتيجية

مثل أي حل تقني، لهذه الاستراتيجية مزايا وعيوب من المهم معرفتها:

المزايا:

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

العيوب:

• فقدان التفاصيل (Loss of Detail): عملية التلخيص بطبيعتها "ضاغطة مع فقدان للبيانات". قد تضيع بعض التفاصيل الدقيقة أو الفروق اللغوية البسيطة من المحادثة المبكرة.
• التكلفة والوقت: كل عملية تلخيص هي استدعاء إضافي لواجهة برمجة التطبيقات، مما يعني تكلفة مالية إضافية ووقت انتظار إضافي.
• صعوبة التوقيت: تحديد اللحظة المثلى للتلخيص يمثل تحديًا. التلخيص المتكرر جدًا مكلف، والانتظار طويلاً قد يؤدي إلى فقدان السياق قبل التلخيص.

خلاصة الدرس

في هذا الدرس، تعاملنا مع أحد التحديات العملية الكبرى في بناء وكلاء محادثة أذكياء.

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

ماذا بعد؟

لقد أنهينا الآن الوحدة السابعة واستكشفنا تقنيات متقدمة للذاكرة، بدءًا من تخزين المعلومات في قاعدة بيانات، والبحث فيها بذكاء باستخدام البحث الدلالي، واستخدامها للإجابة عبر RAG، وأخيرًا، الحفاظ على سياق المحادثة نفسها عبر التلخيص.

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