اب ڈویلپرز یہ یقینی بنا سکتے ہیں کہ LLM جو JSON واپس کرتا ہے وہ پہلے سے طے شدہ شکل (shape) کے مطابق ہو، جس کے لیے وہ Zod schemas کو Vercel AI SDK یا Anthropic کی tool-use API کے ساتھ جوڑ سکتے ہیں۔ اس سے وہ runtime crashes ختم ہو جاتے ہیں جو اس وقت ہوتے ہیں جب کوئی ماڈل کوئی غیر متوقع فیلڈ (field) شامل کر دیتا ہے۔

ایک ٹھوس حفاظتی نظام (guard) کی ضرورت جنوری میں واضح ہوئی، جب پروڈکشن میں موجود ایک classifier تین ہفتوں کے بہترین آپریشن کے بعد دوسری "explanation" key واپس کرنے لگا۔ کوڈ صرف ایک فیلڈ کی توقع کر رہا تھا، اس لیے اس اضافی key نے بغیر کسی کوڈ ڈیپلائمنٹ کے ایک exception پیدا کر دیا۔ یہ واقعہ ایک وسیع تر مسئلے کی نشاندہی کرتا ہے: زیادہ تر ٹیوٹوریلز JSON.parse(response) پر ہی رک جاتے ہیں، یہ فرض کرتے ہوئے کہ ماڈل پرامپٹ کے schema کی پیروی کرے گا۔ حقیقت میں، LLMs اکثر اپنے راستے سے بھٹک جاتے ہیں—جیسے casing تبدیل کرنا، نئی فیلڈز شامل کرنا، یا آؤٹ پٹ کو markdown fences میں لپیٹنا—جس کے نتیجے میں خاموش ڈیٹا کرپشن (silent data corruption) یا مکمل ناکامی ہو سکتی ہے۔

خام JSON پارسنگ (raw JSON parsing) کیوں غیر محفوظ ہے

LLMs کو مددگار بننے کے لیے تربیت دی جاتی ہے، فرمانبردار بننے کے لیے نہیں۔ ایک پرامپٹ جو

{ "category": "string" }

مانگتا ہے، وہ ماڈل کو اس مخصوص ڈھانچے (structure) تک محدود نہیں کرتا۔ ایک بہترین طریقے سے لکھا گیا پرامپٹ بھی ماڈل کے اندرونی ہیورسٹکس (heuristics) کی وجہ سے نظر انداز کیا جا سکتا ہے، خاص طور پر جب temperature سیٹنگ تخلیقی صلاحیتوں کی حوصلہ افزائی کرے یا جب کوئی بعد میں آنے والی ہدایت اسے تفصیل سے بتانے پر اکسائے۔ اس کا نتیجہ متن کے ایک ایسے سلسلے کی صورت میں نکلتا ہے جو JSON جیسا تو لگتا ہے لیکن اتنا مختلف ہوتا ہے کہ وہ پارسرز کو توڑ دیتا ہے جو ایک سخت شکل (strict shape) کی توقع رکھتے ہیں۔

جب ایسا تضاد پروڈکشن کوڈ تک پہنچتا ہے، تو اس کا نقصان فوری ہوتا ہے: ایک exception کا آنا، ایک ناکام درخواست، اور ممکنہ طور پر بعد میں آنے والی غلطیوں کا سلسلہ۔ بڑے سروسز میں ڈاؤن ٹائم کے وہ چند منٹ آمدنی کے نقصان اور صارفین کے بھروسے میں کمی کا باعث بنتے ہیں۔

Zod + Vercel AI SDK: تین مرحلہ وار حفاظتی جال (safety net)

Zod ایک TypeScript-first schema validator ہے جو اس ڈیٹا کی بالکل درست شکل بیان کر سکتا ہے جسے ماڈل کو فراہم کرنا چاہیے۔ Vercel AI SDK کے Output.object ہیلپر کے ساتھ مل کر، ماڈل کے جواب تیار کرنے کے بعد خود بخود ویلیڈیشن ہو جاتی ہے۔

  1. Schema کی تعریف کریں – ایک Zod object لکھیں جو مطلوبہ JSON کی عکاسی کرے۔ ایک سادہ classifier کے لیے یہ z.object({ category: z.string() }) ہو سکتا ہے؛ ایک پیچیدہ invoice extractor کے لیے schema میں objects، arrays، اور discriminated unions کو شامل کیا جا سکتا ہے۔
  2. اسے SDK کو فراہم کریں – schema کو Output.object(schema) کے ساتھ لپیٹ دیں۔ SDK ایک ایسا پرامپٹ شامل کرتا ہے جو ماڈل کو schema کے مطابق JSON بلاک آؤٹ پٹ کرنے کا کہتا ہے اور نتیجے کو Zod کے safeParse کے ذریعے پارس کرتا ہے۔
  3. ناکامیوں کو سنبھالیں – safeParse exception دینے کے بجائے ایک result object واپس کرتا ہے۔ اگر پارسنگ ناکام ہو جائے تو غلطی (error) کو دوبارہ ماڈل کو بھیجیں اور دوبارہ کوشش کریں۔ ماڈل کو درست ویلیڈیشن میسج کی بنیاد پر آؤٹ پٹ کو درست کرنے کی ہدایت دی جا سکتی ہے، جس سے زیادہ تر edge cases ایک خودکار اصلاحی لوپ (self-healing loop) میں بدل جاتے ہیں۔

چونکہ SDK پرامپٹنگ، پارسنگ، اور ری ٹرائی لاجک کو ایک ہی جگہ انجام دیتا ہے، اس لیے ڈویلپرز کئی ad-hoc اسٹرنگ مینیپولیٹیشنز کی جگہ ایک ہی ٹائپ چیک شدہ کال (type-checked call) استعمال کر سکتے ہیں۔

Anthropic tool use: ساختہ آؤٹ پٹ (structured output) کے لیے مجبور کرنا

جب براہ راست Anthropic کی API کے ساتھ کام کیا جا رہا ہو، تو "tool use" کے ذریعے وہی ضمانت حاصل کی جا سکتی ہے۔ ایک ٹول کو ایک ایسے فنکشن کے طور پر بیان کیا جاتا ہے جس کا input schema JSON Schema میں ہوتا ہے؛ Anthropic کا ماڈل ٹول کو صرف اس صورت میں کال کرے گا اگر وہ schema پر پورا اتر سکے۔ tool_choice کو "any" (یا کسی مخصوص ٹول کے نام) پر سیٹ کر کے، ماڈل کو آزادانہ متن کے بجائے ایک ساختہ بلاک (structured block) واپس کرنے پر مجبور کیا جاتا ہے۔

ورک فلو Vercel کے طریقے کی عکاسی کرتا ہے:

  • ایک Zod schema لکھیں۔
  • اسے ٹول کی تعریف کے لیے JSON Schema payload میں تبدیل کریں۔
  • درخواست (request) میں ٹول کو شامل کریں اور ماڈل کو اسے استعمال کرنے کا پابند بنائیں۔
  • ٹول کے جواب کو zod.safeParse کے ذریعے پارس کریں۔

اگر ماڈل پھر بھی غلط ڈیٹا تیار کرتا ہے، تو وہی "retry-with-feedback" والا طریقہ کار لاگو ہوتا ہے۔

جب ویلیڈیشن پھر بھی ناکام ہو جائے

Schema کے نفاذ کے باوجود، کبھی کبھار تضادات پیدا ہو جاتے ہیں۔ وجوہات میں شامل ہیں:

  • Model hallucination: ماڈل ایک ایسی اسٹرنگ تیار کر سکتا ہے جو JSON جیسی نظر آتی ہو لیکن اس میں سنٹیکس غلطیاں (syntax errors) ہوں۔
  • Prompt leakage: گفتگو کے پچھلے مراحل فارمیٹنگ کی ایسی ہدایات خارج کر سکتے ہیں جو schema کی درخواست کو نظر انداز کر دیں۔
  • Version differences: ماڈل کے نئے ورژن کبھی کبھی ٹول کالز کی تشریح کرنے کے طریقے کو بدل دیتے ہیں۔

تجویز کردہ حل ایک ہلکا پھلکا ری ٹرائی لوپ (retry loop) ہے۔ پارسنگ کی ناکامی پر، کوڈ ایک فالو اپ پرامپٹ بھیجتا ہے جیسے کہ “Your last output was not valid JSON. It contained … Please return only the fields defined in the schema.” چونکہ ویلیڈیشن کی غلطی واضح ہوتی ہے، اس لیے ماڈل انسانی مداخلت کے بغیر خود کو درست کر سکتا ہے۔

کارکردگی اور لاگت کے عوامل (Performance and cost considerations)

Zod validation کا اضافہ CPU پر نہ ہونے کے برابر بوجھ ڈالتا ہے—عام payloads کے لیے safeParse کا عمل مائیکرو سیکنڈز میں مکمل ہو جاتا ہے۔ Network latency میں کوئی تبدیلی نہیں آتی؛ دوبارہ کوشش (retry) کے لیے اضافی round-trip صرف نایاب ناکامی کی صورت میں ہوتی ہے۔ عملی طور پر، ایک بھی exception کو روکنے کی قیمت درخواست کے وقت میں معمولی اضافے کے مقابلے میں کہیں زیادہ ہے۔

جوابی دلیل: کیا schema enforcement ضرورت سے زیادہ ہے؟

کچھ ڈویلپرز کا استدلال ہے کہ سخت schemas ماڈل کی لچک (flexibility) کو محدود کرتے ہیں، خاص طور پر جب نئے fields قیمتی سیاق و سباق (context) فراہم کر سکتے ہوں۔ اصل توازن حفاظت اور وسعت کے درمیان ہے۔ مشن کے لیے اہم خدمات (mission-critical services)—جیسے ادائیگیوں کی پروسیسنگ، شناخت کی تصدیق، اور تعمیل کی رپورٹنگ (compliance reporting)—میں پیش گوئی کے قابل ہونا (predictability) جیت جاتا ہے۔ ابتدائی تجرباتی ماڈلز (exploratory prototypes) میں، ایک نرم طریقہ کار قابل قبول ہو سکتا ہے، لیکن وہاں بھی ایک معمولی حفاظتی تدبیر (مثلاً z.object({}).passthrough()) مفید extensions کو ضائع کیے بغیر بڑی parsing کی غلطیوں کو پکڑ سکتی ہے۔

آگے کیا دیکھنا ہے

  • SDK evolution: Vercel کے AI SDK کے روڈ میپ میں بلٹ ان retry policies اور بہتر error reporting شامل ہے، جو اصلاح کے عمل (repair loop) کو مزید آسان بنا دے گی۔
  • Tooling standardization: جیسے جیسے زیادہ فراہم کنندگان (providers) tool-use conventions کو اپنائیں گے، مختلف فراہم کنندگان کے لیے مشترکہ schema validators سامنے آ سکتے ہیں، جس سے فراہم کنندہ کے مخصوص (provider-specific) adapters کی ضرورت کم ہو جائے گی۔
  • Community patterns: اوپن سورس لائبریریاں اب Zod schemas کو prompt templates کے ساتھ جوڑنا شروع کر رہی ہیں، جس سے "schema-first" ورک فلو ایک قابلِ استعمال اثاثہ بن رہا ہے۔

خلاصہ

Zod schema کو ایک ایسے معاہدے (contract) کے طور پر استعمال کر کے جسے ماڈل توڑ نہیں سکتا، ڈویلپرز کمزور JSON.parse ہیکس سے ایک deterministic pipeline کی طرف منتقل ہو جاتے ہیں جہاں غیر متوقع fields کی وجہ سے صرف ایک کنٹرول شدہ validation failure ہوتا ہے، نہ کہ پروڈکشن کریش۔ Vercel کے Output.object ہیلپر اور Anthropic کے tool-use میکانزم کا ملاپ LLMs کو غیر متوقع ٹیکسٹ جنریٹرز سے بدل کر قابلِ اعتماد ڈیٹا فراہم کنندگان میں تبدیل کر دیتا ہے، جس سے ٹیمیں لامتناہی edge-case debugging کے بجائے بزنس لاجک پر توجہ مرکوز کر سکتی ہیں۔