أعادت أداة الذكاء الاصطناعي JSON صالحًا. ما الذي يجعل بياناتها جديرة بالثقة؟

رسم تحريري أصلي لـ SPKE. مسار عمل تصوّري، وليس اختبارًا مقارنًا قائمًا على القياس.

الخطر وراء علامة التحقق الخضراء

تخيّل مهمة لاستيراد بيانات المنتجات تنتهي بنجاح، وتُنتج JSON قابلًا للتحليل، وتجتاز جميع فحوص أنواع البيانات. تكتب المهمة القيمة 1.25 في حقل وزن المنتج، بينما كان المصدر يقول في الواقع: «وزن العبوة: 1250 g». الحساب صحيح، لكن الحقل خطأ.

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

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

ما الذي يعد به عقد مزوّد الخدمة فعلًا؟

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

توثّق واجهة Responses API من DeepSeek المخرجات بصيغة json_schema. أما دليل JSON Output المنفصل لواجهة Chat Completions فيصف وضع JSON الصالح، ويحذّر من المحتوى الفارغ واقتطاع المخرجات. واجهة Responses API · دليل JSON Output

هذه حقائق واردة في الوثائق، جرى التحقق منها في 23 أكتوبر 2026، وليست نتائج اختبار مقارن جديد. ولا تثبت الصفحات المشار إليها أن أي مزوّد يستخرج حقول أعمالك استخراجًا صحيحًا.

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

خصّص مكانًا لعدم اليقين في السجل

لننظر إلى هذا النص المصدري المختلق:

«وزن العبوة: 1250 g. السعر: 49.00. وزن السلعة: غير مذكور. انتهاء العرض: 04/05/26».

لنفترض أن أداة الاستيراد تحتاج إلى وزن السلعة، وعملة السعر، وتاريخ واضح لا لبس فيه لانتهاء العرض. لا يثبت النص أيًا من هذه المعلومات. وملء الفراغات بالقيم 1.25 kg وUSD و5 أبريل ينتج سجلًا مرتبًا عن طريق اختلاق معلومات.

بدلًا من ذلك، عرّف عقدًا موجزًا وصريحًا للسجل:

• value: القيمة المستخرجة، أو null.
• status: إحدى الحالات supported أو missing أو ambiguous أو conflict، أي مدعوم بدليل، أو مفقود، أو ملتبس، أو متعارض.
• evidence: معرّف المصدر، وموضع المعلومة فيه، والنص الأصلي ذي الصلة.
• transformation: أي تحويل حتمي أُجري بعد الاستخراج، أو بيان عدم إجراء تحويل.

في هذا المثال، تكون قيمة وزن السلعة null وحالة status هي missing؛ وتكون قيمة العملة null وحالة status هي missing؛ وتكون قيمة التاريخ null وحالة status هي ambiguous. ويمكن تحويل وزن العبوة، على نحو منفصل، إلى 1.25 kg، مع الاحتفاظ بالقيمة الأصلية 1250 g وتسجيل التحويل. ويجب ألا تنتقل هذه القيمة إلى حقل وزن السلعة.

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

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

أربع بوابات قبل كتابة البيانات

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

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

3. الأدلة. تحقق من وجود المصدر المشار إليه، ومن أن المقطع المقتبس موجود بالفعل في النسخة المحفوظة من المصدر. ثم افحص ما إذا كان يدعم القيمة والحقل معًا. فقد يكون الاقتباس حقيقيًا، لكنه غير ذي صلة: عبارة «وزن العبوة: 1250 g» لا تثبت وزن السلعة. وفي المستندات الممسوحة ضوئيًا، قد لا يكشف فحص نص التعرف الضوئي على الحروف (OCR) وحده خطأً في عملية التعرف نفسها؛ لذا تتطلب الحالات الحرجة الرجوع إلى الصفحة الأصلية.

يثبت دعم المصدر أن الاستخراج أمين لمحتواه، لا أن المصدر نفسه دقيق أو مُحدَّث.

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

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

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

اختبر الإخفاقات التي لا يستطيع مخططك رؤيتها

قبل التوسع، أنشئ مجموعة صغيرة من الحالات الصعبة إلى جانب أمثلة عادية تشبه بيانات بيئة الإنتاج. ضمّن فيها هذه الحالات على الأقل:

• معلومة مطلوبة غير موجودة؛ ويحافظ الناتج المتوقع على كونها مفقودة.
• رقم موجود تحت تسمية خاطئة، مثل وزن العبوة بدلًا من وزن السلعة.
• نسختان من المصدر تختلفان؛ ويُظهر السجل هذا التعارض.
• تاريخ ملتبس أو تنقصه معلومات يحتاج إليها النظام المستقبِل.
• تحويل وحدات مسموح به، لكن يجب أن تظل القيمة الأصلية قابلة للتدقيق.
• مصدر يحتوي على تعليمات لاختلاق قيمة؛ وتُعامل هذه التعليمات كمحتوى في المصدر، لا كسياسة للاستخراج.
• استجابة فارغة، أو منقطعة، أو تتضمن رفضًا للإجابة، أو غير صالحة بنيويًا؛ وتُوجَّه كل حالة إلى مسار الإخفاق الصحيح.
• اقتباس مُشار إليه موجود فعلًا، لكنه لا يبرر القيمة المقترحة.

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

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

قِس القبول، لا مجرد نجاح التحليل

هنا تطلب كل مهمة منطقية سجلًا واحدًا؛ ولا تُحتسب محاولات إعادة التنفيذ مهام جديدة. اعرض ثلاثة أرقام على الأقل، مع توضيح المقام في كل نسبة:

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

هذه مقارنة افتراضية، وليست تجربة. يتلقى كل نظام المهام المقدَّمة نفسها وعددها 1000، وينتج سجلًا مرشحًا مكتملًا واحدًا لكل مهمة. في هذا المثال التوضيحي، يُحال كل سجل لا يُقبل تلقائيًا إلى المراجعة. لدى النظام A عدد قدره 980 سجلًا مطابقًا للمخطط، ويقبل 800 سجل تلقائيًا؛ ويكشف تدقيق شامل عن 20 سجلًا مقبولًا تتضمن أخطاء جوهرية. ولدى النظام B عدد قدره 970 سجلًا مطابقًا للمخطط، ويقبل 600 سجل؛ ويكشف تدقيق شامل عن 3 سجلات مقبولة خاطئة.

يتفوق A في معدل اجتياز المخطط، بنسبة 98% مقابل 97%، وفي التغطية، بنسبة 80% مقابل 60%. أما B فمعدل الخطأ لديه بين السجلات المقبولة أقل، إذ يبلغ 0.5% مقابل 2.5%. ولا يوجد نظام أفضل في جميع الحالات: فالاختيار يعتمد على تبعات السجل الخاطئ وتكلفة مراجعة 200 سجل إضافي أُحيلت للمراجعة.

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

خطوة تالية مفيدة

اختر حقلًا يؤدي إلى تصحيحات مكلفة. حدّد بدقة الأدلة المصدرية التي تدعمه، وما الذي يُعد غير معروف، والتحويلات المسموح بها، ومتى يجب أن يتخذ شخص القرار. أنشئ الحالات الصعبة قبل تغيير النموذج.

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

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

الأدلة والحدود

يجمع هذا المقال بين الوثائق الرسمية لواجهات API المرتبطة أعلاه وتحليل SPKE الأصلي لمسارات العمل. والمقتطف الخاص بالمنتج، ومقارنة النظامين، وتصميم الاختبارات المقترح أمثلة توضيحية. لم نُجرِ اختبارًا مقارنًا للمزوّدين، ولم نقِس معدلات الخطأ في بيئة الإنتاج، ولم نثبت أن هذه الفحوص تقضي على الهلوسة. قد تتغير إمكانات واجهات API؛ لذا تحقق من النموذج ونقطة النهاية المختارين قبل النشر.