Introduction انٹرویو سب سے پہلے، آپ صرف API کے ذریعے ChatGPT کے ساتھ بات چیت کرنے کی کوشش کرتے ہیں، کنٹیکٹ کی چند لائنوں میں ڈالتے ہیں، اور حیران رہتے ہیں کہ یہ بالکل جواب دیتا ہے. پھر آپ چاہتے ہیں کہ یہ کچھ مفید کرے. اس طرح ایک ایجنٹ پیدا ہوتا ہے. اگر آپ نے پچھلے سال بھی سکرپٹ اور لوپروں سے ایجنٹوں کو جمع کرنے، تجربات اور ٹینک کرنے کے لئے خرچ کیا ہے، اور آپ اب بھی ان کی تعمیر کرنے کے لئے ایک صاف، زیادہ مستحکم طریقہ تلاش کر رہے ہیں - یہ مضمون آپ کے لئے ہے. میں نے ریپ اور فورموں کے ذریعے گھوم لیا ہے، اپنے آپ سے بار بار پوچھتے ہیں، "کیا دوسروں کو یہ کر رہے ہیں؟" > میں نے جو پکڑا تھا - جس نے واقعی کچھ حقیقی استعمال کے بعد محسوس کیا، اور آہستہ آہستہ آہستہ ایک ٹھنڈا خیال کو پیداوار کے تیار حل میں تبدیل کرنے کے لئے بنیادی اصولوں کا ایک سیٹ ڈسٹال کیا. یہ ایک منشور نہیں ہے. یہ ایک عملی چیک شیٹ کے طور پر سوچو - انجینئرنگ اصولوں کا ایک مجموعہ جو ایک ایجنٹ کو sandbox سے پیداوار میں رہنمائی کرنے میں مدد ملتی ہے: ایک سادہ API wrapper سے ایک مستحکم، کنٹرول اور پیمانے پر نظام تک. Disclaimer میں (تکامل ایجنٹ کی تعمیر)، Anthropic ایک ایجنٹ کو ایک نظام کے طور پر سمجھا جاتا ہے جہاں LLMs اپنے عمل اور آلے کے استعمال کو قدرتی طور پر ہدایت کرتا ہے، اس کے بارے میں کنٹرول کو برقرار رکھتا ہے کہ وہ کام کیسے انجام دیتے ہیں. یہ مضمون اس مضمون میں، ایجنٹ = ایجنٹ کے نظام، جہاں مستحکم اور کنٹرول کے لئے میں زیادہ سے زیادہ کام کے جریان کی طرف مائل ہوں. میں امید کرتا ہوں کہ قریب مستقبل میں ترقی کے 1-2 مزید دور ہو جائیں گے اور حقیقی ایجنٹ ہر جگہ موجود ہوں گے، لیکن ابھی تک یہ معاملہ نہیں ہے 1. Design the Foundation 1۔ بنیادی ڈیزائن ایجنٹوں کے ابتدائی ورژن عام طور پر تیزی سے آتے ہیں: چند خصوصیات، چند نوٹس - اور ہیلو، یہ کام کرتا ہے. ایجنٹوں کے ابتدائی ورژن عام طور پر تیزی سے آتے ہیں: چند خصوصیات، چند نوٹس - اور ہیلو، یہ کام کرتا ہے. “If it works, why make it complicated?” سب سے پہلے، سب کچھ ایجنٹ جواب دیتا ہے، کوڈ چلاتا ہے، ذہنی طور پر چلتا ہے. لیکن ایک بار جب آپ ماڈل کو تبدیل کرتے ہیں، نظام کو دوبارہ شروع کرتے ہیں، یا ایک نیا انٹرفیس کو لاگ ان کرتے ہیں تو، یہ ناگہاں طور پر غیر مستحکم، غیر متوقع، ڈیبگ کرنے کے لئے مشکل ہو جاتا ہے. لگتا ہے اور اکثر، بنیادی وجہ منطق یا نوٹس میں نہیں ہے، لیکن بہت پہلے: خراب میموری مینجمنٹ، ہارڈ کوڈ کارپوریٹ، سیشنوں کو دوبارہ شروع کرنے کا کوئی طریقہ نہیں، یا ایک ہی سخت داخلہ نقطہ. یہ سیکشن چار اہم اصولوں کے ذریعے چلا جاتا ہے جو آپ کو ایک مضبوط بنیاد بنانے میں مدد ملے گی - جس پر ہر چیز محفوظ طریقے سے بڑھ سکتی ہے. 1. Keep State Outside Problem: آپ عمل کو دوبارہ شروع نہیں کرسکتے ہیں.اگر ایجنٹ کو روک دیا جاتا ہے (ایک حادثہ، ایک ٹائم آؤٹ، کچھ بھی) تو، یہ بالکل وہ جگہ تلاش کرنے کے قابل ہونا چاہئے جہاں یہ روک دیا گیا تھا. reproducerability محدود ہے.You need a way to accurately reproduce what happened – testing, debugging and other such pleasures کے لئے. یہ بالکل ایک مسئلہ نہیں ہے، لیکن اب بھی: Parallelization. پہلے یا بعد آپ ایجنٹ کی منطق کے ساتھ متوازن کرنا چاہتے ہیں. شاید یہ بات چیت کے وسط میں کئی اختیارات کا موازنہ کرنے کی ضرورت ہے (“اس میں سے کون بہتر ہے?”). (مریم ایک مکمل طور پر منفرد مسئلہ ہے - ہم جلد ہی اس پر پہنچیں گے) ملک کو منتقل ایک ایجنٹ - ایک ڈیٹا بیس، ایک کیش، ایک سٹوریج layer - یہاں تک کہ ایک JSON فائل کرے گا. Solution: outside Checklist: ایجنٹ کسی بھی مرحلے سے شروع کیا جا سکتا ہے، صرف ایک session_id - سیشن شناختی - اور بیرونی حالت (مثال کے طور پر، ایک ڈیٹا بیس یا JSON فائل میں محفوظ اقدامات). ٹیسٹ کیس: ایک متضاد ایجنٹ منسلک نہیں ہوتا، دوبارہ شروع کرنے کے بعد نتیجہ ایک ہی ہے ریاست کسی بھی وقت کارکردگی کے نقصان کے بغیر serializable ہے آپ ایک بات چیت کے وسط میں ایک ہی وقت میں کئی انسٹالوں کو ایڈجسٹ کرسکتے ہیں 2. Make Knowledge External LLMs یاد نہیں. یہاں تک کہ ایک واحد سیشن کے اندر، ماڈل آپ نے پہلے سے ہی وضاحت کی ہے کہ کیا بھول سکتا ہے، مرحلے کو منسلک، بات چیت کے ٹرانسمیشن کو کھو سکتے ہیں، یا وہاں نہیں تھے کہ تفصیلات کو "جمع" کرنا شروع کر سکتے ہیں. اور یہ لگتا ہے کہ وقت چلتا ہے، کنکٹیکٹ ونڈوز بڑھ جاتا ہے اور بڑھ جاتا ہے، ہمیں نئے امکانات کے ساتھ خوشی دیتا ہے. LinkedIn پوسٹوں پر ہے جہاں لوگ کس کتاب یا یو ٹیوب کے ویڈیوز کے کتنے گھنٹے اب نئے ماڈل ورژن میں شامل ہیں. Problem خاص طور پر اگر: dialogue is long دستاویزات وسیع ہیں ہدایات پیچیدہ ہیں اور ٹوکن اب بھی ختم نہیں ہیں یہاں تک کہ کنٹیکٹ ونڈوز (8k، 16k، 128k ...) میں اضافہ کے ساتھ، مسائل باقی ہیں: "میٹڈ میں کھو گیا" - ماڈل شروع اور ختم پر زیادہ توجہ مرکوز کرتا ہے (اور وسط سے تفصیلات کو کھو سکتا ہے) قیمت - زیادہ ٹوکن = زیادہ پیسے؛ اور یہ اب بھی ٹھیک نہیں ہے. جس کا مطلب یہ ہے کہ نقصان، غلطی، یا حوصلہ افزائی ہو گی. جب تک ٹرانسفررز کمرے کی پیچیدگی (O(n2) کے ساتھ خود پر توجہ پر کام کرتے ہیں، تو یہ محدودیت ہمارے ساتھ ہوگی. "کاروبار کی یادداشت" سے "مخزون" کو الگ کریں - کلاسک کمپیوٹرنگ سسٹموں میں جیسے. ایجنٹ کو بیرونی یادداشت کے ساتھ کام کرنے کے قابل ہونا چاہئے: اسٹوریج، ڈاؤن لوڈ، خلاصہ، اور ماڈل کے باہر علم کو اپ ڈیٹ. Solution: Approaches Memory Buffer سٹور آخری فوری پروٹائپنگ کے لئے نوٹ کریں. k آسان، تیز، مختصر کاموں کے لئے کافی + اہم معلومات کھو دیتا ہے، پیمائش نہیں کرتا، "آج" کو یاد نہیں کرتا - Summarization Memory تاریخ کو مزید بہتر بنانے کے لئے. Token Savings اور Memory Expansion + ڈراپوریشنز، تجاویز کی کمی، کئی مرحلے کے کمپریشن میں غلطییں - RAG (Retrieval-Augmented Generation) بیرونی ڈیٹا بیس سے علم نکالتا ہے. زیادہ تر وقت آپ یہاں ہوں گے. چمکدار، تازہ، چمکدار + پیچیدہ ترتیبات، وصولی کے معیار کے لئے حساس، latency - Knowledge Graphs موجودات اور حقائق کے درمیان منظم کنکشن. ہمیشہ خوبصورت، شہوت انگیز اور سخت، آپ کو کسی بھی صورت میں RAG کرنے کے لئے ختم ہو جائے گا. منطق، وضاحت، مستحکم + داخلے کے لئے اعلی حراست، LLM انضمام کی پیچیدگی - Checklist: تمام بات چیت کی تاریخ ایک جگہ پر دستیاب ہے (پرسٹ کے باہر) علم کے ذریعہ ریکارڈ کیا جاتا ہے اور دوبارہ استعمال کیا جا سکتا ہے تاریخ کی پیمائش کریں بغیر خطرے سے کنٹیکٹ ونڈوز سے باہر 3. Model as a Config LLMs تیزی سے ترقی کر رہے ہیں؛ گوگل، Anthropic، OpenAI، وغیرہ مسلسل اپ ڈیٹس جاری کرتے ہیں، مختلف بینکنگ مارکیٹز پر ایک دوسرے کے خلاف مقابلے میں. یہ انجینئرز کے طور پر ہمارے لئے ایک جشن ہے، اور ہم اس سے زیادہ سے زیادہ حاصل کرنا چاہتے ہیں. Problem: Solution: model_id کی ترتیب کو نافذ کریں: استعمال ہونے والے ماڈل کی وضاحت کرنے کے لئے ترتیب فائلوں یا ماحول متغیروں میں ایک model_id پارامتر کا استعمال کریں. مختصر انٹرفیس کا استعمال کریں: انٹرفیسوں یا انٹرفیس کلاسوں کو تخلیق کریں جو ایک متحد API کے ذریعے ماڈلوں کے ساتھ بات چیت کرتے ہیں. Middleware حل کا استعمال کریں (بھارت سے - ہم فریم ورکز کے بارے میں تھوڑا بعد بات کریں گے) Checklist: ماڈل کی تبدیلی کو باقی کوڈ پر اثر انداز نہیں ہوتا ہے اور ایجنٹ کی تقریب، آرکسٹریشن، میموری یا آلات پر اثر انداز نہیں ہوتا ہے. ایک نیا ماڈل شامل کرنے کے لئے صرف ترتیب کی ضرورت ہے اور، اختیاری طور پر، ایک اڈاپٹر (ایک سادہ layer جو نئے ماڈل کو مطلوبہ انٹرفیس پر لاتا ہے) آپ آسانی سے اور تیزی سے ماڈلوں کو تبدیل کرسکتے ہیں.Ideally—any models, at least—switching within a model family 4. One Agent, Many Interfaces: Be Where the Users Are یہاں تک کہ اگر ابتدائی طور پر ایجنٹ کو صرف ایک مواصلات انٹرفیس (مثال کے طور پر، UI) ہونا چاہئے تو، آپ آخر میں صارفین کو Slack، WhatsApp، یا، میں یہ کہہ سکتا ہوں، ایس ایم ایس کے ذریعے بات چیت کو شامل کرکے زیادہ انعطاف اور آسانیت فراہم کرنا چاہتے ہیں. ایک API ایک CLI میں تبدیل ہوسکتا ہے (یا آپ کو ڈبگنگ کے لئے ایک چاہتے ہیں). شروع سے اپنے ڈیزائن میں اس کی تعمیر کریں؛ آپ کے ایجنٹ کو استعمال کرنے کے قابل بنائیں جہاں بھی یہ آسان ہے. Problem: : ایک API یا دوسرے میکانیزم کو تیار کریں جو تمام چینلز کے لئے ایک عام انٹرفیس کے طور پر کام کرے گا. Solution: Creating a unified input contract Checklist: Agent is callable from CLI, API, UI All input goes through a single endpoint/parser/schema All interfaces use the same input format No channel contains business logic Adding a new channel = only an adapter, no changes to core II. ایجنٹ کے رویے کی وضاحت اگرچہ صرف ایک کام ہے، سب کچھ سادہ ہے، جیسا کہ AI انجیلز کے پوسٹس میں ہے. لیکن جب آپ آلات، فیصلہ کرنے کی منطق، اور کئی مرحلے شامل کرتے ہیں تو، ایجنٹ ایک مداخلت میں تبدیل ہوتا ہے. اگرچہ صرف ایک کام ہے، سب کچھ سادہ ہے، جیسا کہ AI انجیلز کے پوسٹس میں ہے. لیکن جب آپ آلات، فیصلہ کرنے کی منطق، اور کئی مرحلے شامل کرتے ہیں تو، ایجنٹ ایک مداخلت میں تبدیل ہوتا ہے. یہ ٹریک کھو جاتا ہے، غلطیوں کے ساتھ کیا کرنا نہیں جانتا، صحیح آلے کو کال کرنے کے لئے بھول جاتا ہے - اور آپ کو ایک بار پھر لاگ ان کے ساتھ چھوڑ دیا جاتا ہے جہاں "ہاں، سب کچھ وہاں لکھا لگتا ہے." اس سے بچنے کے لئے، ایجنٹ کو واضح طور پر ضروری ہے : یہ کیا کرتا ہے، اس کے پاس کیا آلات ہیں، کس نے فیصلے کیے ہیں، انسانوں کو کس طرح مداخلت کرتے ہیں، اور جب کچھ غلط ہو جاتا ہے تو کیا کرنا ہے. behavioral model اس سیکشن میں اصولوں پر مشتمل ہے جو آپ کو آپ کے ایجنٹ کو ایک مطابقت پذیر کارروائی کی حکمت عملی فراہم کرنے میں مدد ملے گی، اس کے بجائے امید کرتے ہوئے کہ "مڈل کچھ طریقے سے اسے سمجھائے گا." 5. Design for Tool Use یہ نقطہ نظر واضح ہوسکتا ہے، لیکن آپ اب بھی "Plain Prompting + Raw LLM output parsing" پر تعمیر شدہ ایجنٹوں سے ملاقات کرسکتے ہیں. یہ ایک پیچیدہ میکانیزم کو ہٹانے کی کوشش کی طرح ہے random strings کو نکال کر اور بہترین کے لئے امید. Problem: لچکدار: LLM جواب کے الفاظ میں سب سے چھوٹا سا تبدیلی (ایک لفظ شامل کیا گیا ہے، الفاظ کی ترتیب تبدیل کر دیا گیا ہے) پورے پیسنگ کو توڑ سکتا ہے. واضحات: قدرتی زبان متوازن ہے. جو انسان کے لئے واضح لگتا ہے وہ ایک تجزیہ کار کے لئے ایک پازل ہوسکتا ہے. "John Smith کو کال کریں" - آپ کے ڈیٹا بیس میں تین جان سمیٹس میں سے کون سا؟ اس کا نمبر کیا ہے؟ برقرار رکھنے کی پیچیدگی: پیسنگ کوڈ بڑھ جاتا ہے، پیچیدہ ہو جاتا ہے اور ڈیبگ کرنے کے لئے مشکل ہو جاتا ہے. ہر نئی ایجنٹ "توازن" کو نیا پیسنگ کے قوانین لکھنے کی ضرورت ہوتی ہے. محدود صلاحیتیں: ماڈل کو قابل اعتماد طریقے سے کئی اوزار کال کرنے یا سادہ ٹیکسٹ آؤٹ کے ذریعہ پیچیدہ ڈیٹا ساختوں کو منتقل کرنے کے لئے مشکل ہے. ماڈل JSON (یا کسی دوسرے ساختار فارمیٹ) کی واپسی کرتا ہے — نظام چلتا ہے. Solution: یہاں اہم خیال یہ ہے کہ ذمہ داری چھوڑنے کے لئے صارف کا مقصد اور LLM کے لئے ٹولز، جبکہ اب بھی اس کا تعین کرتے ہوئے اس مقصد کے بارے میں واضح طور پر مقرر کردہ انٹرفیس کے ذریعے. تفسیر منتخب کریں عملے نظام کے خوش قسمتی سے، تقریبا تمام سپلائرز (OpenAI، گوگل، Anthropic، یا جو بھی آپ ترجیح دیتے ہیں) کہا جاتا ہے کہ حمایت کرتا ہے. یا ایک سخت طور پر مقرر کردہ JSON فارمیٹ میں پیدا کرنے کی صلاحیت. "function calling" صرف تازہ کرنے کے لئے کس طرح یہ کام کرتا ہے: آلے کی وضاحت: آپ کو JSON Schema کے طور پر فائلوں (ٹولز) کی وضاحت کرتے ہیں، نام، وضاحت، پیرامیٹرز. Description is critically important—the model relies on it. LLM پر منتقل: ہر کال پر، ماڈل کو آلے کے شیڈولز کے ساتھ ساتھ بھیجا جاتا ہے. Instead of text, the model returns JSON with: Model output: name of the function to call arguments—parameters according to schema عملدرآمد: کوڈ JSON کی تصدیق کرتا ہے اور پیرامیٹرز کے ساتھ مناسب تقریب کو بلاتا ہے. ماڈل جواب (مختص): اختتام کے جواب کی پیداوار کے لئے LLM کو واپس منتقل کیا جاتا ہے. آلے کی وضاحتیں بھی مشورہ ہیں Unclear description = wrong function choice. Important: What to do without function calling? اگر ماڈل آلہ کالز کی حمایت نہیں کرتا ہے یا آپ کسی بھی وجہ سے ان سے بچنا چاہتے ہیں: درخواست میں JSON کو واپس کرنے کے لئے ماڈل سے پوچھیں. فارمیٹ کی وضاحت کریں؛ آپ مثالیں شامل کرسکتے ہیں. جواب کا تجزیہ کریں اور اسے پائیڈینٹک کی طرح کچھ کے ساتھ تصدیق کریں. Checklist: جواب کو سختی سے منظم کیا جاتا ہے (مثال کے طور پر، JSON) Schemes (JSON Schema یا Pydantic) استعمال کیا جاتا ہے. Function calls سے پہلے Validation کا استعمال ہوتا ہے پیداوار کی غلطیوں کو توڑنے کی وجہ سے نہیں ہے (اعداد و شمار کی غلطیوں کا انتظام موجود ہے) LLM = کام کا انتخاب، execution = کوڈ 6. Own the Control Flow Usually agents work as "dialogues"—first the user speaks, then the agent responds. It's like playing ping-pong: hit-response. Convenient, but limiting. Problem: Such an agent cannot: کسی بھی درخواست کے بغیر خود کار طریقے سے کچھ کریں موازنہ میں عمل کریں آگے بڑھنے کی منصوبہ بندی کئی قدموں پر عمل کریں ترقی کی جانچ پڑتال کریں اور ناکام قدموں پر رجوع کریں اس کے بجائے، ایجنٹ کو اس کے اپنے "تغیر کی رفتار" کا انتظام کرنا چاہئے - فیصلہ کریں کہ اگلا کیا کرنا ہے اور اسے کیسے کرنا ہے. This means the agent: decides when to do something on its own ایک قدم ایک دوسرے کے بعد کر سکتے ہیں can retry failed steps can switch between tasks براہ راست درخواست کے بغیر بھی کام کر سکتے ہیں LLM کو تمام منطق کو کنٹرول کرنے کی اجازت کے بجائے، ہم پروڈکٹ کو کوڈ میں شامل کیا جاتا ہے۔ ماڈل صرف مرحلے کے اندر مدد کرتا ہے یا اگلے مرحلے کا مشورہ کرتا ہے۔ یہ "نمائیدار لکھنے" سے "نمائیدار لکھنے" سے ایک تبدیلی ہے کنٹرول شدہ رویے کے ساتھ Solution: control flow engineering a system ہم تین مقبول نقطہ نظر پر نظر ڈالیں: 1. FSM (Finite State Machines) یہ کیا ہے: کام ریاستوں اور واضح انتقالوں میں تقسیم کیا گیا ہے. LLM: اگلے مرحلے کا تعین کرتا ہے یا ایک ریاست کے اندر عمل کرتا ہے. فوائد: سادگی، پیشہ ورانہ، لینیئر سکرینز کے لئے اچھا. آلات: StateFlow، YAML ترتیب، State Pattern. 2. DAG (Directed Graphs) یہ کیا ہے: ایک گراف کے طور پر غیر لینیری یا متضاد کام: نڈوز کارروائی ہیں، کنڈز انفرادیت ہیں. Can be a node or help with plan construction. LLM: فوائد: انعطاف پذیری، parallelism، vizualizable. آلات: LangGraph، Trellis، LLMCompiler، اپنی مرضی کے مطابق DAG ڈگری. 3. Planner + Executor یہ کیا ہے: LLM ایک منصوبہ بناتا ہے، کوڈ یا دیگر ایجنٹ اسے عملدرآمد کرتے ہیں. LLM: "بہترین" ایک منصوبہ بندی، " چھوٹے" ان کو عملدرآمد. فوائد: نگرانیوں کی تقسیم، لاگت کنٹرول، مقناطیسی. آلے: LangChain Plan-and-Execute. Why this matters: کنٹرول، قابل اعتماد، پیمائش کو بہتر بناتا ہے. مختلف ماڈلوں کا مجموعہ کرنے اور عمل کو تیز کرنے کی اجازت دیتا ہے. Task flow قابل تجزیہ اور ٹیسٹ کیا جا سکتا ہے. Checklist: واضح منتقلی کے ساتھ FSM، DAG، یا سکرین کا استعمال کرتا ہے ماڈل فیصلہ کرتا ہے کہ کیا کرنا ہے لیکن بہاؤ کو کنٹرول نہیں کرتا رویے کو دیکھی جا سکتی ہے اور ٹیسٹ کیا جا سکتا ہے غلطی کا انتظام بہاؤ میں تعمیر کیا جاتا ہے 7. Include the Human in the Loop یہاں تک کہ اگر ایک ایجنٹ ساختہ اوزار کا استعمال کرتا ہے اور واضح کنٹرول کی فراہمی ہے تو، حقیقی دنیا میں ایل ایل ایم ایجنٹوں کی مکمل استقلال اب بھی ایک خواب (یا خواب، کنکشن پر منحصر ہے) کا زیادہ ہے. ایل ایل ایم کے پاس حقیقی سمجھ نہیں ہے اور کسی بھی چیز کے لئے ذمہ دار نہیں ہیں. Problem: Main risks of full autonomy: دائمی غلطی: ایجنٹ سنگین اثرات کے ساتھ کارروائیوں کو انجام دے سکتا ہے (اعداد و شمار کو حذف، ایک اہم کلائنٹ کو غلط پیغام بھیجیں، روبوٹ بوٹنگ شروع کریں). مطابقت کی خلاف ورزی: ایجنٹ تصادفی طور پر اندرونی قوانین، قانونی ضروریات کی خلاف ورزی کر سکتا ہے، یا صارفین کے احساسات کو نقصان پہنچا سکتا ہے (اگر یہ منصوبہ نہیں تھا تو، اس نقطہ نظر کو نظر انداز کریں). LLMs might miss social nuances or act against "common sense." Lack of common sense and ethics: صارف اعتماد کی کمی: اگر ایجنٹ اکثر غلطیاں کرتا ہے تو صارفین اس پر بھروسہ کرنے سے روکیں گے. تجزیہ اور ذمہ داری کی پیچیدگی: جب ایک خود کار طریقے سے ایجنٹ "سیر" کرتا ہے تو کس کی ذمہ داری ہے؟ اہم مراحل میں فیصلے کے عمل میں انسانوں کو شامل کریں. Solution: کاربن پر مبنی زندگی کے اقسام کی حکمت عملی HITL Implementation Options 1. Approval Flow جب: کارروائی اہم ہے، مہنگی ہے، غیر متبادل ہے کس طرح: ایجنٹ ایک تجویز بیان کرتا ہے اور تصدیق کا انتظار کرتا ہے 2. Confidence-aware Routing جب: ماڈل غیر یقینی ہے How: self-assessment (logits, LLM-as-a-judge, P(IK)) escalation when confidence falls below threshold 3. Human-as-a-Tool جب: ناممکن ڈیٹا یا ناممکن درخواست فارم کس طرح: ایجنٹ وضاحت کی درخواست کرتا ہے (مثلا، CrewAI میں HumanTool) 4. Fallback Escalation جب: تکرار شدہ غلطی یا غیر حل کی صورت حال کس طرح: کام context کے ساتھ آپریٹر کو منتقل کیا جاتا ہے 5. RLHF (Human Feedback) جب: ماڈل بہتر بنانے کے لئے کس طرح: انسان جوابات کا جائزہ لیتا ہے، وہ تربیت میں جاتے ہیں Checklist: Actions requiring approval are defined اعتماد کا تجزیہ کرنے کا ایک طریقہ انسانوں سے سوالات پوچھ سکتے ہیں اہم اقدامات کی تصدیق کی ضرورت ہے جوابات داخل کرنے کے لئے ایک انٹرفیس ہے 8. Compact Errors into Context بہت سے نظاموں کی معیاری رفتار جب ایک غلطی ہوتی ہے تو وہ یا تو "کڑوا" یا صرف غلطی کی رپورٹ اور روکنے کے لئے ہے. ایک ایجنٹ کے لئے جو خود کار طریقے سے کاموں کو حل کرنا چاہئے، یہ بالکل بہترین رویے کا ماڈل نہیں ہے. Problem: ہم کیا مقابلہ کریں گے: Any failure in an external tool or unexpected LLM response can stop the entire process or lead it astray. Brittleness: غیر مؤثر: مسلسل دوبارہ شروع کریں اور دستی مداخلت وقت اور وسائل کو ضائع کرتے ہیں. سیکھنے کی ناکامی (شامل معنی میں): اگر ایجنٹ اپنی غلطیوں کو کنٹیکٹ میں "نہ دیکھتا ہے" تو، وہ انہیں ٹھیک کرنے یا اپنے رویے کو اپ ڈیٹ کرنے کی کوشش نہیں کرسکتا. ایک بار پھر ہالووینز غلطیوں کو نوٹ یا ذہن میں شامل کیا جاتا ہے. خیال یہ ہے کہ کسی قسم کی "اپنا علاج" کو لاگو کرنے کی کوشش کرنا ہے. ایجنٹ کو کم از کم اس کے رویے کو درست کرنے اور اس کی اصلاح کرنے کی کوشش کرنا چاہئے. Solution: Rough flow کے بارے میں: غلطی کو سمجھنا Self-correction: Error Detection, Reflection, Retry Logic, Retry with changes (Agent can modify request parameters, rephrase the task, or try a different tool) Self-correction mechanisms: More detailed error information (instructions, explanations) usually leads to better self-correction results. Even simple knowledge of previous errors improves performance. Impact of reflection type: Training LLMs for self-correction by introducing errors and their fixes into training data. Internal Self-Correction: If self-correction fails, the agent escalates the problem to a human (see Principle 7). Request human help: Checklist: اگلے مرحلے کی غلطی kontext میں محفوظ کی جاتی ہے RETRY LOGIC موجود ہے Fallback/human escalation دوبارہ ناکامیوں کے لئے استعمال کیا جاتا ہے 9. Break Complexity into Agents ہم اہم LLM محدودیت (یہ کنٹیکٹ ونڈوز چیز) پر واپس جائیں، لیکن اس مسئلے کو ایک اور نقطہ نظر سے دیکھیں. زیادہ سے زیادہ اور زیادہ پیچیدہ کام، اس سے زیادہ اقدامات لگیں گے، جس کا مطلب ہے کہ ایک طویل کنٹیکٹ ونڈوز. جب کنٹیکٹ بڑھ جاتا ہے، LLMs کھو یا توجہ کھو سکتے ہیں. 3-10، شاید زیادہ سے زیادہ 20 اقدامات کے ساتھ مخصوص ڈومینز پر ایجنٹس پر توجہ مرکوز کرتے ہوئے، ہم کنٹیکٹ ونڈوز کو منظم اور اعلی LLM کارکردگی کو برقرار رکھیں. Problem: ایک ایجنٹ = ایک کام؛ اوپر سے آرکسٹریشن. Solution: چھوٹے، توجہ مرکوز ایجنٹوں کے فوائد: منظم کنکشن: چھوٹے کنکشن ونڈوز بہتر LLM کارکردگی کا مطلب ہے واضح ذمہ داری: ہر ایجنٹ کو ایک واضح پیمائش اور مقصد ہے بہتر قابل اعتماد: پیچیدہ کام کی رفتاروں میں کھو جانے کا کم امکان سادہ ٹیسٹنگ: مخصوص سرگرمیوں کو ٹیسٹ اور تصدیق کرنے کے لئے آسان Easier to identify and fix problems when they arise Improved debugging: بدقسمتی سے، سمجھنے کے لئے کوئی واضح heuristic نہیں ہے جب منطق کا ایک ٹکڑا پہلے سے ہی بہت سے ایجنٹوں میں تقسیم کرنے کے لئے کافی بڑا ہے. میں اس بات کا یقین کر رہا ہوں کہ جب آپ اس مضمون کو پڑھ رہے ہیں، LLMs لیبسوں میں کہیں زیادہ ذہین ہو گئے ہیں. اور وہ بہتر اور بہتر ہو رہے ہیں، لہذا اس حدود کو منظم کرنے کی کسی بھی کوشش شروع سے حتمی ہے. جی ہاں، کام کو چھوٹا ہے، یہ زیادہ سادہ ہے، لیکن یہ زیادہ ہو جاتا ہے، زیادہ سے زیادہ امکانات کو پورا کیا جاتا ہے. صحیح اندھیرا صرف تجربے کے ساتھ آ جائے گا. لیکن یہ یقینی نہیں ہے. Checklist: Scenario is built from microservice calls Agents can be restarted and tested separately Agent = minimal autonomous logic. You can explain what it does in 1-2 sentences. III. کنٹرول ماڈل انٹرویو ماڈل نسل کے ساتھ کام کرتا ہے. سب کچھ آپ پر ہے. ماڈل نسل کے ساتھ کام کرتا ہے. سب کچھ آپ پر ہے. آپ نے درخواست کو کس طرح بیان کیا ہے، آپ نے کنکشن میں کیا منتقل کیا ہے، آپ نے کیا ہدایات دی ہیں - یہ سب اس بات کا فیصلہ کرتا ہے کہ نتائج مطابقت پذیر یا "خوددار" ہوں گے. LLMs دماغ نہیں پڑھتے.They read tokens. Which means any input error turns into an output bug—just not immediately noticeable. یہ سیکشن ہر چیز کو ڈرائیو کرنے کے بارے میں نہیں ہے: پروپٹ = کوڈ، واضح کنٹیکٹ مینجمنٹ، حدود کے اندر ماڈل کو محدود کرنے کے بارے میں ہے. 10. Treat Prompts as Code ایک بہت عام نمونہ، خاص طور پر ML یا SE پس منظر کے بغیر لوگوں کے درمیان، کوڈ میں براہ راست پروپٹس کو ذخیرہ کرنا ہے. Problem: This approach leads to several maintenance and scaling difficulties: براؤزنگ، سمجھنے، اور ترمیم منصوبے کی پیچیدگی اور درخواستوں کی تعداد میں اضافہ کے طور پر پیچیدہ ہو جاتے ہیں. واضح ورژننگ کے بغیر، فوری ترقی، تبدیلیوں کی وجہوں کو ٹریک کرنا اور کارکردگی میں کمی کی صورت میں پچھلے مستحکم ورژن کی طرف رجوع کرنا بہت مشکل ہے. غیر مؤثر بہتر بنانے اور ڈبگنگ کے عمل: عارضی میٹرک اور ٹیسٹ کے بغیر فوری بہتر بنانے کے عمل کو غیر مستحکم نتائج کے ساتھ ایک ذہنی اور کام کی شدت مند عمل بن جاتا ہے. دوسرے ٹیم کے ارکان کی شناخت پیچیدہ ہو جاتا ہے، اس میں شامل (اور خاص طور پر) مستقبل آپ. اس سلسلے میں پروموشنز کو کوڈ سے بہت مختلف نہیں ہیں اور ان کے لئے اسی بنیادی انجینئرنگ کے طریقوں کو لاگو کیا جانا چاہئے. Solution: This implies: منفرد اور منظم طور پر ذخیرہ کریں، خصوصی فائلوں (جیسے .txt، .md، .yaml، .json) یا یہاں تک کہ نمونے کے انتظام کے نظام (جیسے Jinja2، Handlebars، یا خصوصی آلات جیسے BAML) کا استعمال کرتے ہوئے. آپ اس کے بعد مختلف ورژن کے ساتھ A / B ٹیسٹ بھی کرسکتے ہیں. Testing. You heard that right. This could be something like unit tests, where you compare LLM responses to specific inputs against reference answers or expected characteristics depending on the prompt Evaluation datasets Format compliance checks and presence/absence of key elements - For example, if a prompt should return JSON, the test can validate its structure Even LLM-as-a-judge if your project and design justify it. ہم اصول 14 میں ٹیسٹ کے بارے میں مزید تفصیل سے بات کریں گے. Checklist: Prompts are stored in separate files, separate from business logic تاریخ بدلتی ہے اور تاریخ بدلتی ہے ٹیسٹ استعمال کیا جاتا ہے (اگر ضروری ہے) (مختصر) کوڈ جائزہ لینے کے حصے کے طور پر فوری جائزہ لینے کے بارے میں کیا؟ کنکشن انجینئرنگ 11. ہم نے پہلے سے ہی LLMs کی "مفیدیت" پر بحث کی ہے، جزوی طور پر یہ حل کی طرف سے تاریخ کو بیرونی میموری میں اڑانے اور مختلف کاموں کے لئے مختلف ایجنٹوں کا استعمال کرتے ہوئے. لیکن یہ سب نہیں ہے. میں پیش کرتا ہوں کہ ہم واضح کنٹاکٹ ونڈوز مینجمنٹ پر بھی غور کریں (اور یہاں میں صرف تاریخ کو زیادہ سے زیادہ سائز میں شامل کرنے کے بارے میں بات نہیں کر رہا ہوں یا کنٹاکٹ میں پچھلے اقدامات سے غلطیوں کو شامل کرنے کے لئے). Problem: ایک سادہ فہرست "Role-content" میں پیغامات ( ) فارمیٹ بنیادی طور پر ہے، لیکن یہ ٹوکن سنگین ہوسکتا ہے، کافی معلومات نہیں ہے، یا آپ کے ایجنٹ کی پیچیدہ حالت کو منتقل کرنے میں کم ہے. Standard formats aren't always optimal: system/user/assistant زیادہ تر LLM گاہکوں کو معیاری پیغام فارمیٹ (ایک فہرست کے ساتھ اشیاء) استعمال کرتے ہیں. ’سسٹم‘،‘ صارف‘،‘ مددگار‘، اور کبھی کبھی کا میدان) role content tool_calls اگرچہ یہ "بہت سے حالات کے لئے بہت اچھا کام کرتا ہے"، یقینی طور پر (دو ٹوکن اور ماڈل کی توجہ کے لحاظ سے) ہم رابطے کی تشکیل کو زیادہ تخلیقی طور پر دیکھ سکتے ہیں. maximum efficiency یہ انجینئرنگ کرنے کے لئے.تصویر کے طور پر LLM کو منتقل تمام معلومات کے پیکج کی تخلیق کا علاج کرنے کے لئے اس کا مطلب ہے: Solution: "Context Engineering." مکمل کنٹرول: کس معلومات کے لئے مکمل مالکیت لینے کے لئے LLM کے کنٹیکٹ ونڈو میں داخل ہوتا ہے، کس شکل میں، حجم، اور سیریز میں. اپنی مرضی کے فارمیٹس بنائیں: ہم خود کو معیاری پیغام کی فہرستوں پر محدود نہیں کرتے. ہمارے اپنے، کام کو بہتر بنانے کے طریقوں کی نمائندگی کرنے کے لئے. مثال کے طور پر، آپ کو ایک یا ایک سے زیادہ پیغامات میں مختلف قسم کی معلومات (پیغامات، آلہ کالز، ان کے نتائج، غلطیوں، وغیرہ) کو گہری طور پر پیک کرنے کے لئے ایک XML کی طرح کی ساخت کا استعمال کرنے پر غور کر سکتے ہیں. ہولسٹک نقطہ نظر: کنکشن کو صرف ایک بات چیت کی تاریخ کے طور پر نہیں دیکھنا، لیکن ماڈل کی ضرورت ہوسکتی ہے کہ سب کچھ کے مجموعی طور پر: فوری نوٹ، ہدایات، RAG سسٹمز سے ڈیٹا، آلہ کالوں کی تاریخ، ایجنٹ کی حالت، دیگر تعاملات سے ذہنیت، اور یہاں تک کہ مطلوبہ پیداوار فارمیٹ پر ہدایات. (Instead of a checklist) How do you know when this makes sense? اگر آپ مندرجہ ذیل میں سے کسی میں دلچسپی رکھتے ہیں: معلومات کی گہرائی: کم سے کم شور کے ساتھ زیادہ سے زیادہ معنی. قیمت کے مؤثر: ٹوکن کی تعداد کو کم کرنے کے لئے جہاں ہم ایک کم قیمت کے لئے موازنہ کیفیت حاصل کرسکتے ہیں. غلطیوں کو بہتر بنانے کے لئے ذہنی معلومات کو شامل کرنے، اس کو کنٹرول کرنے، اس کو فلٹر کرنے، اور تمام کو کلاسیکی "مجھے معذرت ہے، میں صرف ایک چھوٹا سا چھوٹا سا بڑی زبان ماڈل ماڈل ہوں" جواب کے ذریعے ختم کرتا ہوں. 12. Constrain the Chaos: Secure Inputs, Guarded Actions, and Grounded Outputs ہم نے stability کے نام پر پہلے سے ہی بہت کچھ کیا ہے، لیکن کچھ بھی ایک Silver Bullet نہیں ہے.This means it’s worth looking at the most critical potential problems separately and explicitly taking out some “insurance”. Problem: اس اصول میں، ہم سوچتے ہیں: ممکنہ پروپٹ انجیکشن. اگر آپ کا ایجنٹ براہ راست ایک صارف کے ساتھ بات چیت کرے گا تو، آپ کو کنٹرول کرنے کی ضرورت ہے کہ کیا ان پٹ کے طور پر کھایا جاتا ہے. صارف کی قسم پر منحصر ہے، آپ کو ایک حاصل کر سکتے ہیں جو آپ کے بہاؤ کو توڑنا چاہتا ہے اور ایجنٹ کو اپنے ابتدائی مقاصد کو نظر انداز کرنے، غلط معلومات فراہم کرنے، نقصان دہ کارروائیوں کو انجام دینے، یا زبردست مواد پیدا کرنے کے لئے مجبور کر سکتا ہے. ذہنی ڈیٹا چوری: اوپر کی وجہ سے، یا "اس کے سر میں آوازوں" کی طرف سے ہدایت کی جاتی ہے، ایجنٹ اہم معلومات، جیسے صارفین کی ذاتی معلومات، کارپوریٹ خفیہ، وغیرہ کو ظاہر کر سکتا ہے. زہریلا یا زہریلا مواد کی پیداوار. اگر یہ ڈیزائن کی طرف سے ہے تو، اس نقطہ نظر کو نظر انداز کریں. معلومات کے بغیر چیزوں کو تیار کرنے کے لئے ۔ ہمیشہ کے درد مشینوں کی بڑھتی ہوئی، یاد رکھیں؟ لیکن سنجیدگی سے، اس کے خیالات کے عمل میں، ایجنٹ بہت غیر مختصر حلوں پر پہنچ سکتے ہیں، جو سب سے زیادہ معمول کے رویے کے تحت نہیں ہوں گے. ایک LLM ایجنٹ کی حفاظت اور زراعت ایک واحد پیمانے پر نہیں ہے، لیکن ایک کثیر درجے کی حفاظت کے نظام ("بھارت میں گہری") ہے جو تمام تبادلے کی زندگی کے سائیکل پر مشتمل ہے. خطرات مختلف ہیں، اور کوئی ایک ہی تحفظ کا طریقہ نہیں ہے. مؤثر تحفظ تکنیکوں کی ایک مجموعہ کی ضرورت ہے. We must commit to a multi-layered defense system, thinking through and explicitly handling all corner cases and potential scenarios, and having a clear response ready for whatever might happen. Solution: ایک بنیادی ترتیب میں، آپ کو غور کرنا چاہئے: Secure Inputs. Check for known attack-indicator phrases (e.g., "ignore all previous instructions"). It sometimes makes sense to combat potential obfuscation. Try to determine the user's intent separately. You can use another LLM for this, to analyze the input for the current one. Control input from external sources, even if they are your own tools. Control the privileges of both the agent and its tools (granting the minimum necessary), clearly define and limit the list of available tools, validate parameters at the input to tools, and enable Principle #7 (Human in the Loop). Guarded Actions. Design a system of checks for what the model outputs, especially if it goes directly to the user. These can be checks for relevance (ensuring the model uses what's in the RAG and doesn't just make things up) as well as checks for general appropriateness. There are also ready-made solutions (e.g., the OpenAI Moderation API). Output Moderation. آخری نظام، تاہم، آپ کے کاموں اور آپ کے خطرے کی تشخیص پر منحصر ہے. چیک لسٹ میں، ہم کچھ اختیارات کو نظر انداز کرنے کی کوشش کریں گے. Checklist: User input validation is in place. For tasks requiring factual information, the data within the RAG is used. The prompt for the LLM in a RAG system explicitly instructs the model to base its answer on the retrieved context. LLM output filtering is implemented to prevent PII (Personally Identifiable Information) leakage. The response includes a link or reference to the source. LLM output moderation for undesirable content is implemented. The agent and its tools operate following the principle of least privilege. The agent's actions are monitored, with HITL (Human-in-the-Loop) for critical operations. IV. Keep It Alive ایک ایجنٹ جو "Kinda کام کرتا ہے" ایک تاخیر اثر کے ساتھ ایک بیگ ہے. ایک ایجنٹ جو "Kinda کام کرتا ہے" ایک تاخیر اثر کے ساتھ ایک بیگ ہے. میں، سب کچھ ایک بار نہیں توڑتا ہے. اور آپ اس کے بارے میں فوری طور پر نہیں جانتے. کبھی کبھی، آپ کو کچھ بھی نہیں جانتے. یہ سیکشن انجینئرنگ کی عادت کے بارے میں ہے اور لاگ ان، ٹریکنگ، ٹیسٹ - سب کچھ جو ایک ایجنٹ کے رویے کو شفاف اور قابل اعتماد بناتا ہے، یہاں تک کہ جب آپ خواب میں ہیں یا آپ کے اگلے ایجنٹ کو تیار کرتے ہیں. seeing what's happening checking that everything is still working 13. Trace Everything ایک طرح یا دوسری طرح، آپ ہمیشہ ایسے حالات کا سامنا کریں گے جہاں ایجنٹ آپ کی توقع کے طور پر کام نہیں کرتا. ترقی کے دوران، ٹیسٹنگ، تبدیلیوں کو بنانے، یا معمول کے عمل کے دوران. یہ ضروری ہے، اور اس وقت، یہ کچھ حد تک معمول ہے. اس کا مطلب یہ ہے کہ آپ گھنٹوں اور دنوں کو ڈبگنگ کرنے کے لئے مصروف ہیں، اس بات کو سمجھنے کی کوشش کرتے ہیں کہ کیا غلط ہے، مسئلہ کو دوبارہ کریں، اور اسے ٹھیک کریں. میں یہ سوچنا چاہوں گا کہ اس وقت تک آپ نے پہلے سے ہی اصول #1 (پیدا ریاست باہر) اور #8 (کپٹ غلطیوں کو کنٹیکٹ میں لاگو کیا ہے). زیادہ تر صورتوں میں، یہ آپ کی زندگی کو بہت آسان بنانے کے لئے کافی ہوگا. کچھ دیگر اصول یہاں بھی غیر جانبدار طور پر مدد ملے گی. Problem: یہاں تک کہ (اور خاص طور پر اگر آپ نے ابھی تک ان کے ساتھ پریشان نہیں ہونے کا فیصلہ کیا ہے) ، اس اصول پر عمل کرنے سے پہلے ڈبگنگ کے بارے میں سوچنا اور مستقبل میں اپنے آپ کو وقت اور اعصاب بچانے کے لئے بہت منطقی ہے. درخواست سے کارروائی تک پورے راستہ کو لاگ ان کریں. یہاں تک کہ اگر آپ کے پاس پہلے سے ہی انفرادی اجزاء کے لئے لاگ ان ہیں تو، پورے سلسلے کو ٹریک کرنا مشکل ہوسکتا ہے. یہاں تک کہ اگر آپ پازل یا لوگو کے ایک بڑے فیملی ہیں تو، کچھ وقت میں، یہ مذاق نہیں ہو گا. لہذا، لاگ ان موجود ہونا ضروری ہے، وہ آخر تک ہونا چاہئے، اور وہ سب کچھ شامل کرنا چاہئے. Solution: Why it's needed: ڈیبگنگ — فوری طور پر تلاش کریں جہاں چیزیں غلط ہو گئیں. تجزیات — دیکھیں کہ بوتلنگ کہاں ہیں اور کس طرح بہتر بنانے کے لئے. معیار کا جائزہ لینے - دیکھیں کہ تبدیلیوں کو کس طرح رویے پر اثر انداز ہوتا ہے. Reproductibility - آپ صحیح طریقے سے مراحل کو دوبارہ تعمیر کرسکتے ہیں. اکاؤنٹنگ - تمام ایجنٹ فیصلے اور کارروائیوں کا ایک لاگ ان. بنیادی "جنتوں کی سیٹ" اس طرح لگتا ہے: ان پٹ: ابتدائی صارف درخواست، پچھلے مرحلے سے حاصل کردہ پیرامیٹرز. ایجنٹ کی حالت: قدم کو انجام دینے سے پہلے ایجنٹ کی اہم حالت متغیر. پروموٹ: LLM کو بھیجنے والے پروموٹ کا مکمل متن، سسٹم کی ہدایات، بات چیت کی تاریخ، حاصل کردہ RAG کنکشن، آلے کی وضاحتیں، وغیرہ سمیت. LLM Output: کسی بھی پلس یا پروسیسنگ سے پہلے، LLM سے مکمل، خام جواب. Tool Call: اگر LLM نے ایک آلے کو کال کرنے کا فیصلہ کیا ہے تو – آلے کا نام اور اس کے ساتھ صحیح پیرامیٹرز جس کے ساتھ کال کیا گیا تھا (تقریبا ساختہ پیداوار کے مطابق). آلے کا نتیجہ: آلے کی واپسی کا جواب، دونوں کامیاب نتائج اور غلطی کے پیغامات سمیت. ایجنٹ کا فیصلہ: ایجنٹ نے ایل ایل ایم کے جواب یا آلے کے نتائج پر مبنی کیا فیصلہ کیا ہے (مثال کے طور پر، کیا اگلے قدم انجام دینا ہے، کس جواب کو صارف کو دینا ہے). میٹا ڈیٹا: قدم کے عملدرآمد کا وقت، استعمال کردہ LLM ماڈل، کال کی قیمت (اگر دستیاب ہے)، کوڈ / پروموٹ ورژن. موجودہ ٹریکنگ کے اوزار پر نظر ڈالیں؛ بعض حالات میں، وہ آپ کی زندگی کو بہت آسان بنا دیں گے. LangSmith، مثال کے طور پر، کال کی چیلنجوں، نوٹس، جوابات، اور اوزار کے استعمال کی تفصیلی وضاحت فراہم کرتا ہے. آپ اس طرح کے اوزار جیسے Arize، Weights & Biases، OpenTelemetry، وغیرہ کو اپنی ضروریات کے لئے اپنی مرضی کے مطابق بھی اپ ڈیٹ کرسکتے ہیں. Note: Checklist: تمام ایجنٹ قدموں کو لاگ ان کیا جاتا ہے (آپ کے ورژن کے "گمناموں کی سیٹ"). مرحلے ایک session_id اور ایک step_id کی طرف سے منسلک ہیں. پوری زنجیر کو دیکھنے کے لئے ایک انٹرفیس ہے. LLM کو بھیجنے والے پروموٹ کو کسی بھی مرحلے میں دوبارہ کیا جا سکتا ہے. 14. Test Before You Ship اس وقت تک، آپ کو زیادہ سے زیادہ ممکنہ طور پر کچھ عملی طور پر مکمل حل ہے. یہ کام کرتا ہے، شاید صرف آپ کی خواہش کے طور پر بھی. اس کو فروخت کرنے کے لئے جہاز؟ لیکن ہم اس کو کیسے یقینی بنائیں کام کرتا ہے؟ یہاں تک کہ اگلے چھوٹے اپ ڈیٹ کے بعد بھی؟ جی ہاں، میں ہمیں ٹیسٹ کے موضوع پر لاتا ہوں. Problem: رہتا ہے واضح طور پر، LLM سسٹموں میں اپ ڈیٹس، کسی بھی دوسرے کے طور پر، یہ ایپلی کیشن کوڈ میں تبدیلیوں، ڈیٹا سیٹوں کے لئے اپ ڈیٹنگ کے لئے فائن ٹوننگ یا RAG، بنیادی LLM کا ایک نیا ورژن، یا یہاں تک کہ تھوڑا سا نوٹ ایڈجسٹنگ، اکثر موجودہ منطق اور غیر متوقع، کبھی کبھی کمزور ایجنٹ کے رویے میں غیر متوقع اختیارات کی وجہ سے ہوتا ہے. آپ نے کچھ نہیں کیا ہے، لیکن کارکردگی نے وقت کے ساتھ کم کیا ہے. شاید سپلائر نے اپنے ماڈل کو اپ ڈیٹ کیا ہے، شاید input data کی نوعیت نے تبدیل کر دیا ہے (data drift) - جو کام کیا تھا آج کام نہیں کر سکتا. ایک پروپٹ کے لئے ایک چھوٹا سا تبدیلی بھی قائم منطق کو توڑ سکتا ہے اور پیداوار کو توڑ سکتا ہے. LLMs کے غیر حتمی: جیسا کہ آپ جانتے ہیں، بہت سے LLMs غیر حتمی ہیں (خاص طور پر درجہ حرارت > 0 کے ساتھ)، جس کا مطلب یہ ہے کہ وہ ہر کال پر ایک ہی انٹرویو پر مختلف جوابات پیدا کریں گے. یہ آپ کے لئے آسان ہو جائے گا اگر آپ نے پہلا اصول اپ ڈیٹ کیا ہے، لیکن ڈبگنگ کے لئے ایک مخصوص غلطی کو اپ ڈیٹ کرنا ثابت ڈیٹا اور ریاستوں کے ساتھ بھی مشکل ہوسکتا ہے. پیچیدہ نظاموں میں، ایک واحد عنصر (مثال کے طور پر ایک ماڈل یا ایک نوٹ) کو اپ ڈیٹ کرنا API، ڈیٹا بیس، اوزار، وغیرہ کے ایک سلسلے کے ذریعے کاسکڈ کر سکتا ہے، اور دوسری جگہ کے رویے میں تبدیلی کی وجہ سے. حوصلہ افزائی لیکن ہم پہلے ہی سمجھتے ہیں کہ روایتی ٹیسٹ، جو واضح کوڈ منطق کی تصدیق پر توجہ مرکوز کرتے ہیں، ان مسائل کو مکمل طور پر چھپانے کے قابل نہیں ہیں. ہم ایک پیچیدہ، جامع نقطہ نظر کو ڈیزائن کرنے کی ضرورت ہوگی جس میں بہت سے چیزیں شامل ہوں گی، کلاسیکی اور ڈومین مخصوص حلوں کو مل کر. Solution: متعدد سطحوں کی جانچ پڑتال: نظام کے مختلف پہلوؤں پر توجہ مرکوز کرنے والے مختلف ٹیسٹ کی قسموں کا ایک مجموعہ: انفرادی افعال اور نوٹس کے لئے کم سطح کے یونٹ ٹیسٹ سے پیچیدہ اسکرینوں تک جو ایجنٹ کے آخر تک کام کے عمل اور صارف کے تعامل کی تصدیق کرتے ہیں. LLM رویے اور معیار پر توجہ مرکوز کریں: ٹیسٹنگ کو نہ صرف کارکردگی کی درستگی، بلکہ LLM جوابات کی معیار کی خصوصیات، جیسے متعلقہ، درستگی، مطابقت، نقصان دہ یا متضاد مواد کی موجودگی، اور ہدایات اور ایک مخصوص سٹائل کی پیروی کا اندازہ لگانا چاہئے. رجسٹریشن اور معیار کی جانچ پڑتال جس میں "گولڈ ڈیٹا سیٹ" شامل ہیں جس میں مختلف input مثالیں اور reference (یا قابل قبول رینج) outputs شامل ہیں. CI / CD میں آٹومیشن اور انضمام. انسان-in-the-loop جائزہ لینے: LLM-eval کے مخصوص مرحلے میں میٹرک کی کیبلنگ اور پیچیدہ یا اہم کیسوں کی جائزہ لینے کے لئے انسانی شامل ہونا چاہئے. فوری ترقی اور ٹیسٹنگ کے لئے ایک iterative نقطہ نظر: پروپٹ انجینئرنگ کو ایک iterative عمل کے طور پر علاج کیا جانا چاہئے جہاں ایک پروپٹ کے ہر ورژن کو مکمل طور پر ٹیسٹ کیا جاتا ہے اور انضمام سے پہلے کا جائزہ لیا جاتا ہے. Testing at different levels of abstraction: Individual modules (parsers, validators, API calls) and their integration. Component testing: Isolated testing of prompts on various inputs. Prompt testing: Verifying the logic and interaction of components within an agent. Chain/Agent testing: Evaluating the completion of full user tasks. End-to-end system testing: Checklist: Logic is broken down into modules: functions, prompts, APIs—everything is tested separately and in combination. Response quality is checked against benchmark data, evaluating meaning, style, and correctness. Scenarios cover typical and edge cases: from normal dialogues to failures and provocative inputs. The agent must not fail due to noise, erroneous input, or prompt injections—all of this is tested. Any updates are run through CI and monitored in prod—the agent's behavior must not change unnoticed. Principle 15: Own the Execution Path یہ ایک میٹا اصول ہے؛ یہ اوپر درج کردہ تمام کے ذریعے چلتا ہے. خوش قسمتی سے، آج ہم کسی بھی کام کے لئے آلات اور فریم ورک کے دس ہیں.یہ بہت اچھا ہے، یہ آسان ہے، اور یہ ایک دھمکی ہے. تقریبا ہمیشہ، ایک تیار حل کا انتخاب کرنا ایک آپ کو تیزی اور آسان آغاز ملتا ہے، لیکن آپ کھو جاتے ہیں. . trade-off flexibility, control, and, potentially, security یہ خاص طور پر ایجنٹ کی ترقی میں اہم ہے، جہاں یہ منظم کرنے کے لئے اہم ہے: LLMs کی غیر متوقعیت، تبدیلیوں اور خود اصلاح کے لئے پیچیدہ منطق، being ready for the system's adaptation and evolution, even if its core tasks remain unchanged. مندرجہ ذیل frameworks : وہ آپ کے لئے فیصلہ کرتے ہیں کہ ایجنٹ کو کس طرح کام کرنا چاہئے. یہ ایک پروٹوکول کو سادہ کر سکتا ہے لیکن اس کی طویل مدتی ترقی کو پیچیدہ کر سکتا ہے. inversion of control اوپر بیان کردہ اصولوں میں سے بہت سے آفس کے حل کا استعمال کرتے ہوئے لاگو کیا جا سکتا ہے - اور یہ اکثر درست ہے. غیر متوازن سے زیادہ فراہم کرتا ہے . explicit implementation of the core logic takes a comparable amount of time transparency, manageability, and adaptability اس کے برعکس بھی موجود ہے- سب کچھ لکھنے کی خواہش، یہ بھی ایک غلطی ہے. over-engineering انجینئر اپنے آپ کو منتخب کرتا ہے: جہاں یہ ایک فریم ورک پر بھروسہ کرنے کے لئے مناسب ہے، اور جہاں کنٹرول کو برقرار رکھنے کے لئے اہم ہے. This is why the key is balance. آپ کو یاد رکھنا چاہئے: صنعت اب بھی شکل میں آ رہا ہے. بہت سے آلات موجودہ معیاروں کو ظاہر کرنے سے پہلے پیدا کیے گئے تھے. فردا، وہ قدیم ہوسکتے ہیں - لیکن آج آپ کی آرکیٹیکل میں پکانا محدودیاں باقی رہیں گی. Conclusion نتیجہ ٹھیک ہے، ہم نے 15 اصولوں پر غور کیا ہے جو، تجربے سے پتہ چلتا ہے، "یہ زندہ ہے!" کے ابتدائی حوصلہ افزائی کو یقین میں تبدیل کرنے میں مدد ملتی ہے کہ آپ کے ایل ایل ایم ایجنٹ حقیقی دنیا کے حالات میں ایک مستحکم، پیشہ ور اور مفید طریقے سے کام کرے گا. آپ کو ان میں سے ہر ایک پر غور کرنا چاہئے کہ یہ آپ کے منصوبے پر لاگو کرنے کا مطلب ہے یا نہیں، آخر میں، یہ آپ کا منصوبہ ہے، آپ کا کام، اور آپ کی تخلیق. Key takeaways to carry with you: ایک انجینئرنگ نقطہ نظر اہم ہے: LLMs کی "جادو" پر بھروسہ نہ کریں. ساخت، پیشہ ورانہ، کنٹرول اور ٹیسٹ کی صلاحیت آپ کے بہترین دوست ہیں. LLM ایک طاقتور اجزاء ہے، لیکن اب بھی صرف ایک اجزاء ہے: LLM کو آپ کے نظام کے ایک بہت ذہین، لیکن اس کے باوجود، واحد اجزاء کے طور پر علاج کریں. ریٹائرمنٹ اور پیغامات کامیابی کے لئے کلیدی ہیں: یہ پہلی کوشش میں کامل ایجنٹ پیدا کرنے کے لئے نادر ہے. تجربات، پیمائش، غلطی کا تجزیہ، اور مسلسل بہتر بنانے کے لئے تیار رہیں - دونوں ایجنٹ خود اور آپ کی ترقی کے عمل. کمیونٹی اور کھلی: LLM ایجنٹوں کا میدان تیزی سے ترقی کر رہا ہے. نئے تحقیق، آلات، اور بہترین طریقوں پر نظر رکھیں، اور اپنے تجربات کا اشتراک کریں. آپ کے سامنے ہونے والے مسائل میں سے بہت سے، کسی نے پہلے ہی حل کیا ہے یا اب حل کر رہے ہیں. مجھے امید ہے کہ آپ نے یہاں کچھ نیا اور مفید پایا ہے، اور شاید آپ اپنے اگلے ایجنٹ کو ڈیزائن کرتے وقت اس پر واپس آنا چاہتے ہیں.
