← أحدث الأبحاث
💻 computer science

Coligo: A Retrieval-Augmented Generation Assistant for WhatsApp-Based TNEA Engineering Admission Counselling

كوليجو (Coligo) هو مساعد توليد مدعوم بالاسترجاع (RAG) مُنشر عبر تطبيق واتساب، يعمل على تخفيف العبء الإداري لعمليات استشارات قبول الهندسة في تاميل نادو (TNEA) من خلال الاستفادة من نموذج "جوجل جيميناي" (Google Gemini) والبحث الشعاعي (vector search) في وثائق الكليات لتوفير إرشادات قبول دقيقة، وسياقية، ومحددة حسب الفئة، مع التمييز الصريح بين نموذجه الأولي الوظيفي وبنيته الكاملة المستهدفة.

المؤلفون الأصليون: Nithishkumar A, Nitin A V, Prasanna S

نُشر 2026-09-22
📖 1 دقيقة قراءة☕ قراءة في استراحة قهوة

المؤلفون الأصليون: Nithishkumar A, Nitin A V, Prasanna S

البحث الأصلي مرخَّص بموجب CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

ملخص تقني: Coligo – مساعد التوليد المعزز بالاسترجاع (RAG) لخدمات الاستشارات الخاصة بقبول الهندسة عبر واتساب (TNEA)

بيان المشكلة
تتسبب عمليات الاستشارات الخاصة بقبول الهندسة في تاميل نادو (TNEA) في حدوث اختناق للمكاتب الأمامية للكليات، حيث تتدفق إليها استفسارات متكررة تتعلق بإجراءات القبول، والرسوم لكل فرع، والحد الأدنى للدرجات (Cutoff) الخاص بكل فئة مجتمعية (OC, BC, BCM, MBC, SC, SCA, ST). تعتمد الحلول الحالية على التدخل اليدوي للموظفين أو روبوتات الدردشة العامة التي تفتقر إلى الفهم الدلالي والوصول إلى البيانات المؤسسية الموثقة. هناك فجوة حرجة في توفير إجابات تتميز بـ:

  1. الاستناد إلى المصادر: بناءً بشكل صارم على وثائق الكلية الرسمية بدلاً من هلوسة النماذج.
  2. الوعي بالفئات المجتمعية: التمييز بين الفئات الاحتياطية المختلفة وأنواع الحد الأدنى للدرجات (الدرجات مقابل الرتب).
  3. سهولة الوصول: متاحة على المنصة التي يستخدمها الطلاب بالفعل (واتساب) دون الحاجة لتثبيت تطبيقات جديدة.
  4. السياقية: القدرة على التعامل مع الأسئلة المتابعة (مثل: "ماذا عن ECE؟") دون مطالبة المستخدم بإعادة ذكر السياق الكامل.

المنهجية وهندسة النظام
Coligo هو نظام توليد معزز بالاسترجاع (RAG) مصمم كحزمة مكونة من جزأين عبر (Docker Compose) (خدمة FastAPI وقاعدة بيانات PostgreSQL). هندسة النظام هي كما يلي:

  • خط أنابيب الاستيعاب (Ingestion Pipeline): يتم معالجة ملفات PDF الرسمية للكليات (التي تدمج إجراءات القبول، الأكاديميات، والحد الأدنى للدرجات) عبر pypdf. يتم استخراج النص وتقسيمه إلى أجزاء متداخلة (512 كلمة مع تداخل قدره 50 كلمة) للحفاظ على السياق عبر الحدود. يتم تشفير الأجزاء (SHA-256) لمنع تكرار التضمين أثناء إعادة الاستيعاب.
  • التخزين الشعاعي (Vector Storage): يتم تضمين الأجزاء باستخدام نموذج Google text-embedding-004 (بأبعاد 768) وتخزينها في قاعدة بيانات PostgreSQL ممتدة بـ pgvector. وهذا يسمح بالبحث عن التشابه الدلالي باستخدام مسافة جيب التمام (cosine distance).
  • الاسترجاع والتوليد:
    • إعادة كتابة الاستعلام: للتعامل مع أسئلة المتابعة، يستخدم النظام ذاكرة قائمة على الجلسة (مرتبطة برقم هاتف واتساب أو معرف الجلسة). إذا كان الاستعلام يعتمد على السياق (مثل: "ماذا عن ECE؟")، يقوم استدعاء منفصل للنموذج اللغوي الكبير (LLM) بإعادة كتابة الاستعلام إلى صيغة مستقلة لأغراض الاسترجاع، بينما يتم الاحتفاظ بالاستعلام الأصلي لتوليد الإجابة النهائية.
    • خط أنابيب RAG: يقوم النظام باسترجاع أفضل 5 أجزاء ذات صلة (RAG_TOP_K=5). يتم دمج هذه الأجزاء مع "مطالبة نظام" (System Prompt) صارمة تفرض قواعد المجال: التمييز بين درجات الحد الأدنى والرتب، والاستجابة فقط لفئات مجتمعية محددة، ورفض الإجابة إذا كان السياق غير كافٍ.
    • التوليد: يقوم نموذج Google Gemini (LLM) بتوليد الاستجابة النهائية المستندة فقط إلى السياق المسترجع.
  • التكامل مع واتساب: يتصل النظام عبر واجهة برمجة تطبيقات واتساب السحابية (WhatsApp Cloud API). ويقوم بالتحقق من توقيع الويب هوك (X-Hub-Signature-256) وتوجيه الرسائل بناءً على هوية المرسل: توجه استفسارات الطلاب إلى خط أنابيب RAG، بينما توجه استفسارات المسؤول (Admin) لمعالجة الأوامر (رغم أن تنفيذ الأوامر محدود حالياً).
  • النشر: تم وضع الحزمة داخل حاويات باستخدام Docker Compose، مع إعدادات محددة للتعامل مع مشكلات حل أسماء النطاقات (DNS) في البيئات المعتمدة على الحاويات (عبر تثبيت حلول خارجية).

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

  1. خط أنابيب TNEA المحتوى في حاوية: نظام RAG يعمل على واتساب ويعتمد على استيعاب ملفات PDF الرسمية بدلاً من ذاكرة النموذج.
  2. مطالبة نظام خاصة بالمجال: تم تصميم "مطالبة نظام" (Prompt) للتعامل مع منطق TNEA الخاص، بما في ذلك معادلة حساب الحد الأدنى للدرجات (الرياضيات/2 + الفيزياء/4 + الكيمياء/4) وضرورة الاستجابات المعتمدة على الفئة المجتمعية.
  3. ذاكرة محادثة مرنة: تصميم ذاكرة محدودة بنطاق الجلسة، تتراجع بسلاسة إلى إجابات عديمة الحالة (stateless) في حال فشل الوصول إلى سجل قاعدة البيانات، بدلاً من الانهيار.
  4. نشر قابل لإعادة الإنتاج: إعداد Docker Compose موثق لـ PostgreSQL مع pgvector وFastAPI، بما في ذلك إصلاحات حل DNS للحاويات.
  5. تقرير شفاف: حساب موثق ومتحقق منه برمجياً لأي من مكونات الهندسة (مثل Redis، وعمال Celery، وتوجيه LLM متعدد المزودين، وتنفيذ أوامر المسؤول) لم يتم تنفيذها بعد، مما يمنع سوء تمثيل النموذج الأولي كنظام إنتاجي كامل.

النتائج والتحقق
قام المؤلفون بالتحقق من النظام عبر إعادة بناء الحزمة من حالة نظيفة وتشغيل كود الاستيعاب ضد ملف PDF مكون من 9 صفحات و5,048 كلمة من كلية "Sri Krishna College of Engineering and Technology" (SKCET).

  • الاستيعاب: نجح خط أنابيب الاستيعاب في معالجة ملف PDF إلى 11 جزءاً متداخلاً، حيث كان الجزء الأول عند 512 كلمة والأخير عند 428 كلمة، مما يؤكد عمل منطق تقسيم النصوص كما هو مقصود.
  • النشر: بدأت حزمة Docker Compose بالعمل بنجاح، مع عودة فحوصات الحالة (/health و /health/detailed) باستجابة HTTP 200 وتأكيد الاتصال بقاعدة البيانات.
  • القيود في التحقق: بسبب عدم وجود مفتاح GEMINI_API_KEY مهيأ في بيئة التحقق، لم يتم قياس زمن الاستجابة الفعلي، أو دقة الاسترجاع، أو مقاييس الاستناد إلى الإجابة رقمياً. تم التحقق من مرحلة "الاسترجاع والتوليد" عبر مراجعة الكود بدلاً من التنفيذ الحي.
  • توجيه المسؤول: بينما يكتشف النظام ويُسجل أوامر المسؤول (مثل /ingest و /stats) بشكل صحيح، فإن التنفيذ الفعلي لهذه الأوامر لم يتم تنفيذه بعد.

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

  1. الأمانة الهندسية: يوثق المؤلفون صراحةً "الفجوة" بين الهندسة المصممة (والتي تضمنت Redis و Celery وتوجيه LLM متعدد) وبين التنفيذ الحالي. ويجادلون بأن التمييز بين النموذج الأولي والهدف المعماري هو مساهمة في حد ذاتها، مما يضمن عدم خلط أصحاب المصلحة بين الحالة الحالية والتصميم النهائي.
  2. إمكانية الوصول العملية: من خلال استخدام واتساب، يزيل النظام حاجز تثبيت التطبيقات أمام الطلاب وأولياء الأمور، حيث يلتقي بهم في منصة مألوفة.
  3. الموثوقية المستندة إلى المصدر: يعطي النظام الأولوية للدقة الواقعية على الطلاقة، وهو مبرمج صراحةً لرفض الإجابة إذا كانت الوثيقة المصدر لا تحتوي على البيانات المحددة للفئة المجتمعية، مما يقلل من مخاطر هلوسة درجات الحد الأدنى للقبول.

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

غارق في أبحاث مجالك؟

تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.

جرّب Digest →