مقارنة تقنية لتحدي RAG

ما الذي يتناوله هذا المنشور

شاركتُ في تحدي RAG (التوليد المعزز بالاسترجاع) المنظَّم من قِبل ARSII بالشراكة مع Rose Blanche Group. كان التحدي يحتوي على قواعد مكتوبة وواضحة تحدد القيود التقنية بدقة. الحل الفائز لا يستخدم PostgreSQL، في حين أن ملف PDF الخاص بالمسابقة ينص صراحةً على أن استخدامها شرط إلزامي. أثرتُ هذه المسألة مع المنظمين، ولم يصلني أي رد حتى تاريخ نشر هذا المنشور.

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

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

قواعد المسابقة

اقترح هذا التحدي Rose Blanche Group (STE AGRO MELANGE TECHNOLOGIE). الجائزة: قسيمة شراء بقيمة 1000 دينار تونسي.

وصف التحدي الرسمي

Développer un module de recherche sémantique permettant d'interroger cette base vectorielle (RAG)
AR: تطوير وحدة بحث دلالي للاستعلام عن هذه القاعدة المتجهية (RAG)

Dans un contexte où une base documentaire contient un grand volume d'informations [...] L'objectif est de développer un module intelligent capable d'assister l'utilisateur en retrouvant automatiquement les fragments les plus pertinents à partir d'une question formulée en langage naturel.
AR: في سياق تحتوي فيه قاعدة وثائق على حجم كبير من المعلومات [...] الهدف هو تطوير وحدة ذكية قادرة على مساعدة المستخدم عبر استرجاع المقاطع الأكثر صلةً تلقائياً من سؤال صاغه بلغة طبيعية.

ملف PDF التقني الرسمي — القيود الحرفية

يُحدد ملف PDF للمسابقة (Développement d'un Module de Recherche Sémantique pour la Formulation en Boulangerie & Pâtisserie) ما يلي حرفياً:

السياق: Ces fiches ont déjà été : Converties en texte, Découpées en fragments (chunks), Transformées en embeddings, Stockées dans une base PostgreSQL
AR: هذه البطاقات جرى بالفعل: تحويلها إلى نص، وتقطيعها إلى مقاطع (chunks)، وتحويلها إلى تضمينات (embeddings)، وتخزينها في قاعدة بيانات PostgreSQL

الموارد المتاحة: Base de données PostgreSQL — Table : embeddings — Structure : id (Primary Key), id_document (int), texte_fragment (text), vecteur (VECTOR(384))
AR: قاعدة بيانات PostgreSQL — الجدول: embeddings — الهيكل: id (المفتاح الأساسي)، id_document (int)، texte_fragment (text)، vecteur (VECTOR(384))

المعاملات المفروضة: Méthode de similarité : Cosine Similarity — Nombre de résultats à retourner : Top K = 3 — Langage recommandé : Python

نموذج التضمين المطلوب: Modèle imposé : all-MiniLM-L6-v2 — Bibliothèque : sentence-transformers — Dimension : 384

مثال على الاستعلام: Améliorant de panification : quelles sont les quantités recommandées d'alpha-amylase, xylanase et d'Acide ascorbique ?
AR: مُحسِّن الخبز: ما الكميات الموصى بها من alpha-amylase وxylanase وحمض الأسكوربيك؟

قيد قاعدة البيانات ليس مجرد اقتراح. ينص ملف PDF على أن البيانات "Stockées dans une base PostgreSQL" (مخزَّنة في قاعدة بيانات PostgreSQL) ويوفر مخطط جدول دقيقاً بأنواع بيانات تشمل vecteur VECTOR(384) — وهو نوع بيانات لا يوجد إلا في PostgreSQL عبر امتداد pgvector. التحدي بأكمله مُؤطَّر حول الاستعلام عن هذه القاعدة المتجهية في PostgreSQL.

ما الذي يختبره هذا التحدي فعلاً

القيود المذكورة أعلاه ليست اعتباطية. إنها تُحدد مسألة هندسية محددة للغاية: بالنظر إلى نموذج تضمين صغير (22 مليون معامل، 384 بُعداً)، وعمق استرجاع ثابت (K=3)، وقاعدة بيانات PostgreSQL محلية — ما مدى قدرتك على المعالجة المسبقة للبيانات وهيكلتها وتحسينها للحصول على أفضل نتائج استرجاع ممكنة؟

هذا تحدٍّ في هندسة البيانات والتحسين، وليس تمريناً في ربط واجهات برمجية (APIs). النموذج الثابت، وK الثابت، واشتراط قاعدة البيانات المحلية — كلها موجودة تحديداً لتوفير تكافؤ الفرص بين المتسابقين وقياس ما يفعله كل مشارك مع البيانات ذاتها: جودة استخراج PDF، واستراتيجية التقطيع، وطريقة هيكلة التضمينات، ومعالجة الاستعلامات.

لو كان التحدي مجرد بناء نظام RAG، لأمكن لأي أحد توصيل LangChain بواجهة برمجية لنموذج لغوي ضخم (LLM) للحصول على إجابات سلسة في دقائق. لكن هذا النهج لا يتطلب أي تحسين، ويتكبد تكاليف API مرتفعة، ويرسل بيانات مؤسسية ربما تكون حساسة إلى موفرين خارجيين، ولا يُثبت أي فهم لآليات الاسترجاع الجوهرية. المسابقة تلغي هذا المختصر عمداً بفرض إعداد محلي ومكتفٍ بذاته.

المهارة الحقيقية التي يتم اختبارها هي: هل يمكنك جعل نموذج بعشرين ومليوني معامل يتجاوز قدرته الظاهرة من خلال المعالجة الذكية للبيانات وهندسة البحث؟

الحل الفائز لا يستخدم PostgreSQL

كود الفريق الفائز متاح للعموم على: github.com/AyaZantour/RagProject. إليك ما تفعله طبقة التخزين لديهم فعلاً.

vector_store.py — الأسطر 57–68 (دالة الحفظ)

def save(self, path: str) -> None:
    os.makedirs(os.path.dirname(path) if os.path.dirname(path) else ".", exist_ok=True)
 
    np.savez_compressed(f"{path}.npz", embeddings=self.embeddings)
    with open(f"{path}.json", "w", encoding="utf-8") as f:
        json.dump(self.metadata, f, ensure_ascii=False, indent=2)

vector_store.py — الأسطر 94–119 (دالة البحث)

def search(self, query: str, top_k: int = 3) -> list:
    # Embed the query
    query_embedding = self.model.encode(
        [query],
        convert_to_numpy=True,
        normalize_embeddings=True
    )
 
    # Cosine similarity (dot product since vectors are normalized)
    similarities = np.dot(self.embeddings, query_embedding.T).flatten()
 
    # Get top-k indices
    top_indices = np.argsort(similarities)[::-1][:top_k]

يُنفَّذ البحث عبر الضرب النقطي لـ NumPy على مصفوفات في الذاكرة. لا استعلام قاعدة بيانات. لا ORDER BY بـ SQL. لا عامل <=> في pgvector.

requirements.txt

PyPDF2>=3.0.0
sentence-transformers>=2.2.0
numpy>=1.24.0
flask>=3.0.0
groq>=0.4.0

مخطط الجدول المطلوب (من ملف PDF للمسابقة)

CREATE TABLE embeddings (
    id             SERIAL PRIMARY KEY,
    id_document    INT,
    texte_fragment TEXT,
    vecteur        VECTOR(384)
);

النوع VECTOR(384) لا يوجد إلا في PostgreSQL عبر امتداد pgvector. لا يذكر ملف PDF صراحةً pgvector، لكن المخطط يستلزمه ضرورةً. على أي حال، هذا جدول PostgreSQL — وليس ملفات NumPy.

حلّي — الامتثال الكامل

الكود متاح للعموم على: github.com/mohamedyaakoubi/RBG-ARSII-RAG.

docker-compose.yml — PostgreSQL مع pgvector

services:
  postgres-vector:
    build: .
    container_name: postgres-vector-db
    environment:
      POSTGRES_USER: rag
      POSTGRES_PASSWORD: ragpassword
      POSTGRES_DB: ragdb
    ports:
      - "5432:5432"

Dockerfile — PostgreSQL 16 + pgvector

FROM postgres:16
 
RUN apt-get update && apt-get install -y \
    git build-essential postgresql-server-dev-16
 
RUN git clone https://github.com/pgvector/pgvector.git \
    && cd pgvector && make && make install
 
COPY init.sql /docker-entrypoint-initdb.d/

init.sql

CREATE EXTENSION IF NOT EXISTS vector;

مخطط الجدول المطلوب بالضبط (database/models.py)

cursor.execute(f"""
    CREATE TABLE IF NOT EXISTS embeddings (
        id              SERIAL PRIMARY KEY,
        id_document     INT,
        texte_fragment  TEXT,
        vecteur         vector({config.EMBEDDING_DIMENSION})
    )
""")

البحث بتشابه جيب التمام عبر pgvector (database/models.py)

cursor.execute("""
    SELECT
        id_document,
        texte_fragment,
        1 - (vecteur <=> %s::vector) AS score
    FROM embeddings
    ORDER BY vecteur <=> %s::vector
    LIMIT %s
""", (query_vector.tolist(), query_vector.tolist(), top_k))

العامل <=> هو عامل مسافة جيب التمام في pgvector — متوافق مع نوع العمود VECTOR(384) واشتراط تشابه جيب التمام في التحدي.

ملخص الامتثال للقيود

جودة الاسترجاع — اختبار أداء قابل للتكرار

تم اختبار كلا الحلين بنفس 16 استعلاماً، ونفس نموذج التضمين (all-MiniLM-L6-v2)، وK=3. الدرجة = تشابه جيب التمام للمقطع الأول المُسترجَع (R1). القيمة الأعلى تعني استرجاعاً أفضل.

طريقة إعادة التشغيل

الحل الفائز:

• استنسخ github.com/AyaZantour/RagProject
• pip install -r requirements.txt
• شغّل python app.py — يُبنى الفهرس تلقائياً عند أول تشغيل
• أرسل طلب POST إلى /search بصيغة {"query": "سؤالك"} أو استخدم واجهة الويب

حلّي:

• استنسخ github.com/mohamedyaakoubi/RBG-ARSII-RAG
• شغّل docker-compose up -d لتشغيل PostgreSQL
• pip install -r requirements.txt
• python main.py (يُشغّل الاستيعاب ثم يُشغّل واجهة Streamlit)

نتائج الاختبار

مدى مفيدية الإجابات — ما الذي يُعيده كل نظام فعلاً

بعيداً عن درجات التشابه، السؤال الجوهري هو: هل يُجيب المقطع المُسترجَع فعلاً على سؤال المستخدم؟

6.1 استعلام مثال المسابقة

6.2 الاستعلامات الفرنسية — معالجة اللغة

6.3 استعلامات المنتجات المحددة

6.4 ملخص تقييم مدى مفيدية الإجابات

مقارنة جودة المقاطع

حلّي — مقاطع محورية الكيانات (استخراج pdfplumber)

Dosage alpha-amylase (BVZyme AF330) boulangerie panification : 2-10.

BVZyme HCB710 (xylanase): Product: Enzyme preparation based on endo-xylanase.
Source: Bacterial xylanase produced by fermenting a selected unique strain of
Bacillus subtilis. Activity: 583 XylH/g.

BVZyme AF110 (alpha-amylase) storage conditions and shelf life: minimum
durability: 24 months. Store in a cool, dry place (below 20°C).

الحل الفائز — نافذة منزلقة ذات حجم ثابت (استخراج PyPDF2)

Product Description
Enzyme preparation based on Maltogenic Amylase
 
 
 Effective material
 
 
 
 
 Improve freshness, enhance softness, and extend shelf life.
 
 
 Dosage
Aspect: free flowing powder
Color: white -cream
 Physicochemical
Moisture: <15%

ustries.TECH NICAL DATA SHEET   BVZyme TG MAX64 « Bakery Enzyme
Product Description     BVZyme  TG MAX64 « is used in bakery as a strong
protein cross-linking(connecting residues of the amino acid L-glutamine
to the amino acid £¿L-lysine)Application

سبب الفجوة التقنية

الأمر لا يتعلق بأن أحد الفريقين "أفضل" — بل يتعلق بالخيارات المعمارية التي صُمم التحدي لاختبارها.

استخراج PDF

استراتيجية التقطيع

استراتيجية التضمين

هندسة البحث

النطاق والنهج

لا يملك LLM وصولاً إلى ملفات PDF الأصلية أو أي مصدر معرفي خارجي — يرى المقاطع الثلاث المُسترجَعة فقط. أخطاء الاسترجاع الموثقة في القسم 6 تنتقل مباشرةً إلى الإجابة النهائية. حين يُعيد الاسترجاع محتوى خاطئاً، تَرث الإجابة المُولَّدة بواسطة LLM تلك الأخطاء بصرف النظر عن مدى سلاسة المخرجات.

قابلية التوسع — كيف يتعامل كل نظام مع المنتجات الجديدة

قابلية التوسع لم تكن متطلباً معلناً في المسابقة. لكن نظام RAG الذي لا يعمل إلا على البيانات التي بُني عليها ليس نظام RAG — بل هو جدول بحث. النقطة الكاملة من التوليد المعزز بالاسترجاع هي أنه يمكن إضافة وثائق جديدة والاستعلام عنها دون تعديل المسار. يختبر هذا القسم تعميم الاسترجاع: هل النهج الهندسي لكل نظام متين فعلاً أم مُعايَر فقط على الـ35 ملف PDF الأصلية؟

أضفتُ 6 ملفات PDF منتجات جديدة لم تكن في مجموعة البيانات الأصلية: GEbake Amyl، وDomax SF Bingo Plus، وTigris Gold، وO-TENTIC DURUM، وصحيفة مواصفات حمض الأسكوربيك، ووثيقة ترخيص مضافات. شُغِّل 10 استعلامات وقُيِّمت بـمدى مفيدية الإجابة: هل تأتي R1 من ملف PDF المنتج الصحيح، وهل يحتوي المقطع فعلاً على الإجابة؟

استراتيجية التقطيع محوري الكيانات تُضيف بادئة اسم المنتج لكل مقطع، مما يتيح لنموذج التضمين تمييز المنتجات بهويتها حتى مع نمو قاعدة البيانات. دون هذا التثبيت، تتنافس مقاطع الحل الفائز ذات الرؤوس العامة عبر ملفات PDF — مُعيدةً مقاطع حمض الأسكوربيك لاستعلامات Tigris Gold وO-TENTIC DURUM.

التخزين مقابل الدقة — المقايضة بين المساحة والحوسبة

يُخزن حلّي 9.3× أكثر من تضمينات الحل الفائز (1,635 مقابل 176). السؤال الطبيعي هو: ما تكلفة ذلك، وما العائد منه؟

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

يسلك الحل الفائز المسار المعاكس: مقاطع أقل وأكبر تخلط أوصاف المنتجات وجداول الجرعات والخصائص الفيزيائية في نوافذ من 500 حرف. هذا يوفر تخزيناً لا يُذكر لكنه يُجبر نموذج التضمين على ضغط مفاهيم غير مترابطة في متجه واحد بـ384 بُعداً — بالضبط السيناريو الذي يفقد فيه النموذج الصغير قوته التمييزية.

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

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

يستخدم حلّي PostgreSQL مع pgvector الذي يدعم فهارس HNSW وIVFFlat للجار الأقرب التقريبي. هذه تخفض البحث من O(n) إلى O(log n)، مما يبقي زمن الاستجابة تحت 10 مللي ثانية حتى عند مئات الآلاف من المتجهات. الحل الفائز يستخدم البحث الشامل لـ NumPy بدون هيكل فهرسة — لا يتيح توسعاً دون تربيع زمني دون إعادة كتابة جذرية.

عدم التوازن الحقيقي في التكاليف: استدعاء Groq API لكل استعلام له زمن استجابة متغير، وتكلفة نقدية لكل رمز، واعتماد على توفر خدمة خارجية. التخزين الإضافي لحلّي لا يُكلف شيئاً للتشغيل بعد الكتابة على القرص.

استجابة الجهة المنظمة

في 18 مارس 2026، أرسلتُ بريداً إلكترونياً رسمياً إلى ARSII يتضمن تقرير المقارنة التقنية الكامل، وطلبتُ شرحاً لمعايير التقييم المُستخدمة.

كان رد ARSII بريداً إلكترونياً جماعياً لجميع المشاركين (وليس رداً مباشراً):

"We would like to clarify that ARSII does not interfere in the evaluation process of the challenges, except for those proposed by ARSII itself. Each challenge is assessed independently by the respective partner organization responsible for it."
AR: «نودّ أن نوضّح أن ARSII لا تتدخل في عملية تقييم التحديات، باستثناء تلك المقترحة من ARSII نفسها. يُقيَّم كل تحدٍّ بشكل مستقل من قبل المنظمة الشريكة المعنية.»

"In case of any objections or concerns, you are absolutely welcome to submit a reclamation. We will ensure that you are put in direct contact with the responsible party of the challenge."
AR: «في حال وجود أي اعتراضات أو مخاوف، يسعدنا تلقّي شكواكم. سنحرص على وضعكم في تواصل مباشر مع الجهة المسؤولة عن التحدي.»

وفقاً لهذا الرد، تُفوِّض ARSII تقييم التحديات إلى الجهة الشريكة المعنية. المسار المتاح هو التواصل المباشر مع Rose Blanche Group.

حتى 26 مارس 2026، لم يصلني أي رد مباشر، ولم يُصدَر أي إقرار بالتناقض الموثق في متطلبات المسابقة.

ما يُثبته هذا المنشور

هذا المنشور سجلٌ عام للنتائج، وليس طلباً. الأدلة المُقدَّمة هنا قابلة للتحقق بشكل مستقل من أي شخص لديه وصول إلى مستودعَي GitHub وملف PDF للمسابقة. تحديداً:

• الحل الفائز لا يستخدم PostgreSQL — ظاهر في الكود المصدري (القسم 2).
• جودة الاسترجاع أدنى قياساً على كل مقياس اختُبر — تشابه جيب التمام، ومفيدية الإجابة، ودقة المنتج.
• لم تُشرح عملية التقييم. ما المعايير المُستخدمة؟ إذا كان قيد PostgreSQL قد أُعفي، متى وكيف أُبلغ المشاركون؟

هذه ملاحظات موثقة. للقارئ أن يستخلص استنتاجاته بنفسه.

جميع الأدلة — تحقق بنفسك

كل ما وُرد في هذا المنشور قابل للتحقق العلني:

الخلاصة

حلّي يمتثل لجميع قيود المسابقة، ويحقق دقة استرجاع أعلى بنسبة 40.4%، ويُعيد محتوى صحيحاً وقابلاً للتطبيق لـ14 من أصل 16 استعلاماً (مع 0 فشل تام)، وذلك كله دون اتصال بالإنترنت ودون اعتماد على APIs خارجية.

استرجاع الحل الفائز — المهمة الجوهرية للتحدي — يسجل درجات أدنى على كل مقياس اختُبر. مع 176 مقطعاً مُنتَجاً بنافذة منزلقة ذات عرض ثابت، ودون معالجة للفرنسية، ودون تفكيك استعلام، ودون PostgreSQL (وهو شرط مُصرَّح به)، وفقط 4 من 16 استعلاماً تُعيد بيانات قابلة للاستخدام، و5 حالات فشل تام في الاختبار الأساسي، لا تتوافق المخرجات الملاحظة مع مواصفات المسابقة.

كسياق إضافي (غير مُحتسَب — قابلية التوسع لم تكن متطلباً): يتوسع Noobmaster للمنتجات غير المرئية دون إعادة نتائج منتجات خاطئة (5/10 ناجح تماماً، 5/10 جزئي، 0 فشل)، بينما يسترجع الحل الفائز المنتج الخاطئ في 3 من 10 استعلامات منتجات جديدة مع نجاح كامل واحد فقط.

نُفِّذ الاختبار في الفترة 17–26 مارس 2026. كلا الحلين اختُبرا بنفس 16 استعلاماً + 10 استعلامات قابلية توسع، ونفس نموذج التضمين (all-MiniLM-L6-v2)، ونفس K=3، على نفس الجهاز. درجات الاسترجاع هي قيم تشابه جيب التمام القابلة للتكرار. قُيِّمت مفيدية الإجابات بمراجعة يدوية لكل مقطع R1 مقارنةً بمحتوى ملف PDF المصدر — دون مطابقة تلقائية بالكلمات المفتاحية. جرى التحقق المتقاطع لمفيدية إجابات قابلية التوسع مقابل ملفات PDF المصدر باستخدام pdfplumber.

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