When you wire a large language model into a workflow that needs a human to say yes by email, the model is rarely what br

جب آپ ایک لارج لینگویج ماڈل (LLM) کو ایسے ورک فلو (workflow) کے ساتھ منسلک کرتے ہیں جس میں انسان کو ای میل کے ذریعے 'ہاں' کہنا ضروری ہو، تو شاذ و نادر ہی ماڈل میں خرابی آتی ہے۔ خرابی وہاں ہوتی ہے جہاں کوڈ ختم ہوتا ہے اور ان باکس شروع ہوتا ہے۔ ایک خود مختار رن (run) ایک درخواست بھیجتا ہے۔ پھر پہلی درخواست کے مکمل ہونے سے پہلے ہی دوسرا رن شروع ہو جاتا ہے۔ ایک مشترکہ ان باکس مختلف عمل (processes) سے آنے والے تھریڈز کو جمع کر لیتا ہے۔ کوئی شخص ایسے پیغام پر 'اپروو' (approve) کلک کر دیتا ہے جو بارہ گھنٹے دیر سے پہنچا ہو۔ اب آپ کے پاس آؤٹ پٹ ہے۔ آپ کے پاس فیصلہ ہے۔ لیکن آپ یہ ثابت نہیں کر سکتے کہ کس رن نے کیا پیدا کیا، یا آیا کہ وہ منظوری واقعی اسی جنریشن کے لیے تھی یا نہیں۔ میں نے اتنے اندرونی آٹومیشن پائپ لائنز کو درست کیا ہے کہ میں اس پیٹرن کو پہچانتا ہوں۔ یہ الجھن سے ایک بڑے واقعے (incident) میں اتنی تیزی سے بدل جاتا ہے جتنا کہ زیادہ تر ٹیمیں توقع نہیں کرتیں۔

آپریشنل حد (The Operational Boundary)

آپ کے آرکیسٹریٹر (orchestrator) اور آپ کے ای میل فراہم کنندہ کے درمیان حد محض ایک نیٹ ورک ہاپ (network hop) نہیں ہے۔ یہ ایک اسٹیٹ باؤنڈری (state boundary) ہے۔ جب LLM ڈرافٹ تیار کرنا مکمل کر لیتا ہے، تو رن ابھی بھی زندہ ہوتا ہے۔ وہ انتظار کر رہا ہوتا ہے۔ اگر آپ کا سسٹم ای میل بھیجنے کو ایک 'بھیج کر بھول جانے والے' (fire-and-forget) ایونٹ کے طور پر لیتا ہے، تو آپ پہلے ہی تسلسل کھو چکے ہوتے ہیں۔

میں نے ایسی پائپ لائنز دیکھی ہیں جہاں ایک ہی رن دو الگ الگ منظوری کی درخواستیں پیدا کر دیتا ہے کیونکہ ری ٹرائی پالیسی (retry policy) بہت زیادہ جارحانہ تھی۔ میں نے ایک اور رن دیکھا ہے جس نے ایک ایسا میل باکس استعمال کیا جو ابھی بھی گزشتہ ہفتے کے پیغامات کو سنبھالے ہوئے تھا۔ انسانی منظور کنندہ کو رن آئی ڈیز (run IDs) نظر نہیں آتے۔ انہیں صرف ایک سبجیکٹ لائن اور ایک بٹن نظر آتا ہے۔ ڈھانچے (structure) کے بغیر، وہ اسی ان باکس میں اندازے لگا رہے ہوتے ہیں جہاں مارکیٹنگ نیوز لیٹرز اور مانیٹرنگ الرٹس موجود ہوتے ہیں۔

نظر انداز کیا گیا مرحلہ (The Neglected Step)

ٹیمیں پرامپٹس (prompts) کو ٹیون کرنے، گارڈ ریلز (guardrails) شامل کرنے اور آؤٹ پٹس کی بینچ مارکنگ کرنے میں ہفتوں صرف کریں گی۔ پھر وہ منظوری کے مرحلے کو ایک Slack چینل یا مشترکہ سپورٹ ان باکس سے منسلک کر دیتے ہیں اور سمجھتے ہیں کہ کام مکمل ہو گیا۔ یہ تین قابلِ پیش گوئی نقصانات پیدا کرتا ہے:

• ایک مشترکہ ان باکس متعدد رنز سے آنے والے ایونٹس کے لیے کچرا کنڈی بن جاتا ہے۔ سیاق و سباق (context) ختم ہو جاتا ہے۔ آپ تھریڈز کو کھولے بغیر اور دستی طور پر ٹائم اسٹیمپ کا تجزیہ کیے بغیر یہ دوبارہ تعمیر نہیں کر سکتے کہ کون سا پیغام کس کاروباری لین دین (business transaction) سے متعلق تھا۔
• ری ٹرائیز (Retries) ثبوتوں کو مٹا دیتے ہیں۔ اگر کوئی رن اپنی منظوری کی درخواست دوبارہ بھیجتا ہے، تو اصل پیغام دفن ہو سکتا ہے، حذف ہو سکتا ہے، یا کسی ضرورت سے زیادہ فعال ای میل کلائنٹ کی طرف سے ڈپلیکیٹ کے طور پر نشان زد کیا جا سکتا ہے۔ اس طرح آڈٹ ٹریل (audit trail) کمزور پڑ جاتا ہے۔
• انسانی فیصلے سسٹم سے باہر رہ جاتے ہیں۔ کوئی شخص ٹکٹ یا براہ راست پیغام میں "لگتا ہے ٹھیک ہے" (looks good) کا جواب دیتا ہے۔ وہ تاثر ورک فلو کے اندر کبھی بھی اسٹرکچرڈ ڈیٹا (structured data) نہیں بن پاتا۔ ایجنٹ کے پاس یہ تصدیق کرنے کا کوئی طریقہ نہیں ہوتا کہ کس نے کیا کہا، یا کب کہا۔

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

ڈیلیوری کی تفصیل سے چیک پوائنٹ تک (From Delivery Detail to Checkpoint)

اسے ٹھیک کرنے کے لیے ڈیزائن میں تبدیلی کی ضرورت ہے۔ ای میل کو محض ڈیلیوری کی تفصیل سمجھنا بند کریں۔ اسے ایک سسٹم چیک پوائنٹ (system checkpoint) کے طور پر دیکھنا شروع کریں۔ اس کا مطلب ہے کہ ہر پیغام ایک اسٹیٹ ٹرانزیشن (state transition) ہے، اور ہر اسٹیٹ ٹرانزیشن کو شناخت، اتھارائزیشن اور ثبوت کی ضرورت ہوتی ہے۔

جب آپ یہ ذہنیت اپناتے ہیں، تو سوالات بدل جاتے ہیں۔ آپ یہ پوچھنا بند کر دیتے ہیں کہ آیا ای میل کامیابی سے بھیجی گئی یا نہیں۔ آپ یہ پوچھنا شروع کرتے ہیں کہ اسے کس رن نے بھیجا، اس نے کیا ثبوت چھوڑا، اور کس اصول نے ورک فلو کو جاری رکھنے کی اجازت دی۔ ایجنٹ بالکل ای میل کا متن لکھ سکتا ہے۔ لیکن آپ کے پلیٹ فارم کو شناخت اور تصدیق کے راستوں کو نافذ کرنا چاہیے۔ LLM لکھنے والا ہے۔ انفراسٹرکچر نوٹری (notary) ہے۔

ایک کم از کم ڈیزائن (A Minimum Design)

اسے بنانے کے لیے آپ کو کسی بڑی رقم کی ضرورت نہیں ہے۔ میرا کم از کم قابل عمل ورژن (minimum viable version) پانچ باقاعدہ اجزاء پر مشتمل ہے۔

• آرکیسٹریٹر ورک فلو شروع ہوتے ہی بالکل اسی لمحے ایک run_id جاری کرتا ہے۔ یہ شناختی کوڈ ہر اگلے عمل کی ریڑھ کی ہڈی ہے۔ یہ کبھی نہیں بدلتا، اور اسے کبھی دوبارہ استعمال نہیں کیا جاتا۔
• ہر ای میل ایکشن میں تین فیلڈز ہوتی ہیں: run_id، ایک message_type لیبل جیسے کہ "approval_request" یا "evidence_notification"، اور ایک policy_version اسٹرنگ جو یہ بتاتی ہے کہ کون سے گورننس رولز فعال ہیں۔ یہ ایک سادہ پیغام کو ایک ٹائپڈ ایونٹ (typed event) میں بدل دیتا ہے۔
• ثبوت ایک ایسے ان باکس میں رہتے ہیں جو رن کے ذریعے الگ کیا گیا ہو۔ اس کا مطلب ہمیشہ ہر رن کے لیے ایک الگ ای میل اکاؤنٹ نہیں ہوتا۔ اس کا مطلب ایک مخصوص لیبل، ایک سب فولڈر، یا ایک روٹنگ رول ہو سکتا ہے جو تھریڈز کو اس طرح تقسیم کرتا ہے کہ ایک رن کا مراسلہ دوسرے کے ساتھ نہ الجھ سکے۔
• منظوری کا جواب ایک اسٹرکچرڈ ایونٹ ہونا چاہیے، نہ کہ محض ایک آزاد تحریر "ok"۔ انسان اب بھی کلک کرتا ہے یا جواب دیتا ہے، لیکن سسٹم اس عمل کو ایک مشین کے قابل پڑھنے والے پی لوڈ (machine-readable payload) میں تبدیل کر دیتا ہے جو run_id، فیصلے، اور ٹائم اسٹیمپ کا نام لیتا ہے۔
• بہاؤ (flow) صرف اسی صورت میں جاری رہتا ہے اگر ثبوت اور فیصلہ مطابقت رکھتے ہوں۔ ورک فلو تنہا منظوری پر بھروسہ نہیں کرتا۔ یہ LLM کے آؤٹ پٹ کو پروڈکشن تک پہنچنے سے پہلے اصل درخواست کے خلاف منظوری کے پی لوڈ کی تصدیق کرتا ہے۔

ایک مفید چیک پوائنٹ کیا تصدیق کرتا ہے

ایک مفید چیک پوائنٹ انسانی فیصلے کو قبول کرنے سے پہلے چار شرائط نافذ کرتا ہے۔

• وصول کنندہ کا 'run context' سے تعلق ہونا ضروری ہے۔ اگر منظور کرنے والا اس مخصوص ورک فلو انسٹنس کے لیے نامزد جائزہ لینے والا نہیں ہے، تو سسٹم سگنل مسترد کر دیتا ہے۔
• موضوع یا روٹنگ میٹا ڈیٹا کا موجودہ فلو کی حالت سے مطابقت رکھنا ضروری ہے۔ مرحلہ تین کی منظوری مرحلہ دو کو بائی پاس نہیں کر سکتی۔
• ٹائم اسٹیمپ متوقع وقت کے اندر ہونا چاہیے۔ ٹائم آؤٹ کے بعد آنے والا فیصلہ ایک نئے جائزے کا باعث بننا چاہیے، نہ کہ خودکار منظوری کا۔
• ثبوت کسی دوسرے 'run' کے ذریعے دوبارہ استعمال شدہ نہیں ہونا چاہیے۔ اگر وہی میسج آئی ڈی یا ٹوکن دو الگ الگ منظوری کی درخواستوں میں نظر آئے، تو یہ ایک 'collision' ہے، اور سسٹم کو رک جانا چاہیے۔

اصل قیمت

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

آپ وضاحت کے لیے رفتار کا سودا کر رہے ہیں۔