لماذا تحتاج تطبيقات الذكاء الاصطناعي إلى مخرجات منظَّمة؟

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

تخيّل شركة لوجستية ناشئة افتراضية اسمها بارسِل وايز، يعمل بها 12 شخصًا. تعمل مطوّرتها، سناء، على بناء أداة تقرأ رسائل العملاء وتملأ نموذج تغيير التسليم: مرجع الطلب، والتاريخ المطلوب، والعنوان الجديد، وما إذا كان العميل يطلب استرداد المبلغ. تبدو رسالة نموذجية هكذا: 'مرحبًا، بخصوص الطلب PW-88213، لن أكون موجودًا يوم الخميس، هل يمكنكم إحضاره السبت بدلًا من ذلك؟ أو تركه لدى رقم 14. إذا لم يكن ذلك ممكنًا فأرجو إلغاء الطلب ورد المبلغ.' تطلب نسختها الأولى من النموذج أن 'يرد بصيغة JSON'. يمكن تحليل معظم الردود برمجيًا، لكن بعضها يبدأ بعبارة 'بالتأكيد، إليك JSON'، وبعضها يسمّي الحقل 'date' بدلًا من 'requested_date'، وأحدها يعيد التاريخ بصيغة 'السبت'.

ما مخطط JSON، ولماذا هو مفيد؟

مخطط JSON هو وصف رسمي للبيانات التي تتوقعها: الحقول الموجودة، والحقول المطلوبة، ونوع كل حقل، والقيم المسموح بها. إن تزويد النموذج بمخطط يحوّل طلب 'يُرجى الرد بتنسيق JSON' إلى عقد تستطيع شيفرتك التحقق من الالتزام به.

بالنسبة إلى سنا، ينص مخطط البيانات على ما يلي: order_reference سلسلة نصية مطلوبة؛ وrequested_date سلسلة نصية مطلوبة بتنسيق تاريخ، أو null إذا لم يُذكر تاريخ؛ وnew_address سلسلة نصية أو null؛ وrefund_requested قيمة منطقية مطلوبة؛ ولا يُسمح بأي حقول أخرى. وتمنع القاعدة الأخيرة النموذج من إضافة حقول للتعليقات.

كيف تدعم واجهات برمجة تطبيقات النماذج المخرجات المنظَّمة؟

تتيح واجهات برمجة التطبيقات الخاصة بالنماذج الرئيسية تمرير مخطط JSON مع الطلب، وتُقيَّد مخرجات النموذج لتطابقه.

OpenAI

تقيّد ميزة المخرجات المهيكلة من OpenAI الاستجابات بمخطط JSON مُقدَّم عند تفعيل الوضع الصارم. وتميّز وثائقها بين هذه الميزة ووضع JSON الأقدم، الذي لا يضمن إلا صحة بنية JSON، لا الالتزام بمخططك، وتوصي باستخدام المخرجات المهيكلة حيثما توفرت.

Anthropic

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

Google

تقبل واجهة برمجة تطبيقات Gemini مخطط JSON للاستجابات، وتدعم مجموعة فرعية محددة من الكلمات المفتاحية للمخطط. وتوضح وثائقها أنه رغم صحة بنية مخرجات JSON، ينبغي لك التحقق من القيم داخل تطبيقك.

لماذا تظل بحاجة إلى التحقق من الصحة وإعادة المحاولة؟

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

تحقّق على مستويين. أولًا، تحقّق من البنية باستخدام مكتبة للتحقّق من مخطط البيانات، مثل Pydantic في Python أو Zod في JavaScript، وهي أمثلة ترد في وثائق OpenAI وAnthropic وGoogle. ثانيًا، تحقّق من قواعد العمل: هل يطابق الرقم المرجعي للطلب النمط المطلوب وهل هو موجود في النظام؟ وهل التاريخ مستقبلي ويوافق يوم توصيل؟ وهل يقع العنوان ضمن منطقة التوصيل؟ تعامل أيضًا مع الحالات التي يوثّقها المزوّدون: رفض الطلب، الذي قد لا يتبع مخطط بياناتك، وإجابة انقطعت بسبب بلوغ الحد الأقصى للرموز، مما يترك بيانات JSON غير مكتملة.

أعِد المحاولة بحذر. إذا فشل أحد الفحوص، أرسِل محاولة أخرى واحدة تتضمن الخطأ المحدد، مثل 'يجب أن تكون قيمة requested_date تاريخًا؛ تذكر الرسالة يوم السبت، وتاريخ الطلب هو 14 أكتوبر'. اجعل الحد الأقصى لإعادة المحاولة مرة أو مرتين، ثم أحِل الرسالة إلى شخص.

كيف تبدو المخرجات المنظّمة الضعيفة والمتينة؟

النسخة الضعيفة: تقول التعليمة 'استخرج التفاصيل وأجب بصيغة JSON.' يقرأ التطبيق أي مخرجات يتلقاها. وبالنسبة إلى رسالة البريد الإلكتروني أعلاه، يتلقى حقلين باسم order وdate، وقيمة تاريخ هي 'السبت'، وقيمة لاسترداد المبلغ هي true، لأن النموذج تعامل مع عبارة 'وإلا فألغِ الطلب فحسب' على أنها طلب قاطع. تُملأ الاستمارة بشكل خاطئ ويحصل العميل على استرداد مبلغ لم يكن يريده.

النسخة المتينة: يتضمن الطلب مخطط البيانات الذي أعدّته سناء مع تفعيل الوضع الصارم، ويوضح نص التعليمات كل حقل، بما في ذلك 'تكون قيمة refund_requested هي true فقط إذا طلب العميل استرداد المبلغ دون قيد أو شرط'. يُرجع النموذج القيمة PW-88213 للحقل order_reference، وتاريخ السبت القادم للحقل requested_date، والقيمة null للحقل new_address، والقيمة false للحقل refund_requested، ويضبط الحقل conditional_request، الذي أضافته سناء إلى المخطط خصيصًا لهذه الحالة، على 'استرداد المبلغ إذا تعذّر التسليم يوم السبت أو إلى أحد الجيران'. يؤكد التحقق وجود الطلب وأن السبت يوم تسليم. ولأن الرسالة تتضمن طلبًا مشروطًا، تُحيلها القواعد إلى شخص لاتخاذ القرار النهائي.

ما الأخطاء الشائعة في المخرجات المهيكلة؟

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

أين يقع موضوع المخرجات المهيكلة ضمن دليل دورات Tosheo.ai؟

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

المصادر والنطاق

وثائق واجهة برمجة تطبيقات OpenAI، ودليل المخرجات المهيكلة، والمقارنة مع وضع JSON، وحالات رفض الاستجابة (تم التحقق في 19 أكتوبر 2026) ↗

وثائق Anthropic Claude، المخرجات المنظّمة والاستخدام الصارم للأدوات (تم التحقّق في 19 أكتوبر 2026) ↗

وثائق واجهة برمجة تطبيقات Gemini من Google، المخرجات المهيكلة وإرشادات التحقق من صحتها (تم التحقق في 19 أكتوبر 2026) ↗