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

تصور کنید یک منشی مجازی صوتی را استخدام می‌کنید که نه تنها هرگز خسته نمی‌شود، بلکه پاسخ‌هایش را در کمتر از یک ثانیه و بدون مکث‌های آزاردهنده می‌دهد. این دقیقاً همان چیزی است که در پروژه Maya محقق شده تا تجربه تماس با یک کلینیک را از منوهای خسته‌کننده «برای نوبت‌دهی عدد ۱ را فشار دهید» به یک گفتگوی انسانی تبدیل کند. توسعه‌دهنده این پروژه، Maya را به عنوان یک پذیرشگر صوتی برای کلینیک فرضی SwasthyaCare طراحی کرده است که می‌تواند بدون اصطکاکِ منوهای سنتی IVR، برنامه‌های زنده پزشکان و تریاژ پزشکی را مدیریت کند.

بسیاری از دموهای صوتی هوش مصنوعی تنها پوسته‌ای روی چت‌بات‌های متنی یا APIهای ساده هستند و در محیط‌های واقعی شکست می‌خورند. برای اینکه یک عامل صوتی انسانی به نظر برسد، تأخیر (Latency) — یعنی فاصله زمانی بین پایان حرف کاربر و شروع پاسخ مدل — باید تقریباً نامحسوس باشد. اگر این فاصله به ۱.۵ ثانیه برسد، گفتگو مصنوعی، گسسته و آزاردهنده می‌شود. Maya این مشکل را با استفاده از یک پشته فنی (Stack) تخصصی حل کرده است که برای سرعت طراحی شده و مسیر انتقال صدا از مرورگر به ابر و بازگشت آن را به میلی‌ثانیه رسانده است.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی استنتاج در مدل‌های زبانی اشاره کردیم، سرعت در سیستم‌های بلادرنگ (Real-time) اولویت اول است. در این پروژه، توسعه‌دهنده برای رسیدن به این هدف از معماری دقیقی استفاده کرده است.

طبق گزارش فنی این پروژه، خط لوله Maya برای کاهش زمان تا نخستین توکن (Time to First Token یا TTFT) از یک زنجیره با کارایی بالا عبور می‌کند. مسیر جریان داده به این صورت است: میکروفون مرورگر $
ightarrow$ جریان صوتی WebRTC $
ightarrow$ ابر LiveKit (منطقه ap-south / بمبئی) $
ightarrow$ Silero VAD $
ightarrow$ Groq Whisper $
ightarrow$ Groq LLM $
ightarrow$ پایگاه‌داده SQLite $
ightarrow$ Cartesia TTS $
ightarrow$ بلندگوی مرورگر.

جزئیات فنی این زیرساخت به شرح زیر است:

• انتقال صدا: LiveKit (با پروتکل WebRTC) جریان صوتی دوطرفه و بلادرنگ را بین مرورگر کاربر و Worker بک‌اند مدیریت می‌کند.
• تشخیص فعالیت صوتی (VAD): Silero VAD — شبیه به یک نگهبان که دقیقاً می‌فهمد چه زمانی کاربر شروع به صحبت کرده و چه زمانی سکوت کرده است — به صورت محلی در داخل Worker اجرا می‌شود تا لحظه دقیق شروع و پایان صحبت را تشخیص دهد.
• تبدیل گفتار به متن (STT): مدل Groq Whisper (نسخه whisper-large-v3-turbo) صدا را در حدود ۱۰۰ تا ۲۰۰ میلی‌ثانیه به متن تبدیل می‌کند.
• استدلال: مدل Groq (نسخه openai/gpt-oss-120b) وظیفه استدلال سریع، فراخوانی تابع (Tool Calling) و اجرای منطق کلینیکی را بر عهده دارد.
• تبدیل متن به گفتار (TTS): سرویس Cartesia (مدل sonic-turbo) صدای «پریا» را تولید می‌کند که یک پروفایل انگلیسی-هندی طبیعی است و برای محیط یک کلینیک در بمبئی کاملاً مناسب است.
• مدیریت وضعیت: یک پایگاه‌داده SQLite به همراه زبان پایتون، وضعیت نوبت‌ها، بررسی در دسترس بودن پزشکان و ثبت تاریخچه (Audit Trails) را مدیریت می‌کند.
• رابط کاربری: با استفاده از React و Vite ساخته شده و از کتابخانه @livekit/components-react و Tailwind CSS برای استایل‌دهی بهره می‌برد.

یکی از بزرگ‌ترین چالش‌های مهندسی در این پروژه، تله‌ی محدودیت نرخ درخواست (Rate Limit) در طرح رایگان Groq بود که سقف ۸,۰۰۰ توکن (Token) در دقیقه (TPM) داشت. در ابتدا، پرامپت سیستمی Maya به همراه طرح‌های JSON برای پنج ابزار (Function Tools)، در هر یک بار فراخوانی LLM حدود ۱,۹۰۰ توکن مصرف می‌کرد. این بدان معنا بود که تنها با ۴ نوبت گفتگو در یک دقیقه (۱,۹۰۰ * ۴ = ۷,۶۰۰+ توکن)، سیستم با خطای HTTP 429 (Too Many Requests) مواجه شده و عامل صوتی به طور کامل کرش می‌کرد.

توسعه‌دهنده این مشکل را با فشرده‌سازی تهاجمی پرامپت سیستمی و مستندات (Docstrings) ابزارها حل کرد. با حذف دستورات تکراری، استفاده از لیست‌های متراکم (Bullet Points) و به حداقل رساندن پارامترهای ابزارها، حجم هر درخواست به حدود ۵۰۰ توکن کاهش یافت؛ یعنی یک بهینه‌سازی ۷۳ درصدی. این تغییر استراتژیک اجازه داد عامل صوتی بیش از ۱۵ نوبت گفتگو در دقیقه را بدون برخورد با محدودیت‌ها و در عین حال با حفظ تمام حفاظ‌های ایمنی کلینیکی مدیریت کند.

چالش بعدی، حذف محرک‌های ناشی از نویز محیط بود. محیط‌های واقعی برخلاف استودیوها، پر از صدا هستند. در طول تست‌ها با میکروفون لپ‌تاپ، Maya به طور تصادفی فعال می‌شد و شروع به صحبت می‌کرد، حتی زمانی که کاربر ساکت بود؛ زیرا VAD صدای فن لپ‌تاپ، تایپ کردن روی کیبورد و صدای نفس کشیدن را به عنوان گفتار تشخیص می‌داد. هر فعال‌سازی اشتباه، منجر به یک فراخوانی STT، یک فراخوانی LLM و یک سنتز TTS می‌شد که هم سهمیه API را می‌سوزاند و هم جریان گفتگو را قطع می‌کرد.

برای حل این موضوع، توسعه‌دهنده پارامترهای Silero VAD و مدیریت نوبت در LiveKit را به دقت تنظیم کرد:

• min_speech_duration: روی ۰.۲۵ ثانیه تنظیم شد تا کلیک‌ها و صداهای کوتاه نفس کشیدن نادیده گرفته شوند.
• min_silence_duration: روی ۰.۶۵ ثانیه تنظیم شد تا از وجود یک مکث تمیز پیش از علامت‌گذاری پایان نوبت کاربر اطمینان حاصل شود.
• activation_threshold: روی ۰.۶ قرار گرفت تا انرژی صوتی باید به اندازه کافی بالاتر از نویز محیط باشد تا سیستم فعال شود.
• مدیریت نوبت: قابلیت «تولید پیش‌دستانه» (preemptive_generation) غیرفعال شد تا صدا تنها پس از تکمیل کامل صحبت کاربر تولید شود. همچنین حداقل مدت زمان برای قطع کردن صحبت (Interruption) روی ۰.۵ ثانیه تنظیم شد.

استقرار (Deployment) یک عامل صوتی به طور بنیادی با چت‌بات‌ها متفاوت است. در حالی که چت‌بات‌ها از درخواست‌های کوتاه HTTP روی پلتفرم‌های Serverless مانند Vercel یا AWS Lambda استفاده می‌کنند، Maya به یک Worker دائمی (Daemon) نیاز دارد که یک سوکت صوتی فعال و دوطرفه را به صورت ۲۴ ساعته با ابر LiveKit حفظ کند.

استراتژی استقرار به این صورت بود:

• رابط کاربری React: روی Vercel مستقر شد و از یک Endpoint توکن Serverless (مسیر /api/token) برای تولید توکن‌های دسترسی موقت JWT استفاده کرد تا Secret Key مربوط به API در مرورگر کاربر لو نرود.
• Worker پایتون: از طریق Docker کانتینری شد و در سرویس Agent Hosting ابر LiveKit در منطقه بمبئی (ap-south) مستقر شد تا پینگ به کمترین مقدار ممکن برسد.

در طول استقرار داکر، توسعه‌دهنده با خطای ModuleNotFoundError: No module named 'agent.prompts' مواجه شد؛ زیرا نقطه ورود برنامه (python agent/agent.py start) باعث می‌شد مسیر /app/agent به جای ریشه (Root) وارد sys.path شود. این مشکل با افزودن ENV PYTHONPATH="/app" به Dockerfile و پیاده‌سازی رزولوشن دفاعی مسیرها در پایتون حل شد.

بومی‌سازی (Localization) نیز نقش کلیدی داشت. توسعه‌دهنده صداهای استاندارد با لهجه آمریکایی را با پروفایل «پریا» از Cartesia جایگزین کرد. این تغییر نه تنها تأخیر را به زیر ۱۰۰ میلی‌ثانیه رساند، بلکه باعث شد آهنگ کلام و تلفظ نام‌های هندی برای کلینیکی واقع در منطقه HSR Layout بمبئی، کاملاً طبیعی و اصیل به نظر برسد.

در بخش منطق کلینیکی، Maya تنها یک زمان‌بند ساده نیست، بلکه قوانین سخت‌گیرانه‌ای را برای شبیه‌سازی یک پذیرشگر واقعی اجرا می‌کند:

• مدیریت تخصص: تفاوت بین تخصص‌های مختلف (مثلاً پزشک عمومی در مقابل دندان‌پزشک) را می‌فهمد و تقویم‌های زنده هر کدام را چک می‌کند.
• جمع‌آوری داده: اگر اطلاعاتی مانند نام یا شماره تلفن ۱۰ رقمی کاربر ناقص باشد، در طول چندین نوبت گفتگو به صورت طبیعی آن‌ها را می‌پرسد.
• منطق رزرو: نوبت‌ها را حداکثر برای ۱۴ روز آینده رزرو می‌کند، تداخل زمانی (Slot Collision) را بررسی می‌کند و پیش از ثبت نهایی در پایگاه‌داده، خلاصه نوبت را بازگو کرده و تاییدیه صریح «بله» را از کاربر می‌گیرد.
• اجرای سیاست‌ها: یک پنجره زمانی سخت‌گیرانه ۲ ساعته برای لغو یا تغییر زمان نوبت‌ها را اجرا می‌کند.
• تریاژ پزشکی: اگر کاربر علائمی شدید مانند درد حاد قفسه سینه یا مشکلات تنفسی را ذکر کند، Maya به جای رزرو نوبت عادی، فوراً به او دستور می‌دهد که با شماره ۱۱۲ تماس بگیرد یا به اورژانس مراجعه کند.

این پروژه ثابت می‌کند که در هوش مصنوعی صوتی، اقتصاد توکن‌ها و حذف نویز به اندازه قدرت استدلال مدل اهمیت دارند. در واقع، تمرکز از «قابلیت مدل» به «ارکستراسیون سیستم» تغییر کرده است. این پروژه یک نقشه راه برای توسعه‌دهندگانی است که می‌خواهند از اپلیکیشن‌های ساده‌ی «پوسته» (Wrapper) فاصله بگیرند و به سمت عامل‌های قدرتمند با تأخیر کم حرکت کنند که بتوانند در محیط‌های خارج از استودیو دوام بیاورند.

گام بعدی شما

• اگر در حال ساخت عامل‌های صوتی هستید، به جای افزایش اندازه مدل، روی کاهش حجم پرامپت‌های سیستمی تمرکز کنید تا نرخ خطای API کاهش یابد.
• پارامترهای VAD را بر اساس محیط واقعی (نه محیط استودیویی) تنظیم کنید تا از فعال‌سازی‌های اشتباه جلوگیری شود.
• برای کاهش تأخیر، Workerهای خود را در نزدیک‌ترین منطقه جغرافیایی به کاربر مستقر کنید.

اما مرز بعدی در این فناوری، مدیریت پیچیده «قطع کردن صحبت» (Interruption) است؛ جایی که مدل باید در لحظه ورود صدای کاربر، صحبت خود را متوقف کند بدون اینکه رشته کلام و بافت (Context) گفتگو را گم کند. به تحلیل ما درباره‌ی مدل‌های استدلالی جدید مراجعه کنید.