ai-agents-for-beginners
مصنوعی ذہانت ایجنٹس کی پروڈکشن میں: مشاہدہ پذیری اور تشخیص
جب مصنوعی ذہانت کے ایجنٹس تجرباتی پروٹوٹائپس سے حقیقی دنیا کی ایپلیکیشنز میں منتقل ہوتے ہیں، تو ان کے برتاؤ کو سمجھنے، ان کی کارکردگی کی نگرانی کرنے اور ان کے نتائج کو منظم طریقے سے جانچنے کی صلاحیت اہم ہو جاتی ہے۔
سیکھنے کے اہداف
اس سبق کو مکمل کرنے کے بعد، آپ یہ جانیں گے کہ/سمجھیں گے:
- ایجنٹس کی مشاہدہ پذیری اور تشخیص کے بنیادی تصورات
- ایجنٹس کی کارکردگی، لاگت، اور مؤثریت کو بہتر بنانے کی تکنیکیں
- اپنے مصنوعی ذہانت کے ایجنٹس کو منظم طریقے سے کیا اور کیسے جانچیں
- مصنوعی ذہانت کے ایجنٹس کو پروڈکشن میں تعینات کرتے وقت لاگت کو کیسے کنٹرول کریں
- Microsoft Agent Framework کے ساتھ بنائے گئے ایجنٹس میں انسٹرومنٹیشن کیسے کریں
ہدف یہ ہے کہ آپ کو وہ علم فراہم کیا جائے جس سے آپ اپنے “بلیک باکس” ایجنٹس کو شفاف، قابلِ انتظام، اور قابلِ اعتماد نظاموں میں تبدیل کر سکیں۔
نوٹ: محفوظ اور قابل اعتماد AI ایجنٹس تعینات کرنا اہم ہے۔ Building Trustworthy AI Agents سبق بھی دیکھیں۔
ٹریسز اور اسپینز
مشاہدہ پذیری کے اوزار جیسے Langfuse یا Microsoft Foundry عام طور پر ایجنٹ رنز کو ٹریسز اور اسپینز کی شکل میں ظاہر کرتے ہیں۔
- ٹریس ایک مکمل ایجنٹ کام کی نمائندگی کرتا ہے شروع سے ختم تک (جیسے صارف کی استفسار کو ہینڈل کرنا)۔
- اسپینز ٹریس کے اندر انفرادی مراحل ہوتے ہیں (جیسے زبان کے ماڈل کو کال کرنا یا ڈیٹا بازیافت کرنا)۔
مشاہدہ پذیری کے بغیر، AI ایجنٹ “بلیک باکس” محسوس ہو سکتا ہے - اس کی اندرونی حالت اور منطق مبہم ہوتی ہے، جس سے مسائل کی تشخیص یا کارکردگی کی اصلاح مشکل ہو جاتی ہے۔ مشاہدہ پذیری کے ساتھ، ایجنٹس “گلاس باکس” بن جاتے ہیں، جو شفافیت فراہم کرتے ہیں جو اعتماد قائم کرنے اور یقینی بنانے کے لیے ضروری ہے کہ وہ مطلوبہ طریقے سے کام کریں۔
پروڈکشن ماحول میں مشاہدہ پذیری کیوں اہم ہے
AI ایجنٹس کو پروڈکشن ماحول میں منتقل کرنے سے ایک نئی قسم کے چیلنجز اور ضروریات سامنے آتی ہیں۔ مشاہدہ پذیری اب صرف “اچھی سہولت” نہیں بلکہ ایک اہم صلاحیت ہے:
- ڈی بگنگ اور بنیادی سبب کی تجزیہ: جب کوئی ایجنٹ ناکام ہو جائے یا غیر متوقع نتیجہ دے، تو مشاہدہ پذیری کے اوزار اس غلطی کے ماخذ کی نشاندہی کے لیے ٹریسز فراہم کرتے ہیں۔ یہ خاص طور پر پیچیدہ ایجنٹس میں اہم ہے جن میں کئی LLM کالز، ٹول تعاملات، اور مشروط منطق شامل ہو سکتی ہے۔
- تاخیر اور لاگت کا انتظام: AI ایجنٹس اکثر LLMs اور دیگر خارجی APIs پر انحصار کرتے ہیں جن کی بلنگ فی ٹوکن یا کال کی جاتی ہے۔ مشاہدہ پذیری سے ان کالز کی درست ٹریکنگ ممکن ہوتی ہے، جو بہت سست یا مہنگی آپریشنز کی نشاندہی میں مدد دیتی ہے۔ اس سے ٹیم کو پرامپٹس کو بہتر بنانے، زیادہ مؤثر ماڈلز منتخب کرنے، یا ورک فلو کو دوبارہ ڈیزائن کرنے میں مدد ملتی ہے تاکہ آپریشنل لاگتوں کا انتظام کیا جا سکے اور صارف کا تجربہ بہتر بنایا جا سکے۔
- اعتماد، سلامتی، اور تعمیل: کئی ایپلیکیشنز میں یہ یقینی بنانا ضروری ہے کہ ایجنٹس محفوظ اور اخلاقی طریقے سے برتاؤ کریں۔ مشاہدہ پذیری ایجنٹ کی کارروائیوں اور فیصلوں کا آڈٹ ٹریل فراہم کرتی ہے۔ اسے ایسے مسائل کی نشاندہی اور روک تھام کے لیے استعمال کیا جا سکتا ہے جیسے پرامپٹ انجیکشن، نقصان دہ مواد کی تخلیق، یا ذاتی شناخت کے قابل معلومات (PII) کا غلط ہینڈلنگ۔ مثال کے طور پر، آپ ٹریسز کا جائزہ لے کر یہ سمجھ سکتے ہیں کہ ایجنٹ نے کسی مخصوص جواب یا ٹول کو کیوں استعمال کیا۔
- مسلسل بہتری کے لوپس: مشاہدہ پذیری کا ڈیٹا ایک تکراری ترقیاتی عمل کی بنیاد ہے۔ حقیقی دنیا میں ایجنٹس کی کارکردگی کی نگرانی کر کے، ٹیمیں بہتری کے مواقع کی نشاندہی کر سکتی ہیں، ماڈلز کی بہتر ترتیبات کے لیے ڈیٹا جمع کر سکتی ہیں، اور تبدیلیوں کے اثرات کی تصدیق کر سکتی ہیں۔ یہ ایک فیڈ بیک لوپ پیدا کرتا ہے جہاں آن لائن تشخیص سے پروڈکشن کے بصیرتیں آف لائن تجربات اور بہتری کو مطلع کرتی ہیں، جس سے ایجنٹ کی کارکردگی بہتر ہوتی جاتی ہے۔
مانیٹر کرنے کے کلیدی میٹرکس
ایجنٹ کے رویے کو سمجھنے اور مانیٹر کرنے کے لیے مختلف میٹرکس اور سگنلز کو ٹریک کرنا چاہیے۔ اگرچہ مخصوص میٹرکس ایجنٹ کے مقصد کے لحاظ سے مختلف ہو سکتی ہیں، کچھ میٹرکس عالمی سطح پر اہم ہیں۔
یہاں کچھ عام میٹرکس ہیں جو مشاہدہ پذیری کے اوزار مانیٹر کرتے ہیں:
تاخیر: ایجنٹ کتنا تیزی سے جواب دیتا ہے؟ زیادہ انتظار صارف کے تجربے کو منفی طور پر متاثر کرتا ہے۔ آپ کو کاموں اور انفرادی مراحل کے لیے ایجنٹ رنز کو ٹریسنگ کر کے تاخیر ناپنی چاہیے۔ مثال کے طور پر، اگر تمام ماڈل کالز کے لیے ایجنٹ کو 20 سیکنڈ لگتے ہیں تو اسے تیز ماڈل استعمال کر کے یا ماڈل کالز کو متوازی چلانے سے تیز کیا جا سکتا ہے۔
لاگت: ہر ایجنٹ رن کی قیمت کیا ہے؟ AI ایجنٹس LLM کالز اور خارجی APIs پر انحصار کرتے ہیں جن کی بلنگ فی ٹوکن یا کال کی جاتی ہے۔ بار بار ٹولز کے استعمال یا متعدد پرامپٹس لاگت کو تیزی سے بڑھا سکتے ہیں۔ مثال کے طور پر، اگر ایک ایجنٹ محدود معیار میں بہتری کے لیے LLM کو پانچ بار کال کرتا ہے، تو آپ کو اندازہ لگانا چاہیے کہ کیا یہ لاگت جائز ہے یا کالز کی تعداد کم کر کے یا سستا ماڈل استعمال کر کے بچت کی جا سکتی ہے۔ حقیقی وقت کی نگرانی غیر متوقع بلندیوں (جیسے API لوپس کے کیڑے) کی شناخت میں بھی مددگار ہوتی ہے۔
درخواست کی غلطیاں: ایجنٹ کی کتنی درخواستیں ناکام ہوئیں؟ اس میں API غلطیاں یا ناکام ٹول کالز شامل ہو سکتی ہیں۔ پروڈکشن میں ایجنٹ کو مزید مضبوط بنانے کے لیے آپ فال بیک یا ریٹرائز ترتیب دے سکتے ہیں۔ مثال کے طور پر، اگر LLM فراہم کنندہ A غیر فعال ہو جائے تو آپ بیک اپ کے طور پر LLM فراہم کنندہ B استعمال کر سکتے ہیں۔
صارف کی رائے: براہ راست صارف کی تشخیصات نافذ کرنا قیمتی معلومات فراہم کرتی ہے۔ اس میں واضح ریٹنگز (👍تائید/👎عدم تائید، ⭐1-5 ستارے) یا متنی تبصرے شامل ہو سکتے ہیں۔ مستقل منفی رائے آپ کو اطلاع دینی چاہیے کیونکہ یہ اس بات کی علامت ہے کہ ایجنٹ متوقع طور پر کام نہیں کر رہا۔
غیر صریح صارف کی رائے: صارف کے رویے بغیر واضح ریٹنگز کے غیر مستقیم فیڈ بیک فراہم کرتے ہیں۔ اس میں فوری سوال کو دوبارہ بیان کرنا، بار بار استفسار کرنا یا ری ٹرائی بٹن پر کلک کرنا شامل ہو سکتا ہے۔ مثال کے طور پر، اگر آپ دیکھیں کہ صارفین بار بار ایک ہی سوال کرتے ہیں تو یہ اس بات کی علامت ہے کہ ایجنٹ متوقع طریقے سے کام نہیں کر رہا۔
درستگی: ایجنٹ کتنی بار صحیح یا مطلوبہ نتائج فراہم کرتا ہے؟ درستگی کی تعریف مختلف ہو سکتی ہے (مثلاً مسئلہ حل کرنے کی درستگی، معلومات کی بازیافت کی درستگی، صارف کی اطمینان)۔ پہلا قدم یہ تعریف کرنا ہے کہ آپ کے ایجنٹ کے لیے کامیابی کیسا دکھائی دیتی ہے۔ آپ آٹومیٹڈ چیکس، تشخیصی اسکورز، یا ٹاسک مکمل کرنے والے لیبلز کے ذریعے درستگی ٹریک کر سکتے ہیں۔ مثال کے طور پر، ٹریسز کو “کامیاب” یا “ناکام” کے طور پر نشان زد کرنا۔
خودکار تشخیصی میٹرکس: آپ خودکار تشخیصات بھی ترتیب دے سکتے ہیں۔ مثلاً، آپ ایک LLM استعمال کر کے ایجنٹ کے آؤٹ پٹ کو اسکور کر سکتے ہیں کہ آیا یہ مددگار، درست، یا نہیں ہے۔ کئی اوپن سورس لائبریریاں بھی ہیں جو ایجنٹ کے مختلف پہلوؤں کی درجہ بندی میں مدد کرتی ہیں، جیسے RAGAS RAG ایجنٹس کے لیے یا LLM Guard نقصان دہ زبان یا پرامپٹ انجیکشن کا پتہ لگانے کے لیے۔
عملی طور پر، ان میٹرکس کے امتزاج سے AI ایجنٹ کی صحت کا بہترین احاطہ ہوتا ہے۔ اس باب کے مثالی نوٹ بک میں ہم آپ کو دکھائیں گے کہ یہ میٹرکس حقیقی مثالوں میں کیسے دکھائی دیتے ہیں لیکن پہلے ہم جانیں گے کہ ایک معمول کی تشخیصی ورک فلو کس طرح ہوتی ہے۔
اپنے ایجنٹ کی انسٹرومنٹ کریں
ٹریسنگ ڈیٹا جمع کرنے کے لیے، آپ کو اپنے کوڈ میں انسٹرومنٹیشن کرنی ہوگی۔ مقصد یہ ہے کہ ایجنٹ کا کوڈ اس طرح انسٹرومنٹ کیا جائے کہ وہ ٹریسز اور میٹرکس پیدا کرے جو مشاہدہ پذیری پلیٹ فارم کے ذریعے پکڑے، پروسیس اور بصری طور پر دکھائے جا سکیں۔
OpenTelemetry (OTel): OpenTelemetry ایک صنعتی معیار کے طور پر ابھرا ہے جو LLM مشاہدہ پذیری کے لیے ہے۔ یہ ٹیلی میٹری ڈیٹا پیدا کرنے، جمع کرنے، اور ایکسپورٹ کرنے کے لیے APIز، SDKs، اور اوزار فراہم کرتا ہے۔
ایسی بہت سی انسٹرومنٹیشن لائبریریاں ہیں جو موجودہ ایجنٹ فریم ورک کو ریپ کرتی ہیں اور OpenTelemetry اسپینز کو مشاہدہ پذیری کے ٹول میں آسانی سے ایکسپورٹ کرنے کی سہولت دیتی ہیں۔ Microsoft Agent Framework قدرتی طور پر OpenTelemetry کے ساتھ مربوط ہوتا ہے۔ ذیل میں MAF ایجنٹ کی انسٹرومنٹیشن کی مثال دی گئی ہے:
from agent_framework.observability import get_tracer, get_meter
tracer = get_tracer()
meter = get_meter()
with tracer.start_as_current_span("agent_run"):
# ایجنٹ کی عمل درآمد خود بخود ٹریس کی جاتی ہے
pass
اس باب کے مثالی نوٹ بک میں آپ کو دکھایا جائے گا کہ اپنے MAF ایجنٹ کو کیسے انسٹرومنٹ کریں۔
دستی اسپین تخلیق: اگرچہ انسٹرومنٹیشن لائبریریز ایک اچھی بنیادی سطح فراہم کرتی ہیں، اکثر ایسی صورتیں پیش آتی ہیں جہاں مزید تفصیلی یا حسب ضرورت معلومات درکار ہوتی ہیں۔ آپ دستی طور پر اسپینز بنا سکتے ہیں تاکہ کسٹم ایپلیکیشن لاجک شامل کی جا سکے۔ اس سے زیادہ اہم، وہ خودکار یا دستی طور پر بنائے گئے اسپینز کو کسٹم صفات (جنہیں ٹیگز یا میٹا ڈیٹا بھی کہا جاتا ہے) کے ساتھ مالا مال کر سکتے ہیں۔ ان صفات میں کاروباری مخصوص ڈیٹا، درمیانی حسابات، یا کوئی بھی سیاق و سباق شامل ہو سکتا ہے جو ڈی بگنگ یا تجزیہ کے لیے مفید ہو، جیسے user_id, session_id, یا model_version۔
Langfuse Python SDK کے ساتھ دستی طور پر ٹریسز اور اسپینز بنانے کی مثال:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
ایجنٹ کی تشخیص
مشاہدہ پذیری ہمیں میٹرکس دیتی ہے، لیکن تشخیص وہ عمل ہے جو ان ڈیٹا کا تجزیہ کرتا ہے (اور ٹیسٹ کرتا ہے) تاکہ معلوم ہو سکے کہ AI ایجنٹ کس حد تک اچھی کارکردگی دکھا رہا ہے اور اسے کیسے بہتر بنایا جا سکتا ہے۔ دوسرے الفاظ میں، جب آپ کے پاس وہ ٹریسز اور میٹرکس ہوں، تو آپ انہیں ایجنٹ کا جائزہ لینے اور فیصلے کرنے کے لیے کیسے استعمال کرتے ہیں؟
باقاعدہ تشخیص ضروری ہے کیونکہ AI ایجنٹس اکثر غیر متعین ہوتے ہیں اور وقت کے ساتھ (اپ ڈیٹس یا ماڈل کے رویے میں تبدیلی کے ذریعے) تبدیل ہو سکتے ہیں – بغیر تشخیص کے، آپ نہیں جان پائیں گے کہ آپ کا “اسمارٹ ایجنٹ” واقعی اپنا کام ٹھیک کر رہا ہے یا پیچھے ہٹ گیا ہے۔
AI ایجنٹس کے لیے دو قسم کی تشخیصات ہوتی ہیں: آن لائن تشخیص اور آف لائن تشخیص۔ دونوں اہم ہیں اور ایک دوسرے کی تکمیل کرتے ہیں۔ ہم عام طور پر آف لائن تشخیص سے شروع کرتے ہیں، کیونکہ یہ تعیناتی سے پہلے کا کم از کم ضروری قدم ہے۔
آف لائن تشخیص
اس میں ایجنٹ کی محدود ماحول میں جانچ شامل ہوتی ہے، عام طور پر ٹیسٹ ڈیٹاسیٹس کا استعمال کرتے ہوئے، نہ کہ حقیقی صارف کے سوالات کے۔ آپ منظم کردہ ڈیٹاسیٹس استعمال کرتے ہیں جہاں آپ کو متوقع نتیجہ یا درست رویہ معلوم ہوتا ہے، اور پھر اپنے ایجنٹ کو ان پر چلاتے ہیں۔
مثال کے طور پر، اگر آپ نے ریاضی کے لفظی مسائل کا ایجنٹ بنایا ہے تو آپ کے پاس 100 مسائل کا ٹیسٹ ڈیٹاسیٹ ہو سکتا ہے جس کے جوابات معلوم ہوں۔ آف لائن تشخیص عام طور پر ترقی کے دوران کی جاتی ہے (اور CI/CD پائپ لائنز کا حصہ ہو سکتی ہے) تاکہ بہتری کو چیک کیا جا سکے یا پیچھے ہٹنے سے بچا جا سکے۔ فائدہ یہ ہے کہ یہ دہرایا جا سکتا ہے اور آپ کو واضح درستگی کے میٹرکس مل سکتے ہیں کیونکہ آپ کے پاس گراؤنڈ ٹروتھ موجود ہوتا ہے۔ آپ صارف کے سوالات کی نقل کر کے ایجنٹ کے جوابات کو مثالی جوابات کے خلاف ناپ سکتے ہیں یا آٹومیٹڈ میٹرکس استعمال کر سکتے ہیں جیسا کہ اوپر بیان کیا گیا۔
آف لائن تشخیص کے ساتھ ایک کلیدی چیلنج یہ ہے کہ آپ کا ٹیسٹ ڈیٹاسیٹ جامع اور وقت کے ساتھ متعلقہ رہنا چاہیے – ایجنٹ ایک مقررہ ٹیسٹ سیٹ پر اچھا کام کر سکتا ہے لیکن پروڈکشن میں بالکل مختلف سوالات کا سامنا کر سکتا ہے۔ لہٰذا، آپ کو ٹیسٹ سیٹس کو نئے کنارہ کیسز اور حقیقی دنیا کے منظرناموں کی مثالوں کے ساتھ اپ ڈیٹ رکھنا چاہیے۔ چھوٹے “سموک ٹیسٹ” کیسز اور بڑے تشخیصی سیٹ کا امتزاج مفید ہوتا ہے: جلدی چیکس کے لیے چھوٹے سیٹس اور وسیع کارکردگی کے میٹرکس کے لیے بڑے سیٹس۔
آن لائن تشخیص
یہ ایجنٹ کی حقیقی، جیتی جاگتی دنیا میں جانچ کو کہتے ہیں، یعنی پروڈکشن میں اصل استعمال کے دوران۔ آن لائن تشخیص میں ایجنٹ کی حقیقی صارف کے تعاملات پر کارکردگی کی نگرانی اور نتائج کا مسلسل تجزیہ شامل ہوتا ہے۔
مثلاً، آپ کامیابی کی شرح، صارف کی اطمینان کے اسکورز، یا دیگر میٹرکس کو حقیقی ٹریفک پر ٹریک کر سکتے ہیں۔ آن لائن تشخیص کا فائدہ یہ ہے کہ یہ ایسے عوامل کو پکڑتا ہے جو ممکن ہے آپ لیبارٹری میں اندازہ نہ لگا پائیں – آپ وقت کے ساتھ ماڈل ڈرفٹ کو دیکھ سکتے ہیں (اگر ایجنٹ کی مؤثریت ان پٹ پیٹرنز کے بدلنے پر کم ہو جائے) اور غیر متوقع سوالات یا حالات سے آگاہ ہو سکتے ہیں جو آپ کے ٹیسٹ ڈیٹا میں شامل نہیں تھے۔ یہ ظاہر کرتا ہے کہ ایجنٹ جنگل میں کیسے برتاؤ کرتا ہے۔
آن لائن تشخیص میں اکثر پوشیدہ اور واضح صارف کی رائے جمع کی جاتی ہے، جیسا کہ پہلے بحث ہوئی، اور ممکن ہے کہ شیڈو ٹیسٹ یا A/B ٹیسٹ بھی چلائے جائیں (جہاں ایجنٹ کا نیا ورژن پرانا ورژن کے موازنہ کے لیے متوازی چلتا ہے)۔ چیلنج یہ ہے کہ لائیو تعاملات کے لیے قابل اعتماد لیبلز یا اسکورز حاصل کرنا مشکل ہو سکتا ہے – آپ ممکن ہے صارف کی رائے یا بعد کے میٹرکس (جیسے کیا صارف نے نتیجہ پر کلک کیا) پر انحصار کریں۔
دونوں کو ملانا
آن لائن اور آف لائن تشخیصات ایک دوسرے سے متصادم نہیں بلکہ بہت زیادہ تکمیلی ہیں۔ آن لائن مانیٹرنگ سے حاصل ہونے والی بصیرت (مثلاً ایسے نئے قسم کے صارف سوالات جہاں ایجنٹ کمزور ہو) کو آف لائن ٹیسٹ ڈیٹاسیٹس کو بہتر بنانے کے لیے استعمال کیا جا سکتا ہے۔ اس کے برعکس، جو ایجنٹس آف لائن ٹیسٹس میں اچھا کام کرتے ہیں انہیں زیادہ اعتماد کے ساتھ تعینات کیا جا سکتا ہے اور آن لائن مانیٹر کیا جا سکتا ہے۔
واقعی، کئی ٹیمیں ایک لوپ اپناتی ہیں:
آف لائن تشخیص -> تعینات کریں -> آن لائن مانیٹر کریں -> نئے ناکام کیس جمع کریں -> آف لائن ڈیٹاسیٹ میں شامل کریں -> ایجنٹ کو بہتر بنائیں -> دہرائیں۔
عام مسائل
جب آپ AI ایجنٹس کو پروڈکشن میں تعینات کرتے ہیں، تو آپ مختلف چیلنجز کا سامنا کر سکتے ہیں۔ یہاں کچھ عام مسائل اور ان کے ممکنہ حل ہیں:
| مسئلہ | ممکنہ حل |
|---|---|
| AI ایجنٹ کام مستقل طور پر انجام نہیں دے رہا | - AI ایجنٹ کو دیا گیا پرامپٹ بہتر کریں؛ مقاصد واضح کریں۔ - جہاں ممکن ہو کاموں کو ذیلی کاموں میں تقسیم کریں اور متعدد ایجنٹس کے ذریعے ہینڈل کریں۔ |
| AI ایجنٹ مسلسل لوپس میں پھنس رہا ہے | - یقینی بنائیں کہ آپ کے پاس واضح اختتامی شرائط ہوں تاکہ ایجنٹ جان سکے کہ کب عمل ختم کرنا ہے۔ - ایسے پیچیدہ کاموں کے لیے جو منطق اور منصوبہ بندی چاہتے ہیں، بڑے ماڈل استعمال کریں جو منطقی کاموں میں مخصوص ہوں۔ |
| AI ایجنٹ کے ٹول کالز اچھی کارکردگی نہیں دکھا رہے | - ٹول کے نتائج ایجنٹ سسٹم سے باہر ٹیسٹ اور تصدیق کریں۔ - ٹولز کے متعینہ پیرامیٹرز، پرامپٹس، اور ناموں کو بہتر بنائیں۔ |
| کثیر-ایجنٹ سسٹم مستقل کارکردگی دکھانے میں ناکام ہے | - ہر ایجنٹ کو دیا گیا پرامپٹ بہتر کریں تاکہ وہ مخصوص اور ایک دوسرے سے مختلف ہوں۔ - “روٹنگ” یا کنٹرولر ایجنٹ کا استعمال کرتے ہوئے ایک درجہ بندی والا نظام بنائیں جو فیصلہ کرے کہ کون سا ایجنٹ صحیح ہے۔ |
ان میں سے کئی مسائل کو مشاہدہ پذیری کے ذریعے زیادہ مؤثر طریقے سے شناخت کیا جا سکتا ہے۔ پہلے بات کی گئی ٹریسز اور میٹرکس ایجنٹ کے ورک فلو کے بالکل وہیں مقام کی نشاندہی کرتے ہیں جہاں مسائل ہوتے ہیں، جس سے ڈی بگنگ اور اصلاح بہت زیادہ مؤثر ہو جاتی ہے۔
لاگت کا انتظام
یہاں AI ایجنٹس کو پروڈکشن میں تعینات کرنے کی لاگت کو مینج کرنے کے لیے چند حکمت عملیاں دی گئی ہیں:
چھوٹے ماڈلز کا استعمال: چھوٹے لینگویج ماڈلز (SLMs) مخصوص ایجنٹک استعمال کے کیسز میں اچھا کام کر سکتے ہیں اور لاگت میں نمایاں کمی لائیں گے۔ جیسا کہ پہلے ذکر کیا گیا، ایک ایسا ایویلیویشن سسٹم بنانا جو پرفارمنس کا موازنہ بڑے ماڈلز سے کرے، آپ کے استعمال کے کیس میں SLM کی کارکردگی کو سمجھنے کا بہترین طریقہ ہے۔ سادہ کاموں جیسے ارادے کی درجہ بندی یا پیرامیٹر نکالنے کے لیے SLMs استعمال کرنے پر غور کریں، جبکہ پیچیدہ استدلال کے لیے بڑے ماڈلز کو محفوظ رکھیں۔
روٹر ماڈل کا استعمال: ایک مماثل حکمت عملی مختلف ماڈلز اور سائزز کا استعمال ہے۔ آپ ایک LLM/SLM یا سرور لیس فنکشن استعمال کر سکتے ہیں تاکہ درخواستوں کو پیچیدگی کی بنیاد پر بہترین موزوں ماڈلز کی طرف روٹ کیا جائے۔ اس سے لاگت کم کرنے میں مدد ملے گی اور ساتھ ہی صحیح کاموں پر کارکردگی کو یقینی بنایا جائے گا۔ مثال کے طور پر، سادہ سوالات کو چھوٹے، تیز ماڈلز کی طرف بھیجیں، اور صرف مہنگے بڑے ماڈلز کو پیچیدہ استدلالی کاموں کے لیے استعمال کریں۔
جوابات کی کیشنگ: عام درخواستوں اور کاموں کی شناخت کرنا اور ایجنٹک سسٹم سے گزرنے سے پہلے ہی جوابات فراہم کرنا ایک اچھا طریقہ ہے تاکہ ملتی جلتی درخواستوں کی مقدار کم کی جا سکے۔ آپ ایک فلو بھی نافذ کر سکتے ہیں جو یہ پہچانے کہ درخواست آپ کی کیشد شدہ درخواستوں کے ساتھ کتنی مشابہت رکھتی ہے، یہ زیادہ بنیادی AI ماڈلز کے ذریعے کیا جا سکتا ہے۔ یہ حکمت عملی اکثر پوچھے جانے والے سوالات یا عام ورک فلو کے لیے لاگت میں نمایاں کمی کر سکتی ہے۔
آئیے دیکھتے ہیں کہ یہ عملی طور پر کیسے کام کرتا ہے
اس سیکشن کے مثال نوٹ بک میں، ہم دیکھیں گے کہ کیسے ہم آبزرویبلٹی ٹولز کا استعمال کرتے ہوئے اپنے ایجنٹ کی نگرانی اور جائزہ لے سکتے ہیں۔
کیا آپ کے پاس پروڈکشن میں AI ایجنٹس کے بارے میں مزید سوالات ہیں؟
Microsoft Foundry Discord میں شامل ہوں تاکہ دیگر سیکھنے والوں سے ملیں، آفس آورز میں حصہ لیں اور اپنے AI ایجنٹس کے سوالات کے جوابات حاصل کریں۔
پچھلا سبق
اگلا سبق
دستبرداری: یہ دستاویز AI ترجمہ سروس Co-op Translator کے ذریعے ترجمہ کی گئی ہے۔ اگرچہ ہم درستگی کی کوشش کرتے ہیں، براہ کرم اس بات سے آگاہ رہیں کہ خودکار ترجموں میں غلطیاں یا غیر درستیاں ہو سکتی ہیں۔ اصل دستاویز اپنی مادری زبان میں معتبر ماخذ سمجھی جانی چاہئے۔ حساس معلومات کے لیے پیشہ ور انسانی ترجمہ کرنا مناسب ہے۔ ہم اس ترجمے کے استعمال سے پیدا ہونے والی کسی بھی غلط فہمی یا غلط تشریح کے ذمہ دار نہیں ہیں۔