تطوير منظومة إذاعة راديو حية ومتكاملة بالذكاء الاصطناعي

1. التعريف بالمشروع

يهدف المشروع إلى تطوير منظومة برمجية متكاملة لإدارة وتشغيل إذاعة راديو رقمية/محلية تعمل على مدار 24 ساعة يوميًا، 7 أيام في الأسبوع (24/7)، مع الاعتماد على الذكاء الاصطناعي والأتمتة في إنتاج جزء من المحتوى، مع إبقاء المراجعة والموافقة البشرية عنصرًا أساسيًا قبل تحويل المحتوى إلى صوت وبثه.

تتكون المنظومة من:

1. لوحة تحكم مركزية Dashboard.

2. محرك أتمتة ومعالجة خلفية.

3. نظام جمع ومعالجة الأخبار والمصادر.

4. نظام كتابة وإعداد النصوص بالذكاء الاصطناعي.

5. نظام توجيه النبرة والأداء الصوتي.

6. نظام توليد الصوت بالذكاء الاصطناعي.

7. نظام معالجة ومزج الملفات الصوتية.

8. نظام جدولة وإدارة المحتوى.

9. نظام ربط مع برنامج RadioBOSS.

10. نظام بث مباشر عبر الإنترنت.

11. نظام إدارة مواقيت الصلاة والأذان.

12. نظام Logs ومراقبة الأخطاء والاستهلاك.

13. تطبيق ويب متوافق مع الهاتف للاستماع إلى البث ومتابعة Now Playing.

⸻

2. الهدف التشغيلي للنظام

يجب أن تسمح المنظومة بإدارة إذاعة شبه آلية بحيث يستطيع المشرف:

* إعداد الفقرات اليومية.

* تحديد مصادر كل فقرة.

* إنشاء النصوص بالذكاء الاصطناعي.

* مراجعة وتعديل النصوص.

* إضافة أو تعديل تعليمات الأداء الصوتي.

* اعتماد النص.

* توليد الصوت.

* دمج الصوت مع الموسيقى والفواصل.

* معاينة الملف النهائي.

* إرساله تلقائيًا إلى منظومة البث.

* جدولة إعادة استخدام المحتوى.

* متابعة حالة النظام والاستهلاك والأخطاء من لوحة تحكم واحدة.

ويجب أن يكون النظام قادرًا على مواصلة التشغيل الآلي في الفترات التي لا يوجد فيها تدخل بشري، وفقًا للقواعد المحددة مسبقًا.

⸻

3. الهيكل العام للمنظومة

يجب أن تُبنى المنظومة وفق سير العمل التالي:

مصادر المحتوى

↓

Collector / RSS Engine

↓

Filtering & Content Selection

↓

AI Writing Engine

↓

Human Review & Approval

↓

Expression / Voice Direction

↓

Text-to-Speech

↓

Audio Processing & Mixing

↓

Final Audio

↓

Scheduler

↓

RadioBOSS

↓

FM + Online Streaming

مع تسجيل جميع العمليات في نظام Logs.

4. لوحة التحكم الرئيسية Dashboard

يجب أن تكون لوحة التحكم Web Application حديثة ومتجاوبة مع أجهزة الكمبيوتر والأجهزة اللوحية والموبايل.

4.1 الصفحة الرئيسية Dashboard

تعرض بشكل فوري:

* حالة البث.

* حالة RadioBOSS.

* الفقرة الحالية.

* المحتوى التالي.

* حالة الملفات الصوتية.

* آخر محتوى تم إنتاجه.

* حالة المهام الآلية.

* أخطاء النظام.

* استهلاك APIs.

* عدد الملفات المنتجة.

* حالة الاتصال بالخدمات الخارجية.

* حالة Streaming Server.

⸻

5. إدارة الفقرات والبرامج — Show Profiles

يجب أن يدعم النظام 10 ملفات برامجية مستقلة على الأقل.

لكل Profile:

* اسم الفقرة.

* وصف الفقرة.

* وقت البث.

* مدة الفقرة.

* مصادر RSS الخاصة بها.

* قواعد اختيار الأخبار.

* نموذج الذكاء الاصطناعي المستخدم.

* Voice Model الخاص بالمذيع.

* إعدادات النبرة والأسلوب.

* Intro.

* Outro.

* Bed Music.

* Jingles.

* إعدادات مستوى الصوت.

* مجلد التخزين.

* مسار التصدير إلى RadioBOSS.

* قواعد إعادة البث.

* قواعد عدم التكرار.

ويجب أن يكون بالإمكان تعديل هذه الإعدادات من لوحة التحكم دون تعديل الكود البرمجي.

⸻

6. نظام جمع الأخبار والمصادر

يجب تطوير Collector Engine يقوم تلقائيًا بجمع المحتوى من المصادر المحددة لكل فقرة.

يدعم النظام:

* RSS/Atom.

* مصادر أخرى يتم تحديدها مستقبلًا عبر APIs.

* جدولة عمليات الجمع.

* تصنيف المصادر حسب البرنامج.

* فلترة الأخبار.

* إزالة التكرار.

* تسجيل وقت وتاريخ الحصول على الخبر.

* الاحتفاظ بمصدر الخبر ورابطه الأصلي لأغراض التتبع والمراجعة.

ويجب ألا يؤدي تعطل مصدر واحد إلى توقف بقية المنظومة.

⸻

7. نظام الذكاء الاصطناعي لكتابة المحتوى

يقوم AI Writer Engine بتحويل المواد الخام إلى نص إذاعي جاهز للمراجعة.

يجب أن يدعم:

* إعادة صياغة الأخبار بأسلوب إذاعي.

* تلخيص الأخبار.

* تحديد الأولويات.

* ترتيب الأخبار.

* كتابة مقدمات وانتقالات.

* الالتزام بالمدة الزمنية المحددة للفقرة.

* الالتزام بأسلوب كل برنامج.

* إنتاج نص عربي واضح ومناسب للبث الصوتي.

يجب أن تكون التعليمات الخاصة بكل برنامج قابلة للتعديل من Dashboard، دون الحاجة إلى تعديل الكود.

⸻

8. التوجيه التعبيري والنبرة الصوتية

يجب أن يتضمن النظام Expression / Voice Direction Engine.

يتم من خلاله تحديد:

* النبرة.

* السرعة.

* درجة الحماس.

* الوقفات.

* التنفس.

* التأكيد على الكلمات.

* الانتقال بين الجمل.

* أسلوب قراءة الخبر.

ويجب أن يستطيع النظام إدراج هذه التعليمات تلقائيًا، مع إمكانية قيام المشرف بتعديلها يدويًا.

مهم: يجب ألا يكون نظام الـExpression مرتبطًا بشكل جامد بمزود صوت واحد، بحيث يمكن تغييره أو تكييفه عند تغيير مزود TTS مستقبلًا.

⸻

9. المراجعة والموافقة البشرية — Human-in-the-Loop

هذه نقطة إلزامية في النظام.

لا يجوز إرسال أي نص إلى نظام توليد الصوت تلقائيًا إلا بعد المرور بحالة:

Draft → Review → Approved → Generate Audio

ويجب أن يستطيع المشرف:

* قراءة النص.

* تعديله.

* إضافة التشكيل.

* تعديل علامات الترقيم.

* تعديل تعليمات الأداء.

* تعديل النبرة.

* اعتماد النص.

* رفض النص.

* إعادة إرساله إلى AI لإعادة الصياغة.

ويجب تسجيل اسم المستخدم وتاريخ ووقت الاعتماد.

⸻

10. توليد الصوت — Text-to-Speech

بعد اعتماد النص، يتم إرساله إلى مزود TTS المعتمد، مثل ElevenLabs أو أي مزود آخر يتم الاتفاق عليه.

يجب أن يدعم النظام:

* اختيار الصوت لكل برنامج.

* تغيير الصوت من Dashboard.

* تسجيل استهلاك الحروف.

* تسجيل تكلفة كل عملية إن كانت API توفر هذه البيانات.

* إعادة محاولة العملية عند حدوث خطأ.

* منع التوليد المكرر غير الضروري.

* حفظ النسخة الصوتية الناتجة.

⸻

11. معالجة ومزج الصوت — Audio Processing

بعد إنتاج الصوت، يقوم النظام تلقائيًا بإنتاج الملف النهائي.

المعالجة تشمل:

Intro

إضافة المقدمة الخاصة بالفقرة.

Voice

إضافة صوت المذيع.

Bed Music

إضافة الموسيقى الخلفية.

Ducking

خفض مستوى الموسيقى تلقائيًا أثناء كلام المذيع ورفعها في الفواصل.

Outro

إضافة الخاتمة.

Normalization

ضبط مستويات الصوت بما يتناسب مع البث.

Final Export

إنتاج الملف النهائي بصيغة متفق عليها، مثل MP3.

يجب ألا يتطلب هذا العمل تدخلًا يدويًا لكل ملف.

⸻

12. نظام المعاينة

قبل إدخال الملف إلى البث، يجب أن يستطيع المشرف:

* تشغيل الملف.

* إيقافه.

* إعادة تشغيله.

* مراجعة النسخة النهائية.

* اعتمادها للبث.

* رفضها وإعادة المعالجة.

⸻

13. نظام الجدولة وإعادة تدوير المحتوى

يجب أن يدعم النظام إعادة استخدام المحتوى الذي تم إنتاجه سابقًا.

مثال:

18:00 — إنتاج نشرة

20:00 — إعادة بث نفس الملف

دون إعادة إرسال النص إلى AI أو ElevenLabs.

ويجب أن يحتفظ النظام بسجل يوضح:

* تاريخ إنتاج الملف.

* تاريخ أول بث.

* مرات إعادة البث.

* أوقات البث.

* البرنامج المرتبط به.

⸻

14. نظام منع التكرار

يجب تطوير قواعد لمنع تكرار المحتوى بشكل غير مرغوب.

ويجب أن يستطيع النظام التحقق من:

* تكرار نفس الخبر.

* تكرار نفس الملف الصوتي.

* تكرار المحتوى خلال فترة زمنية محددة.

* الحد الأدنى للفاصل بين عمليات إعادة البث.

ويجب أن تكون هذه القواعد قابلة للتعديل من Dashboard.

⸻

15. الربط مع RadioBOSS

يُستخدم RadioBOSS كجزء من منظومة التشغيل والبث المحلي.

يجب أن يستطيع النظام:

* إرسال الملفات إلى مجلدات RadioBOSS المحددة.

* إنشاء/تحديث أسماء الملفات تلقائيًا.

* استخدام Smart Folders أو آلية مماثلة.

* إدخال المحتوى في Scheduler.

* التعامل مع أولوية النشرات.

* تحديث بيانات Now Playing عند الإمكان.

* التعامل مع حالات فشل نقل الملفات.

ويجب ألا يتسبب فشل أحد مكونات الذكاء الاصطناعي في توقف البث الأساسي.

⸻

16. البث عبر الإنترنت

يجب أن يدعم النظام بثًا مباشرًا مستمرًا عبر الإنترنت باستخدام:

* Radio.co

أو

* Icecast

أو حل Streaming مماثل يتم الاتفاق عليه.

ويجب أن يكون البث قادرًا على العمل بالتزامن مع البث المحلي.

⸻

17. تطبيق الويب للمستمع

يجب إنشاء Web App متوافق مع:

* الهاتف.

* الكمبيوتر.

* الأجهزة اللوحية.

ويحتوي على:

* Live Audio Player.

* اسم الإذاعة.

* حالة البث.

* اسم البرنامج الحالي.

* اسم المذيع.

* Now Playing.

* معلومات المحتوى الحالي.

* إمكانية العمل في الخلفية على الهاتف متى كان ذلك مدعومًا من المتصفح.

⸻

18. نظام التخزين والتنظيف الآلي

يجب ألا تتراكم الملفات الصوتية غير الضرورية على الاستضافة.

لذلك يجب إنشاء Storage Management System يقوم تلقائيًا بـ:

* تحديد الملفات المؤقتة.

* تحديد الملفات النهائية.

* الاحتفاظ بالملفات المطلوبة للأرشيف.

* حذف الملفات المؤقتة بعد مدة محددة.

* حذف التسجيلات أو الملفات التي لا حاجة لها بعد 48 ساعة وفقًا لسياسة التخزين المتفق عليها.

ويجب ألا يحذف النظام أي ملف أرشيفي أو ملف ضروري للبث دون تطبيق قاعدة واضحة ومحددة.

⸻

19. نظام مواقيت الصلاة والأذان

يجب تطوير Automated Prayer Times Engine داخل Dashboard.

يقوم النظام بـ:

1. الاتصال بمصدر/API لمواقيت الصلاة.

2. تحديد المدينة.

3. تحديث المواقيت يوميًا.

4. إنشاء جدول تلقائي لمواعيد الأذان.

5. إرسال الأحداث إلى نظام الجدولة/RadioBOSS.

أولوية الأذان

عند حلول وقت الأذان:

Prayer Event

↓

High Priority

↓

تشغيل الأذان

↓

استكمال البرنامج السابق تلقائيًا

ويجب أن تكون المدة والفاصل بعد الأذان قابلة للتهيئة.

كما يجب أن يسجل النظام كل عملية أذان في Logs.

⸻

20. نظام الطوارئ والاستمرارية

يجب تصميم النظام بحيث لا يؤدي فشل:

* OpenAI.

* ElevenLabs.

* RSS.

* الإنترنت.

* API خارجي.

* AI Writer.

* Collector.