تصنيف وتوجيه طلبات اللاجئين من نموذج تسجيل إلى الفريق المختص

التفاصيل البرمجية والتهيئة

## المشكلة منظمة لاجئين تستقبل 50-200 طلب تسجيل شهرياً عبر نموذج ويب. الفريق الإداري يقرأ كل طلب يدوياً، يحدد الفئة (الأسرة بحاجة لدعم نفسي؟ مشكلة قانونية؟ تعليم للأطفال؟ صحة؟)، ثم يوجّهه. التأخير يضرّ بالحالات العاجلة، وعدم التوحيد في التصنيف يصعّب التقارير لاحقاً. ## المُدخلات - نموذج تسجيل ويب (Baserow Forms أو APITable Forms أو Tally) بأسئلة منظمة - نموذج LLM يدعم العربية بقوة: qwen2.5:14b محلي - قاعدة مستفيدين في APITable مع حقول مصنّفة - قائمة منسّقي الفرق وتخصصاتهم في APITable - قاموس مصطلحات للحالات العاجلة (كلمات تشير لـ priority عالية) ## المُخرجات - صف جديد في APITable بحقل التصنيف المقترح + مستوى الأولوية + المنسّق المُسنَد - إيميل/Telegram للمنسّق بتفاصيل الحالة (مع روابط لوثائق مرفوعة) - إيميل تأكيد للمستفيد بلغته المختارة (عربي، فارسي، أوردو، إنجليزي) - تنبيه فوري للمشرف إذا كُشِفت حالة طوارئ (تهديد بانتحار، عنف أسري حاد، طارئ طبي) ## مخطط Mermaid ```mermaid graph TD A[نموذج تسجيل ويب] -->|Submit| B[APITable/Baserow Form] B -->|Webhook| C[n8n Workflow] C --> D{فحص اللغة} D -->|غير العربية| E[LibreTranslate إلى ar] D -->|عربية| F E --> F[Ollama qwen2.5 - Classify] F --> G{Category + Priority?} G -->|طوارئ| H[Alert المشرف Telegram] G -->|عادي| I[Lookup المنسّق] I --> J[Notify المنسّق + Email للمستفيد] H --> J J --> K[Update APITable: Status=Assigned] K --> L[Schedule 48h follow-up check] ``` ## نقاط الفشل - LLM يصنّف خاطئاً: حالة قانونية ضرورية تُصنَّف كـ 'تعليمية' بسبب صياغة المستفيد. الحل: مراجعة بشرية إلزامية قبل التواصل، التصنيف اقتراح لا قرار. - كشف الطوارئ يفشل: المستفيد يصف الانتحار بلغة غير مباشرة لم يلتقطها النموذج. الحل: قاموس واسع للكلمات، + كل حالة جديدة تُقرأ يدوياً في خلال ساعتين بغض النظر عن التصنيف. - LibreTranslate يخفق في ترجمة لهجة: نص فارسي/دري بلهجة غير مدعومة. Fallback: تنبيه للمنسّق المتعدد اللغات لقراءة الأصل. - APITable يعطّل في وقت ضغط: 50 حالة دفعة واحدة قد تخلق race condition في إسناد المنسّقين. الحل: queue mode في n8n. - إيميل المستفيد لا يصل: قد يكون مزود الإيميل يحجبه. تأكد من SPF/DKIM/DMARC، أضف خيار SMS كبديل. ## نقاط المراجعة البشرية - كل تصنيف 'عاجل' يُراجع من المشرف خلال ساعة قبل التواصل - كل تصنيف بـ confidence منخفض (LLM غير متأكد) يُرفع للمشرف لمراجعة يدوية - كل حالة بكلمات إنذار (انتحار، عنف، طارئ) — قراءة بشرية إلزامية فوراً - المنسّق يقرأ السجل قبل الاتصال — التصنيف اقتراحي، التشخيص النهائي بشري - مراجعة شهرية للتصنيفات الصحيحة vs الخاطئة (الفريق يصحّح في APITable)، تغذية راجعة لتحسين الـ prompt ## اعتبارات الخصوصية هذا workflow بأقصى درجات الحساسية. بيانات اللاجئين قد تعرضهم للخطر إذا تسربت. القواعد الصارمة: • كل المعالجة على بنية محلية. Ollama لا OpenAI. LibreTranslate لا Google. • n8n self-hosted مع 2FA إلزامي. • APITable مع تشفير قرص، صلاحيات على مستوى الصف، audit logs مفعّلة. • الإيميلات تحوي روابط فقط، لا تفاصيل شخصية في النص. • الـ logs في n8n قد تحفظ بيانات executions — عطّل حفظ الـ data أو فعّل auto-delete بعد 7 أيام. • نسخ احتياطي مشفّر بـ GPG، خارج الموقع. • سجل الوصول: من قرأ ملف من، متى. APITable يدعم audit logs. • حذف نهائي: عند انتهاء علاقة المستفيد بالمنظمة (حسب السياسة)، حذف آمن لكل بياناته، توثيق الحذف. ## ملاحظات الصيانة مراجعة شهرية لجودة التصنيف: اسأل المنسّقين كم نسبة الحالات التي وُجِّهت لهم بصواب. إذا < 80%، حسّن الـ prompt أو غيّر النموذج. حدّث قائمة الفئات إذا ظهرت احتياجات جديدة (مثلاً: تعليم للبالغين، دعم تشغيلي، …). راجع قاموس الطوارئ كل ربع سنة، أضف عبارات جديدة من حالات فعلية. اختبر الـ workflow E2E شهرياً بحالة وهمية.