ڈویلپرز اب بڑے لینگویج ماڈلز (LLMs) سے حاصل ہونے والے غلط JSON (malformed JSON) کو درست کرنے کے اخراجات کو کنٹرول میں رکھ سکتے ہیں، ایک سادہ پائتھن (Python) لوپ کے ذریعے یہ ممکن ہے کہ اصلاح کی کوششوں کو دو تک محدود رکھا جائے۔ یہ پیٹرن—تولید کرنا، پارس کرنا، تصدیق کرنا، دوبارہ کوشش کرنا، اور پھر قبول کرنا یا ناکام ہونا—"شاید درست JSON" کو ایک قابل پیمائش کامیابی کی شرح میں بدل دیتا ہے اور ٹوکنز کے بے جا استعمال کو روکتا ہے۔

اصلاح کا لوپ کیوں ضروری ہے

LLMs کو اکثر "JSON واپس کریں" کی ہدایت دی جاتی ہے، لیکن آؤٹ پٹ میں اکثر سنٹیکس (syntax) کی غلطیاں، غائب شدہ کیز (keys)، یا ایسی ویلیوز ہوتی ہیں جو کاروباری اصولوں (business rules) کی خلاف ورزی کرتی ہیں۔ ایک ڈاؤن اسٹریم سسٹم (downstream system) جو سخت پی لوڈ (payload) کی توقع رکھتا ہے، اگر اسے ایسا آؤٹ پٹ دیا جائے تو وہ کریش ہو جائے گا یا غلط نتائج دے گا۔ ان مسائل کو پکڑنے اور درست کرنے کے لیے منظم طریقے کے بغیر، ٹیمیں یا تو ناکامی کی بلند شرح کو قبول کرتی ہیں یا ماڈل کو بار بار پرامپٹ (prompt) دے کر پیسے ضائع کرتی ہیں جب تک کہ وہ درست نتیجہ نہ دے دے۔

تصدیق کے تین مراحل

ایک قابلِ اعتماد لوپ تصدیق کو ان حصوں میں تقسیم کرتا ہے:

  • Syntax – کیا اس اسٹرنگ (string) کو JSON کے طور پر پارس کیا جا سکتا ہے؟
  • Shape – کیا ٹاپ لیول آبجیکٹ میں بالکل وہی متوقع کیز (keys) موجود ہیں؟
  • Semantic – کیا ویلیوز ڈومین کی پابندیوں (domain constraints) کا احترام کرتی ہیں (مثال کے طور پر، ایک "category" کا پہلے سے طے شدہ سیٹ سے تعلق ہونا چاہیے)؟

پہلے ناکام ہونے والے مرحلے پر ہی رک کر، لوپ ماڈل کو ایک درست ایرر میسج (error message) دے سکتا ہے، جس سے اگلی کوشش میں درست اصلاح کے امکانات میں نمایاں اضافہ ہوتا ہے۔

پائتھن کی ایک سادہ مثال

درج ذیل کوڈ صرف اسٹینڈرڈ لائبریری کا استعمال کرتا ہے۔ یہ ایک چھوٹا سا اسکیما (ایک ڈکشنری جس میں category اور summary کیز ہیں) اور اجازت یافتہ کیٹیگریز کی ایک مقررہ فہرست متعارف کرواتا ہے۔

import json

CATEGORIES = {"bug", "feature", "question"}

def validate(raw: str):
    try:
        value = json.loads(raw)
    except json.JSONDecodeError as exc:
        return None, f"syntax: {exc.msg}"

    if not isinstance(value, dict):
        return None, "shape: root must be an object"
    if set(value) != {"category", "summary"}:
        return None, "shape: expected category and summary"
    if value["category"] not in CATEGORIES:
        return None, "semantic: invalid category"
    if not isinstance(value["summary"], str) or not value["summary"].strip():
        return None, "semantic: summary must be text"

    return value, None

اصلاح کا لوپ خود کوششوں پر ایک سخت حد (ceiling) عائد کرتا ہے:

MAX_ATTEMPTS = 2
raw = model_response   # initial LLM output

for attempt in range(MAX_ATTEMPTS + 1):
    value, error = validate(raw)
    if error is None:
        break
    if attempt == MAX_ATTEMPTS:
        raise RuntimeError(f"failed after {MAX_ATTEMPTS} retries: {error}")

    # Send the error and schema back to the model for a fix
    raw = ask_model_to_repair(raw, error)

اگر JSON پہلی بار میں ہی تصدیق پاس کر لے، تو لوپ فوری طور پر ختم ہو جاتا ہے۔ بصورتِ دیگر یہ دوبارہ کوشش کرتا ہے، اور ماڈل کو ایک مختصر پی لوڈ فراہم کرتا ہے: اصل آؤٹ پٹ، درست ایرر اسٹرنگ، اور متوقع اسکیما۔ دو ناکام کوششوں کے بعد عمل ایک واضح استثنا (exception) کے ساتھ رک جاتا ہے۔

کم لاگت والی اصلاح کے لیے دو اصول

  1. اصلاح کے پرامپٹس کو مختصر رکھیں – صرف خام JSON، ایرر میسج، اور اسکیما شامل کریں۔ طویل چیٹ ہسٹری شامل کرنے سے ٹوکن کا استعمال بڑھ جاتا ہے اور یہ ماڈل کو الجھا سکتا ہے، جس سے درستگی میں بہتری لائے بغیر ہر دوبارہ کوشش کی لاگت بڑھ جاتی ہے۔

  2. تصدیق کو حقیقت کی جانچ (fact-checking) سے الگ رکھیں – پارسر ساختی مسائل (structural problems) کا پتہ لگا سکتا ہے، لیکن یہ اس بات کی تصدیق نہیں کر سکتا کہ "summary" کا بیان سچ ہے۔ حقیقت کی جانچ بعد کے مرحلے کا کام ہے؛ کسی غلط دعوے کو "درست" کرنے کی کوشش صرف جھوٹ کو صاف ستھرا بنا دیتی ہے۔

کامیابی کی پیمائش

ہر کوشش کی غلطی کی قسم (syntax, shape, semantic) اور یہ کہ لوپ کامیاب ہوا یا نہیں، اسے لاگ (log) کرنا ایک ٹھوس پیمانہ فراہم کرتا ہے: LLM کے ان جوابات کا تناسب جو محدود کوششوں کے اندر قابلِ استعمال بن جاتے ہیں۔ ٹیمیں وقت کے ساتھ اس کا جائزہ لے سکتی ہیں، پرامپٹ کے انداز کا موازنہ کر سکتی ہیں، یا مختلف اسکیما تعریفوں کے ساتھ تجربہ کر سکتی ہیں۔

ممکنہ نقصانات

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

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

  • اصلاح کے لیے پرامپٹ انجینئرنگ – ایرر میسج کے فارمیٹ کو بہتر بنانے سے درکار دوبارہ کوششوں کی تعداد کم ہو سکتی ہے۔
  • متبادل پارسرز – کچھ لائبریریاں ایسی پارسنگ فراہم کرتی ہیں جو معمولی مسائل کو خود بخود درست کر سکتی ہیں؛ ان کی لاگت کا ایک محدود لوپ کے ساتھ موازنہ کرنا فائدہ مند ہے۔
  • ماڈل اپ ڈیٹس – نئے LLM ورژن ممکنہ طور پر پہلے سے ہی صاف ستھرا JSON تیار کر سکتے ہیں، جس سے ری ٹرائی کی حد کو مزید کم کیا جا سکتا ہے۔

ایک محدود JSON اصلاح کا لوپ ڈویلپرز کو ایک عملی ٹول فراہم کرتا ہے جس کے ذریعے وہ بڑھتی ہوئی لاگت کے بغیر غیر واضح LLM آؤٹ پٹ کو قابلِ اعتماد ڈیٹا میں بدل سکتے ہیں۔ تصدیق کو ایک اہم مرحلے کے طور پر لینے اور دوبارہ کوششوں کو محدود کرنے سے، ٹیمیں اپنے بجٹ اور ڈاؤن اسٹریم سسٹمز دونوں کو خوش رکھ سکتی ہیں۔