OpenAI نے GPT-Live بنایا ہے، جو کہ ایک وائس فرسٹ (voice-first) چیٹ بوٹ ہے جو بیک وقت سنتا اور بولتا ہے، اور ان بوجھل "پہلے بولیں پھر سنیں" والے وقفوں کو ختم کرتا ہے جو زیادہ تر اسسٹنٹس میں ہوتے ہیں۔ اس سروس کا مقصد ایسی گفتگو فراہم کرنا ہے جو رک رک کر ہونے والے تبادلے کے بجائے انسانی مکالمے کی طرح رواں ہو۔
پرانا ماڈل کیوں ناکام محسوس ہوتا تھا
عام وائس اسسٹنٹس واکی ٹاکی (walkie-talkies) کی طرح کام کرتے ہیں: آپ ایک جملہ مکمل کرتے ہیں، ڈیوائس اسے ریکارڈ کرتی ہے، آڈیو کو کلاؤڈ پر بھیجتی ہے، جواب کا انتظار کرتی ہے، اور پھر اسے چلا دیتی ہے۔ یہ چکر (round-trip) ایک نمایاں تاخیر کا باعث بنتا ہے اور صارفین کو مداخلت کرنے سے پہلے رکنے پر مجبور کرتا ہے۔ فوری میسجنگ (instant messaging) کے دور میں پروان چڑھی نسل کے لیے یہ تاخیر قدیم معلوم ہوتی ہے۔
OpenAI نے اس کا جواب ایک turn-less آرکیٹیکچر کے ذریعے دیا۔ ہر سیکنڈ میں، GPT-Live فیصلہ کرتا ہے کہ اسے سننا جاری رکھنا ہے، بولنا جاری رکھنا ہے، یا رکنا ہے، جس سے آپ اسسٹنٹ کو جواب کے دوران ہی روک سکتے ہیں یا مکمل جواب کے چکر کا انتظار کیے بغیر کوئی فالو اپ سوال پوچھ سکتے ہیں۔
فل ڈوپلیکس اسٹیک (full-duplex stack) سادہ الفاظ میں
- آڈیو لوپ اور ریزننگ پاتھ کو الگ کرنا – ایک fast path مسلسل آڈیو کے تبادلے کو سنبھالتا ہے، جبکہ ایک slow path ویب سرچ یا ٹول کالز جیسے بھاری کام انجام دیتا ہے۔ جب slow path کام کر رہا ہوتا ہے، fast path گفتگو کو جاری رکھتا ہے، جس سے "سوچتے وقت خاموشی" والا پریشان کن لمحہ ختم ہو جاتا ہے۔
- WARP پروٹوکول – روایتی ویب کنکشنز میں آڈیو کے بہاؤ سے پہلے کئی ہینڈ شیکس (handshakes) کی ضرورت ہوتی ہے، جو اکثر چھ راؤنڈ ٹرپس تک جاتے ہیں۔ OpenAI کا کسٹم پروٹوکول ان مراحل کو ایک ہی ٹرپ میں سمیٹ دیتا ہے، جس سے سیشن کا آغاز تقریباً فوری محسوس ہوتا ہے۔
- لیٹنسی (latency) کے تسلسل کے لیے Python کے بجائے Go کا استعمال – ٹیم نے ریئل ٹائم اجزاء کو Python (جو تیز رفتار ڈویلپمنٹ کے لیے پسند کیا جاتا ہے) سے منتقل کر کے Go میں منتقل کر دیا، جو زیادہ قابلِ پیش گوئی (predictable) ایگزیکیوشن ٹائم فراہم کرتا ہے۔ وائس AI میں، اوسط رفتار کے مقابلے میں بدترین صورتحال میں ہونے والی تاخیر زیادہ اہمیت رکھتی ہے؛ ایک معمولی سی ہچکچاہٹ بھی تسلسل کو توڑ دیتی ہے، اس لیے مستقل لیٹنسی ہی جیتتی ہے۔
- GPU سے آگے اسکیلنگ کرنا – کروڑوں صارفین کے ساتھ، رکاوٹ ماڈل کے کمپیوٹ کورز سے ہٹ کر ارد گرد کے انفراسٹرکچر پر منتقل ہو گئی۔ OpenAI نے دیکھا کہ GPUs سے پہلے CPUs اور نیٹ ورک لنکس بھر (saturate) رہے تھے، اس لیے انہوں نے اسمارٹ روٹنگ اور کنکشن مینجمنٹ کا اضافہ کیا تاکہ باقی اسٹیک کو بوجھل کیے بغیر GPUs کو ڈیٹا فراہم کیا جا سکے۔
ڈویلپرز کے لیے اس کا کیا مطلب ہے
- آڈیو ہینڈلنگ کو بزنس لاجک سے الگ کریں – ایک ہلکا پھلکا، ہمیشہ آن رہنے والا لوپ رکھیں جو مائیکروفون ان پٹ اور اسپیکر آؤٹ پٹ کو پروسیس کرے۔ ایسی ہر چیز جو انتظار کر سکتی ہے—جیسے ڈیٹا بیس کوئریز، بیرونی API کالز—اسے ایک الگ تھریڈ یا سروس پر منتقل کر دیں۔
- لیٹنسی کے استحکام کو ترجیح دیں – رسپانس ٹائم کو ماپیں، اور صرف اوسط (mean) کے بجائے بدترین صورتحال میں ہونے والی تاخیر پر توجہ دیں۔ وہ زبانیں اور رن ٹائمز جو شیڈولنگ پر بہتر کنٹرول فراہم کرتے ہیں (مثلاً Go، Rust) اضافی انجینئرنگ کوشش کے قابل ہو سکتے ہیں۔
- کنکشن اوور ہیڈ (overhead) کو کم کریں – ہر اضافی ہینڈ شیک ملی سیکنڈز کا اضافہ کرتا ہے جو مجموعی طور پر بڑھ جاتے ہیں۔ آتھنٹیکیشن، اسٹریم نیگوشیشن، اور کوڈیک سلیکشن کو ایک ہی تبادلے میں یکجا کر دیں، اور صارفین اس فرق کو محسوس کریں گے۔
توازن اور کھلے سوالات
فل ڈوپلیکس ڈیزائن پیچیدگیوں میں اضافہ کرتا ہے۔