هندسة شخصية للاعتماد على سجل الدردشة

سؤال سريع، ما هو الهيكل “الأفضل” لحالة الاستخدام الخاصة بنا:

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

لدينا حوالي 10 ملفات، كل منها بحجم 1-2 ميجابايت تقريبًا. من حيث استخدام شخصية الذكاء الاصطناعي، سيكون لدينا حوالي 30 شخصًا يجرون حوالي 10 محادثات يوميًا (من الصعب تقدير حجم الرموز هنا).

في هذه المرحلة، أتساءل ما هو النهج المعقول بنسبة 80/20 للاستفادة من سجلات الدردشة هذه مع الحفاظ على اقتصاديتها. لقد توصلت إلى خيارين:

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

أي خيار توصون به؟ أو ربما شيء مختلف تمامًا؟

إعجاب واحد (1)

أوصي بالنهج التالي:

  1. معالجة الملفات العشر باستخدام شخصية “إبداعية” باستخدام نموذج لغوي كبير بسياق كبير / مخرجات كبيرة مثل Sonnet 4 thinking. سيكون الهدف من هذه المعالجة هو “ترتيب” المعلومات وإعدادها لـ RAG
  2. ثم باستخدام التحميل المدمج لدينا، تحميل الملفات العشر المعالجة إلى شخصية، حتى يتمكن RAG من البحث في المحتوى.

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

4 إعجابات

شكرًا، هذا يساعد!

للتوضيح فقط، هل يتم حقن جميع الملفات التي تم تحميلها في موجه النظام؟ أم تتم معالجتها أولاً من خلال ai_embeddings_model المُكوَّن ثم حقنها؟

أنا مرتبك بعض الشيء بشأن توصيتك بحد 10 آلاف رمز مميز خاصة مع الجزء أدناه:

الملفات الموجودة في Discourse AI Persona, upload support محدودة فقط بحجم التحميل الخاص بك، ويمكن أن تكون ضخمة، ويتم معالجتها عبر التضمين، ونحن نحقن أجزاء في المطالبة لكل تكوين.

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

وهذا محدود…

إعجاب واحد (1)

آه، هذا يوضح الأمر، شكرًا!

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

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

إعجابَين (2)

شكراً يا سام، أقدر ذلك حقاً :heart:

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

إعجابَين (2)

@sam كيف تقترح إضافة أرقام الإصدارات أو الطرازات إلى فواصل البيانات الوصفية؟

مثالك الأصلي:

[[بيانات وصفية عن القطط]]
قصة طويلة عن القطط
[[بيانات وصفية عن الكلاب]]
قصة طويلة عن الكلاب

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

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

[[بيانات وصفية عن القطط الإصدار 1.0]]
قصة طويلة عن القطط
[[بيانات وصفية عن الكلاب]]
قصة طويلة عن الكلاب
[[بيانات وصفية عن القطط XXL الإصدار 2.1]]
قصة طويلة عن القطط
[[بيانات وصفية عن الكلاب الإصدار 1.1 بيتا]]
قصة طويلة عن الكلاب

أيضًا، عندما تكون أرقام الإصدارات مفقودة في البيانات الوصفية (انظر بيانات وصفية عن الكلاب)، هل سيتم استخدام هذه القطعة في الرد على جميع الطلبات المتعلقة بالكلاب، بغض النظر عن “إصدار الكلب”؟

نعم، هذه هي الطريقة الصحيحة!

إعجابَين (2)