هل طلبت من ChatGPT أو Claude أو Gemini إخراج البيانات في جدول منظم، لكنه أضاف مقدمة طويلة أو غيّر أسماء الأعمدة أو وضع المعلومات في ترتيب مختلف؟ وربما طلبت ملف JSON لاستخدامه في تطبيق، ثم اكتشفت أن النتيجة تحتوي على حقول ناقصة أو نصوص إضافية تمنع البرنامج من قراءتها. تتكرر هذه المشكلة عند استخدام الذكاء الاصطناعي في معالجة البيانات وإنشاء التقارير والبرمجة وإعداد المحتوى، خصوصًا عندما تحتاج إلى تكرار المهمة على عشرات المدخلات دون مراجعة كل نتيجة يدويًا. وقد يبدو النموذج ملتزمًا بالتعليمات في محاولة، ثم يقدم تنسيقًا مختلفًا عند تغيير الموضوع أو زيادة حجم البيانات. لذلك لا يكفي أن تكون الإجابة صحيحة من حيث المعنى؛ بل يجب أن تأتي في بنية يمكن قراءتها والتحقق منها وإعادة استخدامها. ويتطلب الوصول إلى هذا المستوى فهم الفرق بين طلب التنسيق باللغة الطبيعية وفرض بنية محددة تقنيًا، مع معرفة حدود كل طريقة.
لجعل الذكاء الاصطناعي يلتزم بصيغة محددة، عرّف شكل المخرجات والحقول المطلوبة وأنواع البيانات، وقدّم نموذجًا واضحًا للإجابة، ثم اختبر النتيجة وتحقق منها آليًا عند الحاجة. وللمهام البرمجية الحساسة للتنسيق، استخدم ميزة المخرجات المنظمة Structured Outputs مع JSON Schema متى كانت متاحة، بدل الاعتماد على صياغة الأمر وحدها.
قبل أن تبدأ
- حدد الصيغة المطلوبة: JSON أو جدول أو CSV أو XML أو نص بعناوين ثابتة.
- اكتب أسماء الحقول المطلوبة بالضبط، وحدد الحقول الإلزامية والاختيارية.
- حدد نوع البيانات في كل حقل، مثل النصوص والأرقام والقيم المنطقية والقوائم.
- أنشئ مثالًا صغيرًا يمثل شكل النتيجة الصحيحة دون إدخال بيانات حساسة.
- حدد طريقة التعامل مع المعلومات الناقصة أو غير المؤكدة.
- جهّز وسيلة للتحقق من النتيجة، خصوصًا إذا كانت ستُستخدم داخل برنامج أو قاعدة بيانات.
ما الذي ستحتاجه قبل البدء؟
يمكن تطبيق الخطوات باستخدام واجهة محادثة عادية مثل ChatGPT أو Claude أو Gemini، ولا تحتاج إلى معرفة برمجية إذا كان هدفك إنشاء جدول أو تقرير أو قائمة منظمة. يكفي أن تستطيع وصف البنية المطلوبة وتقديم مثال عليها ومراجعة الناتج.
أما إذا كنت تريد إرسال النتائج تلقائيًا إلى برنامج أو واجهة برمجية، فمن الأفضل استخدام Schema، وهو تعريف منظم يحدد الحقول وأنواع البيانات والقواعد التي يجب أن تستوفيها النتيجة.
على سبيل المثال، عند استخراج معلومات منتج، قد تحتاج إلى حقول ثابتة للاسم والسعر والتصنيف والتوفر. هنا يمكن تعريف الاسم باعتباره نصًا، والسعر رقمًا، والتوفر قيمة منطقية إما صحيحة أو خاطئة.
وتوضح الوثائق الرسمية لمعيار JSON Schema كيفية تعريف بنية البيانات وأنواعها والحقول المطلوبة والتحقق من مطابقة الملفات لتلك القواعد.
ويجب التمييز بين أمرين: صحة التنسيق، أي أن البيانات تتبع البنية المطلوبة، وصحة المحتوى، أي أن المعلومات نفسها دقيقة. فقد ينتج النموذج ملف JSON سليمًا من الناحية التقنية يحتوي على معلومات غير صحيحة.
الفكرة العملية: ابدأ بتحديد شكل النتيجة قبل كتابة التعليمات، واختر طريقة التحقق المناسبة بحسب ما إذا كانت المخرجات للقراءة البشرية أو للاستخدام البرمجي.
ما الخطوات بالترتيب الصحيح؟
للحصول على نتائج مستقرة، انتقل من تحديد هدف المهمة إلى وصف الصيغة، ثم إضافة القيود والأمثلة واختبار التنفيذ. ويمكن استخدام الخطوات نفسها مع أدوات ذكاء اصطناعي مختلفة، مع مراعاة أن مستوى الالتزام قد يتغير من نموذج إلى آخر.
حدد المهمة والنتيجة النهائية: لا تبدأ بعبارة عامة مثل «نظم هذه المعلومات». وضح ما تريد استخراجه أو تحويله، ولمن ستُستخدم النتيجة. مثلًا: «استخرج بيانات المنتجات من النص المرفق، وأعدها بصيغة JSON قابلة للقراءة برمجيًا».
اختر صيغة واحدة واضحة: إذا كانت النتيجة ستُقرأ داخل تطبيق، فقد تكون JSON مناسبة. أما إذا كنت تريد مراجعة بيانات في جدول، فقد تكون CSV أو الجداول المنظمة أكثر ملاءمة. تجنب طلب عدة صيغ مختلفة داخل الإجابة نفسها دون تحديد طريقة الفصل بينها.
اكتب أسماء الحقول المطلوبة: حدد كل حقل باسمه الدقيق بدل ترك النموذج يختار التسميات. على سبيل المثال، استخدم name وcategory وprice وavailable إذا كانت هذه الأسماء مطلوبة في التطبيق المستقبل للبيانات.
حدد أنواع البيانات: وضح أن price يجب أن يكون رقمًا لا نصًا يحتوي على رمز عملة، وأن available يجب أن يكون true أو false، وأن category نص. بهذه الطريقة تقل احتمالات اختلاف طريقة تمثيل القيم.
حدد التعامل مع القيم المفقودة: اطلب استخدام null عندما تكون المعلومة غير متوفرة، إذا كان الحقل يسمح بذلك. ولا تطلب من النموذج تخمين أسعار أو تواريخ أو أسماء لم ترد في البيانات الأصلية.
قدّم مثالًا للمخرجات الصحيحة: يمكن استخدام النموذج التالي داخل الأمر لتوضيح البنية المتوقعة. وهو مثال توضيحي، وليس بيانات منتج حقيقي.
{ "name": "Sample Product", "category": "Electronics", "price": 150, "available": true }إذا كنت تعمل داخل واجهة محادثة، أضف المثال إلى التعليمات واطلب المحافظة على أسماء الحقول وأنواعها. أما في التطبيقات البرمجية، فيُفضّل تعريف البنية من خلال إعدادات المخرجات المنظمة المتاحة.
امنع العناصر غير المطلوبة: اطلب عدم إضافة مقدمة أو خاتمة أو عناوين تفسيرية خارج البيانات. وإذا كنت تحتاج إلى JSON خام، فحدد أن المخرجات يجب أن تحتوي على كائن JSON واحد دون علامات Markdown المحيطة بالأكواد.
حدّد قيود المحتوى: إذا كان الوصف يجب ألا يتجاوز طولًا معينًا، أو كانت الفئة يجب أن تنتمي إلى قائمة خيارات، فاكتب ذلك صراحة. لكن تذكر أن الالتزام بهذه القيود قد يحتاج إلى تحقق مستقل حتى عند استخدام المخرجات المنظمة.
افصل التعليمات عن البيانات: ضع نص المهمة في قسم مستقل، والمدخلات في قسم آخر واضح الحدود. يمنع هذا الالتباس بين التعليمات التي يجب تنفيذها والمحتوى الذي يجب تحليله.
اختبر الأمر بمدخلات مختلفة: جرّبه على بيانات مكتملة وأخرى ناقصة وثالثة تحتوي على معلومات غير متوقعة. تحقق من ثبات أسماء الحقول وترتيبها عندما يكون مهمًا، وطريقة التعامل مع القيم غير المتوفرة.
استخدم المخرجات المنظمة عند توفرها: توفر بعض واجهات النماذج البرمجية إمكانية فرض بنية JSON محددة. وتوضح وثائق Google الرسمية للمخرجات المنظمة في Gemini كيفية استخدام JSON Schema للحصول على مخرجات منظمة، مع التنبيه إلى أن دعم قيود المعيار قد يقتصر على مجموعة محددة منها.
تحقق من النتيجة قبل استخدامها: استخدم محلل JSON للتأكد من سلامة البنية، ثم أداة تحقق من Schema للتأكد من أنواع القيم والحقول. وبعد ذلك افحص دقة المعلومات نفسها قبل حفظها أو نشرها أو تمريرها إلى تطبيق آخر.
يمكن جمع الخطوات السابقة في قالب أمر واحد قابل لإعادة الاستخدام، مع تغيير أسماء الحقول والصيغة ونوع المهمة فقط. فكلما كانت البنية مستقلة عن موضوع البيانات، أصبح تعديل القالب وإعادة اختباره أسهل.
الفكرة العملية: لا تكتفِ بكتابة «أعد النتيجة بصيغة JSON»، بل حدد الحقول وأنواع البيانات والقيم المفقودة وشكل الإجابة، ثم تحقق من تنفيذ هذه الشروط.
ما الأخطاء الشائعة التي يجب تجنبها؟
أحد أكثر الأخطاء شيوعًا هو الاعتماد على وصف عام للتنسيق، مثل طلب «جدول احترافي» دون تحديد الأعمدة. فقد يختار النموذج تسميات أو حقولًا مختلفة بحسب محتوى المدخلات، حتى لو كانت النتيجة مقروءة ومنظمة ظاهريًا.
ومن الأخطاء طلب JSON صالح دون تحديد بنية ثابتة. فقد ينتج النموذج كائنًا صحيحًا من الناحية النحوية لكنه لا يحتوي على الحقول التي يحتاجها البرنامج. لذلك يجب الفصل بين صلاحية JSON ومطابقته للمتطلبات.
كذلك قد يؤدي الجمع بين تعليمات متعارضة إلى نتائج غير مستقرة، مثل طلب «أعد JSON فقط» ثم مطالبة النموذج بشرح قراراته في فقرة خارج الملف. والحل هو تخصيص حقل داخل البنية للتفسير عند الحاجة، أو فصل مهمة إنشاء البيانات عن مهمة شرحها.
ومن الأخطاء أيضًا استخدام أمثلة غير متسقة؛ فإذا كان المثال يعرض السعر كنص بينما تشترط التعليمات أن يكون رقمًا، فقد لا يعرف النموذج أي القاعدتين ينبغي اتباعها.
ولا تفترض أن استخدام JSON Schema يعني صحة جميع القيم. فقد يلتزم النموذج بنوع الحقل لكنه ينتج معلومة غير موجودة في المصدر. وتشدد الوثائق الرسمية لمشروع JSON Schema على دور المعيار في تحديد بنية البيانات وقيودها، لا إثبات صحة المعلومات الواقعية.
ويجب كذلك تجنب الإكثار من الحقول الاختيارية والقواعد المتداخلة دون حاجة. فالبنى المعقدة قد تزيد صعوبة صيانة القالب، وقد تتجاوز القيود التي تدعمها بعض واجهات النماذج.
الفكرة العملية: اجعل كل شرط قابلًا للاختبار، واحذف التعليمات المتعارضة أو غير الضرورية قبل زيادة تعقيد القالب.
كيف تتحقق من نجاح كل خطوة؟
يبدأ التحقق بمقارنة النتيجة بالمواصفات الأصلية. فإذا كنت قد طلبت أربعة حقول محددة، فتأكد من وجودها جميعًا ومن عدم إضافة حقول غير مسموحة. ثم افحص أنواع القيم وطريقة التعامل مع البيانات المفقودة.
يمكن تقسيم التقييم إلى ثلاثة مستويات. المستوى الأول هو الصحة النحوية، مثل إمكانية قراءة JSON دون خطأ. والثاني هو مطابقة البنية، مثل وجود الحقول الإلزامية وأنواعها الصحيحة. والثالث هو صحة المعلومات ودقتها بالنسبة إلى النص المصدر.
إذا كانت النتيجة جدولًا، فتحقق من ثبات أسماء الأعمدة وعدم انتقال قيمة إلى عمود غير مناسب. أما في CSV، فراجع الفواصل والاقتباسات والأسطر، خصوصًا عندما تحتوي الحقول نفسها على فواصل أو علامات تنصيص.
وعند استخراج معلومات من مستندات طويلة، اختر عينة تتضمن حالات واضحة وأخرى غامضة. فقد ينجح القالب مع نص قصير لكنه يحذف معلومات مهمة عند معالجة نص أكثر تعقيدًا.
وتوضح إرشادات التحقق في JSON Schema أن أدوات التحقق تقارن البيانات بقواعد محددة مسبقًا، ما يسمح باكتشاف مشكلات لا يمكن الاعتماد على المراجعة البصرية وحدها لاكتشافها.
ومن الأفضل الاحتفاظ بحالات اختبار ثابتة عند تحسين الأوامر. فعندما تعدّل تعليمات القالب، يمكنك تشغيل الحالات نفسها ومقارنة النتيجة بالإصدار السابق لتحديد ما إذا كان التعديل قد حسّن الالتزام أم تسبب في أخطاء جديدة.
الفكرة العملية: قيّم نجاح التنسيق عبر صحة الملف ومطابقته للبنية وصحة البيانات، ولا تعتبر المخرجات ناجحة لمجرد أنها تبدو مرتبة.
ماذا تفعل إذا فشلت خطوة معينة؟
إذا أضاف الذكاء الاصطناعي مقدمة أو تعليقًا خارج التنسيق المطلوب، فأعد صياغة التعليمات بحيث تفصل بين محتوى الإجابة وشكلها. وإذا استمر ذلك في واجهة محادثة، فقد تحتاج إلى استخراج الجزء المنظم والتحقق منه برمجيًا بدل الاعتماد على النص الخام.
أما إذا غيّر أسماء الحقول، فاستخدم قائمة ثابتة بها، وأضف مثالًا واضحًا، وحدد منع الحقول الإضافية. وفي البيئات التي تدعم المخرجات المنظمة، يمكن استخدام قيود مثل additionalProperties عندما تدعمها واجهة النموذج.
إذا أرجع النموذج رقمًا كنص، فتحقق أولًا من تعليمات الحقل ومن المثال المستخدم. ثم استخدم التحقق الآلي لاكتشاف النوع الخاطئ قبل أن تنتقل البيانات إلى قاعدة المعلومات.
وعندما تكون البيانات ناقصة، لا تطلب من النموذج ملء الفراغ بأي قيمة. الأفضل تعريف سياسة صريحة، مثل استخدام null للحقول التي تسمح به أو وضع حالة «غير متوفر» في حقل نصي مناسب.
إذا فشل النموذج في معالجة بنية طويلة، فحاول تبسيطها وتقليل التداخل والحقول غير الضرورية. وقد يكون تقسيم العمل إلى مرحلتين، استخراج المعلومات ثم تحويلها إلى بنية محددة، أكثر سهولة في الاختبار.
أما إذا كنت تستخدم واجهة API وتظهر أخطاء في تعريف Schema نفسه، فتحقق من أنواع البيانات والخصائص المدعومة. فبعض الخدمات لا تدعم جميع ميزات JSON Schema، وقد تتجاهل قيودًا معينة أو ترفض تعريفات شديدة التعقيد.
وتنبه وثائق Gemini للمخرجات المنظمة إلى أن الالتزام ببنية JSON لا يضمن صحة القيم من حيث المعنى، وأن التحقق داخل التطبيق والتعامل مع الأخطاء يظلان ضروريين.
الفكرة العملية: حدد ما إذا كان الفشل في الصياغة أو البنية أو محتوى البيانات، ثم أصلح السبب مباشرة بدل إضافة تعليمات طويلة قد تولد تعارضات جديدة.
نصائح متقدمة لتحسين النتيجة
بعد نجاح القالب الأساسي، يمكنك تطويره من خلال فصل استخراج المعلومات عن عرضها. ففي المرحلة الأولى تُستخرج الحقائق والحقول من المصدر، وفي المرحلة الثانية تُحوّل إلى التنسيق النهائي. يساعد هذا الفصل على معرفة موضع الخطأ إذا ظهرت معلومات ناقصة أو مخرجات غير صالحة.
ومن المفيد استخدام القيم المحددة مسبقًا، المعروفة باسم enum، عندما لا يُسمح للحقل إلا بعدد محدود من الخيارات، مثل «عاجل» و«متوسط» و«منخفض». وتقلل هذه الطريقة اختلاف التسميات، مع بقاء الحاجة إلى التحقق من صحة التصنيف.
يمكنك أيضًا إضافة حقل يوضح مصدر المعلومة أو حالة الثقة بها عندما تتطلب المهمة ذلك. لكن لا تعتبر درجة الثقة التي يولدها النموذج قياسًا إحصائيًا موثوقًا تلقائيًا؛ فقد تكون مجرد تقدير لغوي يحتاج إلى تقييم مستقل.
وإذا كنت تطور تطبيقًا، ففضّل استخدام آلية المخرجات المنظمة الرسمية لدى مزود النموذج بدل محاولة إصلاح JSON المكسور بتعليمات متكررة فقط. وتختلف أسماء الإعدادات والقدرات المدعومة باختلاف الخدمة والنموذج.
كما يمكن استخدام اختبارات آلية بعد كل تعديل، تتأكد من الحقول الإلزامية وأنواع البيانات وحدود الطول والقيم المسموحة. وإذا فشل الاختبار، فلا تمرر النتيجة مباشرة إلى التطبيق؛ بل سجّل الخطأ وطبّق سياسة إعادة محاولة محدودة أو أحِل الحالة للمراجعة.
وتفيد إرشادات Anthropic الخاصة بالقوالب والمتغيرات في تنظيم التعليمات المتكررة وفصل الأجزاء الثابتة عن البيانات المتغيرة. ويمكن تطبيق المبدأ نفسه على القوالب التي تحدد تنسيق المخرجات.
ولا تتعامل مع الصيغة المنظمة بوصفها وسيلة لمنع جميع الأخطاء. فقد تتوافق الاستجابة مع Schema لكنها تحتوي على تلخيص مضلل أو تصنيف خاطئ أو معلومات مستنتجة دون أساس. ولهذا ينبغي الجمع بين التحقق البرمجي وتقييم جودة المحتوى.
الفكرة العملية: حوّل القالب الناجح إلى نظام يضم بنية ثابتة واختبارات تلقائية وسجلًا للأخطاء، بحيث يمكن إعادة استخدامه دون الاعتماد على المراجعة اليدوية في كل مرة.
مواضيع قد تهمك:
- Suno أم Udio: الأفضل للموسيقى وحقوق الاستخدام التجاري
- كيف يغيّر بروتوكول MCP ربط الذكاء الاصطناعي ببيانات المؤسسات؟
- من يملك حقوق الصور والنصوص والموسيقى المولدة بالذكاء الاصطناعي؟
- كيف تبني مكتبة أوامر Prompts وتعيد استخدامها بذكاء؟
الفكرة العملية: احتفظ بقوالب التنسيق الناجحة ضمن مكتبة أوامر منظمة، واربطها بالمهام التي تحتاج إلى مخرجات ثابتة وقابلة لإعادة الاستخدام.
أسئلة متكررة
هل يكفي أن أطلب من الذكاء الاصطناعي إخراج JSON فقط؟
قد ينجح ذلك في المهام البسيطة، لكنه لا يضمن ثبات الحقول أو أنواع البيانات. للحصول على نتائج أكثر قابلية للاعتماد، حدد البنية المطلوبة واستخدم التحقق الآلي أو المخرجات المنظمة عند توفرها.
ما الفرق بين JSON وJSON Schema؟
JSON صيغة لتمثيل البيانات، بينما JSON Schema وسيلة لوصف البنية والحقول وأنواع القيم والقواعد التي يجب أن تتبعها بيانات JSON.
هل يمكن فرض جدول ثابت دون استخدام البرمجة؟
نعم، يمكنك تحديد أسماء الأعمدة وترتيبها وتقديم مثال واضح داخل الأمر. لكن الالتزام الكامل ليس مضمونًا في جميع الحالات، خصوصًا مع المدخلات المعقدة.
هل المخرجات المنظمة تمنع اختلاق المعلومات؟
لا، فهي تساعد على ضبط شكل البيانات وأنواعها، لكنها لا تضمن دقة المعلومات نفسها. يجب مراجعة المحتوى أو مقارنته بالمصدر الأصلي.
لماذا يتغير تنسيق الإجابة رغم استخدام الأمر نفسه؟
قد تختلف الاستجابة بسبب تغير المدخلات أو النموذج أو الإعدادات أو السياق. ويساعد استخدام بنية ثابتة واختبارات مرجعية على اكتشاف هذه الاختلافات وتقليل أثرها.
متى أحتاج إلى التحقق البرمجي من المخرجات؟
يصبح التحقق البرمجي مهمًا عندما تُستخدم البيانات داخل تطبيق أو قاعدة بيانات أو عملية آلية، لأن الخطأ في الحقول أو الأنواع قد يؤدي إلى فشل التنفيذ أو تخزين معلومات غير صحيحة.
الفكرة العملية: استخدم التعليمات الواضحة للمهام البسيطة، وانتقل إلى Schema والتحقق الآلي عندما يتطلب العمل دقة بنيوية متكررة.
ماذا تفعل الآن
- اختر مهمة تحتاج إلى تنسيق ثابت، وحدد الحقول المطلوبة وأنواع البيانات وشكل النتيجة.
- أنشئ قالب أمر يتضمن مثالًا واضحًا وسياسة للتعامل مع المعلومات الناقصة.
- اختبر القالب على مدخلات مختلفة، ثم تحقق من صحة البنية والمحتوى قبل اعتماده.
جعل الذكاء الاصطناعي يلتزم بصيغة محددة لا يعتمد على تكرار التعليمات أو زيادة طولها، بل على تحويل المطلوب إلى قواعد واضحة يمكن اختبارها. وكلما فصلت بين المهمة والبيانات وبنية المخرجات، أصبحت الأخطاء أسهل في الاكتشاف والمعالجة، مع بقاء التحقق من دقة المعلومات ضروريًا حتى عند نجاح التنسيق. ابدأ الآن بإنشاء قالب JSON بسيط لمهمة تستخدمها باستمرار، واختبر مطابقته للحقول التي حددتها.