بناء pipeline مناسب

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

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

لذا شكل الـ Pipeline:

1. مرحلة الإدخال والمعالجة المسبقة:

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

   2. التقسيم Chunking، بتقسيم النص الكامل المستخرج من كل الملفات إلى Chunksأصغر وذات معنى، مثلاً، كل قطعة عبارة عن فقرة أو 300 كلمة.

   3. مرحلة الترميز والفهرسة:

• تحويل كل قطعة نصية إلى تمثيل رياضي يسمى Vector Embedding أي متجه رقمي يلتقط المعنى الدلالي للقطعة.
• ثم تخزين كل المتجهات في قاعدة بيانات متخصصة تسمى Vector Database مثل ChromaDB, Pinecone, FAISS والتي تتيح البحث عن المعلومات بناءًا على المعنى وليس فقط الكلمات المفتاحية.

   4. مرحلة الاسترجاع:

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

   5. مرحلة التوليد والتقييم:

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

ستحتاج في هذه الحالة إلى pipeline متعدد المراحل بحيث يبدأ بتحويل الملفات إلى نصوص عبر OCR إن لزم ثم تقسيمها إلى chunks صغيرة من حوالي 300 إلى 500 كلمة مع الحفاظ على السياق باستخدام hierarchical chunking حسب العناوين والفقرات.

أما للملفات الكبيرة التي تزيد عن +200 صفحة يمكنك تقسيمها إلى دفعات (batches) من 75 إلى 150 صفحة ومعالجتها بالتوازي لتجنب timeout مع تخزين ال embeddings في vector database مثل Milvus أو Pinecone.

البعض يستخدم نموذج RAG (Retrieval Augmented Generation) مع Arabic embedding model مثل AraBERT أو multilingual model بحيث يسترجع النظام المقاطع ذات الصلة من جميع الملفات المرفقة ثم يمرّرها إلى LLM عربي GPT-4 أو نماذج عربية محلية أخرى لتقييمها وإعطاء scoring مع feedback مفصل.

ولتحديد كفاية الملفات يمكنك أن تستخدم LLM-as-a-judge مع criteria scoring بحيث يقارن محتوى الملفات مقابل checklist المعايير المطلوبة ويخرج completeness score أي نسبة التغطية مع قائمة بالعناصر الناقصة أو المطلوب تحسينها، معتمدا على bidirectional coverage attention لضمان تطابق المتطلبات مع المحتوى.