دوبله با هوش مصنوعی: معماری و آموخته‌های عملیاتی
دوبله فارسی با هوش مصنوعی چگونه کار می‌کند؟ چهار مرحله از تبدیل گفتار به متن تا میکس، دشواری‌های فارسی و پلتفرم پیرامون مدل‌ها؛ از جمله زنجیره ارائه‌دهندگان پشتیبان که پس از یک قطعی جای سکوت را گرفت.
دوبله با هوش مصنوعی زنجیره‌ای از چهار مرحله مبتنی بر مدل است: تبدیل گفتار به متن و تشخیص گوینده، ترجمه‌ای که در زمان گفتار اصلی بگنجد، صدایی متمایز برای هر گوینده و در پایان هم‌ترازی زمانی و میکس نهایی. مدل‌ها را می‌توان به‌صورت سرویس از ارائه‌دهندگان گرفت. تحویل پیوسته دوبله‌ها به پلتفرم پیرامون آن‌ها بستگی دارد: درگاهی جداگانه برای هر ارائه‌دهنده هوش مصنوعی با جایگزینی خودکار، صف‌های پایدار، کاری که پس از خرابی از همان نقطه ادامه یابد، قیمتی که پیش از اجرا دیده شود و بازگشت وجه هنگام شکست کار. در بوق، که مدیر ارشد فنی آن هستم، یک بار قطعی یکی از ارائه‌دهندگان گفتار به دوبله‌هایی انجامید که به‌جای جمله‌های ازدست‌رفته سکوت داشتند. اکنون گفتار از زنجیره‌ای از ارائه‌دهندگان پشتیبان عبور می‌کند؛ صدایی کمی متفاوت بهتر از سکوت است.
زنجیره دوبله هوش مصنوعی در چهار مرحله
پژوهش‌های دوبله خودکار هم زنجیره‌ای مشابه را توصیف می‌کنند. Federico و همکاران (۲۰۲۰) کار را از یک زنجیره ترجمه گفتار به گفتار (speech-to-speech translation) آغاز کردند و آنچه دوبله لازم دارد را به آن افزودند:
ترجمه ماشینی که خروجی را با طول مطلوب تولید کند.
هم‌ترازی نوایی (prosodic alignment)، یعنی تطبیق عبارت‌ها و مکث‌های ترجمه با بخش‌های گفتار اصلی.
تبدیل متن به گفتار (TTS) با تنظیم دقیق مدت هر جمله.
رندر صوتی که نویز زمینه و طنین استخراج‌شده از صدای اصلی را به گفتار ساخته‌شده می‌افزاید.
در ویدئویی که چند نفر در آن صحبت می‌کنند، یک کار دیگر هم لازم است: باید مشخص شود هر جمله را چه کسی گفته است.
نمودار زنجیره را در اندازه کامل ببینید
بخش‌های بعدی که به تک‌تک مراحل می‌پردازند، پژوهش‌ها و فضای طراحی را شرح می‌دهند: اینکه هر مرحله چه مسئله‌ای را باید حل کند و کجا از کار می‌افتد. این بخش‌ها سازوکار درونی هیچ محصولی را توصیف نمی‌کنند، حتی بوق را. هر جا در این بخش‌ها به بوق اشاره شده، فقط همان چیزی آمده که مطالعه موردی آن می‌گوید، و بخش تلفظ فارسی بر پژوهش خودم در تبدیل متن به گفتار تکیه دارد. بخش‌های مربوط به پلتفرم، روایت دست‌اول من است.
مرحله اول: تبدیل گفتار به متن و تشخیص گوینده
همه مراحل بعدی متن رونویسی‌شده را به ارث می‌برند. واژه‌ای که سامانه تبدیل گفتار به متن، یا به اصطلاح پژوهشی بازشناسی خودکار گفتار (ASR)، از خود بسازد، با همان اطمینانِ واژه‌ای که گوینده واقعاً گفته است ترجمه، به گفتار تبدیل و زمان‌بندی می‌شود. برای فارسی، سودمندترین شواهدِ در دسترس عموم درباره اینکه ASR کجا خطا می‌کند از PSRB می‌آید، مجموعه محکی (benchmark) که در سال ۲۰۲۵ منتشر شد.
تبدیل گفتار به متن فارسی کجا خطا می‌کند؟
مجموعه محک PSRB عملکرد ۱۰ سامانه ASR را، هم تجاری و هم متن‌باز، می‌سنجد. جمع‌بندی مقاله این است که مدل‌ها روی فارسی معیار عموماً خوب کار می‌کنند، اما با لهجه‌های محلی، گفتار کودکان و برخی چالش‌های مشخص زبانی مشکل دارند. جزئیات یافته‌ها به فهرستی از همان صداهایی می‌ماند که مردم برای دوبله می‌آورند:
لهجه. از میان ۱۲ لهجه ارزیابی‌شده، دقت تبدیل گفتار به متن برای مشهدی و یزدی از همه کمتر بود.
کودکان. گفتار کودکان از همه گروه‌های سنی بدتر به متن تبدیل شد.
چند گوینده. همه مدل‌ها روی صدای چندگوینده خطای بیشتری از صدای تک‌گوینده داشتند. نویسندگان هم‌پوشانی گفتار را چالش اصلی چنین صداهایی می‌دانند، هرچند در این مجموعه محک تا حد ممکن از هم‌پوشانی پرهیز شده بود، و برخی مدل‌ها گاهی یک گوینده را به‌طور کامل از متن حذف کردند.
نوع محتوا. کتاب‌های صوتی کمترین نرخ خطا را داشتند. برنامه‌های گفت‌وگومحور، پویانمایی‌ها و فیلم‌ها، که گفت‌وگوی خودجوش، هم‌پوشانی گفتار و نویز زمینه در آن‌ها رایج است، نتیجه‌ای به‌مراتب بدتر داشتند.
سبک گفتار. ۷۱٫۳٪ گفتار این مجموعه محک محاوره‌ای است.
مقاله خطاهایی را هم نام می‌برد که خاص خط و گفتار فارسی‌اند:
مرز واژه. «درختها» با نیم‌فاصله (ZWNJ) نوشته می‌شود. اگر نیم‌فاصله حذف یا با نویسه دیگری جایگزین شود، خروجی «درختها» یا «درخت ها» می‌شود.
جابه‌جایی رسمی و محاوره‌ای. «می‌خوام برم» ممکن است به شکل رسمی «می‌خواهم بروم» نوشته شود، یا برعکس.
کسره‌ای که «ه» نوشته می‌شود (He-Kasreh). کسره‌ای که مالکیت یا پیوند را نشان می‌دهد ممکن است به‌صورت حرف «ه» نوشته شود: «کتاب او» به «کتابه او» تبدیل می‌شود. این همان کسره اضافه است که این بار به‌صورت حرف نوشته شده، یعنی همان آوای نانوشته‌ای که مرحله سوم دوباره به آن برمی‌گردد.
نقل به مضمون. «خوش می‌گذره» ممکن است «حال می‌ده» نوشته شود. معنا می‌ماند، واژه‌ها نه.
توهم (hallucination). متنی روان و منسجم که اصلاً بر پایه صدای ورودی نیست.
نرخ خطای واژه (WER) در شکل ساده‌اش هر جایگزینی را یک واژه کاملاً غلط حساب می‌کند؛ پس یک خطای نیم‌فاصله ممکن است به‌اندازه یک واژه متفاوت، یا حتی بیشتر، جریمه داشته باشد: اگر نیم‌فاصله به فاصله تبدیل شود، یک واژه دو واژه می‌شود و یک جایگزینی به‌اضافه یک درج به حساب می‌آید. PSRB گونه‌ای وزن‌دار بر پایه جایگزینی به نام SW-WER پیشنهاد می‌کند: برای هر جایگزینی، نرخ خطای نویسه (CER) محاسبه و در شمار واژه‌های همان هم‌ترازی ضرب می‌شود، تا خطای فاصله‌گذاری جریمه‌ای کمتر از یک واژه متفاوت داشته باشد. بازیابی متن فارسی هم باید همین نویسه‌ها را نرمال‌سازی کند؛ نوشته جستجوی ترکیبی در RAG فارسی این موضوع را شرح می‌دهد.
برداشت من از این یافته‌ها برای طراحی این است: صداهایی که مردم برای دوبله می‌آورند درست همان‌هایی‌اند که تبدیل گفتار به متن روی آن‌ها از همه ضعیف‌تر است، و جمله‌ای که حاصل توهم یا نقل به مضمون باشد در متن رونویسی‌شده نمی‌ماند؛ به جمله‌ای تبدیل می‌شود که با اطمینان دوبله شده است. دلیل گذاشتن یک نقطه بازبینی پیش از ساخت خروجی همین است. بوق هر دو حالت را ارائه می‌دهد: اجرای کاملاً خودکار، یا توقف برای بازبینی و ویرایش زیرنویس پیش از ساخت خروجی.
تفکیک گوینده: چه کسی، چه زمانی صحبت کرد؟
به تعریف Park و همکاران، تفکیک گوینده (speaker diarization) یعنی تشخیص اینکه «چه کسی، چه زمانی صحبت کرد». در دوبله، همین تعیین می‌کند هر جمله با کدام صدا گفته شود. در سومین دوره چالش DIHARD، سامانه‌های تفکیک گوینده در ۱۱ حوزه متنوع سنجیده شدند و نتیجه این بود که در بسیاری از این حوزه‌ها، از جمله ویدئوهای وب، این مسئله «هنوز تا حل‌شدن فاصله زیادی دارد».
پیشنهاد من این است که در هر زنجیره‌ای، درست پس از تفکیک گوینده، یک بررسی ساده گذاشته شود: آیا هر گوینده تشخیص‌داده‌شده جمله‌ای دارد و آیا هر جمله گوینده‌ای دارد؟ برخی سامانه‌ها در PSRB یک گوینده را به‌طور کامل از متن حذف کردند، و گوینده‌ای که از متن بیفتد، در دوبله اصلاً ترک صوتی نخواهد داشت.
مرحله دوم: ترجمه‌ای که در زمان گفتار اصلی بگنجد
دوبله قیدی تازه به ترجمه می‌افزاید: جمله تازه باید تقریباً در همان مدتی گفته شود که جمله اصلی گفته شد. اگر آزادانه ترجمه کنید، صدای ساخته‌شده یا ناچار است تندتر بخواند، یا جمله روی جمله بعدی می‌افتد.
تطابق زمانی (isochrony): طول ترجمه و مدت گفتار یک مسئله‌اند
نام این قید در پژوهش‌ها isochrony است که در فارسی می‌توان آن را تطابق زمانی نامید. Chronopoulou و همکاران (۲۰۲۳) آن را این‌گونه توصیف می‌کنند: گفتار تازه باید با ویدئوی اصلی هم‌تراز زمانی باشد، «از جمله حرکت دهان، مکث‌ها و حرکات دست». آن‌ها مدلی را آموزش می‌دهند که ترجمه و مدت گفتار آن را با هم بهینه می‌کند، و گزارش می‌دهند که گفتار حاصل، در مقایسه با کارهای پیشین، بهتر با زمان‌بندی گفتار اصلی منطبق است و معماری سامانه هم ساده‌تر می‌شود.
کارهای پیشین طول را در خود متن کنترل می‌کردند. Isometric MT (Lakew و همکاران، ۲۰۲۲، ICASSP) برای نمونه ترجمه‌ای را هدف می‌گیرد که شمار نویسه‌هایش در بازه ±۱۰٪ طول متن مبدأ باشد، و بهای این کار را هم پنهان نمی‌کند: کنترل طول خروجی از کیفیت ترجمه می‌کاهد، و راه معمول جبران آن تولید چند ترجمه نامزد (فرضیه‌های N-best) و سپس رتبه‌بندی دوباره آن‌هاست. رقم ±۱۰٪ مثالی است که همین یک مقاله آورده است، نه قاعده‌ای در صنعت؛ شمار نویسه‌ها هم فقط شاخصی تقریبی برای مدتِ گفتن یک جمله است.
وقتی ریتم گفتار به هم بخورد، شنونده بی‌درنگ متوجه می‌شود. صفحه راهنمای دوبله خودکار یوتیوب سرعت گفتار را یکی از دلایلی می‌شمارد که ممکن است ویدئو به‌سبب آن واجد شرایط دوبله نباشد: گفتار اصلی‌ای که بیش از حد تند باشد «به دوبله‌ای تندشده می‌انجامد که نمی‌توان به آن گوش داد».
زمان‌بندی دوبله تا چه حد باید دقیق باشد؟
برای گوینده‌ای که در قاب دیده می‌شود سخت‌گیرانه‌تر از روایت خارج از قاب؛ و اگر دوبله حرفه‌ای را ملاک بگیریم، نه چنان مطلق که پژوهش‌ها اغلب فرض می‌کنند. Brannon، Virkar و Thompson (TACL، ۲۰۲۳) شیوه دوبله انسانی را با بررسی ۳۱۹٫۵۷ ساعت ویدئو از ۵۴ عنوانی که به‌صورت حرفه‌ای تولید شده‌اند مطالعه کردند. نتایج آن‌ها چند فرض رایج را، هم در ادبیات دوبله انسانی و هم در پژوهش‌های دوبله خودکار، زیر سؤال می‌برد. استدلال آن‌ها این است که طبیعی بودن صدا و کیفیت ترجمه از قیدهای هم‌طولی (طول نویسه‌ای) و هماهنگی با لب، که معمولاً بر آن‌ها تأکید می‌شود، مهم‌ترند، و اهمیت قیدهای زمان‌بندی را باید با احتیاط بیشتری سنجید.
دیده‌شدن گوینده در قاب هم اهمیت دارد. Virkar و همکاران (۲۰۲۲) مدل هم‌ترازی نوایی خود را، که پیش‌تر برای دوبله گوینده در قاب ساخته بودند، به دوبله خارج از قاب (off-screen) گسترش دادند؛ دوبله‌ای که «به قیدهای همگام‌سازی کمتر سخت‌گیرانه‌ای نیاز دارد». پس میزان سخت‌گیری در زمان‌بندی را باید برای هر صحنه جداگانه تعیین کرد، نه با یک تنظیم سراسری.
درباره بوق، آنچه منتشر شده این است که زمان‌بندی با نسخه اصلی هماهنگ می‌شود. مطالعه موردی بیش از این درباره زمان‌بندی نمی‌گوید و من هم در اینجا ادعایی فراتر از آن نمی‌کنم.
مرحله سوم: تبدیل متن به گفتار با صدایی متمایز برای هر گوینده
در بوق، هر گوینده تشخیص‌داده‌شده صدایی متمایز می‌گیرد. هر دوبله چندگوینده‌ای از صداهایش دو ویژگی می‌خواهد: دو گوینده نباید شبیه هم به گوش برسند، و هر گوینده باید از نخستین تا آخرین جمله همان صدا را داشته باشد. ویژگی دوم را به خاطر بسپارید؛ در کالبدشکافی مهندسی بوق در ادامه خواهید دید که همین ویژگی چگونه به سکوت باخت.
داده گفتاری آزاد برای فارسی اندک است. نویسندگان ParsVoice می‌نویسند که فارسی در منابع آزاد گفتار و متن «همچنان سهمی بسیار ناچیز دارد». پیکره آن‌ها زیرمجموعه‌ای آماده برای TTS با ۲٬۲۰۰ ساعت گفتار دارد که بیش از ۲۵ برابر بزرگ‌ترین مجموعه داده آزاد TTS فارسی پیش از آن است. داده یکی از قیدهاست. قید دیگر پیش از ساخته‌شدن هر صدایی پیدا می‌شود: اینکه متن اصلاً چگونه باید خوانده شود.
تلفظ فارسی: اِعراب، ساخت اضافه و هم‌نگاشت‌ها
از تیر ۱۴۰۰ تا مهر ۱۴۰۱ روی پژوهش تبدیل متن به گفتار فارسی کار کردم. این پژوهش به سفارش و زیر نظر همراه اول، بزرگ‌ترین اپراتور تلفن همراه ایران، و با مدیریت بنیاد ملی نخبگان در قالب طرح شهید احمدی روشن انجام شد. بخش دشوار کار زبانی بود. در آن زنجیره، متن نوشته‌شده ابتدا از تبدیل نویسه به واج (G2P) می‌گذرد که تعیین می‌کند متن چگونه تلفظ شود؛ سپس مدل تبدیل متن به گفتار و وکودر، گفتار را می‌سازند. وکودر جزئی است که خروجی آکوستیکی مدل را به شکل موج صوتی تبدیل می‌کند. خط فارسی همان گام نخست را از سه جهت مبهم می‌کند:
اِعراب در نوشتار نمی‌آید، بنابراین تلفظ را نمی‌توان فقط از روی متن تعیین کرد.
ساخت اضافه هم نوشته نمی‌شود و باید استنتاج شود.
هم‌نگاشت‌ها واژه‌هایی متفاوت با املایی یکسان‌اند و بدون بافت از هم تفکیک نمی‌شوند.
پژوهش‌های منتشرشده هم همین را می‌گویند. نویسندگان GE2PE (Findings of EMNLP، ۲۰۲۴) کسره اضافه را آوای /e/ می‌دانند که اسم را به صفت و به اسم توصیفی پیوند می‌دهد، و برای هم‌نگاشت مثالی می‌آورند: کِرْم، کِرِم و کَرَم در نوشتار یکسان‌اند و هر سه «کرم» نوشته می‌شوند. نتیجه آن‌ها این است که G2P فارسی برای رسیدن به نتیجه قابل‌قبول به ورودی در سطح عبارت یا جمله نیاز دارد. Doostmohammadi و همکاران (۲۰۲۰) نیز می‌افزایند که کسره اضافه تقریباً هیچ‌گاه در خط فارسی نشان داده نمی‌شود و همین به اشتباه در خواندن جمله‌های پیچیده و خطا در پردازش زبان می‌انجامد. خود پروژه در مطالعه موردی پژوهش تبدیل متن به گفتار فارسی شرح داده شده است.
نتیجه‌ای که من از این یافته‌ها برای طراحی می‌گیرم برداشت خودم است، نه حرف آن مقاله‌ها: متن را در قالب همان تکه‌های کوتاه زیرنویس به TTS فارسی ندهید. مرز زیرنویس ممکن است یک ترکیب اضافی را از میانه دو نیم کند، یا هم‌نگاشتی را از واژه‌هایی که ابهامش را برطرف می‌کنند جدا کند. اگر عبارتی مانند «کتابِ دوستِ من» میان دو زیرنویس بریده شود و تکه نخست به «کتاب» ختم شود، در آن تکه دیگر هیچ نشانه‌ای نمانده که «کتاب» باید با کسره خوانده شود. جمله کامل را به گفتار تبدیل کنید و سپس صدا را روی خط زمانی جا دهید.
مرحله چهارم: هم‌ترازی زمانی و میکس نهایی
مرحله آخر، قطعه‌های گفتار را به باند صوتی‌ای تبدیل می‌کند که از آنِ خود ویدئو باشد. در زنجیره Federico، رندر صوتی نویز زمینه و طنین استخراج‌شده از صدای اصلی را به گفتار می‌افزاید تا صدای تازه در همان فضای صوتی تصویر بنشیند.
در بوق، خروجی نهایی می‌تواند زیرنویس سبک‌دار و حک‌شده روی تصویر برای ویدئوی عمودی و افقی داشته باشد و صدای اصلی یا موسیقی زمینه را آرام زیر دوبله نگه دارد. زیرنویس حک‌شده جزئی از خود تصویر است، پس چیدمان آن باید پیش از ساخت خروجی و برای هر نسبت تصویر تعیین شود؛ هیچ پخش‌کننده‌ای بعداً نمی‌تواند آن را اصلاح کند.
دو پرسش طراحی به این مرحله مربوط است. نخست اینکه با جمله‌ای که صدای ساخته‌شده‌اش پس از ترجمه هنوز از زمانی که در اختیار دارد طولانی‌تر است، چه باید کرد. پژوهش‌ها و تجربه عملی سه راهکار پیش رو می‌گذارند و انتخاب میان آن‌ها تصمیمی طراحی است، نه یافته‌ای پژوهشی:
کوتاه کردن جمله در مرحله ترجمه. در این نقطه، Isometric MT و مدل‌هایی که ترجمه و مدت گفتار را با هم بهینه می‌کنند به کار می‌آیند.
تنظیم مدت هر جمله در مرحله TTS. زنجیره Federico مدت هر جمله را به‌دقت تنظیم می‌کند.
تندتر کردن صدا، در حدی معقول. این راهکار از تجربه عملی می‌آید، نه از پژوهش، و فقط تا حدی کارساز است: صفحه راهنمای یوتیوب هشدار می‌دهد دوبله‌ای که بیش از حد تند شود، ممکن است دیگر شنیدنی نباشد.
پرسش دوم این است که شنونده در جایی که جمله‌ای ساخته نشده چه می‌شنود. معلوم شد این یکی پرسشی معماری است، نه صوتی.
پلتفرم پیرامون مدل‌ها
هر آنچه تا اینجا آمد یا پژوهشی است که می‌توان خواند، یا مدلی که می‌توان به‌صورت سرویس گرفت. در بوق، هر قابلیت به ارائه‌دهندگان بیرونی هوش مصنوعی وابسته است و هرکدام ممکن است مستقل از دیگران از کار بیفتد یا تغییر کند. در نقش مدیر ارشد فنی، معماری بوق را طراحی کردم و آن را از نخستین خط کد به بهره‌برداری رساندم؛ مطالعه موردی بوق این پلتفرم را شرح می‌دهد. همه آموخته‌های کالبدشکافی مهندسی آن به پیرامون مدل‌ها مربوط‌اند، نه به درون آن‌ها.
نمودار پلتفرم را در اندازه کامل ببینید
یک درگاه برای هر ارائه‌دهنده هوش مصنوعی
بوق مجموعه‌ای از سرویس‌های مستقل پشت یک وب‌اپلیکیشن است و هر ارائه‌دهنده هوش مصنوعی درگاه اختصاصی خود را دارد. همین یک تصمیم است که اجازه می‌دهد مدلی عوض شود، کلیدی جایگزین شود یا ارائه‌دهنده‌ای که از کار افتاده به‌طور خودکار کنار گذاشته شود، بی‌آنکه بقیه محصول دست بخورد. مدل‌ها و کلیدهای ارائه‌دهندگان بدون استقرار دوباره از پنل مدیریت تغییر می‌کنند. مطالعه موردی هر درگاه را همراه با جایگزینی خودکار توصیف می‌کند، و کالبدشکافی مهندسی در ادامه نشان می‌دهد چرا گفتار به آن نیاز داشت.
صف‌های اولویت‌دار پایدار و نقطه بازیابی
دوبله یک ویدئوی طولانی جایش درون یک درخواست وب نیست. در بوق، پردازش‌های سنگین به‌جای آن در صف‌های اولویت‌دار و پایدار با سقف هم‌زمانی برای هر سرویس منتظر می‌مانند. همین سقف جداگانه است که نمی‌گذارد یک سرویس پرمشغله ظرفیت سرویس‌های دیگر را از آن خود کند.
ترجمه‌ها نقطه بازیابی (checkpoint) ذخیره می‌کنند و پس از خرابی از همان‌جا ادامه می‌یابند. بدون نقطه بازیابی، خرابی در نزدیکی پایان یک متن طولانی یعنی تکرار همه فراخوانی‌هایی که پیش از آن به ارائه‌دهنده انجام شده بود، و پرداخت دوباره هزینه تک‌تک آن‌ها.
بارگذاری قابل ادامه روی اتصال ناپایدار
فایل‌های ویدئویی حجیم روی اتصال‌های ناپایدار به بوق می‌رسند، و بارگذاری‌ها، از جمله فایل‌های چندگیگابایتی، روی شبکه ضعیف از سر گرفته می‌شوند، نه از نو.
سازوکار عمومی این کار در حال استاندارد شدن است. گروه کاری HTTP در IETF روی پیش‌نویس اینترنتی (Internet-Draft) فعالی با عنوان «Resumable Uploads for HTTP» کار می‌کند که هنوز به RFC تبدیل نشده است: اگر سرور بتواند اعلام کند پیش از قطع اتصال چه مقدار از داده را پردازش کرده است، کلاینت از همان نقطه ادامه می‌دهد و لازم نیست همه داده را دوباره بفرستد. این پیش‌نویس هنوز در دست تکمیل است و توصیفی از پیاده‌سازی بوق نیست.
قیمت پیش از اجرا، بازگشت وجه هنگام شکست
پرداخت و صورت‌حساب هم بخشی از زنجیره است. هر کار در بوق پیش از اجرا قیمت یا برآورد اولیه خود را نشان می‌دهد. کیف پول پیش‌پرداخت و تومانی است و مالیات بر ارزش افزوده پیش از پرداخت نمایش داده می‌شود؛ هر تراکنش در دفتری دائمی ثبت می‌شود و بازگشت وجه برای کاری که شکست بخورد خودکار انجام می‌شود. بازگشت وجه‌ها هم طوری محافظت شده‌اند که هرگز دو بار انجام نشوند.
همین ویژگی آخر سخت‌ترین آزمون را می‌طلبد: تلاش دوباره (retry) پس از پایان مهلت پاسخ (timeout) درست همان لحظه‌ای است که یک سازوکار ساده‌انگارانه، وجه را دو بار برمی‌گرداند.
تنظیم به‌جای انتشار نسخه
بخش‌های محصول در بوق بدون انتشار نسخه جدید روشن یا خاموش می‌شوند. در دسته‌بندی Pete Hodgson از کلیدهای قابلیت (feature toggles)، این به کلید عملیاتی (ops toggle) نزدیک است: کلیدی که به گردانندگان سامانه اجازه می‌دهد قابلیتی را در محیط عملیاتی به‌سرعت غیرفعال یا محدود کنند.
دسترسی‌ها هم با همین منطق از هم جدا شده‌اند. مشتریان، مدیران و کارکنان پشتیبانی هرکدام از اپلیکیشنی جداگانه با استقرار مستقل استفاده می‌کنند، ورود به یکی در دیگری معتبر نیست، و پنل‌ها ورود دومرحله‌ای و مجوزهای نقش‌محور دارند.
کالبدشکافی مهندسی: وقتی یکسانی صدا به سکوت باخت
گفتار در بوق در ابتدا عمداً به یک ارائه‌دهنده ثابت محدود شده بود، چون ارائه‌دهنده دیگر یعنی صدایی دیگر. در دوبله، یکسانی صدا همان ویژگی‌ای به نظر می‌رسید که باید از آن محافظت کرد. سپس آن ارائه‌دهنده دچار قطعی شد و دوبله‌ها با سکوت به‌جای جمله‌های ازدست‌رفته ساخته شدند.
اکنون گفتار از زنجیره‌ای از ارائه‌دهندگان پشتیبان عبور می‌کند، با این اصل که صدایی کمی متفاوت بهتر از سکوت است.
طراحی آگاهانه زنجیره ارائه‌دهندگان پشتیبان
انتخاب نخست از سر بی‌دقتی نبود؛ از ویژگی‌ای واقعی محافظت می‌کرد. مطالعه موردی، تغییر مسیرهایی را که اداره پلتفرم در محیط عملیاتی پیش آورد، در یک جمله خلاصه می‌کند: در هر مورد «فرضی راحت جای خود را به پیش‌فرضی امن‌تر داد». درس این است که پیش از آنکه قطعی به‌جای شما تصمیم بگیرد، تعیین کنید کدام شکست را می‌پذیرید. وقتی ارائه‌دهنده ترجیحی گفتار در دسترس نیست، زنجیره دوبله سه راه دارد: جای خالی بگذارد، کار را ناموفق اعلام کند و وجه را بازگرداند، یا از صدای دیگری استفاده کند. از این سه، فقط جای خالی است که دوبله‌ای بریده‌بریده به دست شنونده می‌دهد.
پس از آن تصمیم دومی لازم است، و آنچه در ادامه می‌آید تحلیل من است، نه توصیف رفتار بوق: جایگزینی تا چه دامنه‌ای انجام شود. اگر فقط جمله ازدست‌رفته از ارائه‌دهنده دیگری گرفته شود، صدای آن گوینده در میانه صحنه عوض می‌شود. اگر کل ترک صوتی آن گوینده جایگزین شود، دوبله یکسان می‌ماند، اما بخش بیشتری از کار دوباره انجام می‌شود.
کتاب SRE گوگل اندیشه‌ای نزدیک به این را برای سرویس‌های زیر بار بیش از حد شرح می‌دهد: افت کیفیت کنترل‌شده (graceful degradation)، یعنی انجام کار کمتر با پایین آوردن کیفیت پاسخ‌ها. آنچه از این اندیشه به کار زنجیره دوبله می‌آید هشدار همان کتاب است که «مسیری از کد که هرگز به کار نمی‌رود، همان مسیری است که (اغلب) کار نمی‌کند»، و توصیه‌اش به اینکه حالت افت کیفیت به‌طور منظم اجرا شود تا از کار کردنش مطمئن بمانید. پیشنهاد من برای هر زنجیره ارائه‌دهندگان پشتیبان گفتار، که توصیه است و نه توصیف رفتار بوق، این است که کارهای آزمایشی دوره‌ای روی کلیپ‌های داخلی از مسیر تک‌تک ارائه‌دهندگان زنجیره اجرا شوند، تا پیش از آنکه قطعی به این مسیر نیاز پیدا کند، معلوم باشد که کار می‌کند.
اینکه کدام شکست درست است، به محصول بستگی دارد. دستیار همین سایت برعکس رفتار می‌کند: وقتی در سایت هیچ مطلبی پشتوانه پاسخ یک پرسش نباشد، به‌جای حدس زدن با متنی ثابت از پاسخ امتناع می‌کند، و اگر تشخیص ندهد که آن پرسش درباره من است، مدل زبانی اصلاً فراخوانی نمی‌شود. در پرسش و پاسخ، سکوت شکست امن است، چون پاسخ نادرستی که با اطمینان داده شود از نبودن پاسخ بدتر است. این طراحی در نوشته جلوگیری از توهم هوش مصنوعی در RAG شرح داده شده و صفحه RAG در برابر پاسخ خام در آزمایشگاه سایت بر همین قاعده بنا شده است. در دوبله، سکوت خودِ شکست است. اینکه کدام شکست پذیرفتنی است تصمیمی محصولی است، نه تصمیمی درباره مدل.
بررسی محتوا بدون معطل کردن کاربر
بررسی محتوا در بوق پیش‌تر درون فرایند ساخت پروژه اجرا می‌شد و کاربر میان پایان بارگذاری و رسیدن به صفحه پروژه منتظر می‌ماند. اکنون در پس‌زمینه اجرا می‌شود. تصویر، ویدئو، صدا و متن بررسی می‌شوند و امکان تجدیدنظر وجود دارد، و نتیجه آماده تا پایان بررسی با وضعیت «بررسی محتوا در جریان است» نگه داشته می‌شود. خروجی تا وقتی بررسی‌اش تمام نشده، آماده نشان داده نمی‌شود.
این الگو برای هر بررسی کندی در زنجیره‌های رسانه‌ای کاربرد دارد: آن را از مسیر درخواست بیرون بیاورید و وضعیت میانی را صریح و قابل‌نمایش کنید.
تأیید دستی انتشار و نسخه پشتیبانی که کسی آن را خوانده باشد
استقرار در محیط عملیاتی بوق از حالت خودکار به تأیید دستی تغییر کرد؛ تأییدی که تنها پس از موفقیت آزمون‌های محیط آزمایشی فعال می‌شود. هر انتشار پیش از آنکه یک نفر آن را برای محیط عملیاتی تأیید کند، از ساخت، آزمون، استقرار در محیط آزمایشی و آزمون سلامت (smoke test) عبور می‌کند، و بازگشت اضطراری به نسخه قبل را می‌توان به‌صورت دستی آغاز کرد. پلتفرم روی یک خوشه کانتینری اجرا می‌شود که به‌صورت کد تعریف شده است.
پشتیبان‌گیری ساعتی شد و تازه‌ترین نسخه از ابتدا تا انتها خوانده شد، چون نسخه پشتیبانی که هیچ‌کس آن را نخوانده باشد، پشتیبان نیست. کتاب SRE گوگل همین را بی‌پرده‌تر می‌گوید: «هیچ‌کس واقعاً نمی‌خواهد نسخه پشتیبان بگیرد؛ آنچه همه واقعاً می‌خواهند بازیابی است.» همان کتاب معیار بالاتری هم می‌گذارد: فقط وقتی می‌دانید می‌توانید وضعیت اخیر را بازیابی کنید که واقعاً این کار را انجام داده باشید، پس آزمون‌های بازیابی باید هر جا ممکن است خودکار شوند و پیوسته اجرا شوند. خواندن کامل یک نسخه پشتیبان کف کار است، نه خط پایان.
ساختن یا خریدن: چک‌لیست ارزیابی هر سامانه دوبله هوش مصنوعی
شکست و مسیر جایگزین
وقتی ارائه‌دهنده گفتار در میانه کار از دسترس خارج شود، شنونده چه دریافت می‌کند: سکوت، صدایی دیگر، یا کاری ناموفق با بازگشت وجه؟ پیش از آنکه قطعی تصمیم بگیرد، تصمیم بگیرید.
وقتی مسیر جایگزین به کار می‌افتد، فقط یک جمله را جایگزین می‌کند یا کل ترک صوتی گوینده را؟
آیا مسیر جایگزین با کارهای آزمایشی دوره‌ای به‌طور منظم و عمدی آزموده می‌شود، یا فقط هنگام قطعی به کار می‌افتد؟
پلتفرم و پرداخت
آیا هر ارائه‌دهنده هوش مصنوعی پشت درگاه خودش است، تا تغییر مدل، جایگزینی کلید یا کنار گذاشتن یک ارائه‌دهنده به انتشار نسخه نیاز نداشته باشد؟
آیا کارهای سنگین بیرون از درخواست وب و از صف‌های پایدار با سقف جداگانه برای هر سرویس اجرا می‌شوند؟
آیا ترجمه طولانی می‌تواند از نقطه بازیابی ادامه یابد، و آیا بارگذاری بزرگ پس از قطع اتصال از سر گرفته می‌شود؟
آیا قیمت یا برآورد پیش از اجرای کار نمایش داده می‌شود، و آیا مطمئن هستید وجه هرگز دو بار برگردانده نمی‌شود؟
آیا بررسی محتوا بیرون از مسیر درخواست است و وضعیت صریح «در حال بررسی» دارد؟
تبدیل گفتار به متن، زمان‌بندی و صداها
آیا تبدیل گفتار به متن روی صداهای خودتان آزموده شده است: لهجه‌ها، کودکان، گفتار محاوره‌ای، چند گوینده، صدای فیلم و برنامه‌های گفت‌وگومحور، نه فقط کتاب صوتی؟
آیا در محاسبه WER شما، خطای نیم‌فاصله یک واژه کاملاً غلط حساب می‌شود؟ پیش از محاسبه، متن را نرمال‌سازی کنید یا از معیاری وزن‌دار مانند SW-WER استفاده کنید.
پس از تفکیک گوینده، آیا هر گوینده تشخیص‌داده‌شده جمله و صدا دارد؟
آیا پیش از ساخت خروجی، نقطه‌ای برای بازبینی و ویرایش زیرنویس وجود دارد؟
زمان‌بندی برای این محتوا تا چه حد باید دقیق باشد: چهره‌ها در قاب، یا روایت خارج از قاب؟
آیا TTS فارسی جمله کامل دریافت می‌کند، نه تکه‌های زیرنویسی که ترکیب‌های اضافی را از میانه قطع می‌کنند؟
انتشار و پشتیبان‌گیری
آیا پس از آزمون‌های محیط آزمایشی و آزمون سلامت، یک نفر انتشار در محیط عملیاتی را تأیید می‌کند، و آیا می‌توان به‌صورت دستی به نسخه قبل بازگشت؟
آیا کسی تاکنون یک نسخه پشتیبان را از ابتدا تا انتها خوانده است؟
پرسش‌های متداول
دوبله با هوش مصنوعی چگونه کار می‌کند؟
زنجیره دوبله با هوش مصنوعی گفتار اصلی را به متن تبدیل می‌کند و تشخیص می‌دهد چه کسی صحبت می‌کند، هر جمله را طوری ترجمه می‌کند که تقریباً در زمان اصلی گفته شود، به هر گوینده صدای ساخته‌شده متمایزی می‌دهد و سپس زمان‌بندی را با گفتار اصلی هم‌تراز می‌کند و گفتار تازه را با صدای زمینه اصلی میکس می‌کند. در محیط عملیاتی، این مراحل درون پلتفرمی از صف‌ها و درگاه‌های ارائه‌دهنده با مسیر جایگزین اجرا می‌شوند و بهتر است پیش از ساخت خروجی یک نقطه بازبینی هم داشته باشند.
آیا می‌توان ویدئوی انگلیسی را با هوش مصنوعی به فارسی دوبله کرد؟
از نظر فنی بله؛ زنجیره برای هر جفت زبان یکسان است. دوبله فارسی با هوش مصنوعی در مرحله صدا دشواری ویژه‌ای دارد، چون خط فارسی اِعراب و کسره اضافه را نمی‌نویسد و تلفظ باید از بافت استنتاج شود. پشتیبانی سرویس‌های همگانی از فارسی هم یکسان نیست: در بازبینی شهریور ۱۴۰۵، صفحه راهنمای دوبله خودکار یوتیوب فارسی را زبان مبدئی فهرست کرده بود که به انگلیسی دوبله می‌شود، و ویدئوهای انگلیسی در آن قابل دوبله به فارسی فهرست نشده بودند.
آیا دوبله هوش مصنوعی با حرکت لب هماهنگ است؟
نه لزوماً، و همیشه هم لازم نیست. پژوهش‌های تطابق زمانی (isochrony) همین را هدف می‌گیرند: گفتار تازه‌ای که با ویدئوی اصلی، از جمله حرکت دهان، مکث‌ها و حرکات دست، هم‌تراز زمانی باشد. اینکه این هماهنگی تا چه حد دقیق باشد، انتخابی طراحی است. همگام‌سازی در دوبله خارج از قاب لازم نیست به سخت‌گیری دوبله گوینده‌ای باشد که دهانش در تصویر دیده می‌شود، و یک مطالعه بزرگ روی دوبله حرفه‌ای انسانی استدلال می‌کند که طبیعی بودن صدا و کیفیت ترجمه از قید هماهنگی با لب، که معمولاً بر آن تأکید می‌شود، مهم‌ترند.
چرا گاهی در دوبله هوش مصنوعی سکوت یا صدای متفاوت شنیده می‌شود؟
یک علت، از کار افتادن ارائه‌دهنده گفتار در میانه کار است. زنجیره‌ای که به یک ارائه‌دهنده محدود است صداها را یکسان نگه می‌دارد، اما هنگام قطعی ممکن است جای خالی بگذارد؛ زنجیره‌ای با مسیر جایگزین، جای جمله را با صدایی کمی متفاوت پر می‌کند. بوق پس از قطعی‌ای که به دوبله‌هایی با سکوت به‌جای جمله‌های ازدست‌رفته انجامید، از طراحی نخست به طراحی دوم رسید. سکوت ممکن است ریشه در مراحل پیشین هم داشته باشد: وقتی تبدیل گفتار به متن گوینده‌ای را حذف کند و چیزی برای ترجمه باقی نماند.
کیفیت تبدیل گفتار به متن فارسی را چگونه باید سنجید؟
روی صداهای خودتان، نه فقط روی گفتار خوانده‌شده و تمیز. لهجه‌های محلی، صدای کودکان، گفتار چند گوینده و صدای فیلم یا برنامه گفت‌وگومحور را، که PSRB در همه آن‌ها خطای بیشتری یافت، به‌همراه گفتار محاوره‌ای در مجموعه آزمون بگذارید. پیش از محاسبه خطا، نیم‌فاصله و شکل‌های عربی و فارسی حروف «ی» و «ک» را نرمال‌سازی کنید، یا از معیاری وزن‌دار بر پایه جایگزینی مانند SW-WER استفاده کنید، و خود خطاها را هم بخوانید، نه فقط نرخ را: یک عدد خطای فاصله‌گذاری را از جمله‌ای روان که گوینده هرگز نگفته جدا نمی‌کند.
اگر ساخت یا ارزیابی یک سامانه گفتار یا دوبله را در پیش دارید، بخش هوش مصنوعی گفتار در صفحه خدمات، تبدیل متن به گفتار، تبدیل گفتار به متن و خطوط دوبله را، از جمله موارد دشوار فارسی، پوشش می‌دهد.
منابع
بوق: ترجمه و دوبله ویدئو با هوش مصنوعی، فارسی‌محور، مطالعه موردی در همین سایت
پژوهش تبدیل متن به گفتار فارسی برای همراه اول، مطالعه موردی در همین سایت
Sedghiyeh و همکاران (۲۰۲۵، arXiv)، PSRB: A Comprehensive Benchmark for Evaluating Persian ASR Systems (متن کامل)
Federico و همکاران (۲۰۲۰، arXiv)، From Speech-to-Speech Translation to Automatic Dubbing
Chronopoulou و همکاران (۲۰۲۳، arXiv)، Jointly Optimizing Translations and Speech Timing to Improve Isochrony in Automatic Dubbing
Lakew و همکاران (۲۰۲۲، ICASSP)، Isometric MT: Neural Machine Translation for Automatic Dubbing
Virkar و همکاران (۲۰۲۲، arXiv)، Prosodic Alignment for off-screen automatic dubbing
Brannon، Virkar و Thompson (۲۰۲۳، TACL)، Dubbing in Practice: A Large Scale Study of Human Localization With Insights for Automatic Dubbing
راهنمای یوتیوب، Use automatic dubbing، تاریخ بازبینی: شهریور ۱۴۰۵
Park و همکاران (۲۰۲۲، Computer Speech & Language)، A Review of Speaker Diarization: Recent Advances with Deep Learning
Ryant و همکاران (۲۰۲۰، arXiv)، The Third DIHARD Diarization Challenge
Rahmati و Sameti (۲۰۲۴، Findings of EMNLP)، GE2PE: Persian End-to-End Grapheme-to-Phoneme Conversion
Doostmohammadi و همکاران (۲۰۲۰، arXiv)، Persian Ezafe Recognition Using Transformers and Its Role in Part-Of-Speech Tagging
Ranjbar Kalahroodi، Faili و Shakery (۲۰۲۶، EMNLP؛ پذیرفته‌شده، نسخه ۴ در arXiv در شهریور ۱۴۰۵)، ParsVoice: A Large-Scale Multi-Speaker Persian Speech Corpus for Text-to-Speech Synthesis
گوگل، Site Reliability Engineering: Addressing Cascading Failures
گوگل، Site Reliability Engineering: Data Integrity: What You Read Is What You Wrote
گروه کاری HTTP در IETF، Resumable Uploads for HTTP، پیش‌نویس اینترنتی
Pete Hodgson (۲۰۱۶، بازنگری ۲۰۱۷، martinfowler.com)، Feature Toggles (aka Feature Flags)