تقنية بذكاء

الصفحة الرئيسية
الذكاء الاصطناعي العملي

لماذا تحتاج بعض مهام الذكاء الاصطناعي إلى مخرجات منظمة بدل النص الحر ؟

تعرف على سبب حاجة بعض مهام الذكاء الاصطناعي إلى مخرجات منظمة بدل النص الحر، وكيف تساعد الحقول والقوالب المحددة على التحقق والأتمتة وتقليل الأخطاء
تطلب من نظام ذكاء اصطناعي قراءة فاتورة ، ثم تسأله :
( استخرج بيانات الفاتورة ) .
فيجيب :
الفاتورة صادرة بتاريخ 15 مايو 2026 ، وقيمتها الإجمالية 1,840 ريالًا ، ويبدو أن الضريبة 240 ريالًا ورقم الفاتورة 7854 .
بالنسبة إلى إنسان ، هذه إجابة مفهومة جدًا .
يمكنك قراءتها ومعرفة ما تريد .
لكن تخيل أن هناك برنامجًا آخر ينتظر النتيجة ليضيفها تلقائيًا إلى قاعدة بيانات .
أين يجد رقم الفاتورة ؟
كيف يعرف أن 1,840 هو الإجمالي وليس المبلغ قبل الضريبة ؟
وماذا يفعل إذا أجاب النظام في المرة التالية بهذه الصياغة :
الإجمالي : 1840 ريال
 رقم المستند : 7854
 الضريبة المضافة : 240
 التاريخ : 15/05/2026
المعلومة نفسها تقريبًا ، لكن شكلها تغير .
بالنسبة للإنسان لا توجد مشكلة كبيرة .
أما بالنسبة إلى برنامج يريد معالجة آلاف النتائج تلقائيًا ، فهذه مشكلة حقيقية .
ولهذا لا تكفي قدرة الذكاء الاصطناعي على إعطاء الإجابة الصحيحة في بعض المهام .
نحتاج أيضًا إلى أن يعطيها بالشكل الصحيح .
وهنا تظهر فكرة المخرجات المنظمة : بدل ترك النموذج يقرر بحرية كيف يصوغ النتيجة ، نحدد مسبقًا الحقول والبنية التي يجب أن تعود بها المعلومات .
الهدف ليس جعل الإجابة أجمل .
بل جعلها قابلة للاستخدام والتحقق والمعالجة من نظام آخر دون الحاجة إلى تخمين ما قصده النص .

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

1. النص الحر ممتاز للإنسان

عندما تطلب :
( اشرح لي لماذا فشلت هذه الخطة ) .
فإن النص الحر مناسب جدًا .
يمكن للنظام أن :

  • يمهد للفكرة .
  • يرتب الأسباب .
  • يضيف مثالًا .
  • يربط بين النقاط .
  • ويستخدم اللغة بالطريقة الأنسب للشرح .

لا يوجد سبب يدفعنا إلى إجباره على تحويل كل فكرة إلى خانات ثابتة .
كذلك في :

  • كتابة مقال .
  • شرح مفهوم .
  • العصف الذهني .
  • اقتراح أفكار .
  • صياغة رسالة .
  • مناقشة قرار .

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

2. البرنامج لا يفهم ( المعنى العام ) بالطريقة التي يفعلها الإنسان

لنفترض أن برنامجًا يحتاج إلى هذه المعلومات :

  • الاسم .
  • التاريخ .
  • المبلغ .
  • العملة .
  • حالة الدفع .

إذا أعاد الذكاء الاصطناعي :
دفع خالد مبلغ 750 ريالًا يوم الثلاثاء الماضي ، ويبدو أن العملية مكتملة .
يمكن للإنسان استنتاج الكثير .
لكن البرنامج يواجه أسئلة :
هل ( خالد ) هو العميل أم المستلم ؟
ما التاريخ الدقيق لـ( الثلاثاء الماضي ) ؟
هل العملة دائمًا ريال سعودي ؟
هل ( يبدو أن العملية مكتملة ) تعني :
paid
أم :
probably_paid
أم شيئًا آخر ؟
المشكلة هنا ليست ضعف الذكاء الاصطناعي .
المشكلة أن النص الطبيعي يسمح بدرجات كبيرة من الغموض والتنوع .
البرامج تحتاج عادة إلى شيء أكثر صرامة .
مثل :

الاسم : خالد
المبلغ : 750
العملة : SAR
حالة_الدفع : مدفوع

الآن أصبح لكل معلومة مكان محدد .

3. ما المقصود بالمخرجات المنظمة ؟

المخرج المنظم هو نتيجة تتبع بنية متفقًا عليها مسبقًا .
وقد تكون هذه البنية مجرد تنسيق نطلب من النموذج الالتزام به ، أو مخططًا Schema تحدده المنصة أو التطبيق ليصف الحقول وأنواعها والقيم المسموحة .
وفي الحالة الثانية يمكن التحقق آليًا من مطابقة المخرج للبنية قبل استخدامه .
قد تكون بسيطة جدًا ، مثل جدول :
الحقل   القيمة
رقم الفاتورة         7854
   التاريخ    2026-05-15
  الإجمالي         1840
   العملة         SAR
وقد تكون بنية يمكن للبرنامج قراءتها مباشرة ، مثل :
{"invoice_number": "7854",
  "date": "2026-05-15",
  "total": 1840,
  "currency": "SAR"}
المهم ليس اسم التنسيق .
الفكرة الأساسية هي أن البرنامج يعرف مسبقًا :
ما الحقول الموجودة ، وما معنى كل حقل ، وما نوع القيمة المتوقع داخله .
بدل البحث داخل فقرة كاملة عن المعلومة المطلوبة .

4. الشكل الثابت يقلل طبقة كاملة من الأخطاء

تخيل نظامًا يقرأ طلبات العملاء .
المطلوب منه استخراج :

  • نوع الطلب .
  • درجة الأولوية .
  • رقم العميل .
  • هل يحتاج تدخلًا بشريًا ؟

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

نوع_الطلب = فوترة
الأولوية = مرتفعة
يتطلب_تدخل_بشري = نعم

فإن الخطوة التالية لا تحتاج إلى تفسير لغوي .
وهذا يقلل مساحة الخطأ .

5. المخرجات المنظمة لا تجعل المعلومة صحيحة تلقائيًا

هذه نقطة مهمة جدًا .
إذا أعاد النظام :
{"total": 2500,
  "currency": "SAR"}
فهذا لا يثبت أن الإجمالي 2500 فعلًا .
قد يكون النموذج قرأ الرقم بصورة خاطئة .
المخرجات المنظمة تحل مشكلة :
كيف تُعرض النتيجة ؟
ولا تحل وحدها مشكلة :
هل النتيجة صحيحة ؟
يمكن أن نحصل على بيانات منظمة تمامًا وخاطئة تمامًا .
ولهذا يجب الفصل بين نوعين من الجودة :
صحة البنية
هل النتيجة تتبع الشكل المطلوب ؟
و :
صحة المحتوى
هل القيم الموجودة داخل هذه البنية صحيحة ؟
وهذا يشبه ما تناولناه في مقال أخطاء الذكاء الاصطناعي في الحسابات : التنظيم لا يعوض خطأ قراءة الرقم الأصلي .

6. لماذا تصبح البنية أكثر أهمية مع الأتمتة ؟

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

7. الوكيل يحتاج إلى نتيجة يستطيع استخدامها لا مجرد قراءتها

هذه النقطة تصبح أوضح مع وكلاء الذكاء الاصطناعي .
لنفترض أن وكيلًا يريد معرفة موعد متاح .
هناك خطوة تبحث عن المواعيد .
ثم خطوة تختار الأفضل .
ثم خطوة تعبئ النموذج .
إذا أعادت خطوة البحث فقرة :
توجد عدة مواعيد ، منها التاسعة صباحًا يوم الاثنين ، وربما يناسبك أيضًا الثلاثاء بعد الظهر .
فإن الخطوة التالية تحتاج إلى تفسير هذه اللغة .
أما إذا عادت النتيجة :
التاريخ : 2026-09-07
الوقت : 09:00
الحالة : متاح
تصبح عملية الانتقال إلى التنفيذ أكثر وضوحًا .
ولهذا فإن المخرجات المنظمة ليست مجرد تحسين شكلي .
إنها أحيانًا اللغة المشتركة التي تتحدث بها أجزاء النظام مع بعضها .

8. البنية الجيدة تكشف المعلومة المفقودة بدل أن تختلقها

هناك فائدة أخرى مهمة .
لنفترض أننا نحتاج :

  • الاسم .
  • رقم الهوية .
  • تاريخ الميلاد .

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

إنفوجرافيك يوضح كيف تكشف المخرجات المنظمة المعلومات المفقودة بوضوح، حيث تظهر الحقول الإلزامية مع القيم المتوفرة بينما يُسجل الحقل غير الموجود على أنه غير متوفر بدل اختلاق قيمة

9. نوع البيانات مهم مثل اسم الحقل

لنقل إن لدينا :
السعر = ( ألفان وخمسمائة ريال )
هذه قيمة مفهومة للإنسان .
لكن إذا كان البرنامج يريد جمع الأسعار ، فسيحتاج إلى تحويلها .
الأفضل قد يكون :
السعر = 2500
و :
العملة = SAR
كذلك التاريخ .
بدل :

15 مايو 2026

قد نحتاج :

2026-05-15

أما تعبير نسبي مثل ( الجمعة القادم ) ، فلا ينبغي تحويله إلى تاريخ مطلق ما لم يكن التاريخ المرجعي معروفًا بوضوح .
والنسبة :
بدل :
حوالي خمسة عشر بالمئة
قد تكون :
0.15
أو :
15
بحسب الاتفاق .
إذن تنظيم المخرج لا يتعلق بأسماء الحقول فقط .
بل أيضًا بنوع البيانات داخل كل حقل .

10. كيف نصمم بنية جيدة ؟

البنية الجيدة ليست التي تحتوي على أكبر عدد ممكن من الحقول .
بل التي تمثل ما تحتاج إليه الخطوة التالية فقط .

أ. اجعل كل حقل يحمل معنى واحدًا

حقل مثل :
details
قد يصبح مكانًا لكل شيء .
أما :
customer_name
order_number
issue_type
فأوضح .

ب. افصل القيم المختلفة

لا تجعل :
المبلغ = 2500 ريال شامل الضريبة
إذا كان النظام التالي يحتاج الرقم والعملة والضريبة بصورة منفصلة .
الأفضل فصلها .

ج. حدد ما هو إلزامي وما هو اختياري

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

د. حدد القيم المسموحة عندما يكون ذلك ممكنًا

إذا كان مستوى الأولوية يجب أن يكون فقط :

منخفضة
متوسطة
مرتفعة

فهذا أفضل من السماح للنظام بابتكار :
شديدة جداً
أو

مهمة نسبيًا .

تحديد الخيارات يقلل اختلاف التفسير .

11. البنية الصارمة جدًا قد تسبب مشكلة أيضًا

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

  • ملء حقول لا علاقة لها بالحالة .
  • استخدام قيم فارغة كثيرة .
  • أو اتخاذ قرارات لم تكن ضرورية .

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

12. مثال عملي : فرز طلبات الصيانة

تخيل شركة تستقبل مئات طلبات الصيانة .
رسالة العميل :
المكيف في غرفة الاجتماعات بالطابق الثاني لا يعمل منذ الصباح ، وهناك اجتماع مهم الساعة الواحدة .
يمكن أن يجيب النظام :
المشكلة تبدو عاجلة لأنها تؤثر في غرفة اجتماعات وهناك موعد قريب ، ويُفضل إرسال فني تكييف بسرعة .
إجابة جيدة للإنسان .
لكن نظام إدارة الصيانة يحتاج شيئًا مثل :
نوع_العطل : تكييف .
الموقع : غرفة الاجتماعات - الطابق الثاني .
الأولوية : مرتفعة .
الموعد_المؤثر : 13:00.
يتطلب_فني : نعم .
الآن يمكن للنظام :

  • إنشاء التذكرة .
  • توجيهها إلى الفريق المناسب .
  • رفع الأولوية .
  • وإظهار الوقت الحرج .

من دون أن يحاول فهم فقرة لغوية كاملة .

13. يمكن الجمع بين النص الحر والمخرج المنظم

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

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

14. تحقق من البنية قبل استخدام النتيجة

هذه مشكلة يجب تصميم النظام للتعامل معها .
لنفترض أن المطلوب حقل :
priority
بقيمة واحدة من :
low
medium
high
لكن النظام أعاد :
urgent
لدينا نتيجة مفهومة ، لكنها لا تتبع الاتفاق .
هنا يجب ألا يفترض البرنامج معنى القيمة ثم يواصل بصمت .
قبل تمرير النتيجة إلى المرحلة التالية ، يمكن فحصها: هل الحقول المطلوبة موجودة ؟ هل أنواع القيم صحيحة ؟ وهل القيم المقيدة تنتمي إلى الخيارات المسموحة ؟
فإذا كنا نتوقع:
الاسم: نص
العمر: رقم
موافق : نعم / لا
ثم وصل :
الاسم : أحمد
العمر : كبير نسبيًا
موافق : ربما
فالمشكلة هنا واضحة : قيمة العمر ليست رقمًا ، وقيمة ( موافق ) لا تنتمي إلى الخيارات المسموحة .
إذا فشل هذا الاختبار ، فلا ينبغي للنظام التالي أن يتعامل مع النتيجة وكأنها صالحة .
يمكن رفضها ، أو طلب إعادة إنتاجها ، أو تحويلها إلى مراجعة بشرية ، أو تطبيق قاعدة تحويل محددة مسبقًا .
وهذا يجعل لدينا اختبارين منفصلين :
أولًا: هل البنية صحيحة ؟
ثم: هل المعلومات نفسها صحيحة ؟
فالنجاح في الاختبار الأول لا يضمن الثاني . 
قد تكون النتيجة منظمة تمامًا ، لكنها تحتوي على معلومة خاطئة .

15. المخرجات المنظمة مهمة جدًا عند استخدام الأدوات

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

  • إنشاء موعد .
  • البحث عن سجل .
  • إرسال قيمة إلى قاعدة بيانات .
  • حساب سعر .
  • تشغيل عملية معينة .

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

16. متى لا تحتاج إلى مخرجات منظمة ؟

ليس كل شيء يحتاج JSON أو جدولًا .
إذا سألت :
( اشرح لي هذه الفكرة كأنني مبتدئ ) .
لا توجد فائدة كبيرة من إجابة مثل :
مقدمة : ...
شرح 1 : ...
شرح 2 : ...
خاتمة : ...
قد تجعل النص أسوأ .
وإذا كنت :

  • تكتب قصة .
  • تناقش فكرة .
  • تريد رأيًا تحليليًا .
  • تحتاج إلى شرح متصل .
  • أو تبحث عن إبداع .

فالنص الحر قد يكون الخيار الأفضل .
المخرجات المنظمة مفيدة عندما تكون البنية نفسها جزءًا من متطلبات المهمة .

17. قاعدة عملية لتحديد الشكل المناسب

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

18. الخلاصة

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