Vector DB Testing

انظر المعايير

كيفية استخدام

• تأكد من تثبيت الحزم المناسبة. تأكد من تثبيت ما يلي: sentence_transformers tqdm pandas pypdf2 torch asyncio convers
• قم بتحميل جميع PDF إلى /بيانات /أو دليل آخر إذا تم تحديده.
  • إذا كان لديك ملف بيانات تعريف لمزيد من المعلومات حول ملفات PDF ، فقم بتحميله على الدليل الرئيسي وتسمية Metadata.csv أو تغيير الاسم. من المحتمل أن يتم تغيير الكود في get_metadata () في MacLoader من أجل استيعاب ملف البيانات الوصفية المحددة.
• تفاصيل اتصال الإدخال في .env. انظر .env-example لما يجب أن يبدو عليه .env.
  • يمكن تجنب ذلك إذا كنت تريد فقط إدخال التفاصيل كجزء من تهيئة DB في الكود بدلاً من ذلك.
• إنشاء ملف Python الفهرس. من هنا أود تحديد التسجيل المناسب. مع كل البيانات ، من المهم البحث عن أي مشكلات. يتم تسمية جميع قطع الأشجار بشكل مناسب باستخدام المعلومات والتحذير والخطأ والحرجة.
• إنشاء delete.txt ، لا تضع أي شيء فيه.
• استيراد الملفات المناسبة من المشروع وتهيئتها بالتفاصيل المناسبة. يتم توثيق جميع المعايير المتاحة جيدًا ويجب أن تظهر من قبل IDE عبر التحويم أو النقر.
  • على سبيل المثال: from Loader import MacLoader from databases.PineconeDB import PineconeDB
• بعد القيام بمجموعة من ملفاتك ، تحقق من DELETE.TXT ومعرفة الملفات التي تعطي مشكلات مع قارئ PYPDF2. إذا كنت ترغب في إزالة هذه الملفات ، فاستخدم Utility.delete_bad_pdfs ()
• استمتع ، اسمحوا لي أن أعرف كيفية تحسين هذه العملية!

الوجبات الرئيسية

ما قبل المعالجة

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

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

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

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

التضمين / المحولات

لم يكن اختيار محولات الجملة أمرًا صعبًا للغاية.

• كانت كل minilm-V2 جيدة وسريعة ، لكنني كنت قلقًا بشأن قابلية التوسع مع كميات هائلة من البيانات. ليس الأكثر دقة ولكن لا يزال جيدا ، ليس فقط للإنتاج.

• فشل E5-LARGE-V2 في استرداد البيانات الأساسية على نطاق صغير في اختباراتي. بسبب هذا لن أفكر في ذلك على نطاق أوسع أيضًا.

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

• All-MPNET-V2 هو الأفضل في كل مكان من حيث السرعة والأداء ، وربما لا تكون دقيقة مثل تضمينات المدرب ولكن قد تفضل السرعة والأداء في بيئة الإنتاج.

• ستكون ADA (Openai) تضمينات أغلى بكثير من محولات الجملة المحلية النموذجية. في الماضي ، واجهت مشكلات في معالجة مجموعات بيانات ضخمة بسبب حدود الأسعار والقيود الأخرى التي يفرضها نموذجها. إن إرسال البيانات المرسلة في القطع سيحل هذه المشكلة.

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

الاختيار النهائي: غير محدد. أحتاج إلى الانتهاء من المعالجة المسبقة أولاً قبل الاختيار بين الأدوات أو mpnet

قواعد بيانات المتجهات

قواعد البيانات المرفوضة

• Chroma
  • تفتقر إلى خيارات نشر الخادم. بالنسبة للمشاريع الصغيرة ، سيكون هذا دائمًا هو الخيار الأفضل على الرغم من أنني أعتقد.
• PGVector
  • أداء سيئ للغاية في المعايير لسبب ما. قد لا يكون ممثل الأداء في العالم الحقيقي. انظر هنا
  • إذا كان من المقرر بالفعل أن تكون قاعدة بيانات PostResQL قيد الاستخدام ، أو من العملي بالنسبة للبيانات المحددة ، فلا شك أن PGVector سيكون الخيار الأفضل. ومع ذلك ، لن أستخدم مكتبة PGVector بمفردها أو التبديل إلى PostresQL لذلك.
• مرنة
  • بطيئة وعلاقة
• Weaviate
  • سبق أن خططت لتقييم هذا ، لكن أثناء محاولة تنفيذ هذا في هذا البرنامج ، واجهت صعوبة أكبر بكثير مقارنة بجميع الآخرين.
    • إن الوثائق الخاصة بعميل Python ليست رائعة على الإطلاق ، لم يكن الأمر صعبًا ولكن عدم وجود توثيق يقلق.
    • حالة الاستخدام الخاصة بي هي التخطيط لاستخدام سحابة مُدارة ، وجعلتني WCS تقلق حقًا. لا يبدو أن هناك الكثير من الأمن ، لا يوجد حتى 2FA. أنا شخصياً لا أثق في WCS ، وكان لديها أسوأ واجهة مستخدم مقارنة بأي من قواعد البيانات الأخرى.
    • إذا تم التخطيط للاستخدام في حاوية Docker ، فيجب إعادة النظر في Weaviate وإعطاء لقطة عادلة ، لكنني في الوقت الحالي لا أستمر في تقييمها.

التحقيق حاليا

• كوز الصنوبر
• ميلفوس
• Qdrant

اعتبارات من العملية برمتها

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