OpenAI مدل GPT-Live را ساخته است؛ یک چت‌بات مبتنی بر صدا که به‌طور هم‌زمان گوش می‌دهد و صحبت می‌کند و مکث‌های سنگین و آزاردهنده «اول حرف بزن، بعد گوش بده» را که اکثر دستیارها استفاده می‌کنند، کنار گذاشته است. هدف این سرویس دستیابی به گفتگویی است که مانند دیالوگ‌های انسانی روان باشد، نه تبادل‌های گسسته و قطع‌وشلی.

چرا مدل قدیمی ناقص به نظر می‌رسید

دستیارهای صوتی معمولی مانند بی‌سیم (walkie-talkie) عمل می‌کنند: شما جمله‌ای را تمام می‌کنید، دستگاه آن را ضبط می‌کند، صدا را به ابر (cloud) می‌فرستد، منتظر پاسخ می‌ماند و سپس آن را پخش می‌کند. این رفت‌وبرگشت باعث ایجاد تأخیر (lag) محسوسی می‌شود و کاربران را مجبور می‌کند قبل از اینکه بتوانند حرفشان را قطع کنند، مکث کنند. برای نسلی که با پیام‌رسان‌های فوری بزرگ شده است، این تأخیر بسیار قدیمی و منسوخ به نظر می‌رسد.

OpenAI با یک معماری بدون نوبت (turn-less) به این مسئله پاسخ داد. در هر ثانیه، GPT-Live تصمیم می‌گیرد که به گوش دادن ادامه دهد، به صحبت کردن ادامه دهد یا مکث کند؛ این ویژگی به شما اجازه می‌دهد تا صحبت دستیار را در میان پاسخ قطع کنید یا بدون منتظر ماندن برای اتمام چرخه کامل پاسخ، سوال بعدی را بپرسید.

توضیح ساده‌ی پشته (stack) تمام‌دوطرفه (full-duplex)

  1. جداسازی حلقه صوتی و مسیر استدلال – یک مسیر سریع (fast path) تبادل مداوم صدا را مدیریت می‌کند، در حالی که یک مسیر کند (slow path) وظایف سنگین‌تر مانند جستجوی وب یا فراخوانی ابزارها را انجام می‌دهد. مسیر سریع باعث می‌شود گفتگو در حین کارِ مسیر کند زنده بماند و آن لحظه ترسناکِ «سکوت در حین فکر کردن» از بین برود.
  2. پروتکل WARP – اتصالات وب سنتی پیش از آنکه صدا بتواند جریان یابد، به چندین مرحله دست‌دادن (handshake) نیاز دارند که اغلب شامل شش رفت‌وبرگشت است. پروتکل اختصاصی OpenAI این مراحل را در یک رفت‌وبرگشت خلاصه می‌کند و باعث می‌شود شروع جلسه تقریباً آنی به نظر برسد.
  3. استفاده از Go به جای Python برای ثبات تأخیر – تیم توسعه، اجزای بلادرنگ (real-time) را از Python (که به دلیل توسعه سریع محبوب است) به Go منتقل کرد که زمان‌های اجرای قابل‌پیش‌بینی‌تری ارائه می‌دهد. در هوش مصنوعی صوتی، تأخیر در بدترین حالت (worst-case) مهم‌تر از میانگین سرعت است؛ یک لکنت ساده باعث از بین رفتن غوطه‌وری (immersion) می‌شود، بنابراین ثبات در تأخیر برنده است.
  4. مقیاس‌پذیری فراتر از GPU – با وجود صدها میلیون کاربر، گلوگاه از هسته‌های محاسباتی مدل به زیرساخت‌های اطراف تغییر یافت. OpenAI متوجه شد که CPUها و لینک‌های شبکه پیش از GPUها اشباع می‌شوند، بنابراین مسیریابی و مدیریت اتصال هوشمندتری را اضافه کردند تا بدون فشار آوردن به بقیه پشته، تغذیه GPUها را حفظ کنند.

این موضوع برای توسعه‌دهندگان چه معنایی دارد

  • جداسازی مدیریت صدا از منطق تجاری (business logic) – یک حلقه سبک و همیشه روشن داشته باشید که ورودی میکروفون و خروجی بلندگو را پردازش کند. هر چیزی را که می‌تواند منتظر بماند — مانند پرس‌وجوهای پایگاه داده یا فراخوانی APIهای خارجی — به یک رشته (thread) یا سرویس جداگانه منتقل کنید.
  • اولویت دادن به پایداری تأخیر – زمان پاسخگویی را اندازه‌گیری کنید و به جای تمرکز صرف بر میانگین، بر تأخیرهای بدترین حالت تمرکز کنید. زبان‌ها و زمان‌های اجرایی (runtimes) که کنترل دقیق‌تری بر زمان‌بندی (scheduling) دارند (مانند Go یا Rust)، می‌توانند ارزش تلاش مهندسی اضافی را داشته باشند.
  • کاهش سربار اتصال – هر مرحله دست‌دادن اضافی، میلی‌ثانیه‌هایی را اضافه می‌کند که در مجموع زیاد می‌شوند. احراز هویت، مذاکره جریان (stream negotiation) و انتخاب کدک را در یک تبادل واحد تجمیع کنید تا کاربران متوجه تفاوت شوند.

سبک‌سنگین کردن‌ها (Trade-offs) و پرسش‌های بی‌پاسخ

طراحی تمام‌دوطرفه باعث پیچیدگی می‌شود.

آنچه باید در آینده زیر نظر داشت