أضف مفسر أكواد إلى تطبيق ذكاء اصطناعي عن طريق توجيه تنفيذ الأكواد التي يطلبها النموذج إلى بيئة اختبار معزولة (sandbox) تحتوي على ملفات محددة النطاق، وسياسة حزم واضحة، وحدود للموارد والوقت، ومخرجات ملتقطة، ومراجعة من جانب التطبيق قبل عرض النتائج أو حفظها. يمكن للنموذج أن يقرر متى يكون الكود مفيدًا، لكن يجب أن يمتلك تطبيقك حدود التنفيذ: قم بتحميل الملفات اللازمة للمهمة فقط، وأنشئ أو أعد استخدام جلسة بيئة اختبار قصيرة العمر، وشغّل بايثون بحدود صارمة، والتقط stdout و stderr والملفات المُنشأة والسجلات، وأعد نتيجة منظمة إلى النموذج، ونظف الجلسة عند انتهاء سير العمل.
ما الذي يضيفه مفسر الأكواد إلى تطبيق الذكاء الاصطناعي
يحول مفسر الأكواد نموذج اللغة من مساعد نصي فقط إلى تطبيق يستخدم أدوات يمكنه الحساب، وتحويل الملفات، وفحص البيانات، وإنشاء الرسوم البيانية، وإنتاج نتائج قابلة للمراجعة. بدلاً من مطالبة النموذج بالتفكير في جدول بيانات من خلال موجه (prompt)، يمكن للتطبيق السماح للنموذج بكتابة بايثون، وتشغيله على الملف المُحمّل، وفحص المخرجات، وشرح النتيجة.
النمط المفيد ليس “دع النموذج يشغل أي شيء”. النمط المفيد هو التنفيذ المتحكم فيه. يقبل تطبيقك مهمة مستخدم، ويسمح للنموذج بطلب استدعاء أداة مثل run_python، ثم ينفذ هذا الطلب داخل بيئة اختبار معزولة بدلاً من تنفيذه في عملية التطبيق الرئيسية. تصبح بيئة الاختبار المعزولة هي منصة العمل للملفات المؤقتة، وتثبيت الحزم، والبرامج النصية، والرسوم البيانية، والسجلات.
ميزات مفسر الأكواد مفيدة بشكل خاص من أجل:
- تحليل ملفات CSV و Excel و JSON والسجلات
- إنشاء رسوم بيانية من البيانات المُحمّلة
- تحويل التنسيقات وتنظيف البيانات
- مهام الرياضيات والمحاكاة التي تحتاج إلى حسابات دقيقة
- مقتطفات الأكواد التي تحتاج إلى اختبار قبل أن يشرحها النموذج
- سير عمل الوكلاء متعددة الخطوات حيث تصبح مخرجات خطوة واحدة مدخلات للخطوة التالية
إنها غير مناسبة للمهام التي تتطلب بيانات اعتماد إنتاج غير مقيدة، أو وصول طويل الأمد إلى أنظمة خاصة، أو تنفيذ صامت بدون أثر تدقيق مرئي للمستخدم. إذا كانت النتيجة يمكن أن تؤثر على المال أو البنية التحتية أو السلامة أو التحكم في الوصول، أضف بوابات مراجعة قبل أن يغادر أي تأثير جانبي بيئة الاختبار المعزولة.
بنية مرجعية
تتكون بنية مفسر الأكواد العملية من خمسة أجزاء:
| الطبقة | المسؤولية | اختيار التصميم الشائع |
|---|---|---|
| واجهة المستخدم | تحميل الملفات، عرض التقدم، عرض النتائج، طلب الموافقة | احتفظ بالملفات المُحمّلة ضمن نطاق المحادثة أو المشروع الحالي |
| خادم التطبيق | مصادقة المستخدمين، فرض السياسة، إنشاء جلسات بيئة اختبار، تخزين السجلات | لا تعرض أبدًا بيانات اعتماد بيئة الاختبار الخام للمتصفح |
| تنسيق النموذج | تحديد متى يتم استدعاء أدوات الكود وتلخيص النتائج | استخدم استدعاءات أدوات منظمة بدلاً من تحليل النص الحر |
| بيئة تشغيل الاختبار | تنفيذ بايثون، الاحتفاظ بالملفات المؤقتة، تثبيت الحزم المسموح بها | شغّل مع ضوابط الموارد، المهلة، والتنظيف |
| مخزن النتائج | حفظ المخرجات المعتمدة مثل الرسوم البيانية وملفات CSV والتقارير والسجلات | خزّن فقط المخرجات التي قبلها التطبيق أو المستخدم |
لا ينبغي للنموذج التحكم مباشرة في البنية التحتية. يجب أن يطلب استدعاء أداة. يقرر تطبيقك ما إذا كان استدعاء الأداة مسموحًا به، وما هي الملفات المرفقة، ومدة التشغيل، والحزم المتاحة، والمخرجات التي يتم إرجاعها.
هذا الفصل يحافظ على فائدة النموذج دون جعله حدود الأمان.
تدفق التنفيذ
يبدأ تدفق تنفيذ قوي قبل تنفيذ أي كود.
1. قبول مهمة المستخدم والملفات
عندما يقوم المستخدم بتحميل ملف، قم بتخزينه تحت سجل ملف على مستوى التطبيق مع المالك، ومساحة العمل، ونوع المحتوى، والحجم، وسياسة الاحتفاظ. لا تعرض كل ملف في حساب المستخدم للمفسر على الفور. يجب أن تستقبل بيئة الاختبار المعزولة فقط الملفات اللازمة للمهمة الحالية.
على سبيل المثال، قد يسأل المستخدم:
“حلل ملف CSV هذا، وابحث عن أهم محركات الإيرادات، وأعد رسمًا بيانيًا مع شرح قصير.”
يمكن لتطبيقك إرفاق ملف CSV المُحمّل بدور النموذج التالي كملف متاح، لكن بايتات الملف الفعلية يجب أن تنتقل إلى بيئة الاختبار المعزولة فقط عند الموافقة على تنفيذ الكود.
2. السماح للنموذج بطلب استدعاء أداة
حدد سطح أداة ضيق. الإصدار الأول النموذجي يحتاج فقط إلى عدد قليل من الأدوات:
{
"name": "run_python",
"arguments": {
"code": "import pandas as pd\n...",
"input_files": ["sales.csv"],
"expected_outputs": ["summary.json", "revenue_chart.png"],
"timeout_seconds": 30
}
}
اجعل المخطط (schema) صريحًا. يجب على النموذج أن يعلن عن الكود، وملفات الإدخال، والمخرجات المتوقعة، وطلب مهلة. يمكن للتطبيق تقصير المهلة، أو رفض الملفات غير المعروفة، أو حظر الأوامر التي تتعارض مع السياسة.
3. إنشاء أو إعادة استخدام جلسة بيئة اختبار معزولة
لاستجابة مساعد لمرة واحدة، أنشئ جلسة بيئة اختبار جديدة، وحمّل ملفات الإدخال، وشغّل الكود، واجمع النتيجة، وأنهِ الجلسة. لتجربة مستخدم تشبه المفكرة، احتفظ بجلسة نشطة للمحادثة الحالية حتى تتمكن الخلايا اللاحقة من إعادة استخدام المتغيرات والملفات السابقة.
الجلسات قصيرة العمر أسهل في التفكير فيها. الجلسات ذات الحالة أكثر راحة لمهام التحليل. اختر عن قصد وأظهر للمستخدم عندما توجد حالة.
4. تنفيذ بايثون والتقاط النتائج
شغّل الكود من خلال واجهة برمجة تطبيقات تنفيذ بيئة الاختبار المعزولة أو العامل الخاص بك داخل بيئة الاختبار. التقط مخرجات التنفيذ المنظمة:
{
"status": "success",
"stdout": "Loaded 12,448 rows\n",
"stderr": "",
"artifacts": [
{
"path": "revenue_chart.png",
"type": "image/png",
"size_bytes": 84231
},
{
"path": "summary.json",
"type": "application/json",
"size_bytes": 1260
}
],
"duration_ms": 1840
}
أعد هذه النتيجة المنظمة إلى النموذج. يمكن للنموذج بعد ذلك شرح ما حدث، والاستشهاد بالملفات المُنشأة، والسؤال عما إذا كان المستخدم يريد تمريرة أخرى.
5. إرجاع النتائج إلى المستخدم
لا تجبر المستخدم على قراءة السجلات الخام إلا إذا فشل شيء ما. تعرض الواجهة الجيدة الإجابة، والرسم البياني أو الملف المُنشأ، وإفصاحًا صغيرًا بأنه تم تنفيذ كود. وفر سجل تنفيذ قابلًا للتوسيع للمراجعة.
لعمليات التنفيذ الفاشلة، اعرض خطأً موجزًا واسمح للنموذج بمراجعة الكود. تجنب إغراق الدردشة الرئيسية بتتبعات طويلة (tracebacks) ما لم يكن المستخدم يقوم بتصحيح الأخطاء.
التعامل مع الملفات والمخرجات والنتائج المُنشأة
معالجة الملفات هي المكان الذي تصبح فيه العديد من مشاريع مفسر الأكواد فوضوية. تعامل مع المدخلات والمخرجات ككائنات منفصلة.
يجب نسخ ملفات الإدخال إلى بيئة الاختبار المعزولة تحت مسارات مستقرة ومنقاة. تجنب الاحتفاظ بأسماء المسارات التي يوفرها المستخدم والتي تحتوي على مسافات أو أحرف شل أو أدلة متداخلة. احتفظ بتعيين من اسم العرض إلى مسار بيئة الاختبار في حالة التطبيق.
يجب فحص الملفات المُنشأة وتصنيفها قبل أن تصبح نتائج قابلة للتنزيل. قد تكون صورة الرسم البياني، أو ملف CSV المنظف، أو ملخص JSON، أو تقرير PDF آمنة للعرض المباشر. يجب أن يتطلب البرنامج النصي المُنشأ، أو الملف القابل للتنفيذ، أو الأرشيف معالجة أكثر صرامة.
لإنشاء الرسوم البيانية، اطلب من النموذج حفظ ملفات الصور بشكل صريح بدلاً من الاعتماد فقط على العرض المضمن. لتحليل البيانات، اطلب ملف ملخص قابل للقراءة آليًا بالإضافة إلى شرح باللغة الطبيعية. هذا يعطي تطبيقك شيئًا ثابتًا للتحقق والتخزين.
تبدو سياسة النتائج المفيدة كما يلي:
| نوع النتيجة | المعالجة الافتراضية |
|---|---|
رسوم بيانية .png، .jpg، .webp، .svg |
معاينة في واجهة المستخدم بعد فحص الحجم والنوع |
مخرجات بيانات .csv، .json، .xlsx |
تقديم كتنزيلات وتلخيص التغييرات |
تقارير .txt، .md، .pdf |
معاينة أو تنزيل حسب الحجم |
ملفات .py، .sh، ثنائيات، أرشيفات |
لا تشغيل تلقائي أو فتح تلقائي؛ تتطلب مراجعة صريحة |
إذا كان تطبيقك يدعم مشاريع دائمة، قم بتخزين النتائج المقبولة خارج بيئة الاختبار المعزولة. يجب أن تظل بيئة الاختبار قابلة للتخلص.
تعيين سياسة الحزم والشبكة
معظم سير عمل مفسر الأكواد يحتاج إلى حزم مثل pandas و NumPy و matplotlib و seaborn و scikit-learn أو openpyxl. السؤال هو ما إذا كانت الحزم مثبتة مسبقًا، أو مثبتة عند الطلب، أو مدمجة في قوالب بيئة اختبار مخصصة.
الحزم المثبتة مسبقًا تحافظ على التنبؤ بالتنفيذ. التثبيت عند الطلب مرن لكنه يمكن أن يبطئ المهام ويقدم انحرافًا في التبعيات. القوالب المخصصة عادة ما تكون أفضل مسار إنتاجي بمجرد معرفة أعباء العمل الشائعة.
حدد سياسة الحزم قبل الإطلاق:
- الحزم المتاحة دائمًا
- ما إذا كان النموذج قد يطلب تثبيت حزم
- ما إذا كانت عمليات التثبيت يمكنها الوصول إلى فهارس الحزم العامة
- ما إذا كانت مثبتات الإصدار مطلوبة
- مدة تشغيل عمليات التثبيت
- ما إذا كانت الحزم المترجمة أو الأصلية مسموح بها
سياسة الشبكة مهمة بنفس القدر. العديد من مهام البيانات لا تحتاج إلى الوصول إلى الإنترنت بعد تحميل الملفات. إذا كان سير العمل يحتاج إلى واجهات برمجة تطبيقات خارجية، قم بتوجيه بيانات الاعتماد من خلال أدوات التطبيق المعتمدة بدلاً من إسقاط أسرار واسعة في بيئة الاختبار. لا ينبغي للنموذج أن يتلقى متغيرات بيئة غير مقيدة بشكل افتراضي.
تطبيق الحدود والسجلات والتنظيف والمراجعة
مفسر الأكواد هو ميزة إنتاجية، وليس مشغل خلايا تجريبي. ضع حدودًا حوله منذ البداية.
يجب أن تتضمن الضوابط الدنيا:
- الحد الأقصى لوقت التنفيذ لكل خلية أو استدعاء أداة
- الحد الأقصى لحجم المخرجات لـ stdout و stderr
- الحد الأقصى لحجم النتائج وعدد الملفات
- حدود وحدة المعالجة المركزية والذاكرة المناسبة للمهمة
- امتدادات الملفات المسموح بها للمعاينة والتنزيل
- حدود التزامن لكل مستخدم ومساحة عمل
- قواعد التنظيف للجلسات والملفات المؤقتة
يجب أن تجيب السجلات على ثلاثة أسئلة: من طلب التنفيذ، وما الكود الذي تم تشغيله، وما المخرجات التي تم إنتاجها. خزّن ما يكفي لتصحيح الأخطاء وتدقيق سير العمل، لكن تجنب الاحتفاظ بالبيانات الخاصة المُحمّلة لفترة أطول مما تتطلبه سياسة منتجك.
المراجعة البشرية أو مراجعة المستخدم هي التحكم النهائي. للتحليل منخفض المخاطر، قد تعني المراجعة أن المستخدم يرى الرسم البياني قبل تنزيله. لسير عمل الوكلاء التي يمكنها تحديث التذاكر، أو الكتابة إلى قواعد البيانات، أو استدعاء واجهات برمجة تطبيقات خارجية، يجب أن تحدث المراجعة قبل التأثير الجانبي، وليس بعده.
أين تتناسب بيئة اختبار وكلاء Novita
بيئة اختبار وكلاء Novita مصممة لوكلاء الذكاء الاصطناعي الذين يحتاجون إلى بيئات تشغيل معزولة لتنفيذ الأكواد، وسير عمل المتصفح، ومهام نمط استخدام الكمبيوتر، والتقييمات، وبيئات التعلم المعزز، وسير العمل الطويلة. لميزة مفسر الأكواد، يعني ذلك أن بيئة الاختبار يمكن أن تعمل كطبقة تنفيذ بينما يظل تطبيقك مسؤولاً عن مصادقة المستخدم، وتنسيق النموذج، وسياسة الملفات، والمراجعة، والاحتفاظ الخاص بالمنتج.
توثيق بيئة اختبار Novita يتضمن سير عمل نظام الملفات لقراءة وكتابة وتحميل وتنزيل ومراقبة الملفات في بيئة الاختبار. تلك الإمكانيات تتوافق مباشرة مع احتياجات مفسر الأكواد: نقل ملفات المستخدم إلى بيئة التنفيذ، وترك الكود يولد رسومًا بيانية أو بيانات محولة، ثم إحضار المخرجات المحددة مرة أخرى إلى التطبيق. راجع توثيق نظام ملفات بيئة اختبار Novita للحصول على نظرة عامة على عمليات الملفات الحالية.
إذا نما مفسر الأكواد الخاص بك إلى ما هو أبعد من مشغل بايثون بسيط، يمكن أن تساعد قوالب بيئة الاختبار المخصصة في توحيد التبعيات وإعداد بيئة التشغيل. هذا مفيد عندما تحتاج كل جلسة إلى نفس مجموعة التحليل، أو أدوات سطر الأوامر الداخلية، أو مكتبات خاصة بالمشروع. ابدأ بمجموعة حزم صغيرة مسموح بها، ثم انقل الإعداد المتكرر إلى قوالب بمجرد استقرار عبء العمل.
احتفظ بقرارات التكامل الخاصة بـ Novita منفصلة عن البنية العامة. لا يزال مفسر الأكواد الخاص بك يحتاج إلى سياسات على مستوى التطبيق لرؤية الملفات، وتثبيت الحزم، والوصول إلى الشبكة، والاحتفاظ بالسجلات، والمراجعة. توفر بيئة الاختبار بيئة التشغيل المتحكم فيها؛ منتجك يحدد كيفية استخدام تلك البيئة.
قائمة التحقق للتقييم
قبل الشحن، اختبر الميزة بسير عمل حقيقي وموجهات خصومة.
| السؤال | ما يجب التحقق منه |
|---|---|
| هل يمكن للمستخدمين تحميل الملفات الصحيحة؟ | حجم الملف، فحوصات النوع، فحوصات المالك، ورسائل خطأ واضحة |
| هل يمكن للنموذج طلب التنفيذ بشكل نظيف؟ | استدعاءات أدوات منظمة مع الكود والمدخلات والمخرجات المتوقعة والمهلة |
| هل بيئة الاختبار محددة النطاق بشكل صحيح؟ | فقط الملفات المعتمدة ومتغيرات البيئة متاحة |
| هل الحزم متوقعة؟ | الحزم الشائعة تعمل، الحزم المرفوضة تفشل بوضوح، عمليات التثبيت لها حدود |
| هل المخرجات قابلة للاستخدام؟ | الرسوم البيانية تُعرض، الملفات تُنزّل، الملخصات تطابق النتائج المُنشأة |
| هل حالات الفشل قابلة للاسترداد؟ | يتم التقاط التتبعات، يمكن للنموذج مراجعة الكود، يرى المستخدم أخطاء موجزة |
| هل الحدود مفروضة؟ | الحلقات اللانهائية، المخرجات الضخمة، المهام كثيفة الذاكرة، وعمليات التثبيت الطويلة تنتهي |
| هل المراجعة مدمجة؟ | يمكن للمستخدمين فحص الكود والسجلات والنتائج قبل التأثيرات الجانبية المهمة |
| هل التنظيف موثوق؟ | تتم إزالة الملفات والجلسات المؤقتة أو تنتهي صلاحيتها وفقًا للجدول الزمني |
أفضل إصدار أول عادة ما يكون ضيقًا: تنفيذ بايثون، مجموعة حزم صغيرة، تحميل ملفات، رسوم بيانية وملفات قابلة للتنزيل، حدود واضحة، وسجل تنفيذ. أضف تثبيت حزم أوسع، جلسات دائمة، وصول إلى واجهات برمجة تطبيقات خارجية، وتأثيرات جانبية وكيلة فقط بعد أن تصبح الحلقة الأساسية قابلة للملاحظة والموثوقية.
الخاتمة
يعمل مفسر الأكواد بشكل أفضل عندما يمكن للنموذج طلب التنفيذ، لكن تطبيقك يتحكم في بيئة الاختبار والملفات والحدود وخطوة المراجعة. ابدأ بأداة بايثون ضيقة، واجعل المدخلات والمخرجات صريحة، وتوسع فقط بعد استقرار التدفق.
الأسئلة الشائعة
ما هي الطريقة الأكثر أمانًا لإضافة مفسر أكواد؟
استخدم بيئة اختبار معزولة، وحدد نطاق ملفات الإدخال، وحدد وقت التشغيل والذاكرة، وأعد مخرجات منظمة بدلاً من الوصول الخام إلى الصدفة.
هل يجب على النموذج التحكم في تثبيت الحزم؟
فقط ضمن سياسة تحددها أنت. تبدأ العديد من التطبيقات بمجموعة حزم ثابتة وتضيف عمليات التثبيت لاحقًا إذا كان عبء العمل يحتاجها.
هل تحتاج جميع مهام مفسر الأكواد إلى الوصول إلى الشبكة؟
لا. العديد من سير عمل التحليل تعمل بشكل كامل دون اتصال بمجرد تحميل ملفات المستخدم، مما يحافظ على نموذج التنفيذ أبسط.
ما الذي يجب أن يراه المستخدم بعد التنفيذ؟
النتيجة، والنتائج المُنشأة، وملخص موجز للسجل أو الخطأ، مع خيار فحص الكود أو إعادة تشغيل المهمة.
