تصور کنید دانشجویی هستید که تمام قواعد گرامری انگلیسی را میداند، اما هنگام صحبت با یک انسان، از ترس قضاوت شدن خشکش میزند. BolBuddy دقیقاً برای شکستن این سد روانی ساخته شده است تا دانشجویان هندی بتوانند بدون ترس از اشتباه، تسلط گفتاری خود را بازیابند. این دستیار هوش مصنوعی با اولویت دادن به محیطی کمفشار به جای نمرهدهیهای رسمی، هدفش کاهش «اضطراب صحبت به زبان خارجی» (FLSA) برای یادگیرندگانی است که در حال انتقال به محیطهای کاری حرفهای هستند.
این پروژه در یک دوی ۱۰ روزه توسعه یافت تا شکاف عمیق میان درک غیرفعال (Passive) و تولید فعال (Active) زبان انگلیسی در هند را پر کند. هدف اصلی، کاهش اضطراب صحبت به زبان خارجی است؛ وضعیتی که در آن ترس از قضاوت همکلاسیها، مانعی بزرگتر از خودِ زبان است. همانطور که در پوشش پیشین ما دربارهی فناوریهای صوتی با تأخیر کم مانند NVIDIA Magpie TTS اشاره کردیم — که با تأخیر ۳۲ میلیثانیهای مرزها را جابهجا کرد — BolBuddy بر کاربرد عملی این سرعتها برای حل یک بحران پداگوژیک (آموزشی) تمرکز دارد.
پارادوکس انگلیسی گفتاری در هند
در سراسر هند، بسیاری از دانشجویان و جویندگان کار در ابتدای مسیر شغلی خود با یک مانع زبانی خاص روبرو هستند. آنها میتوانند انگلیسی را از روی کتاب بخوانند، بنویسند و گرامر آن را درک کنند، اما در مکالمات خودجوش دچار مشکل میشوند. در چشمانداز چندزبانه هند، انگلیسی به عنوان زبان کلیدی برای تحصیلات تکمیلی و فرصتهای شغلی عمل میکند. با این حال، محیط کلاس درس اغلب باعث ایجاد عدم تقارن بین درک غیرفعال و تولید گفتاری فعال میشود. این شکاف مهارتی میتواند مشابه چالشهای گستردهتری باشد که در آن کمبود مهارتهای عملی در برابر تئوریهای دانشگاهی میتواند مسیر پیشرفت شغلی متخصصان را مسدود کند.
تحقیقات میدانی گزارش سالانه وضعیت آموزش (ASER) که توسط بنیاد آموزشی Pratham انجام شده، نشان میدهد که آموزشهای پایه انگلیسی در مدارس دولتی و مدارس خصوصی ارزانقیمت، به طور تاریخی بر خواندن متون کوتاه و نوشتن پاسخها تأکید داشتهاند تا ارتباطات شفاهی. در واقع، انگلیسی بیشتر به عنوان یک «درس امتحانی» تدریس شده تا یک «ابزار ارتباطی».
مطالعات آکادمیک توسط Horwitz و همکاران و همچنین تحلیلهای برنامه درسی NCERT در هند، «دلهره ارتباطی» و «ترس از ارزیابی منفی» را به عنوان موانع اصلی برجسته میکنند. این موضوع بهویژه برای یادگیرندگانی که از آموزشهای منطقهای به محیطهای آکادمیک یا کاری انگلیسیزبان منتقل میشوند، صادق است. وقتی یادگیرندگان نگران قضاوت همسالان یا خطاهای گرامری هستند، از صحبت کردن اجتناب میکنند و این امر سرعت توسعه تسلط آنها را کاهش میدهد.
رابطهای صوتی مشکلی را حل میکنند که چتهای متنی قادر به حل آن نیستند. اپلیکیشنهای متنی به کاربران اجازه میدهند تردید کنند، ویرایش کنند، پاک کنند و از فرمولبندی در لحظه اجتناب کنند. اما تسلط گفتاری نیازمند بازیابی سریع واژگان، بیان فونولوژیک و ریتم مکالمه است. یک رابط صوتی محیطی برای تمرین با فشار کم فراهم میکند که در آن یادگیرندگان میتوانند بدون ترس از قضاوت، اشتباه کنند.
جایگاهسازی مسئولانه محصول
BolBuddy با مرزهای مشخصی مهندسی شده است تا اطمینان حاصل شود که یک «همراه» است، نه جایگزینی برای معلم. این سیستم یک مدرس گواهینامهدار، یک ممتحن یا یک ارزیاب برای آزمونهای حساس نیست. در عوض، یک همراه تمرینی ۲۴ ساعته است که برای کمک به یادگیرندگان جهت ایجاد اعتمادبهنفس از طریق تمرینات مکالمهای حمایتی طراحی شده است.
برای حفظ این جایگاه، توسعهدهندگان مجموعهای از پارامترهای سختگیرانه را تعریف کردند:
- BolBuddy چیست: یک ابزار تمرینی کمفشار، یک پل طبیعی برای زبان «هینگلیش»، ارائهدهنده تمرینات گفتاری تکراری، سیستمی که برای ذخیره حافظه به رضایت شفاهی نیاز دارد و ابزاری با قابلیت ارجاع به انسان در شرایط بحرانی.
- BolBuddy چه نیست: جایگزینی برای معلمان، یک سیستم نمرهدهی رسمی، یک مدرس بیخطا، یک جمعکننده خودکار اطلاعات حساس شخصی (PII) یا سیستمی که نتایج قطعی را تضمین کند.
معماری هسته
طبق تحلیل فنی منتشر شده در ۱۴ اوت ۲۰۲۶، BolBuddy به عنوان یک سیستم Full-stack عمل میکند که فرانتاند Next.js 15 را به بکاند Python 3.12 متصل میکند. این سیستم برای مدیریت ترکهای صوتی دوطرفه WebRTC از LiveKit Agents استفاده میکند تا بازیابی بستههای داده با تأخیر کم و بافرهای جیتر تطبیقی (Adaptive Jitter Buffers) تضمین شود.

برای مدیریت تفاوتهای زبانی منطقه، خط لوله (Pipeline) از Deepgram Nova-3 (نسخه en-IN / چندزبانه) برای تبدیل گفتار به متن (STT) استفاده میکند. این مدل خاص به دلیل توانایی در نسخهبرداری از لهجههای انگلیسی هندی و «هینگلیش» — که ترکیب رایج هندی و انگلیسی است — انتخاب شده است.

لایه هوشمند از طریق یک سیستم جایگزین چند-ارائهدهنده (OpenRouter / NVIDIA NIM / Groq / Google Gemini) سازماندهی شده است. در حالی که Google Gemini پایداری را فراهم میکند، توسعهدهندگان از Groq (بهطور خاص مدل llama-3.1-8b-instant) با چرخش چند-کلیدی (Multi-key rotation) استفاده کردند تا به زمان پاسخدهی (TTFT) بین ۳۳۰ تا ۴۴۰ میلیثانیه دست یابند. این سرعت برای جلوگیری از سکوتهای آزاردهندهای که جریان مکالمه را میشکنند، حیاتی است.
برای خروجی صوتی، سیستم از Murf Falcon TTS استفاده میکند که فریمهای گفتار سنتز شده را روی WebSockets استریم میکند. عامل اصلی از صدای «آنیشا» (زن، انگلیسی هندی مکالمهای) و عامل تخصصی مصاحبه از صدای «سامار» (مرد، انگلیسی هندی حرفهای) استفاده میکند.
لایه داده و مشاهدهپذیری
سیستم از یک پایگاهداده محلی SQLite (bolbuddy_memory.db) برای ردیابی پنج جدول خاص استفاده میکند: user_memory (حافظه کاربر)، scheduled_calls (تماسهای زمانبندی شده)، daily_schedules (برنامههای روزانه)، escalations (ارجاعات انسانی) و call_analytics (تحلیل تماسها). این معماری اجازه میدهد جستوجوهای محلی سریع بدون سربار دیتابیسهای برداری ابری انجام شود. این رویکرد در تضاد با ساختارهای پیچیدهتری است که در بررسیهای مهندسی مدلهای زبانی و حافظههای خارجی RAG مورد بحث قرار میگیرند.
نقشه راه ۱۰ روزه ماژولار
ساخت پروژه از طریق یک برنامه زمانی سختگیرانه پیش رفت تا پایداری تضمین شود:
- روز ۱ تا ۳: موتور اصلی. ایجاد حلقه صوتی Real-Time WebRTC، شخصیت چندزبانه و رابط کاربری Voice Orb.
- روز ۴ و ۵: حافظه و ابزارها. یکپارچهسازی SQLite برای حافظه متنی و توسعه تمرینات گفتاری ساختاریافته و سیستم امتیازدهی.
- روز ۶: تلفنی. افزودن تماسهای تمرینی زمانبندی شده از طریق SIP و یکپارچهسازی ماشین وضعیت (State Machine).
- روز ۷: ایمنی انسانی. پیادهسازی پروتکلهای ارجاع انسانی، شامل وبهوکهای دیسکورد و شناسههای مرجع (Reference IDs).
- روز ۸: مشاهدهپذیری. ساخت داشبورد متریکهای لحظهای برای ردیابی تحلیل تماسها.
- روز ۹: تخصصیسازی. توسعه قابلیتهای انتقال بین عاملها (از BolBuddy به InterviewBuddy) با استفاده از صداهای Murf.
- روز ۱۰: ممیزی سیستم. انجام ممیزی کامل کد، تأیید تلهمتری و ایجاد راهنمای عملی توسعهدهنده.

تجربه کاربری و ایمنی
BolBuddy به عنوان یک همراه جایگاهسازی شده است. رابط کاربری به کاربران اجازه میدهد حوزههای تمرکز خاصی مانند «مصاحبه»، «دفاع از پایاننامه (Viva)»، «انگلیسی روزمره» یا «ارائه» را انتخاب کرده و برنامههای تمرینی روزانه را پیکربندی کنند.

در طول جلسات فعال، یک «Voice Orb» بصری بازخورد لحظهای میدهد که آیا عامل در حال گوش دادن، فکر کردن یا صحبت کردن است، در کنار یک نشان (Badge) برای نمایش عامل فعال و نوع صدا.

ایمنی از طریق چندین حفاظ AI مدیریت میشود:
- رضایت شفاهی صریح: BolBuddy نامها، اهداف یا چالشهای تکراری یادگیرنده را بدون درخواست توافق شفاهی ذخیره نمیکند.
- پاکسازی دادهها: دستور «Forget Me» به یادگیرندگان اجازه میدهد سوابق خود را پس از یک درخواست تأیید، از دیتابیس حذف کنند.
- حذف PII: سیستم از فیلترهای Regular Expression برای پاکسازی شماره تلفنها و آدرسهای ایمیل قبل از ارسال هرگونه گزارش ارجاع به وبهوکهای خارجی استفاده میکند.

وقتی کاربر احساس ناراحتی میکند یا درخواست کمک انسانی میدهد، سیستم یک تیکت پشتیبانی (مثلاً ESC-XXXX) باز میکند، آن را در کشوی Human Help نمایش میدهد و یک هشدار پاکسازی شده را از طریق Discord Webhooks به مشاوران تحصیلی ارسال میکند.

پیادهسازی کد تأیید شده
چندین الگوی کلیدی در مخزن کد، استحکام سیستم را تضمین میکنند. برای مدیریت صداهای مختلف بدون تکرار خط لوله، تیم یک Murf Falcon TTS Factory در backend/src/agent.py پیاده کرد. این فکتوری از یک Sentinel به نام NOT_GIVEN استفاده میکند تا اطمینان حاصل شود که دستیار تنظیمات TTS جلسه را به درستی به ارث میبرد.
برای انتقال بین عاملها، یک سیستم Context-Preserving Specialist Handoff ایجاد شد. هنگام انتقال از BolBuddy به InterviewBuddy، بافت مکالمه قبلی یادگیرنده کپی میشود، اما پرامپتهای سیستمی حذف میشوند تا از «نشت دستورالعملها» (Instruction Bleeding) جلوگیری شود.
برای کاهش محدودیتهای نرخ API (Rate Limits) در طول تستهای با حجم بالا، تیم یک GroqKeyManager در backend/src/groq_key_manager.py ساخت. این ابزار از چرخش Round-robin بین چندین کلید پشتیبان پیکربندی شده استفاده میکند تا پاسخدهی سیستم تضمین شود.
در نهایت، تابع scrub_pii در backend/src/escalation_tools.py از Regex برای جایگزینی شماره تلفنها و ایمیلها با [REDACTED_PHONE] و [REDACTED_EMAIL] قبل از ارسال خارجی استفاده میکند.
موانع فنی و راهکارها
تیم توسعه در طول این دوی ۱۰ روزه با چندین باگ بحرانی روبرو شد:
۱. مشکل Sentinel در LiveKit: subclass کردن Agent با tts=None باعث ایجاد RuntimeError میشد زیرا سیستم تصور میکرد گره TTS غیرفعال است. راهکار، پاس دادن tts if tts is not None else NOT_GIVEN برای به ارث بردن تنظیمات سطح جلسه بود.
۲. کرش مرز RSC در Next.js 15: افزودن یک هوک سفارشی useActiveAgent باعث خطای manifest ماژول شد. این مشکل با افزودن دایرکتیو 'use client'; به فایل frontend/hooks/useActiveAgent.ts حل شد، زیرا هوکهایی که از useState یا useEffect استفاده میکنند باید مرزهای کلاینت را در App Router اعلام کنند.
۳. تأخیر در انتقالهای چند-مرحلهای: در ابتدا، انتقال به InterviewBuddy نیاز به چندین مرحله تأیید داشت. تیم قوانین پرامپت را بهروز کرد تا درخواستهای صریح (مثلاً «هفته آینده مصاحبه دارم») تابع transfer_to_interview_buddy را در همان نوبت (Turn) فعال کند.
متریکهای عملکرد
تلهمتری داخلی از دیتابیس bolbuddy_memory.db پایداری فعلی سیستم را نشان میدهد. از ۴۸ جلسه توسعه ثبت شده، ۴۳ جلسه موفقیتآمیز بود که نرخ موفقیت ۸۹.۵۸٪ را نشان میدهد. پنج تماس شکست خورد که دلیل اصلی آنها incomplete_exercise (تمرین ناقص) بود.
سایر متریکهای کلیدی عبارتند از:
- فعالیتهای تکمیل شده: ۲۷ تمرین گفتاری ثبت شده.
- تیکتهای ارجاع: ۱۶ مورد در مجموع (۱۲ باز، ۴ حل شده).
- سوابق حافظه: ۳۴ رکورد در
user_memory. - تماسهای زمانبندی شده: ۲۴ رکورد در
scheduled_calls. - تأخیر: زمان بازگشت End-to-End مشاهده شده در تستهای مرورگر بین ۵۰۰ تا ۷۵۰ میلیثانیه بود.
- تستها: ۷۷ تست واحد (Unit) و یکپارچهسازی (Integration) پاس شده است.
راهنمای ساخت و راهاندازی محلی
برای استقرار محلی BolBuddy، توسعهدهندگان به Python 3.10+ (با مدیریت بسته uv) و Node.js 18+ (با pnpm) نیاز دارند. سیستم به کلیدهای API از LiveKit Cloud، Murf AI، Deepgram و یکی از مدلهای Google Gemini یا Groq نیاز دارد.
گامهای راهاندازی
- پیکربندی محیط: مخزن را کلون کرده و فایلهای
.env.localرا برای فرانتاند و بکاند تنظیم کنید. کلیدهای بکاند باید شاملLIVEKIT_URL،LIVEKIT_API_KEY،LIVEKIT_API_SECRET،MURF_API_KEY،DEEPGRAM_API_KEY،GOOGLE_API_KEY،GROQ_API_KEYو یکDISCORD_WEBHOOK_URLبرای ارجاعات باشد. - اجرا: از اسکریپتهای
start_app.ps1(ویندوز) یاstart_app.sh(مک/لینوکس) استفاده کنید. به صورت دستی، بکاند از طریقuv run python src/agent.py devو فرانتاند از طریقpnpm devاجرا میشود. - تأیید: مجموعه تستها را میتوان با استفاده از
pytestروی فایلهایtest_analytics.py،test_escalation.py،test_memory_db.pyوtest_handoff.pyبرای تأیید پیکربندیهای صدای متخصص اجرا کرد.
عیبیابی عملی
دو مشکل اصلی در طول استقرار شناسایی شد. اول، پخش صدا اغلب در بارگذاری اولیه صفحه شکست میخورد زیرا مرورگرها Autoplay را مسدود میکنند. این مشکل توسط کامپوننت StartAudioButton حل شد که با تعامل کاربر، Context صوتی را مقداردهی اولیه میکند. دوم، تایماوتهای وبهوک دیسکورد با قرار دادن درخواستها در تسکهای پسزمینه غیرمسدودکننده (Non-blocking) با تایماوت ۵ ثانیهای کاهش یافت تا دیالوگ صوتی توسط تأخیر شبکه قطع نشود.
تحلیل تحریریه
BolBuddy نشاندهنده تغییری در آموزش AI از یادگیری «معلم-محور» به یادگیری «محیط-محور» است. با حذف ریسکهای بالای ارزیابی انسانی، این ابزار به جای مانع زبانی، به مانع روانشناختی FLSA میپردازد. این نشان میدهد که آینده یادگیری زبان ممکن است در «شبیهسازیهای کمریسک» باشد تا ارائه برنامههای درسی سنتی.
از نظر فنی، استفاده از دیتابیس محلی SQLite برای حافظه به جای یک ذخیرهساز برداری ابری، یک سبکسازی هوشمندانه است. این کار تأخیر شبکه را برای جستوجوی حافظه به زیر ۵ میلیثانیه کاهش میدهد و ثابت میکند که برای همراهان تک-کاربره، سادگی اغلب بر مقیاسپذیری معماریهای سنگین RAG غلبه میکند.
برای توسعهدهندگان، این پروژه به عنوان یک نقشه راه برای استقرار سریع عاملهای صوتی عمل میکند. ثابت میکند که ترکیب STT تخصصی (Deepgram) با استنتاج سریع (Groq) و TTS استریمینگ (Murf) میتواند یک تجربه بلادرنگ viable ایجاد کند بدون اینکه به یک تیم مهندسی عظیم نیاز باشد.
برای بهبود بیشتر سیستم، توسعهدهندگان قصد دارند بازخورد تلفظ در سطح فونم (Phoneme-level) را با رابط کاربری Waveform بصری یکپارچه کنند، پشتیبانی از گویشهای منطقهای برای انگلیسی تامیلی و بنگالی را گسترش دهند و Trunking حامل PSTN زنده را از طریق Twilio یا Telnyx SIP برای تماسهای تلفنی خروجی خودکار تکمیل کنند.
اگر در حال ساخت عاملهای صوتی هستید، باید مخزن BolBuddy را بررسی کنید تا ببینید چگونه انتقال بین عاملهای متخصص را بدون شکستن جلسه WebRTC مدیریت کردهاند.




گفتگو