خودکار ورک فلو میں LLM ای میلز کو الگ کرنا

جب ایک LLM ایجنٹ ای میلز بھیجنا یا ٹکٹس کی منظوری دینا شروع کرتا ہے، تو مسئلہ بدل جاتا ہے۔ اب یہ صرف اس بارے میں نہیں رہا کہ آپ کا پرامپٹ (prompt) کام کرتا ہے یا نہیں۔ اب، آپ کا سسٹم تین تہوں پر انحصار کرتا ہے: فیصلہ (decision)، عمل درآمد (execution)، اور تصدیق (verification)۔

اگر آپ ان تہوں کو ملا دیتے ہیں، تو آپ کی ٹیم کو یہ سمجھنے میں مشکل ہوگی کہ ایجنٹ نے اصل میں کیا کیا۔

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

ایک مستحکم ڈیزائن ذہانت کو ایک ساتھ آزمانے کی کوشش نہیں کرتا۔ اس کے بجائے، اپنے سسٹم کو چھوٹے معاہدوں (contracts) میں تقسیم کریں:

• ان پٹ کانٹریکٹ (Input Contract): یہ طے کریں کہ ایجنٹ کون سا ڈیٹا استعمال کرتا ہے اور وہ کن اعمال (actions) کی درخواست کر سکتا ہے۔
• ایگزیکیوشن کانٹریکٹ (Execution Contract): یہ طے کریں کہ ایک عمل کس طرح ایک مخصوص ای میل بنتا ہے۔
• آبزرویبلٹی کانٹریکٹ (Observability Contract): لاگز (logs)، موصول ہونے والے پیغامات، اور سسٹم کی حتمی حالت کو آپس میں جوڑیں۔

ای میل کے لاجک کو آزاد پرامپٹ (free prompt) سے باہر رکھیں۔ LLM "send_followup_email" جیسا عمل تجویز کر سکتا ہے۔ تاہم، ماڈل کو ہیڈرز (headers)، وصول کنندگان (recipients)، یا ری ٹرائی پالیسیوں (retry policies) کا فیصلہ نہیں کرنا چاہیے۔ ان ترجموں کے لیے ڈیٹرمینسٹک کوڈ (deterministic code) استعمال کریں۔

یہ طریقہ کار آپریشنل خطرے کو کم کرتا ہے۔ LLM تجویز کرتا ہے، سسٹم تصدیق کرتا ہے، اور ایگزیکیوٹر (executor) بھیجتا ہے۔

واضح نظر آنے کے لیے (visibility)، ان چار سگنلز پر نظر رکھیں:

• ایجنٹ کا کیا فیصلہ کیا اور کون سا سیاق و سباق (context) استعمال ہوا۔
• ای میل ایگزیکیوٹر کو بھیجا گیا حتمی کمانڈ۔
• ایک الگ ان باکس میں موصول ہونے والا پیغام۔
• کسی لنک پر کلک کرنے یا عمل کی تصدیق کرنے کے بعد ہونے والا حتمی اثر۔

ابتدائی ایونٹ سے لے کر حتمی کلک تک ایک مشترکہ trace_id استعمال کریں۔ یہ آپ کو غلطیوں کو تیزی سے تلاش کرنے میں مدد دیتا ہے۔ آپ کو معلوم ہو جائے گا کہ ناکامی ماڈل، ٹول پالیسی، یا ورکر (worker) میں ہوئی ہے۔

بہتر آٹومیشن کے لیے اس چیک لسٹ پر عمل کریں:

• ہر ایگزیکیوشن کا اپنا trace_id ہوتا ہے۔
• LLM صرف ایک درست اسکیما (schema) کے اندر اعمال کی درخواست کرتا ہے۔
• ای میل ایگزیکیوٹر وصول کنندہ اور ٹیمپلیٹ کی دوبارہ تصدیق کرتا ہے۔
• ہر ٹیسٹ منظر نامہ (scenario) اپنا الگ ان باکس استعمال کرتا ہے۔
• حتمی کلک متوقع اسٹیٹ چینج (state change) کی تصدیق کرتا ہے۔
• لاگز آپ کو اندازہ لگانے کے بجائے کیس پر نظر رکھنے کی اجازت دیتے ہیں۔

ان مراحل کو الگ کرنے سے تھوڑا زیادہ کام بڑھ جاتا ہے۔ لیکن یہ آپ کو کچھ قیمتی دیتا ہے: یہ بتانے کی صلاحیت کہ ای میل کیوں بھیجی گئی یا وہ کیوں ناکام ہوئی۔

Source: https://dev.to/silviutech/como-aislar-emails-de-agentes-llm-en-flujos-automatizados-sin-perder-trazabilidad-26ac

Optional learning community: https://t.me/GyaanSetuAi