بہت سے AI ایجنٹ ٹیوٹوریلز غلط آؤٹ پٹ کے لیے ایک ہی حل تجویز کرتے ہیں: عکاسی۔ کیا آپ کا ایجنٹ کوڑا JSON پیدا کر رہا ہے؟ اس کا "جائزہ لینے” کے لیے بس ایک اور LLM کال شامل کریں۔ دوسری کال پہلی کال پر تنقید کرتی ہے، پہلی کال دوبارہ کوشش کرتی ہے، اور voila — معیار بہتر ہوتا ہے۔ میرے خیال میں یہ صاف، خوبصورت اور علمی ہے۔
میں نے ایک ایجنٹ (ایک ایسا نظام جو تعیناتی کنفیگریشنز، API پے لوڈز، اور ڈیٹا بیس کے سوالات پیدا کرتا ہے) کو ایک بڑی ویب کمپنی کے لیے پیداواری ماحول میں بھیج دیا۔ اور میں آپ کو تکلیف دہ تجربے سے بتا سکتا ہوں۔ خود شناسی ساختی پیداوار کے لیے کام نہیں کرتی ہے۔ یہ ناقابل اعتبار ہے اور اس سے کوئی فرق نہیں پڑتا۔
یہاں اصل میں کیا ہوتا ہے: ایجنٹ JSON تیار کرتا ہے۔ تقریباً ایک تہائی غلطیاں لاپتہ فیلڈز، غلط اقسام، کاروباری اصول کی خلاف ورزیوں وغیرہ کی وجہ سے ہوتی ہیں۔ میں عکاسی کا مرحلہ شامل کرتا ہوں کیونکہ ٹیوٹوریل ایسا ہی کہتا ہے۔ اب یہ 6 میں سے 1 بار ناکام ہو جاتا ہے۔
باقی ناکامیاں بے نظر. عکاسی کے مرحلے کے دوران، میں نے کہا، "یہ اچھا لگ رہا ہے!” اور ان کی طرف ہلایا۔ آپ نے واضح طور پر ایک خراب نظام بنایا ہے، اور آپ کو اس وقت تک معلوم نہیں ہوگا جب تک کہ ہفتہ کی صبح 2 بجے پروڈکشن بند نہ ہوجائے۔
اس لوپ کو ڈیبگ کرنے میں کئی ہفتے لگے اس سے پہلے کہ مجھے ایسا نمونہ ملے جس نے حقیقت میں کام کیا۔ یہ شرمناک حد تک آسان ہے، قریب قریب کامل درستگی پیش کرتا ہے، اور کسی ہوشیار عکاسی کے اشارے کی ضرورت نہیں ہے۔ میں آپ کو دکھاتا ہوں۔
ہم کیا احاطہ کریں گے:
شرائط
اس مضمون سے زیادہ سے زیادہ فائدہ اٹھانے کے لیے، آپ کو یہ جاننے کی ضرورت ہے:
-
بنیادی ازگر (فنکشنز، لغات، قسم کے اشارے)
-
LLM API اعلی سطح پر کیسے کام کرتا ہے (پرامپٹ بھیجیں، تکمیل پر واپس جائیں)
-
JSON اسکیما کیا ہے (آپ کو ماہر بننے کی ضرورت نہیں ہے، کوڈ خود بولتا ہے)
عکاسی کا مسئلہ
میری رائے: کسی LLM سے دوسرے LLM کے ساختی نتائج پر تنقید کرنے کے لیے کہنا ایسا ہی ہے جیسے کسی ایسے شخص سے پوچھنا جو ریاضی میں اچھا نہیں ہے کسی ایسے شخص کو درجہ دینے کے لیے جو ریاضی میں اچھا نہیں ہے۔ ان میں ایک جیسے یا ملتے جلتے اندھے دھبے ہونے کا امکان ہے۔ وہی وزن جنہوں نے غلطی پیدا کی تھی اب غلطی کا پتہ لگانے کے لئے کہا جاتا ہے۔ مجھے اچانک دوسرے پاس پر صحیح نتائج کیوں ملے؟
عکاسی کے مرحلے کے دوران آپ اپنے ماڈل سے اصل میں کیا کرنے کو کہہ رہے ہیں اس کے بارے میں سوچیں۔ "ارے، اس JSON کو دیکھو جو آپ نے ابھی بنایا ہے۔ timeout_seconds سے چھوٹا ہونا چاہیے۔ interval_seconds? کیا ریپلیکس اور سی پی یو کی حدود سسٹم پرامپٹ میں درج کاروباری اصولوں سے میل کھاتی ہیں؟”
ماڈل اسے دوبارہ پڑھتا ہے، پیٹرن کو "جو صحیح لگتا ہے” سے ملتا ہے، اور پھر کہتا ہے، "ہاں، سب اچھا ہے۔” تخلیق کے دوران یہ رکاوٹیں چھوٹ گئیں۔ ہم اپنے جائزے کے دوران بھی اس کی کمی محسوس کریں گے، کیونکہ یہ وہی ماڈل ہے جو اسی قسم کا اندازہ لگا رہا ہے۔
ناکامی کا موڈ جو مجھے پریشان کرتا رہا وہ غلط آؤٹ پٹ نہیں تھا۔ منظور شدہ غلط آؤٹ پٹ۔ غلط مثبت۔ عکاسی کے مرحلے میں، ہم کہتے ہیں، "یہ کنفیگریشن درست ہے،” یہاں تک کہ جب ایسا بالکل بھی نہ ہو۔
ایک ایسا نظام جو کہتا ہے کہ "آپ ناکام ہوگئے، دوبارہ کوشش کریں” پریشان کن لیکن محفوظ ہے۔ ایک ایسا نظام جو کہتا ہے "یہ ہے” جب یہ ٹوٹ جاتا ہے؟ یہ ایک کنفیگریشن ہے جو پائپ لائن سے گزرے گی اور آپ کو سروس سے باہر لے جائے گی۔ یہ 2 بجے کا صفحہ ہے۔
عکاسی کھلے کاموں کے لیے خوبصورتی سے کام کرتی ہے، جیسے ای میل کے لہجے کو بہتر بنانا، کسی مضمون میں منطقی خلا کی نشاندہی کرنا، یا بلاگ پوسٹ کے لیے بہتر ڈھانچہ تجویز کرنا۔ لیکن سخت رکاوٹوں کے ساتھ ساختی پیداوار کا کیا ہوگا؟ آپ کو ایسی چیز کی ضرورت ہے جس کا آپ اندازہ نہیں لگا سکتے۔ کسی حتمی چیز کی ضرورت ہے۔
حل: ڈیٹرمینسٹک تصدیق
ترمیم پیٹرن بہت آسان ہے.
تخلیق → حقیقی تصدیق کنندہ کے ساتھ توثیق → درست غلطی کی رائے → دوبارہ کوشش کریں۔
بس۔ "تنقید” کے لیے کوئی دوسرا LLM کال نہیں ہے۔ درستگی کے لیے فکری استدلال کی کوئی ٹرین نہیں ہے۔ ایک فنکشن جو صرف واپس آتا ہے۔ true یا false ایک مخصوص ایرر سٹرنگ شامل کریں – یہ اسی قسم کا توثیق کنندہ ہے جسے آپ فارم جمع کرانے یا API کی درخواست کے لیے لکھیں گے۔
کلیدی بصیرت میں شامل ہیں: سچ پوچھیں تو پورا مضمون ایک جملہ ہے۔ LLM غلطیوں کو درست کرنے میں بہت اچھا ہے اگر آپ انہیں بتا دیں کہ کیا غلط ہے۔ وہ اپنی غلطیوں کو تلاش کرنے میں خوفناک ہیں۔
ماڈل میں آؤٹ پٹ میں درج ذیل مخصوص خرابیاں تھیں۔ timeout_seconds must be < interval_seconds، replicas > 5 requires cpu_limit >= 1.0"، تقریباً ہر بار جب میں اپنی اگلی کوشش پر دونوں کو ٹھیک کرتا ہوں۔
ٹھیک کرنا آسان ہے۔ کہ تلاش کریں یہ مشکل حصہ ہے۔ اور اس ٹکنالوجی کے ساتھ، آپ مائیکرو سیکنڈز میں ہر بار ایک مکمل طور پر مقررہ فنکشن کو آؤٹ سورس کرتے ہیں۔ کوئی فریب نظر نہیں ہے اور کوئی "پراعتماد لیکن غلط" رد عمل نہیں ہیں۔ صحیح وجوہات کے ساتھ پاس یا ناکام۔
توثیق کرنے والے واقعی کیا پکڑتے ہیں (اور ایل ایل ایم کیوں نہیں کر سکتے ہیں)
ڈیٹرمنسٹک توثیق کرنے والے تین سطحوں پر غلطیوں کی جانچ کرتے ہیں، ہر ایک اس بات کا فائدہ اٹھاتا ہے کہ LLM کے بارے میں بنیادی طور پر کیا برا ہے۔
1. ساختی خرابی۔
کیا آؤٹ پٹ درست JSON ہے؟ کیا تمام مطلوبہ فیلڈز موجود ہیں؟ کیا یہ صحیح قسم ہے (سٹرنگ، انٹیجر، سرنی)؟ JSON اسکیما اسے مائیکرو سیکنڈز میں ہینڈل کرتی ہے۔
ایک LLM اسی آؤٹ پٹ کی "تحقیق" کر سکتا ہے ڈھانچے کو دیکھ سکتا ہے اور کہے کہ "یہ درست JSON کی طرح لگتا ہے" حقیقت میں اس کی تجزیہ کیے بغیر۔ توثیق کرنے والا تعبیر کرنا کہ کوئی "ایک جیسا نظر" نہیں ہے۔ یہ گزر سکتا ہے، یہ نہیں ہوسکتا ہے.
2. پابندی کی خلاف ورزی
ہے replicas 1 سے 20 کی قابل قبول حد کے اندر؟ کرو service_name ریگولر ایکسپریشن کو میچ کریں۔ ^[a-z][a-z0-9-]*$? ہے memory_limit_mb کم از کم 128؟
یہ ایک باؤنڈری چیک ہے۔ LLM درست عددی موازنہ اور ریگولر ایکسپریشن میچنگ کے لحاظ سے بہت برا ہے۔ یہ تخمینی ہے اور توثیق کار اس کا درست اندازہ کریں گے۔
3. کراس ڈسپلنری کاروباری قواعد
یہ وہ جگہ ہے جہاں عکاسی سب سے زیادہ ناکام ہوتی ہے۔ "اگر نقلیں 5 سے زیادہ ہیں تو cpu_limit >= 1.0 ہونی چاہیے۔" یا "ٹائم آؤٹ_سیکنڈز وقفہ_سیکنڈز سے سختی سے کم ہونے چاہئیں" جیسے اصولوں کا تقاضا ہے کہ آپ دونوں اقدار کو ذہن میں رکھیں اور ایک مخصوص منطقی تعلق کا اطلاق کریں۔
یہ اصول ٹریننگ ڈیٹا میں ان نمونوں کے طور پر موجود نہیں ہیں جن سے ماڈل پیٹرن میچ کر سکتا ہے۔ وہ آپ کا قواعد، مخصوص آپ کا نظام LLM کے پاس پرامپٹ میں موجود چیزوں سے آگے کچھ بھی "جاننے" کی کوئی وجہ نہیں ہے، اور پرامپٹ طویل تناظر میں کھو گیا ہے۔
یہاں یہ ہے کہ توثیق کنندہ تینوں پر کیوں جیتتا ہے: یہ بغیر کسی دلیل کے چلتا ہے۔ تشریح، توجہ کی کھڑکیوں، یا رکاوٹوں کو چھوڑنے کا کوئی موقع نہیں ہے۔ کیونکہ سیاق و سباق کا ابتدائی مواد زیادہ نمایاں تھا۔ تمام اصولوں کو ترتیب سے، ہر بار ترتیب سے نافذ کیا جاتا ہے۔
اس کے برعکس، LLM کا مشن یہ ہے: بنائیں: ایسی چیز بنانا جو کسی نمونے کے مطابق بالکل فٹ ہو جائے۔ یہ بنیادی طور پر مختلف مہارت ہے۔ چیک کر رہا ہے۔ تفصیلات میں تمام رکاوٹوں کو پورا کیا گیا ہے۔ آپ کسی ناول نگار سے اپنے ٹیکس ریٹرن کو پروف ریڈ کرنے کے لیے نہیں کہیں گے۔ جنریٹر سے اس کے اپنے آؤٹ پٹ کی تصدیق کرنے کو نہ کہیں۔
ڈوری
لینگ گراف کا مکمل نمونہ درج ذیل ہے: ایک گراف جس میں توثیق کار، نوڈس، اور مشروط روٹنگ ہے۔ ایک مکمل چلانے کے قابل مثال (اسکیما، توثیق کار، لوپس، اور ٹیسٹ) GitHub پر ہے: github.com/manishramavat/langgraph-deterministic-validation۔
سب سے پہلے، اسکیما اور توثیق کرنے والے - یہ معلومات کے حقیقی ذرائع ہیں۔
from jsonschema import validate, ValidationError
DEPLOYMENT_CONFIG_SCHEMA = {
"type": "object",
"required": ["service_name", "replicas", "resources", "health_check"],
"properties": {
"service_name": {"type": "string", "pattern": "^[a-z][a-z0-9-]*$"},
"replicas": {"type": "integer", "minimum": 1, "maximum": 20},
"resources": {
"type": "object",
"required": ["cpu_limit", "memory_limit_mb"],
"properties": {
"cpu_limit": {"type": "number", "minimum": 0.1, "maximum": 8.0},
"memory_limit_mb": {"type": "integer", "minimum": 128, "maximum": 16384},
},
},
"health_check": {
"type": "object",
"required": ["path", "timeout_seconds", "interval_seconds"],
"properties": {
"path": {"type": "string", "pattern": "^/"},
"timeout_seconds": {"type": "integer", "minimum": 1},
"interval_seconds": {"type": "integer", "minimum": 5},
},
},
},
}
# The validator: your REAL source of truth. This is the hard part.
def validate_config(config: dict) -> tuple[bool, list[str]]:
"""Schema validation + business rules. This IS your spec."""
errors = []
try:
validate(instance=config, schema=DEPLOYMENT_CONFIG_SCHEMA)
except ValidationError as e:
errors.append(f"Schema: {e.message} (at {list(e.path)})")
return False, errors # bail early — no point checking rules on broken structure
# Cross-field rules that JSON Schema can't express
if config["replicas"] > 5 and config["resources"]["cpu_limit"] < 1.0:
errors.append(f"replicas={config['replicas']} requires cpu_limit >= 1.0")
if config["health_check"]["timeout_seconds"] >= config["health_check"]["interval_seconds"]:
errors.append("timeout_seconds must be < interval_seconds")
return len(errors) == 0, errors
اب لینگ گراف لوپ جو تخلیق کو اس توثیق کار سے جوڑتا ہے اس طرح لگتا ہے:
import json
from typing import TypedDict
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI
from langchain_core.messages import SystemMessage, HumanMessage
SYSTEM_PROMPT = ("You generate deployment configs as valid JSON. "
"Required fields: service_name, replicas, resources, health_check. "
"Follow ALL constraints exactly. Return ONLY the JSON object.")
class State(TypedDict):
request: str
config: dict | None
errors: list[str]
attempts: int
llm = ChatOpenAI(model="gpt-4o", temperature=0.2)
def generate_node(state: State) -> dict:
"""Generate config, injecting exact errors on retries."""
content = f"Generate config for: {state['request']}"
if state["errors"]: # the magic — exact errors fed back, not vague critique
content += "\n\nYour previous attempt had these errors:\n"
content += "\n".join(f"- {e}" for e in state["errors"])
content += "\nFix ALL of them."
resp = llm.invoke([SystemMessage(content=SYSTEM_PROMPT), HumanMessage(content=content)])
try:
config = json.loads(resp.content.strip()) if resp.content else {}
except json.JSONDecodeError:
config = None # validator will catch this
return {"config": config, "attempts": state["attempts"] + 1}
def validate_node(state: State) -> dict:
"""Run deterministic validation. No LLM involved."""
if not state["config"]:
return {"errors": ["Output was not valid JSON"]}
_, errors = validate_config(state["config"])
return {"errors": errors}
def route(state: State) -> str:
"""Done if valid OR exhausted retries."""
if not state["errors"]:
return "done"
return "retry" if state["attempts"] < 3 else "done"
graph = StateGraph(State)
graph.add_node("generate", generate_node)
graph.add_node("validate", validate_node)
graph.set_entry_point("generate")
graph.add_edge("generate", "validate")
graph.add_conditional_edges("validate", route, {"retry": "generate", "done": END})
app = graph.compile()
گراف کو ایک لوپ کے طور پر مرتب کیا گیا ہے جس میں ڈیٹرمنسٹک ایگزٹ کنڈیشن ہے۔ اس کا مطلب ہے کہ آؤٹ پٹ توثیق کو پاس کرے گا یا اسے بڑھانے میں 3 کوششیں لگیں گی۔ آرکیسٹریشن فریم ورک کا کوئی جادو نہیں ہے۔ تصدیق کرنے والوں کے پاس مشکل کام ہے۔
یہ اتنا اچھا کام کیوں کرتا ہے؟
آپ دو بنیادی طور پر مختلف کاموں کو الگ کر رہے ہیں۔ غلطی کا پتہ لگانا اور غلطی کی اصلاح. اور آپ ہر کام کو ایک ایسے ٹول کو تفویض کرتے ہیں جو اس میں اصل میں اچھا ہے۔
توثیق کرنے والے پتہ لگانے کے لیے بہترین ہیں۔ ہم کئی دہائیوں سے JSON اسکیما ویلیڈیٹرز، ایس کیو ایل پارسرز، اور ٹائپ چیکرز استعمال کر رہے ہیں۔ مسئلہ حل ہو گیا۔ مائیکرو سیکنڈ میں انجام دیتا ہے۔ وہ پاس ہونے والے نتائج کے بارے میں کبھی فریب نہیں کھاتے اور کبھی بھی ایک دن کی چھٹی نہیں لیتے۔ وہ تربیت کے دوران دیکھے جانے والے مشکل انتہائی کیسوں سے بھی کبھی الجھتے نہیں ہیں۔
دوسرا کام وہ ہے جہاں ایل ایل ایم گیند کو گراتا ہے۔ منظم طریقے سے تمام رکاوٹوں کی جانچ کرنا وہ نہیں ہے جو اگلی ٹوکن پیشن گوئی کو بہتر بناتی ہے۔
ایک ساتھ، وہ تقریبا کامل ہیں. توثیق کرنے والا ہر چیز کو پکڑتا ہے (کیونکہ یہ تعییناتی ہے)۔ LLM ہر وہ چیز ٹھیک کرتا ہے جسے توثیق کرنے والا پکڑتا ہے (کیونکہ رائے واضح ہے)۔ الگ الگ، وہ دونوں اپنے مشترکہ کام میں معمولی ہیں۔ تصدیق کنندہ کنفیگریشن نہیں بنا سکتا۔ LLM قابل اعتماد طور پر اس کی تصدیق نہیں کر سکتا۔ لیکن ایک ٹیم کے طور پر؟ یہ کسی ایک کو اکیلے استعمال کرنے سے بہتر ہے، اور آپ کو اس قسم کی غلطیوں پر غور کرنے سے کہیں زیادہ بہتر نتائج حاصل ہوں گے۔
جب تین کوششیں کافی نہیں ہیں۔
اگر ماڈل تین کوششوں کے اندر مسئلہ حل نہیں کرتا ہے، تو چوتھی کوشش بہت کم مددگار ہوگی۔ بقایا غلطیاں عام طور پر تصریح میں ابہام ہوتی ہیں بجائے اس کے کہ قابل اصلاح جنریشن مسائل۔ لہذا، پہلے سے فیصلہ کریں کہ آپ کے سسٹم میں "ہار کرنے" کا کیا مطلب ہے۔
-
ناکامی کا ریکارڈ درخواستوں اور حتمی غلطیوں کی فہرست - یہ اس بات کی بہترین نشانی ہے جہاں وضاحت خود مبہم ہے۔
-
واضح غلطی کے ساتھ مسترد کر دیا گیا۔ (مثال کے طور پر توثیق کے پیغام کے ساتھ 422) آپ خراب کنفیگریشن کو نیچے کی طرف منتقل نہیں کر رہے ہیں۔
-
ذمہ دار شخص تک پہنچائیں۔ زیادہ خطرے والے راستوں کے لیے۔
آپ جو بھی کریں، اپنے ٹوکنز کو یہ توقع نہ رکھیں کہ 7 جادو کی طرح کام کرنے کی کوشش کریں۔
اسے کب استعمال کرنا ہے (اور کب نہیں)
ایک سادہ ٹیسٹ ہوگا: کیا میں کوئی ایسا فنکشن لکھ سکتا ہوں جو کچھ واپس کرے؟ true یا false ایجنٹ کی پیداوار کے لیے؟
اگر ایسا ہے تو، اس فنکشن کو Create → Validate → Retry loop سے جوڑیں۔ تصدیق کنندہ پہلے سے موجود ہے، لیکن ہم نے اسے ایجنٹ کے تاثرات کے راستے میں ابھی تک نہیں ڈالا ہے۔
-
JSON آؤٹ پٹ؟ میرے پاس پہلے سے ہی ایک اسکیما ہے۔ چلائیں
jsonschema.validate(). -
ایس کیو ایل آؤٹ پٹ؟ چلائیں
EXPLAIN- ڈیٹا بیس آپ کو بتاتا ہے کہ آیا اسے پارس کرنا ہے یا نہیں۔ -
کوڈ آؤٹ پٹ؟ اسے مرتب کریں۔ ٹیسٹ چلائیں۔ وہ ہے آپ کا توثیق کرنے والا۔
-
Terraform؟
terraform validateیہ اسی وجہ سے موجود ہے۔
بصورت دیگر - اگر "صحیح" ساپیکش ہے (ای میل کا لہجہ، خلاصہ کا معیار، کاپی کی قائلیت)، یہ عکاسی یا انسانی جائزہ پر واپس آ گیا ہے۔ یہ ٹھیک ہے عکاسی موضوعی معیار کے لیے کام کرتی ہے۔ جب صحیح اور غلط جوابات ہوں تو عکاسی اچھی طرح سے کام نہیں کرتی ہے۔
ٹیک آؤٹ
پہلے توثیق کنندہ بنائیں اور دوسرے ایجنٹ کو۔ آپ کا توثیق کرنے والا آپ کی تفصیلات ہے۔ یہ "درست" کی وضاحت اس لحاظ سے کرتا ہے کہ ایک مشین تصدیق کر سکتی ہے۔ ایک بار جب آپ کے پاس یہ ہو جائے تو، ایجنٹ ایک سادہ لوپ بن جاتا ہے جس میں ایک خارجی خارجی حالت ہوتی ہے اور وہ حقیقی اعتماد کے ساتھ قابل اعتماد ہونے کے بارے میں استدلال کر سکتا ہے، بجائے اس کے کہ اس امید کے کہ اشارے کافی ہوشیار ہیں۔
فیصلہ کن نتائج کی تصدیق کرنے کے لیے اپنے LLM سے مت پوچھیں۔ انہیں ایسا آئینہ دیں جو حقیقت کی عکاسی کرے۔
تمام آراء میری اپنی ہیں اور میرے آجر کی نمائندگی نہیں کرتی ہیں۔