فائدہ:
- اس بات کی وضاحت کر سکتا ہے کہ سٹریمنگ کیا ہے، ایونٹ کی اقسام اور اس کی ضرورت کیوں ہے۔
- max_tokens وقت ختم ہونے اور 128K طویل آؤٹ پٹ تعلقات کو سمجھتا ہے۔
- کام کے بوجھ کے مطابق سٹریمنگ اور نان سٹریمنگ درخواستوں کے درمیان صحیح انتخاب کر سکتے ہیں۔
آپ نے دیکھا ہوگا کہ چیٹ انٹرفیس میں جواب لفظ بہ لفظ "ٹائپ" ہوتا ہے۔ یہ کوئی بصری پنپنا نہیں ہے۔ یہ سٹریمنگ نامی تکنیک کا نتیجہ ہے اور اکثر پیداواری معیار کے LLM انضمام کے لیے لازمی ہوتا ہے۔ اس یونٹ میں، آپ سیکھیں گے کہ بہاؤ کیا ہے، یہ کن واقعات پر مشتمل ہے، اس کا طویل آؤٹ پٹ اور ٹائم آؤٹ کے ساتھ تعلق، اور فلو کو کب استعمال کرنا ہے اور کب نہیں۔ ہم ایک پیشہ ور کے حقیقی کاموں کے ذریعے موضوع کا احاطہ کریں گے — لائیو اسسٹنٹ، طویل رپورٹ جنریشن، بیچ پروسیسنگ۔
بہاؤ کیا ہے؟
نان اسٹریمنگ (مطابقت پذیر) درخواست کے ساتھ، آپ اس وقت تک انتظار کرتے ہیں جب تک کہ ماڈل پورا جواب نہیں دے دیتا۔ جب جواب تیار ہوتا ہے، تو یہ ایک ٹکڑے میں آتا ہے۔ اسٹریمنگ کی درخواست میں، سرور ماڈل کے تیار ہونے کے ساتھ ہی جواب ٹکڑے ٹکڑے کر کے بھیجتا ہے۔ تکنیکی طور پر، یہ سرور کے بھیجے گئے واقعات کے ساتھ کیا جاتا ہے (SSE — Server-Sent Events، ایک ایسا طریقہ جس میں سرور ایک کھلے کنکشن پر یکے بعد دیگرے چھوٹے واقعات بھیجتا ہے)۔
صارف کے تجربے میں فرق واضح ہو جاتا ہے: 8 سیکنڈ کے جواب پر، نان اسٹریم صارف 8 سیکنڈ کے لیے خالی اسکرین کو گھورتا ہے۔ سٹریمنگ صارف پہلے الفاظ کو ~0.5 سیکنڈ میں دیکھتا ہے اور متن بہنا شروع ہو جاتا ہے۔ سمجھی جانے والی تاخیر — صارف کو محسوس ہونے والا انتظار— کافی حد تک کم ہو گیا ہے، جبکہ کل وقت میں کوئی تبدیلی نہیں ہوئی ہے۔
واقعہ کے بہاؤ کی اقسام
بہاؤ واقعات کا ایک سلسلہ ہے۔ تصوراتی طور پر، ایک عام بہاؤ اس طرح جاتا ہے:
واقعہ
مطلب
پیغام_شروع
جواب شروع ہوا؛ ہیڈر کی معلومات جیسے کہ ماڈل اور ID آچکی ہے۔
مواد_بلاک_شروع
مواد کا ایک بلاک (مثلاً متن) شروع ہوا۔
مواد_بلاک_ڈیلٹا
متن کا ایک چھوٹا سا ٹکڑا (ڈیلٹا) پہنچا؛ آپ یہ جمع کرتے ہیں
content_block_stop
بلاک مکمل
پیغام_ڈیلٹا
اپ ڈیٹ شدہ اختتامی معلومات جیسے stop_reason اور استعمال
پیغام_روکیں۔
جواب دیں۔
آپ کا کوڈ ترتیب وار متن کے ٹکڑوں کو content_block_delta ایونٹس میں جوڑتا ہے۔ آپ کا اختتام وہی متن کے ساتھ ہوتا ہے جس طرح نان اسٹریم شدہ جواب ہوتا ہے۔ استعمال (ٹوکن نمبرز) عام طور پر بہاؤ کے اختتام پر واضح ہوتے ہیں - جب بہاؤ ختم ہو جاتا ہے تو آپ لاگت پر نظر رکھتے ہیں۔
ٹپ: زیادہ تر آفیشل SDKs (سافٹ ویئر ڈیولپمنٹ کٹ — فراہم کنندہ کی ریڈی میڈ لائبریری) ایک مددگار فراہم کرتے ہیں جو آپ کے لیے سلسلہ جمع کرتا ہے (جیسے stream.get_final_message())۔ آپ کو تمام ٹریکس کو دستی طور پر منظم کرنے کی ضرورت نہیں ہے۔ اگر آپ مکمل متن چاہتے ہیں تو یہ مددگار استعمال کریں، انفرادی واقعات پر کارروائی کریں لیکن لائیو پرنٹنگ کے لیے۔
طویل جوابات، max_tokens اور ٹائم آؤٹ
سلسلہ بندی کی دوسری اور زیادہ تکنیکی وجہ ٹائم آؤٹ ہے۔ اگر HTTP کی درخواست ایک مخصوص مدت کے اندر مکمل نہیں ہوتی ہے، تو کلائنٹ کنکشن چھوڑ دیتا ہے۔ جب آپ ماڈل سے بڑے آؤٹ پٹ کی درخواست کرتے ہیں (مثلاً 40,000 ٹوکنز کی رپورٹ)، نان فلو کال اس حد سے تجاوز کر سکتی ہے اور وقت ختم ہو سکتا ہے — درخواست ناکام ہو جائے گی، اور آپ کو پیدا ہونے والے ٹوکنز کے لیے ادائیگی کرنا پڑے گی۔
جدید ماڈلز ایک درخواست میں 128,000 ٹوکن تک آؤٹ پٹ کر سکتے ہیں۔ لیکن انگوٹھے کا اصول واضح ہے: اگر `max_tokens` قدر زیادہ ہے (تقریباً 16,000 سے اوپر) تو اسٹریمز کا استعمال کریں۔ سلسلہ بندی کنکشن کو زندہ رکھتی ہے اور ٹائم آؤٹ کو روکتی ہے۔ آپ کو فوری طور پر ترقی بھی نظر آئے گی۔
- `max_tokens`: زیادہ سے زیادہ آؤٹ پٹ ٹوکن جو ماڈل تیار کر سکتا ہے۔ ایک سخت چھت. اگر کوئی خلل واقع ہوتا ہے، تو stop_reason max_tokens واپس کر دیا جاتا ہے۔
- سیاق و سباق کی ونڈو: وہ ونڈو جس میں ان پٹ + آؤٹ پٹ کا مجموعہ فٹ ہونا ضروری ہے۔ max_tokens آؤٹ پٹ کی حد ہے۔ دونوں کو مکس نہ کریں۔
احتیاط: بڑے max_tokens کے ساتھ غیر روانی کی درخواستوں کو پھینکنا پیداوار میں ایک کلاسک غلطی ہے۔ جواب کے بغیر، کنکشن گر جاتا ہے، صارف کو ایک غلطی نظر آتی ہے، اور ٹوکن کی قیمت ضائع ہو جاتی ہے۔ لمبی آؤٹ پٹ = ندی۔
کب بہنا ہے اور کب نہیں؟
حیثیت
ترجیح
کیوں
لائیو چیٹ / اسسٹنٹ
بہاؤ
لیٹینسی میں کمی محسوس کی گئی، صارف ترقی دیکھتا ہے۔
طویل رپورٹ/دستاویز کی تیاری
بہاؤ
ٹائم آؤٹ کو روکتا ہے، بڑے آؤٹ پٹ کو محفوظ طریقے سے لے جاتا ہے۔
مختصر درجہ بندی (مثال کے طور پر ایک لفظ کا ٹیگ)
کوئی بہاؤ نہیں
آؤٹ پٹ پہلے ہی چھوٹا ہے؛ اضافی پیچیدگی غیر ضروری ہے
بیچ پروسیسنگ
بہاؤ کے بغیر/بیچ
نتائج فوری طور پر نہیں دکھائے جاتے ہیں۔ یونٹ 7 دیکھیں
آٹومیشن مرحلہ (پس منظر میں)
عام طور پر کوئی بہاؤ نہیں
آپ نتیجہ کو اگلے مرحلے پر منتقل کرتے ہیں، کوئی لائیو ڈسپلے نہیں۔
کاپی کرنے کے قابل پرامپٹ/ٹیمپلیٹس
اسٹریم بذات خود کوئی پرامپٹ نہیں ہے، لیکن اسٹریم کے ذریعہ تیار کردہ آؤٹ پٹ کو منظم کرنے کے لیے اشارے اہم ہیں۔ لمبی اور تیز پروڈکشن میں، سامنے سے ڈھانچے کو مسلط کرنے سے معیار اور ٹریس ایبلٹی دونوں میں اضافہ ہوتا ہے۔
# طویل رپورٹ کو حصوں میں تقسیم کریں (تاکہ پیشرفت بہاؤ میں نظر آئے) اسی ترتیب میں درج ذیل عنوانات کے ساتھ رپورٹ لکھیں۔ ہر سرخی کو '##' کے ساتھ شروع کریں:## خلاصہ## نتائج## سفارشات## اگلے مراحل
# طویل پیداوار میں کٹوتی سے بچنے کے لیے ہدف کی لمبائی دیں۔ کل متن تقریباً 800 الفاظ پر مشتمل ہوگا۔ حصوں کو متوازن رکھیں؛ آخر میں آدھا جملہ نہ چھوڑیں۔
# اسٹریمنگ اسسٹنٹ کے لیے فوری طور پر پہلا جملہ دیں۔ پہلے براہ راست ایک جملے کا جواب دیں، پھر تفصیل میں جائیں۔ لہذا صارف انتظار کے دوران فوری نتیجہ دیکھتا ہے۔
# طویل آؤٹ پٹ کو سٹرکچرڈ رکھیں (تاکہ اسے بعد میں پارس کیا جا سکے) ان سیکشنز میں آؤٹ پٹ آؤٹ پٹ کریں اور ہر سیکشن کو علیحدہ '###' ہیڈر سے نشان زد کریں تاکہ میں اسے پروگرام کے لحاظ سے پارس کر سکوں: ### تعارف ### BODY ### ذرائع
کمزور فوری / مضبوط اشارہ (طویل پیداوار)
# WEAK اس موضوع پر ایک طویل اور مفصل رپورٹ لکھیں۔
# STRONGاس موضوع پر تقریباً 900 الفاظ پر مشتمل رپورٹ لکھیں۔ عنوانات: ## خلاصہ، ## تجزیہ، ## خطرات، ## سفارشات۔ ہر سرخی زیادہ سے زیادہ 3 پیراگراف کی ہونی چاہیے۔ آخر میں آدھا جملہ نہ چھوڑیں۔
طاقتور ورژن؛ یہ لمبائی، ساخت اور تکمیل کے معیار کا پہلے سے تعین کرتا ہے۔ جیسے جیسے حصے بہاؤ میں آتے ہیں، صارف پیش رفت کو واضح طور پر دیکھتا ہے اور ماڈل میں رکاوٹ کے خطرے کے خلاف خود لمبائی کا انتظام کرتا ہے۔
تین چھوٹے کیسز
کیس 1 - خالی اسکرین کی شکایت۔ ایک مشاورتی ٹیم کا کلائنٹ اسسٹنٹ بہاؤ کے بغیر جواب دے رہا تھا۔ اوسط جواب میں 7 سیکنڈ لگتے ہیں، صارفین پوچھتے ہیں "کیا یہ جم جاتا ہے؟" اس نے شکایت کی. ایک بار جب میں بہاؤ میں آیا، پہلا لفظ ~0.6 سیکنڈ میں آیا؛ کل وقت وہی رہا، لیکن "سست" شکایات تقریباً غائب ہو گئیں۔
کیس 2 - پرانی رپورٹ۔ ایک فنانس ٹیم 30 صفحات کی سہ ماہی رپورٹ تیار کر رہی تھی۔ max_tokens: 30000 کے ساتھ، no-flow کی درخواست 60-سیکنڈ کے کلائنٹ کے ٹائم آؤٹ میں پھنس جائے گی، درخواست ناکام ہو جائے گی — اور تیار کردہ ٹوکن انوائس پر لکھے جائیں گے۔ وہ بہاؤ کے ساتھ چلے گئے۔ کنکشن زندہ رہا، رپورٹ مکمل طور پر پہنچا دی گئی، اور ضائع ہونے والے اخراجات کو ختم کر دیا گیا۔
کیس 3 - غیر ضروری بہاؤ۔ ایک آپریشنز ٹیم آنے والی ای میلز کو "فوری/باقاعدہ" کا لیبل لگا رہی تھی۔ آؤٹ پٹ ایک لفظ تھا، لیکن وہ عادتاً بہاؤ استعمال کرتے تھے۔ بہاؤ نے ایک لفظ کے جواب میں کوئی فائدہ نہیں دیا، کوڈ کو غیر ضروری طور پر پیچیدہ بنا دیا۔ جب میں نے فلو لیس پر سوئچ کیا تو کوڈ آسان ہو گیا اور سلوک وہی رہا۔ سبق: سٹریمنگ طویل/لائیو آؤٹ پٹ میں قیمتی ہے، ہر جگہ نہیں۔
عام غلطیاں
- طویل آؤٹ پٹ میں اسٹریمز کا استعمال نہ کرنا: ٹائم آؤٹ اور ٹوکن لاگت ضائع ہو گئی۔
- مختصر آؤٹ پٹ میں اسٹریمنگ کا استعمال: غیر ضروری پیچیدگی، صفر فائدہ۔
- سلسلہ کے آخر میں `stop_reason` کو چیک نہیں کرنا: max_tokens کے ساتھ کٹے ہوئے جواب کو مکمل سمجھا جاتا ہے۔
- ڈیلٹا کو غلط طریقے سے ضم کرنا: SDK مددگار کے ساتھ دستی خلاصہ ترتیب/گمشدہ حصوں کی خرابی پیدا کرتا ہے۔
- 'استعمال' درمیانی سلسلہ کو پڑھنے کی کوشش کرنا: ٹوکن نمبر عام طور پر آخر میں واضح ہو جاتے ہیں۔ آخر میں اخراجات کا ٹریک رکھیں۔
- لاگت میں کمی کے لیے سٹریمنگ کی غلطی کرنا: سٹریمنگ تجربے اور برداشت کو بہتر بناتی ہے۔ یہ ٹوکن کی قیمت کو تبدیل نہیں کرتا ہے۔
گہرا: بہاؤ کے وقفے اور لچک
سلسلہ بندی ایک لائیو کنکشن ہے؛ یہ اس کی طاقت اور کمزوری دونوں ہے۔ اگر کنکشن درمیان میں گر جاتا ہے (نیٹ ورک کے اتار چڑھاؤ، کلائنٹ کا وقت ختم)، تو آپ اب تک جمع کردہ متن کو برقرار رکھیں گے، لیکن جواب نامکمل ہوگا۔ اس کے لیے پروڈکشن کے معیار کے اسٹریمنگ کلائنٹ کو تیار کیا جانا چاہیے: اسے جزوی متن کو "مکمل جواب" کے طور پر نہیں ماننا چاہیے، اور نہ ہی اسے جواب کو ختم کرنے پر غور کرنا چاہیے جب تک کہ یہ پیغام_سٹاپ ایونٹ کو نہ دیکھ لے۔
دوسری باریک بینی یہ ہے کہ بہاؤ لاگت کو تبدیل نہیں کرتا ہے۔ چاہے آپ کو سٹریمنگ کے ساتھ یا اس کے بغیر جواب موصول ہونے سے ٹوکن کی قیمت متاثر نہیں ہوتی ہے۔ بہاؤ صرف تجربہ اور برداشت کو بہتر بناتا ہے۔ تو "اگر ہم سلسلہ بندی کرتے ہیں تو کیا وہ سستے ہوں گے؟" سوال کا جواب نہیں ہے — لاگت کے لیے، 5ویں اور 6ویں اکائی (ماڈل کا انتخاب، کیشے) کو دیکھیں۔
تیسرا نکتہ ایک عملی توازن قائم کرنا ہے: لائیو معاونین کے ساتھ، پہلے لفظ کی تیزی سے آمد (تخیر میں سمجھی جانے والی) انتہائی قابل قدر ہے۔ اس لیے، ماڈل سے براہ راست جواب داخل کرنے اور پہلے مختصر نتیجہ دینے کے لیے کہنا (4ویں یونٹ میں سسٹم پرامپٹ کے ذریعے) بہاؤ کے فائدے کو بڑھا دیتا ہے۔ اگر صارف پہلے سیکنڈ میں کوئی معنی خیز چیز دیکھتا ہے، تو وہ اس کے بعد آنے والی تفصیل کا صبر سے انتظار کرتے ہیں۔ دوسری طرف، پس منظر میں چلنے والی ملازمتوں میں بہاؤ کا کوئی حصہ نہیں ہے، جس کا آؤٹ پٹ اگلے آٹومیشن مرحلے پر جاتا ہے۔ وہاں صرف ایک ہی معیار ہے کہ کام صحیح اور مکمل طور پر مکمل ہوا ہے۔
خلاصہ میں
سٹریمنگ جواب کو ٹکڑے ٹکڑے کرکے بازیافت کرتی ہے، سمجھی جانے والی تاخیر کو کم کرتی ہے اور بڑے تھرو پٹس پر ٹائم آؤٹ کو روکتی ہے۔ لائیو اسسٹنٹ اور طویل دستاویز کی تیاری کے لیے تقریباً لازمی؛ مختصر/ پس منظر کے کام کے لیے یہ غیر ضروری ہے۔ طویل پروڈکشنز میں، ایک پرامپٹ کے ساتھ سامنے سے ساخت اور لمبائی کو مسلط کرنے سے معیار اور ٹریس ایبلٹی دونوں میں اضافہ ہوتا ہے۔ جب بہاؤ ختم ہوجاتا ہے، تو stop_reason اور استعمال کو یقینی طور پر چیک کیا جاتا ہے۔
درخواست کا کام
دو منظرنامے منتخب کریں: ایک زندہ/لمبا (مثلاً گاہک کو رپورٹ)، ایک مختصر/پس منظر (مثلاً ٹیگنگ)۔ (1) فیصلہ کریں اور جواز پیش کریں کہ آیا آپ ہر ایک کے لیے بہاؤ استعمال کریں گے۔ (2) ایک پرامپٹ لکھیں جو طویل اسکرپٹ (ہیڈنگز + ہدف کی لمبائی) کے ڈھانچے کو نافذ کرے۔ (3) max_tokens کی قدروں کا تعین کریں۔ (4) فہرست بنائیں کہ آپ سٹاپ_ریزن کے ساتھ کون سے چیک انجام دیں گے اور بہاؤ کے اختتام پر استعمال کریں۔
چیک لسٹ
- میں وضاحت کر سکتا ہوں کہ سٹریمنگ کیا ہے اور یہ سمجھی جانے والی تاخیر کو کیسے کم کرتی ہے۔
- میں ندی اور ڈیلٹا میں شامل ہونے کی بنیادی قسموں کو سمجھ گیا ہوں۔
- میں بڑے max_tokens کے ساتھ سٹریم کرنے کی ضرورت اور ٹائم آؤٹ رشتہ کے بارے میں جانتا ہوں۔
- میں فیصلہ کر سکتا ہوں کہ کس کام کے بوجھ میں میں سٹریمنگ کا استعمال کروں گا اور کس میں نہیں کروں گا۔
- میں سٹریم کے آخر میں stop_reason اور استعمال کو چیک کر سکتا ہوں۔