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

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

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

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

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

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

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

هذه طريقة جيدة لتوضيح أن الذاكرة في تطبيقات نماذج اللغة الكبيرة يجب أن توازن دائماً بين جودة الإجابة والتأخير والتكلفة أو الحمل، حتى بالنسبة للنموذج المحلي. تستخدم المقالة تكويناً محلياً يعتمد على Ollama و LiteLLM والنموذج qwen2.5:3b.

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

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

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

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