116 lines
12 KiB
Markdown
116 lines
12 KiB
Markdown
# خارطة تطوير SovereignAI
|
|
|
|
هذه خارطة تنفيذ تدريجية للمشروع الحالي. التطبيق اليوم Flutter، وواجهة الخدمة FastAPI، والتخزين SQLite، وتوليد النص عبر خادم Ollama محلي. لا نبدأ بتدريب نموذج من الصفر؛ نبني منتجًا قابلًا لتبديل النموذج ونقيس كل مرحلة قبل توسيع الصلاحيات.
|
|
|
|
## المرحلة 1 — تجربة المحادثة
|
|
|
|
- [x] نسخ إجابة المساعد.
|
|
- [x] مشاركة نص الإجابة عبر نظام التشغيل.
|
|
- [x] تعديل آخر سؤال وإعادة إرساله؛ تُستبدل الإجابة وما بعدها في سياق المحادثة.
|
|
- [x] إعادة توليد آخر إجابة.
|
|
- [x] إشعار داخل التطبيق عند اكتمال الإجابة أو انتهاء الطلب بخطأ.
|
|
- [x] تجهيز تنبيهات نظام Windows/macOS/Linux/Android/iOS مع طلب إذن الهاتف عند ضغط المستخدم؛ الويب يعرض تنبيهًا داخل الصفحة في إصدار Flutter الحالي.
|
|
- [x] إنشاء أصل أيقونة موحّد وإعداد توليد أيقونات Android/iOS/macOS/Windows/Web، وإضافة أصل تغليف Linux.
|
|
- [x] اختيار نموذج Ollama مثبت من واجهة التطبيق، وتمريره صراحةً للطلب.
|
|
- [x] وضع وكيل تجريبي للبحث وقراءة مقتطفات ملفات المشروع فقط، مع إرجاع مراجع الملفات.
|
|
- [ ] حفظ محاولات الإجابة كنسخ منفصلة بدل استبدالها، مع واجهة للتنقل بينها.
|
|
- [ ] إظهار حالة النموذج والوقت وسبب الخطأ، وتوفير إيقاف التوليد.
|
|
- [ ] دعم إخراج Markdown كامل، وروابط قابلة للفتح، ونسخ الكتل البرمجية منفردة.
|
|
|
|
## المرحلة 2 — أساس موثوق للواجهة والـ API
|
|
|
|
- [ ] فصل عقد التطبيق عن تفاصيل Ollama عبر طبقة مزوّد موحدة (Model Provider)، مع بقاء Ollama أول مزوّد.
|
|
- [x] جلب قائمة Ollama المحلية والتحقق من اختيار النموذج قبل الإرسال؛ [ ] إضافة بيانات قدرات كل نموذج.
|
|
- توحيد أخطاء API ومعرّفات الطلبات والمهل الزمنية، وإضافة اختبارات تكامل لعقد API.
|
|
- إبقاء الخدمة محلية افتراضيًا؛ لا تُعرض على الشبكة قبل مصادقة المستخدم ومراجعة إعدادات الأمان.
|
|
- نقل إعدادات المستخدم من حقول مؤقتة إلى إعدادات محفوظة، وإظهار حالة الخادم والنموذج بوضوح.
|
|
|
|
## المرحلة 3 — الهوية والبيانات
|
|
|
|
- استبدال `X-User-ID` التطويري بجلسة موثقة قبل دعم عدة مستخدمين فعليين.
|
|
- تصميم بيانات المستخدمين والمحادثات والمرفقات ونسخ الإجابات مع ملكية واضحة وفهارس وترحيلات قاعدة بيانات.
|
|
- SQLite مناسب لنسخة محلية أحادية الجهاز. عند تشغيل خدمة لعدة مستخدمين/أجهزة، ننتقل إلى PostgreSQL، مع نسخ احتياطية وسياسة حذف وتصدير.
|
|
- تخزين الملفات الكبيرة في مساحة ملفات منظّمة، وحفظ بياناتها الوصفية ومراجعها في قاعدة البيانات، لا في سجل الرسائل ككتل ضخمة.
|
|
|
|
## المرحلة 4 — نواة الوكيل
|
|
|
|
### دورة التنفيذ
|
|
|
|
1. يستقبل الوكيل هدفًا وسياقًا ومجموعة الأدوات المسموح بها.
|
|
2. يقرر النموذج هل يجيب مباشرة أو يطلب استدعاء أداة ببنية محددة.
|
|
3. يتحقق الخادم من صحة الوسائط والصلاحية والحدود قبل تنفيذ الأداة.
|
|
4. يعيد الخادم نتيجة الأداة إلى النموذج ليستكمل أو يطلب خطوة أخرى.
|
|
5. يعرض التطبيق الخطة والخطوات والنتيجة، ويسجل الاستدعاءات والأخطاء.
|
|
|
|
### سلم الأدوات والصلاحيات
|
|
|
|
1. [x] قراءة فقط: معلومات الوقت/الحاسبة والبحث في ملفات مساحة عمل يضبطها المستخدم عند تشغيل الخادم. اختيار مساحة العمل من نافذة التطبيق ما زال مطلوبًا.
|
|
2. مساحة عمل محددة: استعراض الملفات وقراءتها والبحث داخلها.
|
|
3. كتابة: إنشاء وتعديل ملفات داخل مساحة العمل فقط، مع معاينة diff وتأكيد المستخدم قبل التطبيق.
|
|
4. أوامر تطوير: تشغيل أوامر محددة في بيئة معزولة وبمهلة وحدود موارد، ومع موافقة لكل أمر في البداية.
|
|
5. لا وصول عام إلى القرص، ولا أوامر مدمرة أو نشر خارجي دون موافقة صريحة. كل أداة لها مخطط مدخلات ومخرجات واختبارات وسجل تدقيق.
|
|
|
|
### كودكس للبرمجة
|
|
|
|
- مساحة مشروع يختارها المستخدم، مع فهرسة نصية أولًا ثم استرجاع المقاطع الملائمة للسؤال.
|
|
- أدوات مقترحة: قراءة ملف، بحث نصي، قائمة ملفات، إنشاء/تعديل ملف عبر patch، عرض diff، تشغيل اختبارات وأوامر allowlist.
|
|
- التنفيذ يتم في مجلد المشروع المحدد، مع حفظ التغييرات في Git وإظهارها للمستخدم قبل اعتمادها.
|
|
- نبدأ بوكيل خطوة بخطوة (دورة واحدة واستدعاء أداة واحد)، ثم نرفع عدد الخطوات تدريجيًا بعد قياس الدقة والأمان.
|
|
|
|
## المرحلة 5 — المعرفة والمهارات
|
|
|
|
- بناء RAG للمستندات المحلية: استخراج النص، تقطيع، فهرسة محلية، استرجاع مع مصادر وإشارات للمقاطع.
|
|
- تعريف المهارات كتعليمات وإجراءات موثقة ومحددة النطاق، مع صلاحية اختيار الأدوات المطلوبة فقط.
|
|
- [x] قراءة رابط عام محدد عبر `POST /v1/web/read`: استخراج نص HTML الثابت وتمريره إلى Gemma المحلية للإجابة مع إرجاع الرابط والعنوان.
|
|
- إضافة بحث ويب كمزوّد اختياري مستقل لاحقًا، مع إظهار المصادر ووقت جلبها؛ لا يُخلط بمحتوى المستخدم المحلي.
|
|
- اختبار كل مهارة على أمثلة ناجحة وفاشلة قبل إتاحتها افتراضيًا.
|
|
|
|
## المرحلة 6 — الوسائط
|
|
|
|
- الصوت: فصل واجهة مزوّد النسخ، مع إبقاء Groq خيارًا خارجيًا حاليًا وإضافة Whisper محلي عندما تسمح الموارد؛ المفاتيح تبقى في الخادم.
|
|
- الصور: استقبال وتحجيم آمن، ثم نموذج رؤية محلي ملائم للذاكرة؛ OCR محلي للنصوص داخل الصور كأداة تكميلية.
|
|
- دعم ملفات PDF والمستندات عبر استخراج نص موثوق مع الصفحات والمصادر.
|
|
- تصميم الواجهة لتوضيح ما إذا عولج الملف محليًا أم أرسل إلى مزوّد خارجي.
|
|
|
|
## المرحلة 7 — تقييم النماذج والتدريب
|
|
|
|
- إنشاء مجموعة أسئلة عربية/برمجية ممثلة لاستخدامنا، وقياس صحة الإجابة، اتباع التعليمات، استدعاء الأدوات، السرعة واستهلاك الذاكرة.
|
|
- اختيار النماذج حسب الرخصة، الجودة، اللغة، دعم الأدوات، كمية VRAM، وإمكانية التشغيل التجاري. لا نعتمد وصف «مفتوح» وحده كإثبات سماح تجاري؛ نراجع الرخصة الرسمية لكل إصدار.
|
|
- تحسين أولي عبر prompts وRAG والأدوات؛ هذه غالبًا تعالج نقص المعرفة أو القدرة على الفعل دون تغيير أوزان النموذج.
|
|
- عند توفر GPU مناسب: تجربة LoRA/QLoRA على بيانات مرخصة ومنقحة، ومقارنة النتائج بالمجموعة المرجعية قبل اعتماد adapter.
|
|
- تدريب نموذج أساسي من الصفر خارج نطاق العتاد الشخصي المعتاد؛ يحتاج بيانات وحوسبة وبنية تدريب كبيرة، ولا يكون خطتنا الأولى.
|
|
|
|
## المرحلة 8 — تطبيق Windows ثم التوزيع
|
|
|
|
- أثناء التطوير نشغّل Debug/hot reload. بعد ثبات الوظائف ننتج نسخة Windows قابلة للتثبيت.
|
|
- حسم طريقة توزيع خدمة Python وOllama/النماذج وإدارتها، دون تضمين أوزان ضخمة داخل التطبيق نفسه.
|
|
- توقيع التطبيق، تحديثات واضحة، سجلات تشخيص لا تكشف الأسرار، وإعدادات حذف البيانات والنسخ الاحتياطي.
|
|
- قبل الاستخدام التجاري: مراجعة تراخيص النماذج والاعتماديات، الخصوصية، المصادقة، حدود الاستخدام، النسخ الاحتياطي، والتحديثات الأمنية.
|
|
|
|
## إضافات قبل توسيع الوكيل
|
|
|
|
- إضافة إلغاء التوليد وإظهار المدة وحالة الاتصال بكل وضوح.
|
|
- حفظ نسخ إعادة التوليد والتنقل بينها، مع تجربة أفضل للأخطاء وإعادة المحاولة.
|
|
- إكمال طبقة مزوّد النموذج وعقد API قبل ربط أدوات الوكيل.
|
|
- حفظ إعدادات التنبيه والمظهر وعنوان API بطريقة محلية آمنة.
|
|
- إضافة دعم Markdown موثوقًا، وروابط المصادر، ونسخ كتل الكود بصورة مستقلة.
|
|
- وضع تقييم صغير بالعربية والبرمجة لقياس التغييرات على السرعة والجودة وعدم فقد الميزات.
|
|
- بعدها نكمل وكيل الملفات: اختيار مجلد مساحة العمل، معاينة التغييرات، ثم موافقة صريحة قبل أي كتابة أو أمر.
|
|
|
|
## ترتيب التنفيذ القادم
|
|
|
|
1. التحقق من إجراءات المحادثة الجديدة على Windows Debug.
|
|
2. إيقاف التوليد وحفظ نسخ الإجابات وترحيل SQLite.
|
|
3. إضافة طبقة مزود النموذج واكتشاف النماذج.
|
|
4. تصميم عقد الأدوات وسجل التنفيذ، ثم أداة قراءة الملفات داخل مساحة يحددها المستخدم.
|
|
5. إضافة التعديل مع diff وموافقة، ثم الاختبارات/الأوامر المعزولة.
|
|
6. الهوية متعددة المستخدمين قبل أي نشر شبكي.
|
|
7. البحث والوسائط وقياس النماذج، ثم ضبط دقيق عند توفر بيانات وعتاد مناسبين.
|
|
|
|
## شروط الانتقال بين المراحل
|
|
|
|
- كل قدرة جديدة لها عرض واضح للمستخدم، حدود صلاحيات، وسجل مفهوم.
|
|
- لا تُفعل أداة كتابة أو تنفيذ قبل وجود تحقق خادمي من المسارات والمدخلات.
|
|
- لا نعتبر نجاح HTTP كافيًا: نتحقق من النتيجة في الواجهة ومن استمرار حفظ البيانات بعد إعادة فتح التطبيق.
|
|
- قبل الإنتاج، نستبدل هوية التطوير ونراجع المصادقة والترخيص والأسرار والنسخ الاحتياطية.
|