أشارك في هذا الموضوع تجربة عملية لاختبار قدرة وكلاء الذكاء الاصطناعي على فهم بيانات خارجية وتوظيفها في عملية تطوير التطبيقات القرآنية.
فأبرز تحدي يواجهه المطور حين يعتمد على وكيل ذكي هو الهلوسة وعدم الاعتماد على مصادر بيانات موثوقة في نموذج الذكاء الاصطناعي نفسه.
فلو طلبت منه تطوير صفحة لعرض بيانات القرآن الكريم تعتمد على إحدى الواجهات البرمجية التي توفر النصوص قد يخمن روابط غير دقيقة للواجهة البرمجية وتكون النتيجة النهائية غير صحيحة.
لتجاوز الأمر استخدمت وكيل Google Antigravity وطلبت قراءة بيانات منظمة من مستودع رتق الذي وفرته إتقان على جيتهب ووصفت فيه العديد من التقنيات البرمجية بشكل واضح ومفصل
ثم طلبت من الوكيل استخدام هذه البيانات لبناء عارض قرآني بسيط Quran Viewer يعمل على الويب.
الفكرة من التجربة ليست بناء منتج نهائي، بل اختبار 3 أمور:
- قدرة الوكيل على فهم ملف توثيق خارجي (Markdown)
- التزامه بالتعليمات بدلًا من الاعتماد على المعرفة المسبقة.
- إمكانية استخدام API قرآنية مفتوحة لبناء مصحف رقمي بسيط.
خطوات التجربة
بداية استعنت بملف مارك داون من مستودع رتق يحتوي على توصيف الواجهة البرمجية quran.com-API وأضفت أبرز نقاط الوصول التي أحتاجها من هذه الواجهة لتكون مصدر معلومات للمشروع.
بعدها حولت ملف رتق إلى ملف قواعد rules file وداخل وكيل Antigravity أنشأت ملفًا باسم:
quran-ratq-rules.md لجعله يتقيد بها.
أضفت في هذا الملف:
- الهدف من المشروع.
- وصف تقني للمطلوب: صفحة ويب بسيطة، نص عربي مناسب، استخدام API مفتوحة.
- التوثيق الكامل القادم من رتق.
- توجيهات صريحة ليعتمد على التوثيق المقدم ولا يستخدم معرفة مسبقة.
بعد هذه الخطوة بدأت محادثتي مع الوكيل وطلبت منه:
- قراءة ملف القواعد.
- وضع خطة تنفيذ.
- تحديد المجلدات، الملفات، وتدفق البيانات.
- عدم كتابة أي كود قبل عرض الخطة.
أنشأ لي الوكيل وثيقة ذكية Artifact تتضمن صفحة لسرد السور وصفحة لعرض آيات سورة محددة، بعد الموافقة على الوثيقة:
- أنشأ الوكيل ملفات المشروع.
- نفذ استدعاءات API بدقة كما وضحت له في ملف القواعد.
- بنى واجهة أمامية بسيطة وأنيقة.
- اختبر الكود ذاتيًا سطرًا بسطر عبر فتح المتصفح وتحليل DOM.
في المرحلة التالية طلبت منه جلب التلاوات الصوتية من الواجهة البرمجية مع استخدام timestamps لقص مقطع كل آية، وعرض زر تشغيل تحت كل آية ليشغل الجزء الخاص بها
فهم الوكيل المطلوب، وأنشأ:
- عنصر <audio> واحد لكل السورة.
- منطق لتشغيل مقطع الآية فقط.
- زر أسفل كل آية لتنفيذ التشغيل.
وبذلك أصبح لدي عارض قرآني بسيط يعرض نص السورة كاملة معه زر لتشغيل كل آية.
ملاحظة: توفر الواجهة البرمجية مسارًا مباشرًا لجلب التلاوات آية بآية:
GET /content/api/v4/recitations/{recitation_id}/by_chapter/{chapter_number}
لكنني في هذه التجربة استخدمت المسار:
GET /chapter_recitations/:id/:chapter_number
لاختبار قدرة وكيل الذكاء الاصطناعي على التعامل مع ملف صوتي واحد للسورة وربطه بزمن كل آية عبر Timestamping.
إيجابيات التجربة
لاحظت أن هذا الوكيل الذكي قدرة عالية على فهم ملفات MD الخارجية والتفاعل مع ملف القواعد والالتزام بها وهذا يعالج مشكلة نقص تدريب النماذج على البيانات القرآنية فلم يخترع API أخرى، ولم يعتمد على خبرته بل استخدم المعلومات التي قدمتها له فقط.
كما أنه يتميز بقدرته على توليد مشروع حقيقي من البداية للنهاية وتضمني هيكل المشروع وملفاته وأكواده البرمجية والواجهة المرئية إلى جانب الاختبار الذاتي.
فالوكيل: يقرأ التوثيق، ويخطط، وينفذ، ويختبر، ويعدل، كل ذلك داخل مساحة عمل واحدة مما يسرع عملية التطوير بشكل كبير.
سلبيات التجربة
لم يتمكن الوكيل من تحقيق ميزة timestamps بدقة كبيرة ففي الملف الصوتي لبعض الآيات قد تسمع جزء بسيط من الآية التالية نتيجة أخطاء قفز بين timestamps.
يحتاج التنفيذ لملف قواعد واضح ودقيق كي لا يقوم الوكيل بالهلوسة والاستنتاج من تلقاء نفسه مما يتطلب من المطور التدخل وتحديد السياق المطلوب.
Antigravity ما زال في مرحلة التجربة، قد تتصرف بعض أدواته بشكل غير ثابت، خصوصًا عند تشغيل مهام متعددة في الوقت نفسه، لكني أعتقد أن المنصة واعدة بشرط توفير التوثيق الصحيح وسنرى في القريب العاجل تطبيقات عديدة مطورة باستخدامها.
ماذا عنكم؟ هل لديكم تجارب في التعامل مع هذا الوكيل أو غيره من وكلاء الذكاء الاصطناعي وكيف تقيمون تجربتكم معه؟ وهل ترون أنه من الممكن الاعتماد عليه بالفعل لتطوير تطبيقات قرآنية موثوقة؟
