هل أصبحت RAG قديمة العهد الآن مع ظهور وكلاء يعملون منذ فترة طويلة مثل كلود كورك؟

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

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

هذا يطرح سؤالين عمليين للمطورين:

1. إذا كان بإمكان النموذج أن يتذكر المعلومات السابقة بالفعل، فأين لا يزال RAG أو RAG الوكيل مناسبًا؟ هل سيتم استبدال RAG؟

2. إذا كنا نريد وكيلًا محليًا على غرار Cowork، كيف يمكننا تنفيذ الذاكرة طويلة المدى بأنفسنا؟

تتناول بقية هذه المقالة هذه الأسئلة بالتفصيل وتشرح كيف تتناسب قواعد البيانات المتجهة مع مشهد "الذاكرة النموذجية" الجديد هذا.

كلود كاورك مقابل RAG: ما الفرق بينهما؟

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

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

إذا كان كلا النظامين يساعدان النموذج على "التذكر"، فما الفرق الفعلي؟

كيف يتعامل Cowork مع الذاكرة

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

كيفية تعامل RAG و RAG العميل مع الذاكرة

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

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

طريقة أخرى للنظر إلى الأمر:

• تعتمد ذاكرة كاوورك على المهام: يقوم الوكيل بكتابة وقراءة حالته المتطورة الخاصة به.

• أما RAG فهي مدفوعة بالمعرفة: يسترجع النظام المعلومات الثابتة التي يجب أن يعتمد عليها النموذج.

الهندسة العكسية كلود كلود كاورك: كيف يبني ذاكرة عميل طويلة الأمد

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

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

إذا حللت بنية الطلب، سيبدو تقريبًا هكذا:

[0] Static system instructions
[1] User memory (long-term)
[2] Retrieved / pruned conversation history
[3] Current user message

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

ذاكرة المستخدم: الطبقة الدائمة

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

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

• تحديثات صريحة: يمكن للمستخدمين تعديل الذاكرة مباشرةً باستخدام الأداة memory_user_edits ("تذكر س"، "انسَ ص"). هذه الكتابات فورية وتتصرف مثل عملية CRUD.

تقوم كلود بتشغيل الاستدلال في الخلفية لتقرير ما يستحق الاستمرار، ولا تنتظر تعليمات صريحة.

استرجاع المحادثة: الجزء عند الطلب

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

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

• نوعًا من المطابقة الدلالية (التضمينات)

• ربما مقترنة بالتطبيع أو الترجمة الخفيفة

• البحث عن الكلمات الرئيسية في طبقات من أجل الدقة

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

كيف يختلف سلوك كلود في الاسترجاع عن مخازن السجل الأساسية

من الاختبارات والسجلات، تبرز بعض الأنماط:

• الاسترجاع ليس تلقائيًا. يختار النموذج متى يستدعيها. إذا اعتقد أن لديه بالفعل سياقًا كافيًا، فلن يزعج نفسه.

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

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

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

هذه البنية ذكية، ولكنها ليست مجانية:

• يضيف الاسترجاع وقتًا إضافيًا ومزيدًا من "الأجزاء المتحركة" (الفهرسة والترتيب وإعادة الترتيب).

• يخطئ النموذج أحيانًا في الحكم على ما إذا كان يحتاج إلى السياق أم لا، مما يعني أنك ترى "النسيان الكلاسيكي" على الرغم من توفر البيانات.

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

كلود كورك مقابل كلود كودكس في التعامل مع الذاكرة طويلة المدى

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

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

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

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

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

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

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

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

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

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

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

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

• الجهاز الذي تستخدمه

• حالة الحساب/الاشتراك

• أنماط الاستخدام التقريبي (الأيام النشطة، توزيع النموذج، متوسط طول المحادثة)

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

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

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

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

يظهر الاختلاف الأكبر عن Claude في كيفية تعامل ChatGPT مع المحادثات "الحديثة وليس الحالية". سيتصل كلود بأداة بحث لاسترداد السياق السابق إذا اعتقد أنه ذو صلة. لا يقوم ChatGPT بذلك.

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

• تلخص رسائل المستخدم فقط، وليس رسائل المساعدين.

• يخزن مجموعة صغيرة جدًا من العناصر - 15 عنصرًا تقريبًا - ما يكفي فقط لالتقاط المواضيع أو الاهتمامات الثابتة.

• لا تقوم بحساب التضمين ولا ترتيب التشابه، ولا تقوم باستدعاءات الاسترجاع. إنه في الأساس سياق تم مضغه مسبقًا، وليس بحثًا ديناميكيًا.

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

تحديات جعل ذاكرة الوكيل قابلة للكتابة

عندما ينتقل الوكيل من ذاكرة للقراءة فقط (RAG النموذجية) إلى ذاكرة قابلة للكتابة - حيثيمكنه تسجيل إجراءات المستخدم وقراراته وتفضيلاته - فإن التعقيد يقفز بسرعة. أنت لم تعد تسترجع المستندات فقط؛ أنت تحافظ على حالة متنامية يعتمد عليها النموذج.

يجب على نظام الذاكرة القابلة للكتابة أن يحل ثلاث مشاكل حقيقية:

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

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

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

التحدي 1: ما الذي يستحق التذكر؟

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

(1) الطرق الشائعة للحكم على الأهمية

تعتمد فرق العمل عادةً على مزيج من الاستدلال:

• المستند إلى الوقت: الإجراءات الحديثة أكثر أهمية من الإجراءات القديمة

• قائم على التكرار: الملفات أو الإجراءات التي يتم الوصول إليها بشكل متكرر أكثر أهمية

• على أساس النوع: بعض الأشياء بطبيعتها أكثر أهمية (على سبيل المثال، ملفات تكوين المشروع مقابل ملفات ذاكرة التخزين المؤقت)

(2) عند تعارض القواعد

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

(3) كيف تساعد قواعد البيانات المتجهة

تمنحك قواعد بيانات المتجهات آليات لفرض قواعد الأهمية دون تنظيف يدوي:

• TTL: يمكن لـ Milvus إزالة البيانات تلقائيًا بعد وقت محدد

• الاضمحلال: يمكن تقليل ترجيح المتجهات الأقدم حتى تتلاشى بشكل طبيعي من الاسترجاع

التحدي 2: تصنيف الذاكرة في الممارسة العملية

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

(1) تحديد متى تصبح الذاكرة باردة

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

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

(2) مكان تخزين الذاكرة الساخنة والباردة

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

(3) كيف تساعد قواعد البيانات المتجهة

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

التحدي 3: ما مدى سرعة كتابة الذاكرة؟

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

(1) لماذا تحتاج ذاكرة الوكيل إلى كتابات في الوقت الفعلي

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

(2) التوتر بين سرعة الكتابة وجودة الاسترجاع

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

(3) كيف تساعد قواعد البيانات المتجهة

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

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

الخلاصة

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

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

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

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