تأملات في ChatGPT وأنظمة ذاكرة كلود: ما يتطلبه الأمر لتمكين استرجاع المحادثات عند الطلب

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

تشكل هذه الاختيارات بشكل مباشر زمن استجابة الوكيل، واستخدام الموارد، وفي النهاية سقف قدراته.

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

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

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

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

نظام ذاكرة ChatGPT

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

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

على مستوى عالٍ، تتكون مطالبة ChatGPT الكاملة من الطبقات التالية، مرتبة من الأكثر عمومية إلى الأكثر فورية:

[0] تعليمات النظام

[1] تعليمات المطور

[2] البيانات الوصفية للجلسة (سريعة الزوال)

[3] ذاكرة المستخدم (حقائق طويلة الأمد)

[4] ملخص المحادثات الأخيرة (المحادثات السابقة، العناوين + مقتطفات)

[5] رسائل الجلسة الحالية (هذه المحادثة)

[6] رسالتك الأخيرة

من بين هذه المكونات، تشكل المكونات من [2] إلى [5] الذاكرة الفعالة للنظام، وكل منها يؤدي دورًا مميزًا.

البيانات الوصفية للجلسة

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

تلتقط هذه الطبقة إشارات حول البيئة المباشرة للمستخدم وأنماط الاستخدام الأخيرة. تتضمن الإشارات النموذجية ما يلي:

• معلومات الجهاز - على سبيل المثال، ما إذا كان المستخدم على الهاتف المحمول أو سطح المكتب

• سمات الحساب - مثل فئة الاشتراك (على سبيل المثال، ChatGPT Go)، وعمر الحساب، وتكرار الاستخدام الإجمالي

• المقاييس السلوكية - بما في ذلك الأيام النشطة على مدار الأيام 1 و7 و30 يوماً الماضية، ومتوسط طول المحادثة، وتوزيع استخدام النموذج (على سبيل المثال، 49% من الطلبات التي تم التعامل معها بواسطة GPT-5)

ذاكرة المستخدم

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

يمكن تحديث هذه الذاكرة بطريقتين:

• تحدثالتحديثات الصريحة عندما يدير المستخدمون الذاكرة مباشرةً بتعليمات مثل "تذكر هذا" أو "احذف هذا من الذاكرة".

• تحدثالتحديثات الضمنية عندما يحدد النظام المعلومات التي تفي بمعايير التخزين الخاصة بـ OpenAI - مثل اسم مؤكد أو مسمى وظيفي - ويحفظها تلقائيًا، مع مراعاة الموافقة الافتراضية للمستخدم وإعدادات الذاكرة.

ملخص المحادثة الأخيرة

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

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

رسائل الجلسة الحالية

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

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

نظام ذاكرة كلود

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

سياق موجه كلود منظم على النحو التالي:

[0] موجه النظام (تعليمات ثابتة)

[1] ذكريات المستخدم

[2] تاريخ المحادثة

[3] الرسالة الحالية

تكمن الاختلافات الرئيسية بين Claude و ChatGPT في كيفية استرجاع سجل المحادثة وكيفية تحديث ذاكرة المستخدم وصيانتها.

ذكريات المستخدم

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

يدعم كلود مسارين للتحديث:

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

• التحديثات الصريحة - يمكن للمستخدمين إدارة الذاكرة بشكل مباشر من خلال أوامر مثل "تذكّر هذا" أو "احذف هذا"، والتي يتم تنفيذها عبر أداة مخصصة memory_user_edits.

بالمقارنة مع ChatGPT، يضع Claude مسؤولية أكبر على النظام نفسه لتنقيح الذاكرة طويلة المدى وتحديثها وتشذيبها. وهذا يقلل من حاجة المستخدمين إلى تنظيم ما يتم تخزينه بنشاط.

تاريخ المحادثة

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

المكوّن	الغرض	كيفية استخدامه
النافذة المتجددة (المحادثة الحالية)	يخزّن سجل الرسائل الكامل للمحادثة الحالية (وليس ملخصًا)، على غرار سياق جلسة الدردشة في ChatGPT	يتم حقنه تلقائيًا. حد الرمز المميز هو 190 ألف تقريبًا؛ يتم إسقاط الرسائل القديمة بمجرد الوصول إلى الحد الأقصى
conversation_search أداة	البحث في المحادثات السابقة حسب الموضوع أو الكلمة المفتاحية، وإرجاع روابط المحادثة، والعناوين، ومقتطفات رسائل المستخدم/المساعد	يتم تشغيلها عندما يحدد النموذج أن هناك حاجة إلى تفاصيل تاريخية. تشمل المعلمات query (مصطلحات البحث) و max_results (1-10)
recent_chats الأداة	استرجاع المحادثات الحديثة ضمن نطاق زمني محدد (على سبيل المثال، "الأيام الثلاثة الماضية")، مع تنسيق النتائج بنفس تنسيق conversation_search	يتم تشغيلها عندما يكون السياق الحديث ذو صلة بالنطاق الزمني. تتضمن المعلمات n (عدد النتائج)، sort_order ، والنطاق الزمني

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

بشكل عام، يتميز نهج كلود للاسترجاع عند الطلب بالعديد من نقاط القوة الملحوظة:

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

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

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

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

القيود الكامنة وراء الاسترجاع عند الطلب على نمط كلود

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

1. تحمل الكمون المنخفض

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

2. متطلبات البحث الهجين

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

3. الفصل بين التخزين والحساب

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

4. أنماط استعلام متنوعة

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

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

لماذا يعمل ميلفوس 2.6 بشكل جيد للاسترجاع التحادثي

تتماشى خيارات التصميم في Milvus 2.6 بشكل وثيق مع المتطلبات الأساسية للاسترجاع التحادثي عند الطلب. فيما يلي تفصيل للقدرات الرئيسية وكيفية ارتباطها باحتياجات الاسترجاع التخاطبي الحقيقي.

الاسترجاع الهجين مع المتجهات الكثيفة والمتناثرة

يدعم برنامج Milvus 2.6 أصلاً تخزين المتجهات الكثيفة والمتناثرة في نفس المجموعة ودمج نتائجها تلقائيًا في وقت الاستعلام. تلتقط المتجهات الكثيفة (على سبيل المثال، التضمينات ذات 768 بُعدًا التي تم إنشاؤها بواسطة نماذج مثل BGE-M3) التشابه الدلالي، بينما تحافظ المتجهات المتفرقة (التي ينتجها عادةً BM25) على إشارات الكلمات الرئيسية الدقيقة.

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

الفصل بين التخزين والحساب وتحسين الاستعلامات

يدعم Milvus 2.6 التخزين المتدرج بطريقتين:

• البيانات الساخنة في الذاكرة، والبيانات الباردة في تخزين الكائنات

• الفهارس في الذاكرة، والبيانات المتجهة الخام في تخزين الكائنات

باستخدام هذا التصميم، يمكن تحقيق تخزين مليون مدخل محادثة باستخدام 2 جيجابايت تقريبًا من الذاكرة و8 جيجابايت من تخزين الكائنات. مع الضبط المناسب، يمكن أن يظل زمن انتقال P99 أقل من 20 مللي ثانية، حتى مع تمكين الفصل بين التخزين والحساب.

تمزيق JSON والتصفية السريعة للكمية الحجمية

يتيح الإصدار Milvus 2.6 من Milvus 2.6 إمكانية تمزيق JSON Shredding افتراضيًا، مما يؤدي إلى تسطيح حقول JSON المتداخلة في التخزين العمودي. يحسن هذا من أداء التصفية العددية بمقدار 3-5 أضعاف وفقًا للمعايير الرسمية (تختلف المكاسب الفعلية حسب نمط الاستعلام).

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

تحكم مفتوح المصدر ومرونة تشغيلية

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

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

لماذا اتخذ كل من ChatGPT وكلود مسارات مختلفة

على مستوى عالٍ، يكمن الفرق بين نظامي ذاكرة ChatGPT وClaude في كيفية تعامل كل منهما مع النسيان. يفضل ChatGPT النسيان الاستباقي: بمجرد أن تتجاوز الذاكرة الحدود الثابتة، يتم إسقاط السياق القديم. هذا يقايض الاكتمال بالبساطة وسلوك النظام الذي يمكن التنبؤ به. يفضل كلود النسيان المتأخر. من الناحية النظرية، يمكن أن ينمو سجل المحادثة دون حدود، مع تفويض الاسترجاع إلى نظام استرجاع عند الطلب.

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

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

بحلول عام 2025، تغير المشهد. فالتقدم في البنية التحتية - مدفوعًا بأنظمة مثل Milvus 2.6 -جعل الفصل بين التخزين والحساب، وتحسين الاستعلام، والاسترجاع الهجين الكثيف والمتناثر، وتقطيع JSON Shredding قابلاً للتطبيق في الإنتاج. تقلل هذه التطورات من زمن الاستجابة وتتحكم في التكاليف وتجعل الاسترجاع الانتقائي عمليًا على نطاق واسع. نتيجة لذلك، لم تصبح الأدوات عند الطلب والذاكرة القائمة على الاسترجاع عند الطلب ممكنة فحسب، بل أصبحت جذابة بشكل متزايد، خاصةً كأساس لأنظمة على غرار الوكيل.

في نهاية المطاف، تتبع خيارات الهندسة المعمارية ما تتيحه البنية التحتية.

الخاتمة

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

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

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

هل لديك أسئلة أو تريد التعمق في أي ميزة في أحدث إصدار من ميلفوس؟ انضم إلى قناة Discord الخاصة بنا أو قم بتسجيل المشكلات على GitHub. يمكنك أيضًا حجز جلسة فردية مدتها 20 دقيقة للحصول على رؤى وإرشادات وإجابات عن أسئلتك من خلال ساعات عمل Milvus المكتبية.