بهینه‌سازی مسیر صوتی؛ راهکار کاهش تأخیر در عامل‌های صوتی هوش مصنوعی

اگر امروز یک عامل صوتی می‌سازید، احتمالاً متوجه شده‌اید که فاصله بین پایان جمله کاربر و پاسخ سیستم، بیش از هر چیزی روی تجربه کاربر اثر می‌گذارد. در حالی که کد اپلیکیشن شما منطق عامل صوتی را مدیریت می‌کند، شکاف بحرانی بین لحظه‌ای که تماس‌گیرنده جمله‌اش را تمام می‌کند و لحظه‌ای که پاسخ را می‌شنود، در واقع مجموعی از تقریباً دوازده گام یا «پرش» (Hop) است که اکثر آن‌ها برای توسعه‌دهنده نامرئی باقی می‌مانند. این معیار واحد است که موفقیت یا شکست یک عامل صوتی را تعیین می‌کند، همان‌طور که در یک راهنمای فنی منتشر شده در dev.to در ۱۲ اوت ۲۰۲۶ به تفصیل شرح داده شده است.

بسیاری از برنامه‌نویسان تمام تمرکز خود را روی سریع‌تر کردن مدل زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — می‌گذارند، اما این اغلب نبردی شکست‌خورده است. اگر زمان رسیدن به نخستین توکن (Time to First Token) تنها بخش کوچکی از تأخیر کل باشد، نصف کردن سرعت مدل، تأثیر ناچیزی بر تجربه کاربر خواهد داشت. برای ساخت محصولی که انسانی به نظر برسد، شما نباید فقط به مدل فکر کنید، بلکه باید کل مسیر صوتی از گوشی تا سرور و بازگشت آن را ابزارگذاری کنید.

تصور کنید یک تماس تلفنی شبیه به یک مسابقه دو امدادی فیزیکی است. صدا فقط «نمی‌رسد»؛ بلکه ابتدا توسط سخت‌افزار ضبط می‌شود، به فریم‌های ۲۰ میلی‌ثانیه‌ای تبدیل (Packetized) می‌شود، از طریق رادیوهای موبایل ارسال می‌گردد، از درگاه‌های اپراتور عبور می‌کند و برای حذف نوسانات در بافر ذخیره می‌شود. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی زیرساخت‌های استنتاج اشاره کردیم، تا زمانی که کد شما صدا را دریافت کند، بخش زیادی از بودجه زمانی تعامل انسانی — که معمولاً در محدوده چند صد میلی‌ثانیه متمرکز است — پیش از آنکه پردازش شروع شود، هزینه شده است.

مسیر ورودی (D_in)

سفر صدا از سخت‌افزار تماس‌گیرنده آغاز می‌شود. میکروفون گوشی صدا را می‌گیرد و کدک آن را قاب‌بندی می‌کند. چون ۲۰ میلی‌ثانیه استاندارد تقریباً جهانی در تلفنی است، رمزگذار (Encoder) باید یک فریم کامل را نگه دارد و سپس ارسال کند که همین موضوع باعث ایجاد یک تأخیر فوری ۲۰ میلی‌ثانیه‌ای می‌شود. کدک Opus چند میلی‌ثانیه دیگر برای پیش‌بینی الگوریتمی (Algorithmic Look-ahead) اضافه می‌کند، در حالی که کدک G.711 هیچ تأخیری در این مرحله ندارد.

سپس نوبت به شبکه دسترسی می‌رسد که متغیرترین بخش در کل مسیر است. چه این شبکه رادیوی موبایل باشد و چه پهنای باند ثابت، این بخش یک «جعبه سیاه» است که توسعه‌دهنده هیچ کنترلی روی آن ندارد. پس از آن، ترانزیت اپراتور از طریق شبکه تلفنی (PSTN) و هرگونه تبدیل کدک (Transcoding) در درگاه‌هایی که کدک‌ها را تغییر می‌دهند، رخ می‌دهد.

زمانی که صدا به سرور رسانه (Media Server) یا SBC ارائه‌دهنده شما می‌رسد، به سمت پردازش شما حرکت می‌کند. در اینجا بافر لرزش (Jitter Buffer) — که بزرگ‌ترین متغیر شبکه است که شما عملاً روی آن کنترل دارید — بسته‌ها را از حالت نوسانی خارج و منظم می‌کند. در نهایت، فریم صوتی به سیستم تشخیص فعالیت صوتی (VAD) شما تحویل داده می‌شود.

شکاف پردازشی

به محض اینکه VAD متوجه شود تماس‌گیرنده صحبتش را تمام کرده است، فاز «پردازش» آغاز می‌شود. اینجا جایی است که بیشترین تأخیر در سطح نرم‌افزار زندگی می‌کند. این مرحله از چهار عبارت متوالی تشکیل شده است:

• انتظار برای پایان (e): سیاست min_silence که برای تأیید اینکه کاربر واقعاً صحبتش را تمام کرده استفاده می‌شود. توجه کنید که این یک «سیاست» است، نه یک محدودیت سیستمی.
• نهایی‌سازی ASR (r): زمان بین لحظه‌ای که نقطه پایان (Endpoint) فعال می‌شود تا لحظه‌ای که متن نهایی (Final Transcript) تحویل داده شود.
• زمان مدل (m): زمان رسیدن به نخستین توکن از سوی LLM.
• زمان TTS (s): زمان رسیدن به اولین بایت صوتی از گفتار سنتز شده.

در یک مثال تشریحی ارائه شده در منبع، این چهار مورد می‌توانند مجموعاً ۱,۳۵۰ میلی‌ثانیه تأخیر ایجاد کنند که در مقایسه با تأخیر شبکه، عددی غول‌آسا است. بزرگ‌ترین سهم از این تأخیر اغلب مربوط به یک پارامتر است که به صورت دستی تایپ شده است — یعنی «انتظار برای پایان» — که در واقع زمان کاملاً مرده (Dead Time) است.

مسیر خروجی (D_out)

مسیر بازگشت دقیقاً آینه مسیر ورودی است. رمزگذار شما صدا را قاب‌بندی می‌کند (۲۰ میلی‌ثانیه دیگر انتظار برای پر شدن فریم)، آن را از مسیر رسانه ارائه‌دهنده، ترانزیت اپراتور و شبکه دسترسی عبور می‌دهد. در نهایت، بافر لرزش و سیستم پخش (Playout) گوشی تماس‌گیرنده، صدا را به گوش او می‌رساند.

بودجه زمانی به شکل یک معادله

برای تحلیل علمی این موضوع، شکاف پاسخ را می‌توان به شکل معادله‌ای نوشت که در آن هر عبارت بر حسب میلی‌ثانیه اندازه‌گیری می‌شود:
gap = D_in + e + r + m + s + D_out

که در آن:

• D_in = h1 + h2 + h3 + h4 + h5 + h6 (تأخیر یک‌طرفه ورودی)
• D_out = h7 + h8 + h9 + h10 + h11 (تأخیر یک‌طرفه خروجی)

دو حقیقت ساختاری از این معادله استخراج می‌شود. اول اینکه هزینه قاب‌بندی (Packetization) دو بار پرداخت می‌شود — یک بار در هر جهت — زیرا هیچ رمزگذاری نمی‌تواند بسته‌ای را ارسال کند که هنوز پر نشده است. دوم اینکه بافر لرزش نیز دو بار اعمال می‌شود (یک بار در سمت شما و یک بار در سمت کاربر). هیچ‌کدام از این‌ها مقدار ثابتی ندارند؛ بافر‌های تطبیقی (Adaptive Buffers) زمانی که کیفیت شبکه افت می‌کند، بزرگ‌تر می‌شوند.

معیارهای کیفیت

برای ارزیابی این اعداد، توسعه‌دهندگان می‌توانند به استاندارد ITU-T G.114 نگاه کنند. این استاندارد توصیه می‌کند که تأخیر یک‌طرفه از دهان تا گوش (فقط D_in) برای کیفیت مکالمه عمومی، در سطح ۱۵۰ میلی‌ثانیه یا کمتر باشد. این استاندارد بازه ۱۵۰ تا ۴۰۰ میلی‌ثانیه را در صورتی که طرفین از وجود سیستم انتقال آگاه باشند، «قابل قبول» می‌داند و هر عددی بالای ۴۰۰ میلی‌ثانیه را برای استفاده تعاملی «غیرقابل قبول» تلقی می‌کند.

با این حال، شکاف یک عامل صوتی بسیار بزرگ‌تر از D_in است؛ زیرا شامل D_in، D_out و چهار عبارت پردازشی است. پژوهش‌های مربوط به نوبت‌گیری انسانی (Stivers et al., PNAS 2009، که ده زبان مختلف را پوشش داده) نشان می‌دهد که آفست‌های پاسخ (Response Offsets) در حدود چند صد میلی‌ثانیه متمرکز هستند. این همان استانداردی است که یک شنونده به طور غریزی به کار می‌برد.

استراتژی‌های هم‌پوشانی برای کاهش تأخیر

برای تبدیل یک دموی ساده به محصولی در سطح تولید (Production-grade)، باید از نگاه به این مراحل به عنوان یک توالی متوالی دست بردارید. هدف این است که تا حد امکان عبارات را با یکدیگر هم‌پوشانی (Overlap) کنید.

اول، انتظار برای پایان را بهینه کنید. به جای یک تایمر ثابت، از «پایان معنایی» (Semantic Endpointing) استفاده کنید. زمانی که متن به نظر کامل می‌رسد، زمان انتظار را کوتاه کنید و زمانی که کاربر جمله را با یک حرف ربط یا یک عدد ناتمام به پایان می‌برد، آن را طولانی‌تر کنید.

دوم، نهایی‌سازی ASR را با درخواست مدل هم‌پوشانی کنید. به محض فعال شدن نقطه پایان، درخواست LLM را با استفاده از آخرین متن ناقص (Partial Transcript) ارسال کنید. اگر متن نهایی تفاوت مادی با متن ناقص داشت، درخواست را لغو و دوباره ارسال کنید. این کار کل مدت زمان نهایی‌سازی ASR (r) را ذخیره می‌کند، هرچند ممکن است گاهی منجر به یک فراخوانی هدر رفته شود.

سوم، توکن‌های مدل را مستقیماً به TTS استریم کنید. به جای انتظار برای پاسخ کامل، سنتز صدا را از اولین مرز جمله (Sentence Boundary) شروع کنید. این کار هزینه مدل را از «زمان کل تولید» به «زمان تا نخستین توکن» به اضافه زمان رسیدن به مرز یک عبارت تبدیل می‌کند.

در نهایت، صدای TTS را استریم کنید. اولین فریم‌های صوتی را به محض تولید به سرور رسانه بفرستید. هر ارائه‌دهنده TTS که فقط پاسخ‌های کامل (Whole Utterances) را برمی‌گرداند، باید به همین دلیل رد شود.

اثر هم‌پوشانی بر معادله

وقتی این هم‌پوشانی‌ها پیاده‌سازی شوند، معادله متوالی تغییر می‌کند. به جای gap = D_in + e + r + m_total + s_total + D_out تبدیل می‌شود به:
gap ~= D_in + e + max(r, m_first_token) + s_first_audio + D_out

در این مدل، m_first_token زمان رسیدن به اولین توکن است، نه کل پاسخ، و s_first_audio زمان رسیدن به اولین بایت صوتی از اولین عبارت است. بقیه پاسخ در حالی تولید و سنتز می‌شود که تماس‌گیرنده در حال گوش دادن به ابتدای جمله است.

سقف کیفیت کدک‌ها

تأخیر تنها هزینه نیست؛ کیفیت صدا یک سقف برای دقت ایجاد می‌کند. کدک G.711 (PCMU/PCMA) که پیش‌فرض PSTN است، با نرخ ۸ کیلوهرتز و صدای ۸ بیتی در ۶۴ کیلوبیت بر ثانیه نمونه‌برداری می‌کند. طبق قانون نایکوئیست، سقف فرکانسی ۴ کیلوهرتز است و باند عبور حتی narrower است. هر چیزی بالای تقریباً ۳.۴ کیلوهرتز حذف می‌شود — و این دقیقاً همان جایی است که انرژی تفکیک‌کننده بین صداهای /s/ و /f/ و /th/ قرار دارد.

در حالی که G.722 صدای Wideband ۱۶ کیلوهرتزی را در ۶۴ کیلوبیت بر ثانیه ارائه می‌دهد، اما تنها در صورتی کار می‌کند که هر گام در زنجیره از آن پشتیبانی کند. یک بخش Narrowband در مسیر، باعث تبدیل کدک (Transcode) مجدد به ۸ کیلوهرتز می‌شود. Opus، پیش‌فرض WebRTC، استاندارد طلایی است که ۸ تا ۴۸ کیلوهرتز را مدیریت کرده و نرخ بیت خود را با شبکه تطبیق می‌دهد. این کدک معمولاً یک فریم ۲۰ میلی‌ثانیه‌ای (در بازه ۲.۵ تا ۶۰ میلی‌ثانیه) به اضافه چند میلی‌ثانیه پیش‌بینی الگوریتمی را نگه می‌دارد.

توسعه‌دهندگان باید مراقب باشند که صدای ۸ کیلوهرتزی را برای یک مدل ASR به ۱۶ کیلوهرتز ارتقا (Upsampling) ندهند. این یک تبدیل فرمت است، نه بازسازی؛ باند فرکانسی حذف شده برای همیشه رفته است. هر تبدیل کدک در مسیر، فشرده‌سازی تخریبی (Lossy Compression) اضافه می‌کند و تبدیل گفتار به متن را به طور محسوسی سخت‌تر می‌کند. این دلیل اصلی است که نرخ خطای کلمه (WER) در تماس‌های تلفنی بدتر از ضبط‌های استودیویی است.

ابزارگذاری و ترتیب ساخت

برای رفع شکاف، باید آن را اندازه بگیرید. لاگ‌های اپلیکیشن ناکافی هستند چون پرش‌های شبکه را نمی‌بینند. این راهنما سه اندازه‌گیری خاص را توصیه می‌کند:

۱. برچسب‌های نرم‌افزاری (Software Stamps): از یک ساعت یکنواخت (Monotonic Clock) برای برچسب‌گذاری ۶ رویداد استفاده کنید: آخرین فریم گفتار مشاهده شده، فعال شدن نقطه پایان، دریافت متن نهایی ASR، ارسال درخواست مدل، دریافت اولین توکن مدل و ارسال اولین بایت صوتی TTS. این کار مقادیر e، r، m و s را دقیقاً به شما می‌دهد.
۲. تحلیل RTP: زمان رفت‌وبرگشت (RTT) و عمق بافر لرزش را از سرور رسانه لاگ کنید. نیمی از زمان رفت‌وبرگشت، تخمینی کاربردی برای h2 + h3 + h4 در هر جهت است و عمق بافر مستقیماً همان h5 است.
۳. ضبط فیزیکی: یک تماس واقعی را از طریق گوشی در یک فایل استریو ضبط کنید. فاصله بین پایان عبارت در یک کانال و پاسخ در کانال دیگر، تنها عدد واقعی پایان-به-پایان (End-to-End) است. این مورد باید هم روی شبکه‌های موبایل و هم خطوط ثابت تست شود، زیرا نتایج آن‌ها یکسان نخواهد بود.

تمام معیارها باید در p50 و p95 گزارش شوند و هرگز به صورت میانگین (Mean) ارائه نشوند. یک مورد «راه‌اندازی سرد» (Cold-start) یا گسترش بافر لرزش می‌تواند میانگین را به شدت جابه‌جا کند، در حالی که تماس‌های «دم» (Tail calls) همان‌هایی هستند که باعث شکایت کاربران می‌شوند.

ترتیب پیشنهادی برای پیاده‌سازی

سیستم را در مراحل زیر بسازید تا از کابوس‌های دیباگ جلوگیری کنید:

• پاسخ و اکو: تماسی را بپذیرید و صدا را با یک تأخیر ثابت پخش کنید تا مسیر رسانه، کدک و بافرینگ را اعتبارسنجی کنید. این کار D_in + D_out را قبل از اضافه کردن هوش مصنوعی اندازه می‌گیرد.
• VAD و لاگ: هر مرز گفتار و سکوت را ثبت کنید. یک هیستوگرام از مکث‌ها بسازید تا مقدار انتظار پایان (e) را بر اساس داده‌های واقعی انتخاب کنید.
• ASR استریمینگ: متن‌های ناقص (Partials) و نهایی (Finals) را در کنسول چاپ کنید تا تأیید شود در زمان مورد انتظار می‌رسند و متن قابل استفاده است.
• TTS با متن ثابت: مقدار s را اندازه بگیرید و تأیید کنید استریمینگ در کل مسیر کار می‌کند. مطمئن شوید می‌توانید پخش را در وسط عبارت متوقف کنید، که برای قابلیت قطع کردن (Barge-in) ضروری است.
• مدل: LLM را در آخرین مرحله اضافه کنید. از آنجایی که هر عبارت دیگر قبلاً اندازه‌گیری شده است، هر تغییری در شکاف زمانی را می‌توان مستقیماً به مدل نسبت داد.

تحلیل: مغالطه «سرعت مدل»

این تفکیک نشان می‌دهد چرا «مدل‌های سریع‌تر» اغلب در بهبود حس یک محصول صوتی شکست می‌خورند. وقتی شبکه و مسیر تلفنی بخش قابل توجهی از بودجه نوبت‌گیری انسانی را مصرف می‌کنند، سرعت LLM تنها یک متغیر در یک معادله پیچیده است.

برای توسعه‌دهندگان، تغییر رویکرد از بهینه‌سازی یک مدل به بهینه‌سازی یک خط لوله (Pipeline) است. برد واقعی در تعداد توکن در ثانیه نیست، بلکه در «زمان تا نخستین توکن» و توانایی استریم کردن صدا در میانه عبارت است. اگر سرعت ترکیبی مدل و TTS نتواند نرخی سریع‌تر از گفتار انسانی (تقریباً ۱۵۰ کلمه در دقیقه) را حفظ کند، استریمینگ باعث لکنت (Stuttering) می‌شود و در این صورت، بافر کردن اولین جمله گزینه امن‌تری خواهد بود.

در نهایت، توسعه‌دهندگان باید قابلیت‌های «Barge-in» را بررسی کنند که به کاربران اجازه می‌دهد صحبت عامل را قطع کنند. این ویژگی با هر جزء از مسیر صوتی تعامل دارد و اگر خیلی زود اضافه شود، معمولاً خط لوله را مختل می‌کند. علاوه بر این، به خاطر داشته باشید که تماس‌های ورودی و خروجی به طور متفاوتی تنظیم شده‌اند و ضبط تماس قوانین قانونی خاص خود را در مورد رضایت و نگهداری داده‌ها دارد. در کنار بهینه‌سازی این خط لوله‌ها، مدیریت مقیاس‌پذیر عامل‌ها نیز اهمیت دارد؛ برای مثال پروتکل Pilot با اتوماسیون فرآیند Onboarding هزینه افزودن عامل‌های جدید به ناوگان‌های هوش مصنوعی را به صفر رسانده است.

گام بعدی شما

• بررسی کنید آیا ارائه‌دهنده TTS شما از استریمینگ بایت‌های صوتی پشتیبانی می‌کند یا فقط پاسخ کامل را می‌فرستد.
• به جای استفاده از تایمر ثابت برای تشخیص پایان صحبت، یک سیستم تشخیص پایان معنایی (Semantic Endpointing) پیاده کنید.
• یک تماس واقعی را ضبط کرده و فاصله زمانی را به صورت دستی اندازه بگیرید تا متوجه شوید چقدر از تأخیر مربوط به شبکه است و چقدر به نرم‌افزار.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.