المخرجات المنظّمة JSON: عبدالله بن سنكر يشرح ليش تهم أي نظام إنتاج

في التجربة، تطلب من النموذج يصنّف رسالة العميل ويرجّع النتيجة بصيغة JSON، ويرجعها مضبوطة. تربطه بالنظام وتطلقه. بعد يومين يوقف سير العمل كله لأن النموذج قرر مرة يبدأ رده بـ«أكيد! هذا التصنيف المطلوب:» قبل الـ JSON، والكود اللي يقرأ الرد انهار. الكلام الحر يناسب الإنسان، والكود يحتاج شكلاً ثابتاً كل مرة. عبدالله بن سنكر يشرح هنا ليش المخرجات المنظّمة هي المفصل بين «تجربة حلوة» و«نظام يشتغل»، ويقارن الطرق المتاحة من الأضعف للأقوى.

وش ممكن يخرب في الرد؟

لما يكون مستهلك الرد كوداً، أي انحراف صغير يكسره. والانحرافات هذي تتكرر في الأنظمة الحقيقية:

• مقدمة أو خاتمة كلامية حول الـ JSON، أو تغليفه بعلامات تنسيق Markdown.
• حقل ناقص: النموذج ما لقى المعلومة فحذف الحقل بدل ما يقول إنها غير موجودة.
• نوع غلط: السعر يجي نصاً «مية وخمسين ريال» بدل رقم ١٥٠.
• قيمة خارج القائمة: طلبت التصنيف من «شكوى» أو «استفسار» أو «طلب»، فرجّع «ملاحظة».
• رد مقطوع: وصل الحد الأقصى لطول الرد قبل ما يسكّر الأقواس، فطلع JSON ناقص ما ينقرأ.

أربع طرق، من الأضعف للأقوى

الطريقة الأولى: تطلب بالكلام. تكتب في التعليمات «رد بـ JSON فقط بهالشكل» مع مثال. تشتغل أغلب الوقت، وهنا الخطر: «أغلب الوقت» في نظام يعالج آلاف الطلبات يعني أعطال يومية. تنفع للنماذج الأولية فقط.

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

الطريقة الثالثة: مخطط ملزم. عند المزودين اللي يدعمون المخرجات المنظّمة، ترسل مخطط JSON Schema مع الطلب، والمزوّد يقيّد توليد النموذج بحيث الرد يطابق المخطط: الحقول المطلوبة موجودة، والأنواع صحيحة، والقيم من القائمة المسموحة. هذي أقوى ضمانة متاحة. وانتبه إن كل مزوّد يدعم جزءاً من مواصفات المخطط مو كلها، فارجع لوثائقه.

الطريقة الرابعة: أداة كقالب. تعرّف أداة وهمية مدخلاتها هي الشكل اللي تبيه، وتطلب من النموذج يستدعيها. النموذج يملأ المدخلات حسب مخطط الأداة، وأنت تاخذها كنتيجة. هالطريقة مفيدة مع النماذج اللي تدعم استدعاء الأدوات وما تدعم المخطط الملزم مباشرة.

مثال: من رسالة واتساب إلى سجل في النظام

عميل يكتب لمكتب صيانة: «السلام عليكم، المكيف في غرفة النوم يقطّر موية من أمس، أنا في حي النرجس، ومتى أقرب موعد؟». المطلوب يتحول لسجل في نظام الحجز. المخطط فيه: نوع الجهاز من قائمة محددة، ووصف المشكلة نصاً قصيراً، والحي، ودرجة الاستعجال من «عادي» أو «مستعجل» أو «طارئ»، ورقم الجوال.

النموذج يملأ: الجهاز «مكيف»، والمشكلة «تسريب ماء من الوحدة الداخلية»، والحي «النرجس»، والاستعجال «مستعجل». ورقم الجوال؟ ما انكتب في الرسالة. لو الحقل إلزامي ولا يقبل الفراغ، بيحط النموذج رقماً من خياله. لو يقبل null، يرجعه فارغاً، والنظام يعرف إنه لازم يسأل العميل عنه. هذا الفرق بين مخطط يحمي بياناتك ومخطط يلوّثها.

تصميم مخطط ما يجبر النموذج على الكذب

• اسمح بـ«ما أعرف»: لو الحقل إلزامي والمعلومة مو موجودة في النص، النموذج بيخترع قيمة عشان يملأه. خلّ الحقل يقبل null، واكتب في وصفه «اتركه فارغاً إذا ما ذُكر».
• استخدم القوائم المغلقة: التصنيف والحالة والأولوية تكون قيماً محددة، مو نصاً حراً.
• اكتب وصفاً لكل حقل: «delivery_date: تاريخ التسليم اللي ذكره العميل بصيغة سنة-شهر-يوم» أوضح بكثير من الاسم لحاله.
• خلّه مسطّحاً قدر الإمكان: كل مستوى تداخل إضافي فرصة إضافية للخطأ.
• رتّب الحقول بذكاء: لو تبي النموذج يبرر قراره، حط حقل التبرير قبل حقل القرار، لأن النموذج يكتب بالترتيب، فيفكر قبل ما يحكم.

تحقّق دائماً، حتى مع الضمان

المخطط الملزم يضمن الشكل، ما يضمن الصحة. ممكن يرجع لك JSON مثالي فيه رقم طلب غلط أو تاريخ مستحيل. عشان كذا كل رد يمر على طبقة تحقق في كودك قبل ما يدخل النظام: مكتبة مثل Zod في TypeScript أو Pydantic في بايثون تتحقق من الشكل، وأنت تضيف فوقها قواعد العمل: التاريخ مو في الماضي، والمبلغ موجب، ورقم الطلب موجود فعلاً في قاعدة البيانات.

وهالطبقة تصير ضرورية أكثر لو نظامك يتنقل بين أكثر من نموذج أو مزوّد، لأن دعم المخرجات المنظّمة يختلف بينهم، والنموذج البديل ممكن ما يقدم نفس الضمانة. التحقق في كودك هو الشي الوحيد الثابت مهما تغيّر النموذج. واجعل المخطط نفسه مصدراً واحداً: نفس التعريف اللي ترسله للمزوّد هو اللي تتحقق به في كودك، بدل نسختين تبتعد كل وحدة عن الثانية مع كل تعديل.

لما يفشل الرد

الفشل بيصير، والسؤال كيف تتصرف. أول خطوة إعادة محاولة ذكية: ترسل الطلب مرة ثانية مع رسالة الخطأ نفسها، مثل «الحقل category قيمته خارج القائمة المسموحة»، والنموذج غالباً يصلحها. حط حداً لعدد المحاولات، اثنتين أو ثلاث، لأن كل محاولة تكلّف. وإذا فشلت كلها، لا ترمي الطلب ولا تمرّره ناقصاً: حطه في قائمة مراجعة بشرية، وسجّل السبب. وراقب ردود الرفض كمان: النموذج أحياناً يرفض المهمة لسبب يخصه، ورفضه ما بيكون بشكل مخططك. وبعض المزودين يرجّعون الرفض في حقل مستقل عن المحتوى، فتعامل معه كحالة لها مسارها الخاص، مو كخطأ صياغة تعيد عليه المحاولة. وسجّل نسبة الردود اللي تفشل في التحقق أسبوعياً، لأن ارتفاعها المفاجئ أول علامة إن شي تغيّر في النموذج أو في نوع الرسائل.

عبدالله عبدالرحيم بن سنكر الكندي يحمل شهادة Agents and Workflows من OpenAI Academy، وفي أي سير عمل آلي تبنيه منصة أزهل الرقمية تبقى القاعدة نفسها: المخرجات المنظّمة هي العقد بين النموذج وباقي النظام. كل خطوة تسلّم اللي بعدها شكلاً متفقاً عليه، ومتحققاً منه، ومعروفاً وش يصير لو اختل. بدون هالعقد، أي نظام ذكاء اصطناعي يبقى عرضاً تجريبياً مهما كان ذكياً.