إعداد للسماح بتخزين بيانات JSON دائمة في القطع الأثرية

أقترح بتواضع تنفيذ إعداد في وحدة تحكم Rails يسمح للمسؤولين بتمكين القدرة على تخزين بيانات دائمة في ملف JSON واحد بواسطة القطع الأثرية للذكاء الاصطناعي. قد يؤدي هذا بالطبع إلى إدخال بعض المشكلات/المخاطر عن غير قصد، تمامًا مثل الإعداد لتمكين حذف المواضيع بشكل دائم - :warning: لهذا السبب يتم تمكينه عبر وحدة تحكم Rails.

تعتبر القطع الأثرية للذكاء الاصطناعي مفيدة للغاية وتضيف الكثير إلى جودة المناقشات، ومع ذلك، يمكن مضاعفة فائدتها ثلاث مرات إذا كان بإمكانها تخزين البيانات البسيطة بشكل دائم ومعالجة تلك البيانات بطرق بسيطة :eyes:.

حالة الاستخدام الشخصي الخاصة بي

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

أعتزم استخدام واجهة برمجة تطبيقات Discourse لجلب بيانات JSON هذه (سيرة المتعلم من القطعة الأثرية) من محتوى الموضوع (ربما سأحتاج إلى بعض التعبيرات العادية المكثفة هنا) ثم تغذيتها إلى بنيتي المعرفية المبنية باستخدام FastAPI والتي تعمل على نفس الخادم مع وكيل عكسي. تقوم البنية المعرفية بسحرها، ثم تنشئ محتوى جديدًا لهذا المتعلم، ثم تنشئ موضوعًا جديدًا بهذا المحتوى في الفئة الخاصة بهذا المتعلم.

إليك تصور سريع وغير مصقول لما أتحدث عنه:

    flowchart TD
    A[مثيل Discourse<br/>LMS + مختبر أبحاث الذكاء الاصطناعي] --|> B[فئات الطلاب الخاصة<br/>مع التحكم في الوصول للمجموعة]
    
    B --|> C[سيرة المتعلم<br/>مخزنة في محتوى الموضوع<br/>تنسيق JSON]
    
    C --|> D[واجهة برمجة تطبيقات Discourse<br/>جلب محتوى الموضوع]
    
    D --|> E[تعبير عادي<br/>استخراج بيانات JSON]
    
    E --|> F[سيرة المتعلم<br/>البيانات المستخرجة]
    
    F --|> G[بنية معرفية FastAPI<br/>نفس الخادم + وكيل عكسي]
    
    H[رسم بياني للمعرفة<br/>بيانات بحث سرية] --|> G
    
    G --|> I[توليد محتوى الذكاء الاصطناعي<br/>يحدث السحر هنا ✨]
    
    I --|> J[محتوى تعليمي جديد<br/>مخصص للمتعلم]
    
    J --|> K[إنشاء موضوع جديد<br/>عبر واجهة برمجة تطبيقات Discourse]
    
    K --|> L[المحتوى المنشور في<br/>فئة الطالب الخاصة]
    
    L --|> M[مواد التعلم<br/>متتبعة ومحفوظة]
    
    M --|> N[حلقة تعلم وبحث مستمرة]
    
    N -.-> C
    
    style A fill:#e1f5fe
    style G fill:#f3e5f5
    style I fill:#fff3e0
    style L fill:#e8f5e8


من الناحية الفنية، يمكن تحقيق كل هذا (وبشكل أكثر أناقة) عن طريق السماح بـ HTTP في القطع الأثرية، ولكنني أشك في أن هذا أكثر خطورة من تخزين البيانات.

:heart: أنوي تمامًا فتح مصدر هذه التقنية بمجرد أن أحصل على كل شيء يعمل ويتم اختباره بدقة.


تعمل قطعة سيرة المتعلم هذه بشكل لا تشوبه شائبة باستثناء حقيقة أن البيانات المدخلة تختفي بعد تحديث الصفحة :see_no_evil_monkey:

كيف تبدو حقول البيانات في القطعة الأثرية

3 إعجابات

لقد كنت أفكر بالفعل في هذه الميزة القوية جدًا، وراء إعدادات الموقع أريد السماح بتخزين القطع الأثرية من أزواج القيمة المفتاحية، المرتبطة بالمستخدم الحالي

هذا يفتح مجموعة هائلة من حالات الاستخدام، بما في ذلك هذا

6 إعجابات

أوه يا عزيزي السيد سام، سيكون ذلك بمثابة هبة من الله!

في تنفيذك، هل يشير “مرتبط بالحالي” للمستخدم إلى أن مجرد مستخدم واحد يمكنه تحرير/عرض البيانات المحفوظة؟ أنا أطرح هذا السؤال لأنه اعتمادًا على كيف تقوم بذلك قد أحتاج إلى تعديل نهجي. في حالتي، أود أن تكون البيانات قابلة للتحرير من قبل كل منّي والطالب. لن يتمكن أي مستخدم آخر من تحريرها، أو حتى رؤيتها، لأن الأثر سيكون في فئة خاصة بذلك الطالب على أية حال.

إعجاب واحد (1)

أنا أفكر في API جافا سكريبت في الوقت الحالي، لكن على أي حال ستتمكن دائمًا من الوصول إلى البيانات في مستكشف البيانات لأنه سيكون في جدول. (معرف المستخدم، معرف الأثر، إصدار الأثر، المفتاح، القيمة، عام (صحيح أو خطأ))

دعني أأخذ بعض الوقت للتفكير قليلاً لأن لدي مجموعة كبيرة من الأسئلة التي أجيب عليها في رأسي.

  • هل المساحة العامة للمجهول؟ نعم أم لا؟ ما هي الحدود
  • الوصول الإداري إلى كل شيء عبر الأثر؟
  • المعلومات العامة مقابل الخاصة (مثل: الاستطلاعات)

سأتوسع هنا عند الرد على النموذج.

3 إعجابات

نوعًا ما توسيعًا لهذه الفكرة حول البيانات المستمرة في القطع الأثرية… سيكون من الرائع إذا تمكنا بطريقة ما من “إعادة استخدام” القطع الأثرية (أو تسجيل قطع أثرية جديدة يدويًا) مع تعديلات بسيطة فقط على بيانات JSON في كل منها. على سبيل المثال:

كما ذكرنا بالفعل، لكل طالب من طلابي فئة خاصة به مما يعني أن لديهم موادهم واختباراتهم الخاصة. اليوم اختبرت إنشاء قطعة أثرية للاختبار.

النهج الحالي لإنشاء الاختبارات

(يتم إنشاء الموضوع كموضوع ويكي حتى يتمكن الطالب من تحديد مربع اختيار الإجابة الخاص به.)

إصدار القطعة الأثرية

السبب في أن هذا سيكون مفيدًا هو أننا سنتمكن بعد ذلك من الحصول على “محرك اختبار” واحد يعمل بشكل جيد (البرنامج المصغر الفعلي) ثم فقط استبدال الأفعال الاصطلاحية (أو أي بيانات أخرى) باستخدام كائن JSON مختلف. لذا تتغير البيانات ولكن الكود لا يتغير، إذا كان هذا منطقيًا.

إعجاب واحد (1)