آخر سے آخر تک پیداوار: تصدیق، نگرانی اور اخلاقیات

فائدہ:

• اینڈ ٹو اینڈ آرکیٹیکچر کو ڈیزائن کر سکتا ہے جو آئیڈیا سے پروڈکشن تک LLM فیچر لیتا ہے۔
• تصدیق کے نفاذ، انسانی منظوری، اور ٹریکنگ کی تہوں کو قائم کرتا ہے (لاگنگ/میٹرکس)
• حدود پیداوار کے فیصلوں میں اخلاقیات اور رازداری کے اصولوں کا ترجمہ کرتی ہیں۔

پچھلی دس اکائیوں میں، ہم نے ایک ایک کرکے پرزے سیکھے: درخواست کی ساخت، ٹوکن اکنامکس، فلو، سسٹم پرامپٹ، ماڈل سلیکشن، کیش، بیچ، ایرر مینجمنٹ، محفوظ کلید اور آٹومیشن۔ اس آخری یونٹ میں، ہم حصوں کو یکجا کرتے ہیں اور ایک جامع فن تعمیر قائم کرتے ہیں جو خیال سے پیداوار تک LLM کی خصوصیت رکھتا ہے۔ پیداوار "کام کرنے والے ڈیمو" سے مختلف ہے: تصدیق لازمی ہے، آؤٹ پٹ کی نگرانی کی جانی چاہیے، فیصلوں میں حدود اور اخلاقی اصولوں کو سرایت کرنا چاہیے۔ یہ یونٹ ماڈیول کا کیریئر کالم ہے۔ پچھلے سارے یہاں اکٹھے ہوتے ہیں۔

پروڈکشن آرکیٹیکچر کی پرتیں۔

ایک ٹھوس LLM اہلیت تقریباً پانچ پرتوں پر مشتمل ہوتی ہے:

1. ان پٹ پرت: ڈیٹا اکٹھا کریں، اسے صاف کریں، حساس علاقوں کو ماسک کریں، صرف وہی منتقل کریں جو ضروری ہو۔
2. ماڈل پرت: صحیح ماڈل (یونٹ 5) کو منتخب کریں، سسٹم پرامپٹ اور پیرامیٹرز (یونٹ 4)، کیش (یونٹ 6) سیٹ کریں۔
3. توثیق کی پرت: اگر ضروری ہو تو اسکیما/قاعدہ، ماخذ، اور انسانی منظوری کے خلاف آؤٹ پٹ چیک کریں۔
4. ایکشن لیئر: تصدیق شدہ آؤٹ پٹ کے ساتھ کارروائی کریں؛ اعلی اثر والے اقدامات کیپچر کریں۔
5. مانیٹرنگ پرت: ہر کال، لاگت، غلطی اور معیار کو ریکارڈ اور پیمائش کریں۔

یہ پرتیں ایک پائپ لائن ہیں۔ ہر ایک پچھلے ایک کے آؤٹ پٹ کو چیک کرتا ہے۔

تصدیق کیوں ضروری ہے؟

ایل ایل ایم روانی پیدا کر سکتے ہیں لیکن بعض اوقات غلط آؤٹ پٹ بھی۔ اسے ہیلوسینیشن کہا جاتا ہے: ماڈل ایسی معلومات کو گھڑ سکتا ہے جو بظاہر درست معلوم ہوتی ہے لیکن نہیں ہے۔ چیٹ گیم میں یہ قابل برداشت ہے۔ پیداواری نظام (انوائس، صحت، قانونی، مالیات) میں برداشت نہیں کیا جا سکتا۔ تو یہ نکلا، آنکھیں بند کرکے ناقابل اعتبار؛ تصدیق شدہ ہے.

تصدیقی پرتیں (اثر کے لحاظ سے بڑھتی ہوئی):

• فارمیٹ/اسکیما کی توثیق: کیا آؤٹ پٹ متوقع JSON اسکیما کے مطابق ہے؟ (ساختہ پیداوار بڑی حد تک اس کی ضمانت دیتا ہے۔)
• اصول/منطق کی توثیق: کیا اقدار معقول ہیں؟ (کیا رقم منفی ہے، کیا مستقبل کی تاریخ ہے، کیا زمرہ درست ہے؟)
• ماخذ کی تصدیق: کیا دعویٰ فراہم کردہ دستاویزات پر مبنی ہے؟ کیا ماڈل کچھ کہتا ہے جو دستاویز میں نہیں ہے؟
• انسانی منظوری: ایک ماہر اعلیٰ اثر یا مبہم فیصلوں کا جائزہ لیتا ہے۔

احتیاط: "ماڈل بہت اچھا ہے، مزید تصدیق کی ضرورت نہیں ہے" سب سے خطرناک پیداواری غلطی ہے۔ اس سے کوئی فرق نہیں پڑتا ہے کہ ماڈل کتنا ہی اچھا ہو، تصدیقی پرت اعلیٰ اثر والے فیصلوں میں ایک حفاظتی جال ہے۔ یہاں تک کہ ایک غلط خودکار فیصلہ تمام وقت بچا سکتا ہے۔

ہیومن ان دی لوپ

ضروری نہیں کہ ہر فیصلہ مکمل طور پر خودکار ہو۔ ہیومن ان دی لوپ اپروچ میں، ماڈل کام کو تیز کرتا ہے اور انسان اسے منظور کرتا ہے۔ صحیح توازن فیصلہ کے اثرات اور اس کام پر ماڈل کی وشوسنییتا پر منحصر ہے۔

فیصلے کا اثر

نقطہ نظر

کم (لیبل تجویز، مسودہ)

مکمل آٹومیشن؛ غلطی سستی اور الٹ سکتی ہے۔

میڈیم (روٹنگ، ترجیح)

آٹومیشن + سیمپلنگ کنٹرول

زیادہ (رقم، معاہدہ، صحت، حذف)

انسانی رضامندی لازمی ہے؛ ماڈل صرف تجویز کرتا ہے۔

مانیٹرنگ: آپ اس کا انتظام نہیں کر سکتے جو آپ نہیں دیکھتے ہیں۔

پیداوار میں، آپ کو ہر کال کی نگرانی کرنی چاہیے۔ نگرانی کے بغیر، آپ لاگت، معیار کو بہتر نہیں کر سکتے یا کسی مسئلے کو جلد نہیں پکڑ سکتے۔ ریکارڈ کرنے کے لیے کلیدی میٹرکس:

• استعمال/قیمت: فی درخواست اور کل ٹوکن، ماڈل کی تقسیم، روزانہ کا خرچ۔
• لیٹنسی: اوسط اور بدترین کیس جوابی وقت۔
• خرابی کی شرح: 429/500 شرحیں، دوبارہ کوششیں، ترک کرنا۔
• معیار: تصدیقی پرت پر مسترد شدہ آؤٹ پٹ ریٹ، انسانی منظوری پر اصلاح کی شرح، صارف کی رائے۔

مشورہ: مانیٹرنگ لاگز پر حساس ڈیٹا (ذاتی معلومات، چابیاں) نہ لکھیں۔ رازداری کے دائرہ کار میں لاگز پر غور کریں۔ اگر ضروری ہو تو ماسک لگا کر ریکارڈ کریں (یونٹ 9)۔

اخلاقیات اور حدود

اخلاقی ذمہ داری پیداوار کے فیصلے کا اتنا ہی حصہ ہے جتنا کہ تکنیکی درستگی:

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

کاپی کرنے کے قابل ٹیمپلیٹس

# توثیق چیک لسٹ (آؤٹ پٹ جنریشن کے بعد) 1) کیا اسکیما درست ہے؟ (سٹرکچرڈ آؤٹ پٹ کی توثیق) 2) کیا اقدار معنی رکھتی ہیں؟ (قاعدہ چیک: حد، تاریخ، اینوم)3) کیا دعویٰ ماخذ پر مبنی ہے؟ (اگر دستاویز میں نہیں ہے تو مسترد کریں) 4) کیا اثر زیادہ ہے؟ → انسانی منظوری کے لیے بھیجیں

# سسٹم پرامپٹ جو ماخذ پر انحصار کرنے پر مجبور کرتا ہے صرف فراہم کردہ دستاویز میں موجود معلومات پر انحصار کرتا ہے۔ ایسی کوئی بھی چیز شامل نہ کریں جو دستاویز میں نہ ہو۔ اگر کوئی معلومات دستاویز میں نہیں ہے تو، "دستاویز میں نہیں ملا" لکھیں۔ کبھی بھی چیزوں کا اندازہ نہ لگائیں اور نہ بنائیں۔

# انسانی منظوری کی حد (فیصلے کا قاعدہ) IF فیصلہ_ٹائپ میں [پیسہ، معاہدہ، حذف، صحت] → انسانی منظوری لازمیIF ماڈل_ٹرسٹ < حد یا توثیق "غیر یقینی" → انسانی منظوری کو جمع کروائیں

# ٹریس لاگ ٹیمپلیٹ (حساس ڈیٹا کو لکھنا)

کمزور فوری / مضبوط اشارہ (پیداوار کی وشوسنییتا)

# کمزور (کوئی تصدیق نہیں، کوئی ذریعہ نہیں، خود بخود لاگو ہوتا ہے) اس درخواست کا جائزہ لیں، رقم کی واپسی کا فیصلہ کریں اور درخواست دیں۔

# مضبوط (ذریعہ پر مبنی، سفارش تیار کرتا ہے، انسانی منظوری پر چھوڑ دیتا ہے) صرف واپسی کی پالیسی دستاویز کی بنیاد پر اس واپسی کی درخواست کا اندازہ کریں۔ جواز کے ساتھ فیصلہ تجویز کریں لیکن عمل درآمد نہ کریں: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}۔اگر پالیسی دستاویز میں کوئی واضح بنیاد نہیں ہے تو "غیر واضح" دیں۔ ایک نمائندہ حتمی فیصلے کی منظوری دے گا۔

طاقتور ورژن؛ یہ فیصلے کو ماخذ سے منسوب کرتا ہے، ماڈل کو "کرنے والے" کے بجائے "مشورہ دینے والے" کے طور پر رکھتا ہے اور انسانی منظوری کے پیچھے اعلیٰ اثر والے قدم رکھتا ہے۔ یہ پیداوار کی وشوسنییتا کا جوہر ہے.

تین چھوٹے کیسز

کیس 1 — جس دن تصدیقی پرت محفوظ ہوئی۔ ایک فن ٹیک کے پاس ماڈل کی درجہ بندی لین دین کی تفصیل اور خودکار اکاؤنٹنگ ریکارڈز تیار کرنا تھا۔ انہوں نے اصول کی توثیق شامل کی: ایک بار جب ماڈل نے رقم کو غلط طریقے سے آؤٹ پٹ کیا (دستاویز میں 1,250 کی بجائے 12,500)، "رقم دستاویز سے میل نہیں کھاتی" کے اصول نے آؤٹ پٹ کو مسترد کر دیا اور ریکارڈ انسان کے پاس گر گیا۔ اگر کوئی تصدیق نہ ہوئی تو، غلط ریکارڈ خاموشی سے سسٹم میں داخل ہو جائے گا۔

کیس 2 - مفرور نگرانی کے ذریعے پکڑا گیا۔ ساس کی ایک ٹیم نے ایک مانیٹرنگ پینل قائم کیا تھا۔ ایک صبح روزانہ کی قیمت تین گنا بڑھ گئی۔ لاگز سے یہ دیکھا گیا کہ ایک کلائنٹ نے ایک لوپ میں داخل کیا اور ہزاروں بار ایک ہی درخواست بھیجی۔ انہوں نے کوٹہ اور تخفیف کا اضافہ کیا۔ گھنٹوں میں مسئلہ حل ہو گیا۔ ٹریکنگ کے بغیر، مہینے کے آخر میں بل ایک سرپرائز ہوگا۔

کیس 3 - حد کو قبول کرنا۔ ایک ہیلتھ کیئر اسٹارٹ اپ مکمل طور پر خود بخود تشخیص کی سفارش کرنے اور اسے مریض کو دکھانے کا منصوبہ بنا رہا تھا۔ اخلاقیات اور ذمہ داری کے جائزے میں، انہوں نے فیصلہ کیا کہ یہ حدود سے باہر ہے: ماڈل صرف ایک ڈاکٹر کو خلاصہ اور ممکنہ نکات فراہم کرتا ہے، ڈاکٹر تشخیص کرتا ہے۔ کسی کام کو خودکار نہ کرنا بھی ایک بالغ ڈیزائن کا فیصلہ ہے۔

عام غلطیاں

• توثیق کو چھوڑنا: "ماڈل اچھا ہے" کہہ کر آنکھیں بند کرکے آؤٹ پٹ کا اطلاق کرنا۔
• خودکار اعلیٰ اثر والے فیصلے: رقم/صحت/قانون میں انسانی منظوری ضروری ہے۔
• نگرانی نہیں کرنا: قیمت اور معیار کے مسائل دیر سے دریافت ہوتے ہیں۔
• لاگز پر حساس ڈیٹا لکھنا: رازداری کی خلاف ورزی؛ اسے ماسک لگا کر محفوظ کریں۔
• ماخذ پر بھروسہ کرنے کی کوشش نہیں کرنا: ماڈل وہ چیز بنا سکتا ہے جو دستاویز میں نہیں ہے۔
• حدود کو نظر انداز کرنا: کچھ کاموں کو خودکار نہ کرنا درست فیصلہ ہے۔ شفافیت اور ذمہ داری آپ کی ہے۔

گہرا: ریلیز مینجمنٹ، رول بیک، اور انکریمنٹل تعیناتی۔

ایل ایل ایم کی خصوصیت کو پروڈکشن میں لے جانا اسے ترتیب دینے اور اسے بھول جانے کے بارے میں نہیں ہے۔ وقت کے ساتھ محفوظ طریقے سے لائیو سسٹم میں ترمیم کرنا ہے۔ اس کے تین ستون ہیں۔

ورژننگ آپ کا سسٹم پرامپٹ، ماڈل کا انتخاب، اور توثیقی اصول وقت کے ساتھ بدلتے رہتے ہیں۔ ہر ایک اہم تبدیلی کو ورژن بنائیں اور ریکارڈ کریں کہ کون سا ورژن لائیو ہے۔ اگر ایک دن معیار گر جائے تو "ہم نے کیا بدلا؟" آپ کو منٹوں میں سوال کا جواب دینے کے قابل ہونا چاہئے۔ بغیر ورژن کے نظام میں، رجعت کی اصل وجہ تلاش کرنے میں دن لگتے ہیں۔

رول بیک۔ اگر کوئی نیا پرامپٹ یا ماڈل لائیو میں توقع سے زیادہ برا برتاؤ کرتا ہے، تو آپ کو جلدی سے پچھلے، معروف ورژن پر واپس جانے کے قابل ہونا چاہیے۔ رول بیک پلان کے بغیر تبدیلی لائیو رسک کو آنکھ بند کر کے قبول کرنا ہے۔ "میں نے کچھ بدلا، یہ خراب ہو گیا، میں واپس نہیں جا سکتا" سب سے مہنگا پروڈکشن منظرنامہ ہے۔

بتدریج رول آؤٹ۔ ایک ساتھ تمام ٹریفک میں تبدیلی کو لاگو کرنے کے بجائے، آپ اسے پہلے ایک چھوٹے فیصد (مثلاً 5%) میں رول آؤٹ کریں اور میٹرکس (معیار، لاگت، غلطیاں) کی نگرانی کریں۔ اگر یہ اچھا ہے، تو آپ فیصد بڑھاتے ہیں۔ اگر یہ خراب ہے، تو آپ اسے صرف ایک چھوٹے سے متاثرہ حصے کے ساتھ واپس حاصل کریں گے۔ یہ خطرے کو بہت حد تک محدود کرتا ہے۔

یہ تینوں طریق کار تمام پچھلی اکائیوں کی تکنیکوں کو یکجا کرتے ہیں: eval (یونٹ 5) پہلے سے تبدیلی کے اقدامات کرتے ہیں، نگرانی (یہ یونٹ) پھیلاؤ کے دوران ابتدائی وارننگ دیتی ہے، تصدیقی پرت غلط نتائج کو پکڑتی ہے اس سے پہلے کہ وہ قابل عمل ہو جائیں۔ پیداوار ایک واحد درست سیٹ اپ نہیں ہے؛ یہ ایک مسلسل نظم و ضبط ہے جو پیمائش کرتا ہے، نگرانی کرتا ہے اور اعتماد کے ساتھ بدل سکتا ہے۔ اس نظم و ضبط کو قائم کرنے کے لیے پورا ماڈیول آپ کے لیے ہے۔

خلاصہ میں

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

درخواست کا کام

ایک LLM فیچر اینڈ ٹو اینڈ ڈیزائن کریں۔ (1) اپنے مخصوص کام کے لیے پانچ تہوں (ان پٹ، ماڈل، تصدیق، کارروائی، نگرانی) کو پُر کریں۔ (2) اثر سے نشان زد کریں کہ کن فیصلوں کو انسانی منظوری کی ضرورت ہوگی۔ (3) کم از کم تین تصدیقی چیک لکھیں (اسکیما، اصول، ماخذ)۔ (4) ان کلیدی میٹرکس کا تعین کریں جنہیں آپ ٹریک کریں گے اور کن چیزوں کو آپ لاگ نہیں کریں گے۔ (5) ایک حد اور اخلاقی اصول لکھیں جسے آپ اس خصوصیت میں قبول کرتے ہیں۔

چیک لسٹ

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

ماڈیول امتحان

1. LLM چیٹ API میں 'سسٹم' کا کردار کیا کرتا ہے؟

• A) ماڈل کو مستقل ہدایات اور رویے کے اصول دیتا ہے جو پوری گفتگو میں لاگو ہوتے ہیں ✔
• ب) صارف کے لکھے ہوئے آخری سوال کو رکھتا ہے۔
• C) ماڈل کے ذریعہ تیار کردہ ردعمل کو اسٹور کرتا ہے۔
• D) API کلید کو خفیہ کرتا ہے۔

تفصیل: نظام کا کردار ماڈل کو مستقل ہدایات، شخصیت، اور قواعد دیتا ہے جو پوری گفتگو میں لاگو ہوتے ہیں۔ یہ ایک اعلیٰ سطحی ری ڈائریکٹ ہے، جو صارف کے پیغامات سے الگ ہے۔

2. API کی درخواست میں ہر بار گفتگو کی سرگزشت (پچھلے پیغامات) کو دوبارہ کیوں بھیجا جاتا ہے؟

• A) بیک اپ لینا ضروری ہے کیونکہ سرور تاریخ کو حذف کرتا ہے۔
• ب) API کالیں بے وطن ہیں۔ ✔ ہر درخواست پر سیاق و سباق کو دوبارہ بھیجا جاتا ہے کیونکہ ماڈل کو تاریخ یاد نہیں ہے۔
• C) صرف انوائسنگ کے لیے درکار ہے، اس کا ماڈل پر کوئی اثر نہیں ہے۔
• D) جواب کو سست کرنے سے بچنے کے لیے تاریخ بھیجنا لازمی ہے۔

وضاحت: LLM API کالیں بے وطن ہیں۔ ماڈل کو پچھلے راؤنڈ یاد نہیں ہیں، لہذا سیاق و سباق کو محفوظ رکھنے کی ہر درخواست پر تمام متعلقہ تاریخ کو دوبارہ بھیج دیا جاتا ہے۔

3. LLM قیمتوں میں 'ٹوکن' کیا ہے؟

• A) API میں لاگ ان کرنے کے لیے ایک بار استعمال ہونے والا پاس ورڈ
• ب) ہر درخواست پر ایک مقررہ فیس ادا کی جاتی ہے۔
• ج) سب سے چھوٹی اکائی جس میں ماڈل ٹیکسٹ پر کارروائی کرتا ہے۔ عام طور پر لفظ کے حصے سے مطابقت رکھتا ہے ✔
• D) ایک یونٹ جو صرف آؤٹ پٹ کی لمبائی کی پیمائش کرتا ہے۔

تفصیل: ٹوکن سب سے چھوٹی اکائی ہے جس میں ماڈل ٹیکسٹ پر کارروائی کرتا ہے۔ یہ عام طور پر کسی لفظ کے ٹکڑے سے مطابقت رکھتا ہے، اور ان پٹ اور آؤٹ پٹ دونوں کو ٹوکن کی تعداد کی بنیاد پر چارج کیا جاتا ہے۔

4. زیادہ تر LLM فراہم کنندگان میں آؤٹ پٹ ٹوکن ان پٹ ٹوکن سے زیادہ مہنگے کیوں ہیں؟

• A) آؤٹ پٹ ٹوکن ہمیشہ ان پٹ سے لمبے ہوتے ہیں۔
• ب) ان پٹ ٹوکن مفت ہیں۔
• C) آؤٹ پٹ ٹوکن انٹرنیٹ پر دو بار بھیجے جاتے ہیں۔
• D) یونٹ کی قیمت زیادہ ہے کیونکہ آؤٹ پٹ جنریشن کے لیے ہر ٹوکن کے لیے اضافی حساب کی ضرورت ہوتی ہے ✔

تفصیل: آؤٹ پٹ ٹوکن میں سے ہر ایک ماڈل کو مرحلہ وار جنریشن انجام دینے کی ضرورت ہوتی ہے۔ یہ پیداواری لاگت ان پٹ کو ایک ساتھ پروسیس کرنے سے زیادہ ہے، اس لیے آؤٹ پٹ یونٹ کی قیمت عام طور پر زیادہ ہوتی ہے۔

5. کس صورت حال میں سٹریمنگ کا استعمال سب سے زیادہ فائدہ مند ہے؟

• A) طویل جوابات میں؛ سمجھی جانے والی تاخیر کو کم کرتا ہے اور ٹائم آؤٹ کو روکتا ہے ✔
• ب) صرف بہت مختصر، ایک لفظی جوابات
• C) لاگت کو صفر تک کم کرنا
• D) API کلید کو چھپانے کے لیے

تفصیل: طویل جوابات میں، سٹریمنگ پہلے الفاظ کو فوری طور پر ظاہر کر کے سمجھی جانے والی تاخیر کو کم کرتی ہے اور بڑی max_tokens قدروں پر HTTP ٹائم آؤٹ کو روکتی ہے۔

6. جدید ماڈلز میں 'کوشش' پیرامیٹر میں اضافہ عام طور پر کیا اثر انداز ہوتا ہے؟

• ا) جواب کو ہمیشہ مختصر کریں۔
• ب) API کلید کو خود بخود گھماتا ہے۔
• C) یہ صرف ان پٹ ٹوکن کی قیمت کو کم کرتا ہے۔
• D) سوچ کی گہرائی اور ٹوکن اخراجات میں اضافہ؛ یہ معیار کو بہتر بنا سکتا ہے، لیکن یہ تاخیر اور لاگت کو بھی بڑھاتا ہے ✔

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

7. عام طور پر ایک سادہ، اعلی حجم کی درجہ بندی کے کام کے لیے سب سے زیادہ سرمایہ کاری مؤثر طریقہ کیا ہے؟

• ا) ہمیشہ سب سے مہنگا اور طاقتور ماڈل استعمال کریں۔
• ب) ہر درخواست کے لیے ایک ہی وقت میں تمام ماڈلز کو کال کرنا
• ج) سب سے ہلکے/سستے ماڈل کا انتخاب کرنا جو کام کو تھوڑا سا ایول کے ساتھ تصدیق کرکے پورا کرتا ہے ✔
• D) max_tokens کی قدر کو غیر ضروری طور پر بہت زیادہ رکھنا

وضاحت: اگر کام پیچیدہ نہیں ہے، تو ایک تیز اور سستا ماڈل کا انتخاب کرنا جو کام کو آسانی سے پورا کر سکے (مثلاً ہائیکو کلاس) مہنگا اور طاقتور ماڈل استعمال کرنے کی بجائے لاگت میں نمایاں کمی آئے گی۔

8. کس منظر نامے میں پرامپٹ کیشنگ لاگت کو سب سے زیادہ کم کرتی ہے؟

• A) جب بہت سی درخواستوں میں ایک بڑا اور مقررہ سیاق و سباق بار بار استعمال کیا جاتا ہے ✔
• ب) جب ہر درخواست کے ساتھ بالکل مختلف متن بھیجا جاتا ہے۔
• ج) جب صرف ایک درخواست کی جاتی ہے۔
• D) آؤٹ پٹ ٹوکن کو کم کرنا

تفصیل: کیشنگ ایک سابقہ میچ ہے۔ ایسی صورتوں میں جہاں ایک بڑا، ناقابل تغیر سیاق و سباق (سسٹم پرامپٹ، دستاویزات) کو کئی درخواستوں میں دوبارہ استعمال کیا جاتا ہے، کیشے سے پڑھنا پوری قیمت کا ایک چھوٹا حصہ (~0.1x) ہے۔

9. مجھے پرامپٹ میں کیسے ترمیم کرنی چاہیے تاکہ پرامپٹ کیش ہٹ جائے؟

• A) متغیر مواد کو شروع میں اور مقررہ مواد کو آخر میں رکھنا
• ب) ہر درخواست کے لیے سسٹم پرامپٹ میں موجودہ تاریخ اور وقت شامل کریں۔
• ج) شروع میں فکسڈ مواد (سسٹم پرامپٹ، دستاویزات) اور آخر میں متغیر مواد ڈالنا ✔
• D) ہر درخواست کے ساتھ ٹول لسٹ کی ترتیب کو تبدیل کرنا

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

10. کس قسم کے کام کے بوجھ کے لیے بیچ پروسیسنگ بہترین ہے؟

• A) لائیو چیٹ جہاں صارف کو اسکرین پر فوری جواب کی توقع ہوتی ہے۔
• ب) صرف ایک مختصر سوال
• C) API کلید پیدا کرنا
• D) وہ نوکریاں جو تاخیر برداشت کرنے والی، بڑی مقدار میں اور فوری نتائج کی ضرورت نہیں ✔

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

11. کس چیز کو اعتماد کے ساتھ میچ کرنے کے لیے استعمال کیا جاتا ہے جس کی درخواست کے نتائج کسی بیچ سے تعلق رکھتے ہیں؟

• A) درخواستوں کا آرڈر (پوزیشن) بھیجنا
• ب) جوابات کی لمبائی
• C) API کلید کے آخری 4 ہندسے
• D) ہر درخواست کو ایک منفرد custom_id دیا جاتا ہے ✔

تبصرہ: بلک نتائج جمع کرانے کے آرڈر سے مختلف ترتیب میں واپس کیے جا سکتے ہیں۔ لہذا یہ ضروری ہے کہ نتائج کو ID کے مطابق ملایا جائے، نہ کہ محل وقوع سے، ہر درخواست کو دی گئی ایک منفرد custom_id کے ساتھ۔

12. جب آپ کو API سے 429 (شرح کی حد) کی غلطی موصول ہوتی ہے تو کیا تجویز کیا جاتا ہے؟

• A) ایک ہی وقت میں بہت سی مزید درخواستیں بھیج کر مجبور کرنا
• ب) دوبارہ کوشش کے بعد سرخی ✔ کے بعد، ایکسپونینشل بیک آف کے ساتھ دوبارہ کوشش کرنا
• C) درخواست کو مکمل طور پر منسوخ کریں اور صارف کو کریش کے طور پر غلطی دکھائیں۔
• D) API کلید کو تبدیل کرنا

وضاحت: 429 دوبارہ کوشش کرنے والی غلطی ہے۔ درست نقطہ نظر یہ ہے کہ دوبارہ کوشش کے بعد ہیڈر کا احترام کرتے ہوئے ایکسپونینشل بیک آف کے ساتھ دوبارہ کوشش کریں۔ زیادہ تر سرکاری SDKs یہ خود بخود کرتے ہیں۔

13. درج ذیل میں سے کون سے HTTP ایرر کوڈز کو عام طور پر دوبارہ کوشش کے قابل سمجھا جاتا ہے؟

• A) 400 (غلط درخواست)
• B) 401 (تصدیق کی غلطی)
• C) 529 (سرور اوورلوڈ) ✔
• D) 404 (نہیں ملا)

وضاحت: 429 (رفتار کی حد)، 500 (سرور کی خرابی) اور 529 (اوورلوڈ) عارضی خرابیاں ہیں اور بیک آف کرکے دوبارہ کوشش کی جا سکتی ہیں۔ 400 اور 401 جیسی خرابیاں درخواست/شناخت کے مسائل ہیں۔ دوبارہ کوشش کرنے سے یہ حل نہیں ہوگا۔

14. API کیز کو منظم کرنے کا مندرجہ ذیل میں سے کون سا محفوظ طریقہ ہے؟

• A) ماحول کے متغیر/ پوشیدہ مینیجر میں ذخیرہ کرنا، اسے کوڈ میں شامل نہ کرنا اور باقاعدگی سے گھومنا ✔
• ب) کلید کو براہ راست سورس کوڈ میں لکھیں اور اسے ریپوزٹری کو بھیجیں۔
• C) کلید کو کلائنٹ سائڈ (براؤزر) جاوا اسکرپٹ میں ڈالنا
• D) ای میل کے ذریعے پوری ٹیم کے ساتھ ایک کلید کا اشتراک کرنا

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

15. رازداری کے معاملے میں آٹومیشن ٹول (n8n، Zapier، Make) کے ساتھ LLM انضمام کا بہترین طریقہ کیا ہے؟

• A) تمام خام ڈیٹا ماڈل کو بھیجنا، چاہے یہ ضروری نہ ہو۔
• ب) API کلید کو فلو سٹیپ کے اندر سادہ متن میں لکھنا
• C) حساس ڈیٹا کو کم سے کم اور ماسک کرنا اور کلید کو خفیہ اسناد کے طور پر محفوظ کرنا ✔
• D) ذاتی ڈیٹا کو بہاؤ کی تاریخ میں مستقل طور پر رکھنا

تفصیل: جیسا کہ آٹومیشن میں داخل ہونے والا ڈیٹا تھرڈ پارٹی سسٹمز اور ماڈل سے گزرتا ہے، حساس/ذاتی ڈیٹا کو کم سے کم، نقاب پوش اور صرف مطلوبہ فیلڈز بھیجنے کی ضرورت ہوتی ہے۔ API کلید کو بھی ٹول کے اندر خفیہ اسناد کے طور پر محفوظ کیا جاتا ہے۔

16. ایل ایل ایم پر مبنی پروڈکشن فیچر میں آؤٹ پٹ کی توثیق کیوں لازمی ہے؟

• A) صرف فارمیٹنگ کی ضرورت ہے کیونکہ ماڈل کبھی غلطی نہیں کرتا ہے۔
• ب) کیونکہ ماڈل سیال طریقے سے لیکن بعض اوقات غلط طریقے سے پیدا کر سکتا ہے۔ وسائل اور انسانی منظوری کے ساتھ اسکیما/ اصول کا آڈٹ ہونا ضروری ہے ✔
• ج) توثیق سے گریز کیا جانا چاہئے کیونکہ اس سے صرف لاگت میں اضافہ ہوتا ہے۔
• D) تصدیق صرف ٹوکن کی تعداد کو کم کرنے کے لیے ہے۔

تفصیل: LLMs روانی پیدا کر سکتے ہیں لیکن بعض اوقات غلط (فریب) آؤٹ پٹ؛ لہذا یہ اعلی اثرات کے فیصلوں میں سامنے آیا؛ اسکیما/قواعد کی جانچ پڑتال، ماخذ کی توثیق، اور ضرورت پڑنے پر انسانی منظوری کے ذریعے اس کا آڈٹ کیا جانا چاہیے۔