Habr AI يوضح كيفية إضافة الذاكرة والسياق إلى دردشة LLM بلغة Python باستخدام Ollama وLiteLLM

لا تبقى دردشة LLM البسيطة في سطر الأوامر دردشة حقيقية إذا كان النموذج يرى السؤال الحالي فقط. في الجزء الجديد من الدليل العملي حول Python وOllama وLiteLLM، يعرض المؤلف أهم خطوة بعد التكامل الأساسي: كيف تضيف سجل الرسائل وتحوّل سلسلة من الطلبات المنفصلة إلى حوار متماسك له سياق.

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

ويشدد الشرح على فكرة مهمة كثيرًا ما تُبسَّط في النقاشات حول LLM: لا يملك النموذج ذاكرة طويلة الأمد خفية بين الاستدعاءات. والذاكرة في هذه الدردشة لا تصنعها Ollama ولا LiteLLM، بل التطبيق الذي يخزّن المراسلات ويعيد إرسالها إلى النموذج مع كل طلب جديد. ويستخدم المثال التعليمي لذلك قائمة Python عادية باسم conversation_history، تُسجَّل فيها الرسائل تباعًا بدورَي user وassistant. أما الـ system prompt فلا يُخزَّن في السجل، بل يُضاف بشكل منفصل عند بناء كل طلب.

تبدو التغييرات في البنية صغيرة، لكنها تغيّر سلوك البرنامج جذريًا. فدالة إرسال الطلب لم تعد تتلقى user_message الحالية فقط، بل السجل أيضًا. بعد ذلك تُبنى قائمة messages بترتيب صارم: system أولًا، ثم جميع الرسائل السابقة، ثم سؤال المستخدم الجديد. وبعد أن يرد النموذج، يحفظ التطبيق طرفَي التبادل معًا: السؤال والجواب. وهذا ليس تفصيلًا شكليًا، فلو سُجّلت رسائل المستخدم وحدها لجاء الطلب التالي ناقصًا، لأن النموذج سيرى أن السؤال طُرح سابقًا لكنه لن يرى كيف أجاب عنه.

ويتناول الشرح بشكل منفصل تقييد السجل. ففي المثال أُدخل الثابت MAX_HISTORY_MESSAGES = 6، وتُبقي الدالة المساعدة trim_history على آخر ست رسائل فقط، أي آخر ثلاثة تبادلات. وهذا حل عملي وسط لنموذج أولي محلي: فالسجل لا ينمو بلا حدود، والطلبات لا تتضخم، ومع ذلك يحصل النموذج على أقرب سياق. وهي طريقة جيدة لتوضيح أن الذاكرة في تطبيقات LLM تتطلب دائمًا موازنة بين جودة الإجابة وزمن الاستجابة والتكلفة أو الحمل، حتى مع النموذج المحلي.

يعتمد المقال على إعداد محلي قائم على Ollama وLiteLLM والنموذج qwen2.5:3b. وهذه المجموعة مناسبة للتعلّم، لأنها تتيح بناء دردشة تعمل من دون API خارجي ومن دون بنية تحتية معقدة. وتُظهر الأمثلة بوضوح كيف يتغيّر رد فعل النظام بعد إضافة السجل: فطلب «حدّثني بتفصيل أكبر عن الثاني» يبدأ بالإحالة بشكل صحيح إلى القائمة السابقة، وعبارة «اجعله أقصر» لم تعد تُفهم كأمر مجرد منفصل. أي أن النموذج لا يصبح أذكى بذاته، لكن التطبيق يمنحه السياق الذي كان يضيع من قبل.

وفي الوقت نفسه، تُذكر حدود هذه النسخة صراحةً. فالسجل كله يُحفظ في الذاكرة العشوائية للتشغيل الحالي فقط: إذا أُغلق السكربت اختفى الحوار. وهذا كافٍ لواجهة سطر أوامر تعليمية، لكن بوت Telegram أو خدمة الويب أو المساعد الموجّه للعملاء سيحتاج إلى تخزين دائم، ولو في ملف أو SQLite أو قاعدة بيانات كاملة. وعادةً ما تكون الخطوات التالية هي تلخيص الحوارات الطويلة، وتصفية الرسائل غير ذات الصلة، وإدارة أكثر مرونة لنافذة السياق.

الخلاصة الرئيسية من هذا الجزء واقعية، ولذلك فهي مفيدة: الذاكرة في دردشة LLM ليست وظيفة سحرية منفصلة في النموذج، بل مسؤولية عادية تقع على الكود المحيط به. فبضعة أسطر مع conversation_history، وترتيب صحيح لـ messages، وتقييد بسيط لحجم السجل، تكفي لتحويل سكربت العرض التجريبي إلى أساس لمساعد أقرب إلى الواقع. وهو مثال جيد للمطورين على أن قيمة واجهة الدردشة كثيرًا ما لا تنبع من اختيار النموذج نفسه، بل من دقة تجميع التطبيق لسياق المحادثة وتمريره.