يمكن للمطورين الآن ضمان مطابقة الـ JSON الذي تُرجعه النماذج اللغوية الكبيرة (LLM) لشكل محدد مسبقاً من خلال ربط مخططات (schemas) Zod بـ Vercel AI SDK أو واجهة برمجة تطبيقات استخدام الأدوات (tool-use API) من Anthropic، مما يقضي على حالات الانهيار أثناء التشغيل (runtime crashes) التي تحدث عندما يضيف النموذج حقلاً غير متوقع.

أصبحت الحاجة إلى نظام حماية ملموس واضحة في شهر يناير، عندما بدأ مصنف (classifier) تم إطلاقه في بيئة الإنتاج بإرجاع مفتاح "explanation" ثانٍ بعد ثلاثة أسابيع من العمل المثالي. كان الكود يتوقع حقلاً واحداً فقط، لذا تسبب المفتاح الإضافي في حدوث استثناء (exception) — دون إجراء أي عملية نشر للكود (code deploy). توضح هذه الحادثة مشكلة أوسع: معظم الشروحات التعليمية تتوقف عند JSON.parse(response)، بافتراض أن النموذج سيلتزم بالمخطط (schema) المحدد في الأمر (prompt). في الواقع، غالباً ما تحيد النماذج اللغوية الكبيرة عن المسار — فتغير حالة الأحرف، أو تضيف حقولاً، أو تضع المخرجات داخل أطر markdown — مما يؤدي إلى فساد صامت للبيانات أو فشل تام.

لماذا يُعد تحليل JSON الخام غير آمن

يتم تدريب النماذج اللغوية الكبيرة لتكون مفيدة، لا مطيعة. فالأمر (prompt) الذي يطلب

{ "category": "string" }

لا يلزم النموذج بهذا الهيكل الدقيق. حتى الأمر المكتوب جيداً يمكن أن يتم تجاوزه بواسطة الاستدلالات الداخلية (heuristics) للنموذج، خاصة عندما تشجع إعدادات درجة الحرارة (temperature) على الإبداع أو عندما تدفعه تعليمات لاحقة إلى الاستفاضة في الشرح. والنتيجة هي تدفق نصي يبدو كأنه JSON ولكنه ينحرف بما يكفي لكسر أدوات التحليل (parsers) التي تتوقع شكلاً صارماً.

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

Zod + Vercel AI SDK: شبكة أمان من ثلاث خطوات

Zod هو أداة للتحقق من صحة المخططات (schema validator) تعتمد على TypeScript أولاً، ويمكنها وصف شكل البيانات الدقيق الذي يجب أن يخرجه النموذج. وبالاقتران مع المساعد Output.object في Vercel AI SDK، تتم عملية التحقق تلقائياً بعد أن يولد النموذج استجابته.

  1. تحديد المخطط (Define the schema) – اكتب كائن Zod يعكس الـ JSON المطلوب. بالنسبة لمصنف بسيط، قد يكون z.object({ category: z.string() })؛ أما بالنسبة لمستخرج فواتير معقد، فيمكن للمخطط أن يتضمن كائنات ومصفوفات و discriminated unions متداخلة.
  2. تمريره إلى الـ SDK – قم بتغليف المخطط باستخدام Output.object(schema). يقوم الـ SDK بحقن أمر (prompt) يخبر النموذج بإخراج كتلة JSON تطابق المخطط، ثم يقوم بتحليل النتيجة باستخدام safeParse من Zod.
  3. معالجة الإخفاقات – تعيد safeParse كائن نتيجة بدلاً من إطلاق استثناء. إذا فشل التحليل، قم بتغذية الخطأ مرة أخرى للنموذج وأعد المحاولة. يمكن توجيه النموذج لتصحيح المخرجات بناءً على رسالة التحقق الدقيقة، مما يحول معظم الحالات الاستثنائية إلى حلقة إصلاح ذاتي.

ولأن الـ SDK يتولى عمليات صياغة الأوامر، والتحليل، ومنطق إعادة المحاولة في مكان واحد، يستبدل المطورون مجموعة من عمليات معالجة النصوص العشوائية باستدعاء واحد يتم التحقق من نوعه (type-checked).

استخدام أدوات Anthropic: فرض المخرجات المهيكلة

عند العمل مباشرة مع واجهة برمجة تطبيقات Anthropic، يمكن تحقيق نفس الضمان من خلال "استخدام الأدوات" (tool use). تُعرف الأداة بأنها دالة يتم التعبير عن مخطط مدخلاتها باستخدام JSON Schema؛ ولن يقوم نموذج Anthropic باستدعاء الأداة إلا إذا كان بإمكانه تلبية متطلبات المخطط. ومن خلال ضبط tool_choice على "any" (أو اسم أداة محدد)، يُجبر النموذج على إرجاع كتلة مهيكلة بدلاً من نص حر التنسيق.

يحاكي سير العمل نهج Vercel:

  • اكتب مخطط Zod.
  • قم بتحويله إلى حمولة (payload) بتنسيق JSON Schema لتعريف الأداة.
  • قم بتضمين الأداة في الطلب واطلب من النموذج استدعاءها.
  • قم بتحليل استجابة الأداة باستخدام zod.safeParse.

إذا استمر النموذج في إنتاج بيانات غير صالحة، ينطبق نفس نمط "إعادة المحاولة مع التغذية الراجعة".

عندما يفشل التحقق رغم ذلك

حتى مع فرض المخطط، تحدث حالات عدم تطابق عرضية. وتشمل الأسباب ما يلي:

  • هلوسة النموذج (Model hallucination): قد يولد النموذج سلسلة نصية تبدو كأنها JSON ولكنها تحتوي على أخطاء في الصيغة (syntax errors).
  • تسرب الأوامر (Prompt leakage): يمكن أن تؤدي جولات المحادثة السابقة إلى تسريب تعليمات التنسيق التي تتجاوز طلب المخطط.
  • اختلاف الإصدارات: تؤدي إصدارات النماذج الأحدث أحياناً إلى تغيير كيفية تفسيرها لاستدعاءات الأدوات.

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

اعتبارات الأداء والتكلفة

تؤدي إضافة التحقق من صحة البيانات باستخدام Zod إلى عبء ضئيل جداً على وحدة المعالجة المركزية (CPU)—إذ تستغرق عملية safeParse أجزاءً من المليون من الثانية للحمولات النموذجية. ولا يتأثر زمن انتقال الشبكة (Network latency)؛ حيث لا تحدث الرحلة الإضافية (round-trip) لإعادة المحاولة إلا في حالات الفشل النادرة. ومن الناحية العملية، فإن تكلفة منع استثناء (exception) واحد تفوق بكثير الزيادة الطفيفة في وقت الطلب.

الحجة المضادة: هل فرض المخطط (schema enforcement) مبالغ فيه؟

يجادل بعض المطورين بأن المخططات الصارمة تحد من مرونة النموذج، خاصة عندما يمكن للحقول الجديدة أن توفر سياقاً قيماً. المفاضلة هنا هي بين الأمان والانفتاح. في الخدمات الحساسة (mission-critical)—مثل معالجة المدفوعات، والتحقق من الهوية، وتقارير الامتثال—تكون الأولوية للقدرة على التنبؤ. أما في النماذج الأولية الاستكشافية، فقد يكون النهج الأكثر مرونة مقبولاً، ولكن حتى هناك، يمكن لآلية حماية بسيطة (مثل z.object({}).passthrough()) أن تكتشف أخطاء التحليل (parsing errors) الكارثية دون التخلص من الامتدادات المفيدة.

ما يجب مراقبته لاحقاً

  • تطور الـ SDK: تتضمن خارطة طريق Vercel’s AI SDK سياسات إعادة محاولة مدمجة وتقارير أخطاء أكثر ثراءً، مما سيسهل عملية الإصلاح (repair loop) بشكل أكبر.
  • توحيد الأدوات: مع اعتماد المزيد من المزودين لاتفاقيات استخدام الأدوات (tool-use conventions)، قد تظهر أدوات تحقق من المخططات (schema validators) عابرة للمزودين، مما يقلل الحاجة إلى محولات (adapters) خاصة بكل مزود.
  • أنماط المجتمع: بدأت المكتبات مفتوحة المصدر في دمج مخططات Zod مع قوالب الأوامر (prompt templates)، مما يجعل سير العمل القائم على "المخطط أولاً" (schema-first) أصلاً قابلاً لإعادة الاستخدام.

الخلاصة

من خلال التعامل مع مخطط Zod كعقد لا يمكن للنموذج خرقه، ينتقل المطورون من حيل JSON.parse الهشة إلى مسار عمل حتمي (deterministic pipeline) حيث تتسبب الحقول غير المتوقعة في فشل تحقق مُتحكم به، وليس في انهيار بيئة الإنتاج. إن الجمع بين مساعد Output.object من Vercel وآلية استخدام الأدوات من Anthropic يحول نماذج LLMs من مولدات نصوص غير متوقعة إلى مزودي بيانات موثوقين، مما يتيح للفرق التركيز على منطق العمل (business logic) بدلاً من الانشغال اللامتناهي بتصحيح أخطاء الحالات الاستثنائية (edge-case debugging).