إبقاء وكلاء الذكاء الاصطناعي راسخين: استراتيجيات هندسة السياق التي تمنع تعفن السياق باستخدام ميلفوس

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

هذا ليس "تعب" النموذج - إنه تعفن السياق. مع نمو المحادثة، يضطر النموذج إلى التوفيق بين المزيد من المعلومات، وتتراجع قدرته على تحديد الأولويات ببطء. تُظهر دراسات أنتروبيك أنه مع امتداد نوافذ السياق من حوالي 8 آلاف رمز إلى 128 ألف رمز، يمكن أن تنخفض دقة الاسترجاع بنسبة 15-30%. لا يزال لدى النموذج متسع، ولكنه يفقد مسار ما هو مهم. تساعد نوافذ السياق الأكبر في تأخير المشكلة، لكنها لا تقضي عليها.

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

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

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

لماذا يحدث تعفن السياق

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

تُظهِر ذاكرتنا العاملة ذات السلوك المماثل - ولكن على نطاق أوسع بكثير ومع أنماط فشل أكثر دراماتيكية.

تأتي المشكلة الجذرية من بنية المحول نفسها. يجب أن يقارن كل رمز رمزي نفسه مع كل رمز رمزي آخر، مما يشكل اهتمامًا ثنائيًا عبر التسلسل بأكمله. هذا يعني أن الحساب ينمو O(n²) مع طول السياق. إن توسيع المطالبة من ألف رمز إلى 100 ألف لا يجعل النموذج "يعمل بجهد أكبر" - بل يضاعف عدد تفاعلات الرمز المميز بـ 10000 مرة.

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

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

والسؤال التالي هو: كيف نحافظ على انتباه النموذج دون أن نربكه في العمل؟

مناهج استرجاع السياق لحل تعفن السياق

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

1. الاسترجاع في الوقت المناسب: تقليل السياق غير الضروري

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

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

على سبيل المثال، إذا طلبت من Claude Code تحليل قاعدة بيانات بسعة 10 جيجابايت، فإنه لا يحاول أبدًا تحميل كل شيء. إنه يعمل مثل المهندس:

1. يقوم بتشغيل استعلام SQL لسحب ملخصات عالية المستوى لمجموعة البيانات.

2. يستخدم أوامر مثل head و tail لعرض عينة من البيانات وفهم بنيتها.

3. يحتفظ فقط بالمعلومات الأكثر أهمية - مثل الإحصائيات الرئيسية أو صفوف العينة - في السياق.

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

2. الاسترجاع المسبق (البحث المتجه): منع انجراف السياق قبل أن يبدأ

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

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

في إعداد RAG النموذجي:

• يتم تضمين المستندات وتخزينها في قاعدة بيانات متجهة، مثل Milvus.

• في وقت الاستعلام، يسترجع النظام مجموعة صغيرة من الأجزاء ذات الصلة العالية من خلال عمليات البحث عن التشابه.

• تدخل تلك القطع فقط في سياق النموذج.

هذا يمنع التعفن بطريقتين:

• الحد من الضوضاء: لا يدخل النص غير ذي الصلة أو ذي الصلة الضعيفة في السياق في المقام الأول.

• الكفاءة: تقوم النماذج بمعالجة عدد أقل بكثير من الرموز، مما يقلل من فرصة فقدان التفاصيل الأساسية.

يمكن لـ Milvus البحث في ملايين المستندات في أجزاء من الثانية، مما يجعل هذا النهج مثاليًا للأنظمة المباشرة حيث يكون زمن الاستجابة مهمًا.

3. الاسترجاع المسبق الهجين المستند إلى المتجهات

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

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

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

لذلك في أعباء العمل في العالم الحقيقي، فإن التطبيق الهجين هو الحل الأمثل.

• البحث المتجه عن معرفة مستقرة وعالية الثقة

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

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

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

1. البحث الناقل المدعوم من ميلفوس (الاسترجاع المسبق)

• قم بتحويل وثائقك ومراجع واجهة برمجة التطبيقات وسجلات التغيير والمشكلات المعروفة إلى تضمينات.

• قم بتخزينها في قاعدة بيانات Milvus Vector مع البيانات الوصفية مثل منطقة المنتج والإصدار ووقت التحديث.

• عندما يطرح أحد المستخدمين سؤالاً، قم بإجراء بحث دلالي للحصول على أهم المقاطع ذات الصلة.

يؤدي هذا إلى حل ما يقرب من 80% من الاستفسارات الروتينية في أقل من 500 مللي ثانية، مما يمنح النموذج نقطة انطلاق قوية ومقاومة للسياق.

2. الاستكشاف المستند إلى الوكيل

عندما يكون الاسترجاع الأولي غير كافٍ - على سبيل المثال، عندما يطلب المستخدم شيئًا محددًا للغاية أو حساسًا للوقت - يمكن للوكيل استدعاء أدوات لجلب معلومات جديدة:

• استخدم search_code لتحديد موقع دوال أو ملفات محددة في قاعدة الرموز

• استخدم run_query لسحب البيانات في الوقت الحقيقي من قاعدة البيانات.

• استخدم fetch_api للحصول على أحدث حالة للنظام

تستغرق هذه المكالمات عادةً من 3 إلى 5 ثوانٍ، لكنها تضمن عمل النموذج دائمًا ببيانات جديدة ودقيقة وذات صلة - حتى بالنسبة للأسئلة التي لم يتمكن النظام من توقعها مسبقًا.

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

يعتبر Milvus فعّالاً بشكل خاص في هذه السيناريوهات الهجينة لأنه يدعم:

• البحث المتجه + التصفية القياسية، والجمع بين الصلة الدلالية والقيود المنظمة

• تحديثات متزايدة، مما يسمح بتحديث التضمينات دون توقف

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

على سبيل المثال، يمكنك تشغيل استعلام مثل:

# You can combine queries like this in Milvus
collection.search(
    data=[query_embedding],  # Semantic similarity
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"nprobe": 10}},
    expr="doc_type == 'API' and update_time > '2025-01-01'",  # Structured filtering
    limit=5
)

كيفية اختيار النهج الصحيح للتعامل مع تعفن السياق

مع توفر كل من الاسترجاع المسبق للبحث المتجه، والاسترجاع في الوقت المناسب، والاسترجاع الهجين، فإن السؤال الطبيعي هو: أيهما يجب أن تستخدم؟

إليك طريقة بسيطة وعملية للاختيار بناءً على مدى استقرار معرفتك ومدى إمكانية التنبؤ باحتياجات النموذج من المعلومات.

1. البحث المتجه → الأفضل للمجالات المستقرة

إذا كان المجال يتغير ببطء ولكنه يتطلب الدقة - التمويل، والعمل القانوني، والامتثال، والوثائق الطبية - فعادةً ما تكون قاعدة المعرفة التي تعمل بنظام Milvus مع الاسترجاع المسبق هي الأنسب.

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

مهام يمكن التنبؤ بها + معرفة مستقرة → الاسترجاع المسبق.

2. الاسترجاع في الوقت المناسب → الأفضل لسير العمل الديناميكي والاستكشافي

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

مهام لا يمكن التنبؤ بها + معرفة سريعة التغير ← استرجاع في الوقت المناسب.

3. النهج الهجين → عندما يكون كلا الشرطين صحيحًا

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

• تحميل معرفة معروفة ومستقرة باستخدام البحث المتجه (سريع، منخفضة الكمون)

• جلب معلومات ديناميكية باستخدام أدوات الوكيل عند الطلب (دقيقة ومحدثة)

معرفة مختلطة + بنية مهام مختلطة → نهج الاسترجاع الهجين.

ماذا لو كانت نافذة السياق لا تزال غير كافية

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

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

في الآونة الأخيرة، قدمت أنثروبيك ثلاث استراتيجيات عملية.

1. الضغط: الحفاظ على الإشارة وإسقاط الضوضاء

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

• القرارات الرئيسية

• القيود والمتطلبات

• القضايا المعلقة

• العينات أو الأمثلة ذات الصلة

ويزيل

• مخرجات الأداة المطولة

• السجلات غير ذات الصلة

• الخطوات الزائدة عن الحاجة

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

2. التدوين المنظم للملاحظات: نقل المعلومات المستقرة خارج السياق

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

على سبيل المثال، يخزّن نموذج بوكيمون-وكيل كلود حقائق دائمة مثل:

• Pikachu leveled up to 8

• Trained 1234 steps on Route 1

• Goal: reach level 10

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

التدوين المنظم للملاحظات يمنع تعفّن السياق الناجم عن التفاصيل المتكررة وغير الضرورية مع إعطاء النموذج مصدرًا موثوقًا للحقيقة.

3. بنية الوكيل الفرعي: تقسيم المهام الكبيرة

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

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

يعمل كل نهج على توسيع "الذاكرة العاملة" الفعالة للنظام دون إفساد نافذة السياق - ودون التسبب في تعفن السياق.

أفضل الممارسات لتصميم سياق يعمل بالفعل

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

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

موجهات النظام: البحث عن منطقة المعتدل

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

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

على سبيل المثال:

You are a technical documentation assistant serving developers.
1. Start by retrieving relevant documents from the Milvus knowledge base.  
2. If the retrieval results are insufficient, use the `search_code` tool to perform a deeper search in the codebase.  
3. When answering, cite specific documentation sections or code line numbers.
## Tool guidance

search_docs: Used for semantic retrieval, best for conceptual questions.
search_code: Used for precise lookup in the codebase, best for implementation-detail questions.

…

تحدد هذه المطالبة التوجيهات دون إرباك النموذج أو إجباره على التلاعب بالمعلومات الديناميكية التي لا تنتمي إلى هذا المكان.

تصميم الأداة: الأقل هو الأكثر

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

هناك قاعدة عامة جيدة:

• أداة واحدة، غرض واحد

• معلمات واضحة لا لبس فيها

• عدم تداخل المسؤوليات

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

يجب استرجاع المعلومات الديناميكية وليس ترميزها بشكل ثابت

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

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

الخاتمة

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

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

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

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

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

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

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