اگر یک فریم صوتی ۲۰ میلیثانیهای حتی با اندکی تأخیر برسد، گوش انسان فوراً متوجه یک نقص یا «تپق» میشود. در سامانههای عملیاتی، شکست در رعایت این ضرباحکام سخت، منجر به یخ زدن عامل یا صحبت کردن همزمان مدل و کاربر میشود.
بسیاری از توسعهدهندگان تصور میکنند راه حل این مشکل، استفاده از مدلهای پیشرفتهتر است؛ اما حقیقت این است که مشکل در معماری نهفته است. سامانههای صوتی معمولاً تلاش میکنند پردازش صدا و استدلالهای پیچیده را در یک فرآیند واحد اجرا کنند. این کار باعث تداخل میشود؛ زیرا صدا به دقت میلیثانیهای نیاز دارد، در حالی که فراخوانی ابزارها توسط مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — کند، متغیر و غیرقابلپیشبینی است.
به نقل از نیکولاس لاکمن در راهنمای فنی ai-audio-gateway، وقتی یک پرسوجوی کند از پایگاهداده یا یک حلقه استدلالی پیچیده، «حلقه رویداد» (Event Loop) را مسدود میکند، جریان صدا میمیرد. همانطور که در تحلیلهای قبلی ما دربارهی بهینهسازی تأخیر در مدلهای زایشی اشاره کردیم، مدیریت منابع در لایههای مختلف، کلید رسیدن به تجربه انسانی است. لاکمن اشاره میکند که تلاش برای حل این مشکل با استفاده از رشتههای مجزا (Threads) تنها یک بازی «کلاهبرداری» موقت است و راه حل واقعی، حذف کامل هر چیز غیرضروری از فرآیند اصلی است.
به همین دلیل، صنعت در حال حرکت به سوی معماری دوصفحهای است.
صفحات رسانه و کسبوکار
صفحه اول، «صفحه رسانه» یا همان دروازه صوتی است که کارهای سخت و آنی را بر عهره دارد. این بخش شامل موارد زیر است:
- ورودی و خروجی صوتی تلفنی یا WebRTC
- تشخیص فعالیت صوتی (VAD)
- مدیریت سرعت پخش و قطع صحبت کاربر (Barge-in)
- مدیریت کدکها
صفحه دوم، «صفحه کسبوکار» است که مالک معناست: پرامپتها، ابزارها، ارکستراسیون، استدلالهای چندمرحلهای و دسترسی به دادهها.
بین این دو صفحه، یک جریان دوطرفه gRPC قرار دارد که قراردادهای کوچک و تایپشدهای را منتقل میکند. قانون اینجا مطلق است: زمانبندی صدا هرگز نباید منتظر کارهای بخش کسبوکار بماند. بخش کسبوکار میتواند در ارائه نتیجه یک ابزار تأخیر داشته باشد، اما نمیتواند مانع از تشخیص قطع صحبت یا ارسال یک فریم صوتی خروجی شود.
پیشینههای صنعتی
این جداسازی دقیقاً مشابه روش شرکتهای بزرگ است. برای مثال:
- LiveKit: زیرساختی که OpenAI برای حالت صوتی پیشرفته (Advanced Voice Mode) استفاده میکند. سرور رسانه آنها یک SFU است که بستههای صوتی را بدون رمزگشایی ارسال میکند و عاملها به عنوان شرکتکنندگانی مجزا در اتاق حضور دارند.
- Vapi: خود را یک «لایه ارکستراسیون» مینامد. در این مدل، تشخیص قطع صحبت و مدیریت جریان در زیرساخت Vapi است، اما مدلهای LLM و ابزارها روی سرور کاربر اجرا میشوند.
- Pipecat: چارچوب متنباز شرکت Daily که انتقال دادهها و پردازش فریمها را کاملاً مجزا میکند.
- تلفنی سنتی: این الگو قدیمی است؛ صنعت تلفنی از زمان پیدایش SIP، سیگنالینگ را از رسانه جدا کرده بود. این رویکرد بنیادین در پروژههایی مانند AVA برای اتصال عاملهای صوتی به سختافزارهای Asterisk نیز مشاهده میشود تا پایداری ارتباط تلفنی تضمین گردد.
قرارداد: رویدادها و دستورات
در پیادهسازی مرجع، فرمت انتقال از پوشههای Pydantic استفاده میکند که به صورت JSON روی gRPC سریالیزه میشوند. این ساختار اجازه میدهد دادهها در لاگها برای انسان قابل خواندن باشند. مرز این دو بخش با دو نوع داده تعریف میشود:
- GatewayEventType: رویدادهایی که از دروازه به سمت کسبوکار میروند (مانند
CALL_STARTEDیاUSER_SPEECH_STOPPED). - GatewayCommandType: دستوراتی که از کسبوکار به دروازه میروند (مانند
RESPONSE_CREATEیاRESPONSE_CANCEL).
مکانیزم پروکسی ابزار
یکی از چالشهای فنی، نحوه فراخوانی ابزارها بدون مسدود کردن مسیر رسانه است. راه حل، استفاده از «ابزارهای پروکسی توخالی» است. طبق مستندات این معماری، یک ابزار به دو بخش تقسیم میشود: طرحواره (Schema) و پیادهسازی (Implementation).
در مرحله تنظیم، صفحه کسبوکار تنها طرحواره را به دروازه میفرستد. دروازه سپس یک پروکسی برای هر طرحواره میسازد. وقتی مدل ابزاری را فراخوانی میکند، پروکسی یک شناسه منحصربهفرد (UUID) ایجاد کرده و رویداد TOOL_CALL_REQUESTED را ارسال میکند. دروازه شکل ابزار را میشناسد اما از رفتار آن بیخبر است.
این ساختار انعطافپذیری شدیدی ایجاد میکند. یک دروازه میتواند همزمان از یک عامل ساده با چهار ابزار مستقیم و یک عامل پیچیده «متفکر-پاسخدهنده» پشتیبانی کند. در حالت دوم، یک پروکسی ممکن است یک حلقه استدلالی را در صفحه کسبوکار فعال کند که به دهها فراخوانی ابزار داخلی منجر شود، در حالی که دروازه فقط یک درخواست و یک پاسخ میبیند.
مدیریت قطع صحبت و دادههای قدیمی
مدیریت وقفهها در مکالمات طبیعی دشوار است. وقتی کاربر حرف مدل را قطع میکند، دروازه باید فوراً صف صوتی خروجی را پاک کند. چون مدلها متن را سریعتر از سرعت شنیدن انسان تولید میکنند، دروازه باید پاسخ را لغو کرده و متن را کوتاه کند تا نوبت بعدی بر اساس کلماتی که کاربر هرگز نشنیده، شکل نگیرد. این پیچیدگی در مدیریت توقفات، دلیل آن است که چرا در سیستمهایی مثل GPT-Live برای کاربردی واقعی، نیاز به رابطهای کاربری مخصوص کنترل وقفهها وجود دارد تا تداخلات صوتی به شکل بهتری مدیریت شوند.
برای هماهنگی این دو فرآیند بدون حافظه مشترک، دروازه از یک turn_id استفاده میکند؛ عددی که با هر بار قطع صحبت افزایش مییابد.
- این شناسه روی هر فریم درخواست ابزار قرار میگیرد.
- صفحه کسبوکار این شناسه را قبل از شروع کار کند، ثبت میکند.
- پس از اتمام کار، دوباره شناسه را چک میکند.
- اگر شناسه تغییر کرده باشد، کار به عنوان «داده قدیمی» علامت زده شده و فوراً رها میشود تا مدل روی نوبت جدید صحبت نکند.
مرجعیت تشخیص پایان صحبت (VAD)
پاسخدهی سریع در لحظه «پایان صحبت» (Endpointing) تعیین میشود. قانون این است که تنها یک جزء باید تصمیم بگیرد کاربر چه زمانی ساکت شده است. ai-audio-gateway ترجیح میدهد از VAD محلی در دروازه استفاده کند که میتواند تأخیر را در مقایسه با VAD معنایی در سمت سرور، حدود ۶۰۰ میلیثانیه کاهش دهد.
وقتی VAD محلی فعال است، تشخیص پایان صحبت در سمت ارائهدهنده غیرفعال میشود تا پاسخهای تکراری ایجاد نشود. متغیر کلیدی در اینجا «Hangover» است؛ یعنی مقدار سکوت مورد نیاز قبل از اینکه یک عبارت نهایی شود. برای خروج از تنظیمات «حسی»، دروازه رویداد turn_latency را صادر میکند تا زمان دقیق از لحظه سکوت کاربر تا اولین فریم صوتی مدل را اندازهگیری کند.
هزینهها و لجستیک جداسازی
این معماری بدون هزینه نیست. این کار دو حوزه شکست مجزا ایجاد میکند و عیبیابی توزیعشده را میطلبد. برای کاهش این مشکل، توسعهدهندگان باید Context Trace را در جریان gRPC منتقل کنند تا بازههای زمانی ابزارها در صفحه کسبوکار، زیرمجموعه بازههای دروازه باشند.
هر فراخوانی ابزار، هزینه سریالیزه شدن و یک گام شبکه دارد. با این حال، اگر دو صفحه در شبکه به هم نزدیک باشند، این هزینه در برابر تأخیر استنتاج مدل ناچیز است. همچنین چرخه توسعه تغییر میکند: مهندسان پرامپت دیگر نیازی ندارند کل پشته صوتی را اجرا کنند؛ مرز gRPC باید از هر دو طرف قابل تست باشد.
آیندهنگری در برابر مدلهای یکپارچه
برخی میگویند با پیشرفت مدلهای تبدیل گفتار به گفتار (S2S)، نیاز به دروازه از بین میرود. اما دروازه و عامل دو مشکل متفاوت را حل میکنند. حتی اگر «مغز» سیستم به یک مدل واحد تبدیل شود، شما همچنان به لایهای برای موارد زیر نیاز دارید:
- ورودی/خروجی تلفنی و WebRTC
- بافرهای لرزش (Jitter buffering) و مدیریت سرعت
- VAD و پاکسازی صف قطع صحبت
- مدیریت کدکها و اتصال مجدد
- مدیریت اعتبارنامههای APIهای خارجی
ادغام با پروتکل زمینه مدل (MCP)
هنگام استفاده از سرورهای MCP، صفحه کسبوکار باید به عنوان میزبان عمل کند. این بخش اتصالات کلاینت را مدیریت کرده و ابزارها را از سرورهای مختلف جمعآوری میکند و یک مجموعه ابزار یکپارچه را به دروازه ارائه میدهد. دروازه اصلاً نمیداند MCP وجود دارد. این یعنی اگر از توابع محلی به سرورهای MCP کوچ کنید، ضرباحکام ۲۰ میلیثانیهای صفحه رسانه هرگز دستنخورده باقی میماند.
سایر مسئولیتهای صفحه کسبوکار
علاوه بر ابزارها، مسئولیتهای زیر منحصراً در صفحه کسبوکار هستند:
- حفاظها (Guardrails): بررسیهای سیاستی برای دادههای حساس در اینجا رخ میدهد. چون متنها به صورت رویداد منتقل میشوند، صفحه کسبوکار میتواند مکالمه را رصد کرده و دستور
response.cancelرا برای وتو کردن صدا صادر کند. - پردازش پس از تماس: ثبت در CRM، خلاصهسازی مکالمه و تحلیلها از طریق جریان رویدادها تغذیه میشوند، بدون اینکه دروازه از وجود آنها باخبر شود.
این جداسازی معماری تضمین میکند که واقعیتهای سخت فیزیکی صدا به عنوان یک مقدار ثابت در نظر گرفته شوند، در حالی که الگوهای متغیر عاملها میتوانند مستقل از آن تکامل یابند.
گام بعدی شما
- اگر سیستم صوتی شما در هنگام فراخوانی APIها تپق میزند، بررسی کنید آیا منطق استدلال و ارسال صدا در یک Thread یا Event Loop مشترک هستند یا خیر.
- برای کاهش تأخیر در پاسخدهی، VAD را از سمت سرور مدل به لایه Gateway منتقل کنید تا حدود ۶۰۰ میلیثانیه سود کنید.
- از gRPC برای ارتباط بین لایه رسانه و لایه منطق استفاده کنید تا از قابلیت Multiplexing در HTTP/2 بهره ببرید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو