12 بڑے لینگویج ماڈلز (LLM) APIs کے ایک نئے بینچ مارک سے معلوم ہوا ہے کہ تقریباً ہر سروس ایسا JSON فراہم کرتی ہے جو مطلوبہ schema سے مطابقت رکھتا ہے، لیکن ایک بڑی تعداد حقیقت کے خلاف غلط ویلیوز (values) فراہم کرتی ہے۔ اسی schema کی ٹوکن لاگت چند درجن ٹوکنز سے لے کر تقریباً پانچ ہزار تک گھومتی ہے۔ ڈیٹا نکالنے کے پائپ لائنز (extraction pipelines) یا ڈیٹا پر مبنی ایجنٹس بنانے والے ڈویلپرز اب "schema-valid" کو "درست" ہونے کی علامت کے طور پر استعمال نہیں کر سکتے۔

یہ ٹیسٹ کیوں اہم ہے

API فراہم کرنے والے "structured output" کو پارسنگ کی غلطیوں کو ختم کرنے کے طریقے کے طور پر پیش کر رہے ہیں۔ اس کا وعدہ سادہ ہے: ماڈل کو ایک JSON schema دیں، اور وہ آپ کے لیے نازک پوسٹ پروسیسنگ کوڈ لکھے بغیر فیلڈز کو بھر دے گا۔ عملی طور پر، بہت سے پروڈکشن سسٹم کریش ہونے سے بچنے اور ڈاؤن اسٹریم اینالیٹکس پائپ لائنز کو صاف رکھنے کے لیے پہلے ہی اس ضمانت پر بھروسہ کرتے ہیں۔ جب یہ ضمانت صرف آدھی سچ ہوتی ہے، تو خاموشی سے بگ (bugs) پیدا ہو جاتے ہیں، اور ٹوکن کے استعمال پر مبنی لاگت کے حساب کتاب میں بہت زیادہ فرق آ جاتا ہے۔

اچھی خبر: schemas اب زیادہ تر نافذ کیے جاتے ہیں

  • ٹیسٹ سوٹ کے زیادہ تر ماڈلز نے ایسا JSON تیار کیا جو ایک سخت ویلیڈیٹر (validator) سے گزر گیا۔
  • Constrained decoding – وہ ماڈلز جو ڈیکوڈر کو schema تک محدود رکھتے ہیں، وہ اضافی حروف (stray characters) جاری نہیں کر سکتے، اس لیے غلط فارمیٹ والے پے لوڈز (malformed payloads) تقریباً ختم ہو چکے ہیں۔
  • Parse-error rates – ڈویلپرز کو اب JSON سنٹیکس کی ناکامیوں کے لیے ہر کال کو try-catch بلاکس میں لپیٹنے کی ضرورت نہیں ہے۔

بری خبر: validity ≠ accuracy

ایک درست شکل (shape) درست ویلیو (value) کی ضمانت نہیں دیتی۔ بارہ میں سے چار ماڈلز—DeepSeek V4، Qwen، اور GLM-5.2 (آخری دو رپورٹ میں دو مختلف ناموں کے تحت نظر آتے ہیں)—نے مکمل طور پر درست JSON تیار کیا جس میں غلط نمبرز شامل تھے جب "thinking" (یا chain-of-thought) موڈ آن تھا۔

  • Qwen ماڈل پر، reasoning فعال ہونے کے ساتھ 16 میں سے صرف 1 درست جواب تھا، جبکہ reasoning غیر فعال ہونے پر 8 میں سے 8 درست جوابات ملے۔
  • DeepSeek V4 Pro نے بھی اسی طرح کا فرق دکھایا: جب ماڈل نے اپنے مراحل کی وضاحت کرنا بند کر دیا تو extraction کی درستگی 1/8 سے بڑھ کر 7/8 ہو گئی۔

اضافی reasoning کا مرحلہ constrained decoder میں مداخلت کرتا ہے، جس سے ماڈل بیرونی بریکٹس (brackets) کا احترام کرتے ہوئے بھی hallucination (خیالی معلومات) کی طرف مائل ہو جاتا ہے۔

تاریک پہلو: ٹوکن لاگت کے حیران کن نتائج اور نظر انداز کیے گئے پیرامیٹرز

  • Claude کا response format – جب OpenAI کے ہم آہنگ (compatible) اینڈ پوائنٹس کے ذریعے رسائی حاصل کی گئی، تو Claude نے response_format فلیگ کو مکمل طور پر نظر انداز کر دیا، اور 0% schema کے مطابق آؤٹ پٹ فراہم کیا۔ ماڈل structured calls کو سپورٹ کرتا ہے، لیکن صرف Anthropic کے نیٹو tool-call انٹرفیس کے ذریعے ہی۔
  • Schema token inflation – ایک معمولی 12 KB کا schema DeepSeek پر 30 ٹوکنز کے برابر ہے، جبکہ وہی پے لوڈ Claude پر 4,959 ٹوکنز استعمال کر گیا۔
  • Billing inconsistencies – کچھ فراہم کنندگان schema کو پرامپٹ (prompt) کے حصے کے طور پر شمار کرتے ہیں اور اس کے استعمال ہونے والے ہر ٹوکن کے لیے چارج کرتے ہیں؛ جبکہ دوسرے اسے ایک مفت اوورلے (overlay) کے طور پر لیتے ہیں۔ بڑے پیمانے پر، schema کا بل ماڈل کے تیار کردہ مواد کی لاگت سے بھی زیادہ ہو سکتا ہے۔

ڈویلپرز کو اب کیا کرنا چاہیے

  1. صرف شکل (shape) ہی نہیں بلکہ ویلیوز (values) کو بھی ویلیڈیٹ کریں – ایک schema ویلیڈیٹر غلط عددی جواب کو نہیں پکڑ سکے گا اگرچہ وہ مطلوبہ قسم (type) کے مطابق ہو۔ ڈومین سے متعلقہ چیکس (جیسے رینج، یونٹ، کراس فیلڈ کنسسٹنسی) شامل کریں۔
  2. DeepSeek، Qwen، اور GLM پر extraction کے لیے chain-of-thought کو بند کر دیں جب آپ کو قابل بھروسہ فیلڈ بھرنے کی ضرورت ہو۔ اضافی reasoning کا مرحلہ اختیاری ہے، درستگی کے لیے ضروری نہیں ہے۔
  3. ٹوکن کے استعمال کا آڈٹ کریں – اس بات کا ریکارڈ رکھیں کہ ہر درخواست (request) میں کتنے ٹوکنز استعمال ہو رہے ہیں، بشمول schema کا حصہ، اور بڑے پیمانے پر تعیناتی (deployment) سے پہلے مختلف فراہم کنندگان کے بلوں کا موازنہ کریں۔
  4. پورٹیبلٹی (portability) کا ٹیسٹ کریں – ایک schema جو OpenAI پر کام کرتا ہے، ہو سکتا ہے کہ Gemini یا Claude پر خاموشی سے نظر انداز کر دیا جائے۔ کوڈ ریلیز کرنے سے پہلے ہر ٹارگٹ پلیٹ فارم پر ایک فوری sanity check ضرور کریں۔

فراہم کنندگان کا مؤقف

کچھ فراہم کنندگان کا کہنا ہے کہ "thinking" موڈ ڈویلپر کا اپنا انتخاب ہے جو ان کاموں کے لیے ہے جہاں وضاحت (explanation) خام extraction کی درستگی سے زیادہ اہم ہے۔ Claude response_format فلیگ کو نظر انداز کرتا ہے اور اس کے بجائے Anthropic کے نیٹو tool calls استعمال کرنے کا مشورہ دیتا ہے۔ یہ وضاحتیں تکنیکی طور پر درست ہیں، لیکن یہ بوجھ ڈویلپرز پر ڈال دیتی ہیں کہ وہ جانیں کہ کون سا موڈ منتخب کرنا ہے اور چھپے ہوئے ٹوکن فیس کے لیے بجٹ کیسے بنانا ہے۔

خلاصہ

JSON schema اب کوئی حفاظتی جال (safety net) نہیں رہا؛ یہ محض ایک شکل (shape) ہے۔ اس بات کو یقینی بنائیں کہ اندر موجود ڈیٹا حقیقت کے مطابق ہو، چھپی ہوئی ٹوکن لاگت پر نظر رکھیں، اور یاد رکھیں کہ ماڈل کی "thinking" صاف ستھرے نظر آنے والے آؤٹ پٹ کو بھی خراب کر سکتی ہے۔