ہر کوئی پرومپٹ کے پیچھے پاگل ہے۔ وہ سلام کے انداز کو بہتر بناتے ہیں، لہجے کو درست کرتے ہیں، اور اس بات کی فکر کرتے ہیں کہ ماڈل کافی دوستانہ لگ رہا ہے یا نہیں۔ یہ ایک توجہ ہٹانے والی چیز ہے۔ جب ایک اے آئی ایجنٹ حقیقی صارفین کو حقیقی ای میلز بھیجنا شروع کرتا ہے، تو خطرہ یہ نہیں ہے کہ وہ "Best regards" کے بجائے "Cheers" لکھتا ہے۔ خطرہ یہ ہے کہ آپ یقین کے ساتھ یہ نہیں بتا سکتے کہ ایجنٹ کے فیصلے اور ان باکس میں پیغام پہنچنے کے درمیان کیا ہوا تھا۔ میں سب سے پہلے سرحد (boundary) کو دیکھتا ہوں۔ وہیں پروڈکشن سسٹم خاموشی سے ناکام ہو جاتے ہیں۔
کنٹریکٹ ہی کمزور کڑی ہے
اے آئی ڈیمو معاف کرنے والے ہوتے ہیں۔ براؤزر ونڈو میں ایک ہموار گفتگو مفروضوں کے ڈھیر کو چھپا لیتی ہے۔ پروڈکشن میں، اصل کمزوری تین چیزوں کے درمیان کنٹریکٹ (معاہدے) میں ہوتی ہے: ایجنٹ کا فیصلہ، وہ ٹول جو عمل کو نافذ کرتا ہے، اور وہ مرحلہ جو نتیجے کی تصدیق کرتا ہے۔ اگر یہ سرحد دھندلی ہو، تو سسٹم تب تک خوبصورتی سے کام کرتا ہے جب تک کہ وہ کام کرنا چھوڑ نہ دے۔ پھر یہ خاموشی سے ناکام ہو جاتا ہے، پورے کسٹمر سیگمنٹ کو ڈپلیکیٹ ای میلز بھیج دیتا ہے، یا بغیر کسی واضح ریکارڈ کے غلط وقت پر پیغامات بھیج دیتا ہے۔ پرومپٹ شاید شاعری کی طرح لگے، لیکن اس کے نیچے کا آرکیٹیکچر اب بھی دھاگوں سے بندھا ہوا ہو سکتا ہے۔
ایجنٹ کو آزادانہ لکھنے کی اجازت دینا بند کریں
سب سے عام غلطی ایجنٹ کو ایک خالی صفحہ دینا ہے۔ ٹیمیں اسے خام متن (raw text) میں ای میل بیان کرنے دیتی ہیں اور پھر اس امید پر بھروسہ کرتی ہیں کہ نیچے والا ٹول اس نثر سے مقصد (intent) نکال لے گا۔ یہ طریقہ بہت نازک ہے۔ ایک LLM ایک مناسب مقصد تجویز کر سکتا ہے، لیکن آپ کے انفراسٹرکچر کو تخلیقی صلاحیتوں کی ضرورت نہیں ہے۔ اسے ایک کنٹریکٹ کی ضرورت ہے۔ اسے مخصوص فیلڈز کی ضرورت ہے جنہیں مشین بغیر کسی ابہام کے درست ثابت (validate) کر سکے۔
جب ایک ایجنٹ ای میل کی درخواست جاری کرتا ہے، تو آؤٹ پٹ میں بالکل وہی چیز ہونی چاہیے جس کی ضرورت سسٹم کے بنیادی ڈھانچے (plumbing) کو ہے:
- ٹیمپلیٹ ورژن (Template version): ای میل باڈی کا کون سا ورژن استعمال کیا جا رہا ہے، تاکہ آپ کو معلوم ہو کہ صارف نے کیا دیکھا۔
- وصول کنندہ کا دائرہ کار (Recipient scope): یہ کسے ملے گا، جسے یوزر آئی ڈیز (user IDs) یا سیگمنٹ رولز کے ذریعے بیان کیا جائے، نہ کہ "وہ صارف جس نے ابھی سائن اپ کیا ہے" جیسی قدرتی زبان کے ذریعے۔
- ٹریس آئی ڈی (Trace ID): ایک منفرد شناختی نمبر جو ایجنٹ سے لے کر آپ کے ایگزیکیوٹر، ای میل فراہم کنندہ، اور آپ کے لاگز (logs) تک اس درخواست کا پیچھا کرتا ہے۔
- وقت کا وقفہ (Time window): یہ بھیجنے کا عمل کب تک کارآمد ہے، تاکہ ایجنٹ کے پرانے فیصلے گھنٹوں بعد آدھی رات کو ای میلز نہ بھیج دیں۔
- آئیڈیمپوٹینسی (Idempotency): ایک ایسی کلید (key) جو ایک ہی منطقی بھیجنے کے عمل کو دو بار ہونے سے روکتی ہے اگر ایجنٹ دوبارہ کوشش کرے یا نیٹ ورک میں کوئی خرابی آ جائے۔
خام متن (Raw text) ایک انتہائی ناقص API ہے۔ یہ ہنگامی صورتحال، سامعین، اور عمل کے بارے میں ابہام کی گنجائش چھوڑ دیتا ہے۔ مخصوص فیلڈز مشین کے پڑھنے کے قابل، آڈٹ کے قابل، اور ٹیسٹ کے قابل ہوتی ہیں۔ وہ ایک مبہم ہدایت کو ایک تصدیق کے قابل کمانڈ میں بدل دیتی ہیں۔
نثر نہیں، بلکہ اقدامات (Actions)
ایجنٹ کو ایک کھلا لکھنے کا کام دینے کے بجائے، اسے صرف منظور شدہ اقدامات (actions) کے مینو تک محدود رکھیں۔ اسے ایک فکسڈ enum کے ساتھ اندرونی API کی طرح سمجھیں۔ ایجنٹ سبجیکٹ لائن نہیں لکھتا اور نہ ہی سلام کے انداز کے بارے میں سوچتا ہے۔ وہ ایک عمل کا انتخاب کرتا ہے جیسے کہ send_review_request یا send_retry_notice۔ اس کی تخلیقی آزادی بس یہیں تک ہے۔
ایک یقینی (deterministic) ایگزیکیوٹر پھر اس ایکشن کی (action key) کو لیتا ہے، ورژن کنٹرول سے درست ٹیمپلیٹ نکالتا ہے، اسے صاف شدہ ڈیٹا کے ساتھ بھرتا ہے، تصدیق شدہ ذریعے سے وصول کنندہ کی فہرست مکمل کرتا ہے، اور حتم
3. ٹول اجازت ناموں (permissions) اور مطلوبہ فیلڈز کی تصدیق کرتا ہے۔
کیا اس ایجنٹ سیاق و سباق (context) کے پاس اس صارف کے لیے send_review_request کو ٹرگر کرنے کا حق ہے؟ کیا وصول کنندہ کا دائرہ کار (recipient scope) خالی نہیں ہے اور مقررہ حدود کے اندر ہے؟ کیا idempotency key آپ کے لاگ میں موجود اور منفرد ہے؟ کیا trace ID درست طریقے سے بنائی گئی ہے؟ کسی بھی ای میل سروس کو چھونے سے پہلے، یہاں فوری اور واضح طور پر ناکامی (fail) کا اشارہ دیں۔
4. ای میل سروس trace ID کے ساتھ بھیجنے کا اندراج (log) کرتی ہے۔
آپ کے سسٹم سے نکلنے والا ہر پیغام فراہم کنندہ (provider) کی API کے ذریعے اور آپ کے observability stack میں اس trace identifier کو ساتھ لے کر جانا چاہیے۔ اگر کوئی صارف شکایت کرتا ہے کہ اسے دو کاپیاں موصول ہوئی ہیں، تو آپ کو ایک ID کے ذریعے یہ جاننے کے قابل ہونا چاہیے کہ دوہراؤ (duplication) کہاں سے شروع ہوا: ایک دوبارہ کوشش کیا گیا ایجنٹ کال، ایک غیر مستحکم (flaky) executor، یا ایک غلط کام کرنے والا callback۔
5. اینڈ ٹو اینڈ ٹیسٹ مواد اور اثر کے لیے اصل ان باکس کی جانچ کرتا ہے۔
رینڈر شدہ پیغام کو ایک حقیقی میل باکس میں کھولیں۔ کیا سبجیکٹ لائن درست طریقے سے بھری گئی ہے؟ کیا ان سبسکرائب (unsubscribe) لنک کام کر رہا ہے؟ کیا بنیادی کال ٹو ایکشن (call-to-action) بٹن پر کلک کرنے سے صارف صحیح حالت (state) کے ساتھ درست صفحے پر پہنچتا ہے؟ ایک کامیاب یونٹ ٹیسٹ کا مطلب ہے کہ کوڈ چل گیا۔ صرف ان باکس ٹیسٹ ہی آپ کو بتاتا ہے کہ ای میل واقعی کسی انسان کے لیے کام کر رہی ہے۔
اندازوں کے بجائے شواہد
جب اس پائپ لائن میں کوئی ٹیسٹ ناکام ہوتا ہے، تو آپ کو شواہد کے چار مخصوص ٹکڑوں کی ضرورت ہوتی ہے۔ اس سے کم کچھ بھی قبول نہ کریں۔
- ایجنٹ کا اصل فیصلہ۔ اس نے کون سا عمل منتخب کیا، اور مکمل ان پٹ سیاق و سباق (input context) کیا تھا؟
- ٹول کی طرف سے نارملائزڈ کمانڈ۔ ٹیمپلیٹ، ہائیڈریشن لاجک (hydration logic)، اور تصدیقی قواعد (validation rules) لاگو کرنے کے بعد ڈिटरمنسٹک executor نے کیا بنایا؟
- علیحدہ ان باکس میں پیغام۔ یہ اس بات کا لاگ نہیں ہے کہ آپ کے خیال میں آپ نے کیا بھیجا، بلکہ اصل MIME پیغام، ہیڈرز اور سب کچھ، جو ایک مخصوص ٹیسٹ میل باکس میں محفوظ کیا گیا ہو۔
- لنک پر کلک کرنے کے بعد کا حتمی اثر۔ نتیجہ کے طور پر صفحے کی حالت (page state)، ڈیٹا بیس میں تبدیلی، یا کوئی بیرونی واقعہ جو یہ ثابت کرے کہ ای میل نے اپنا مقصد حاصل کر لیا ہے۔
اگر ایک بھی حصہ غائب ہو، تو آپ کی ٹیم اس خلا کو مفروضوں سے بھر دے گی۔ وہ اندازہ لگائیں گے۔ آٹومیشن میں اندازہ لگانا مہنگا پڑتا ہے۔ یہ گھنٹوں ضائع کرتا ہے، اعتماد کو ختم کرتا ہے، اور ہر واقعے کو ایک فارنزک معمہ (forensic mystery) کے بجائے ایک...