«تفاوت دیالوگ و سکوت»؛ کلید کاهش خطای سیستم‌های کپشن‌نویس هوشمند

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

اتوماسیون فرآیند حک کردن (Burn-in) زیرنویس‌ها شامل زنجیره‌ای شکننده از ویدیوهای مولد، تبدیل گفتار به متن (Transcription) و رندرینگ با ffmpeg است. این خط لوله کوچک است: ابتدا کلیپ تولید می‌شود، سپس تبدیل به متن شده، یک فایل با فرمت .ass نوشته می‌شود و در نهایت ffmpeg زیرنویس را روی تصویر حک می‌کند. اکثر توسعه‌دهندگان تصور می‌کنند اگر یک زیرنویس بیش از حد روی صفحه بماند، حتماً یک باگ است که ناشی از گسترش یک بخش توسط هوش مصنوعی به فضای سکوت انتهایی است. این یک حالت شکست رایج در ابزارهایی مانند OpenAI Whisper است که ممکن است با خوش‌حالی، چند ثانیه گفتار را با ده ثانیه سکوت مطلق ادغام کند.

برای حل این مشکل، توسعه‌دهنده ابتدا یک «حفاظ نسبتی» (Ratio Guard) پیاده کرد. منطق این بود که اگر هر بخش تک‌زبان از زیرنویس بیش از ۴۰٪ از کل زمان کلیپ را اشغال می‌کرد، سیستم به زمان‌بندی بی‌اعتماد شده و به نشانه‌های دستی (Manual Cues) بازمی‌گشت. فرمول به این شکل بود: if longest / duration > 0.40: return None. در حالی که این روش کلیپ‌های خراب را می‌گرفت، اما یک ویدیوی ۱۵ ثانیه‌ای حاوی یک خط دیالوگ ۶.۴ ثانیه‌ای را هم رد کرد. چون ۶.۴ معادل ۴۳٪ از ۱۵ است، سیستم آن را به عنوان شکست علامت‌گذاری کرد، در حالی که گفتار کاملاً طبیعی بود.

شکست تناسبات

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

• گفتار معتبر: کسی که برای ۶ ثانیه صحبت می‌کند.
• زمان‌بندی خراب: کسی که ۱ ثانیه صحبت می‌کند و سپس ۵ ثانیه سکوت می‌کند.

تحت یک اندازه‌گیری مبتنی بر درصد، این دو مورد کاملاً یکسان هستند. تغییر آستانه از ۴۰٪ به ۵۰٪ یا ۶۰٪ منطق را اصلاح نمی‌کند؛ بلکه فقط تعیین می‌کند که کاربر کدام نوع شکست را بپذیرد. نسبت، کمیت اشتباهی بود زیرا «مدت زمان» در صورت کسر قرار داشت، اما هیچ چیزی در فرمول نشان نمی‌داد که واقعاً چه مقدار کلمه گفته شده است.

راه حل نرخ گفتار

اصلاح این مشکل نیازمند نرمال‌سازی داده‌ها بر اساس عاملی است که واقعاً باعث تغییرات می‌شود: تعداد کلمات. تحویل طبیعی گفتار انسانی معمولاً بین ۲ تا ۳ کلمه در ثانیه است. توسعه‌دهنده با محاسبه نرخ واقعی گفتار، یک «حفاظ نرخ» (Rate Guard) با حداقل آستانه‌ی ۱.۵ کلمه در ثانیه (MIN_WORDS_PER_SEC = 1.5) ایجاد کرد.

وقتی سکوت با یک بخش ادغام می‌شود، تعداد کلمات ثابت می‌ماند اما مدت زمان افزایش می‌یابد و در نتیجه نرخ کلمات بر ثانیه سقوط می‌کند. سیستم اکنون کندترین بخش را با این فرمول محاسبه می‌کند: min((len(text.split()) / (e - s), s, e, text) for s, e, text in segs if e > s).

مقایسه این دو حفاظ، تفاوت در رفتار آن‌ها را آشکار می‌کند:

• یک خط طولانی (سالم): ۶.۴ ثانیه در کلیپ ۱۵ ثانیه‌ای. حفاظ نسبتی (۴۳٪) آن را رد کرد، اما حفاظ نرخ (۱.۷۲ کلمه/ثانیه) آن را پذیرفت.
• دیالوگ پراکنده (خراب): بخش ۸.۱ ثانیه‌ای. حفاظ نسبتی (۵۴٪) آن را رد کرد و حفاظ نرخ (۰.۴۹ کلمه/ثانیه) نیز آن را رد کرد.

درس‌های یکپارچه‌سازی خط لوله

فراتر از ریاضیات، توسعه‌دهنده به دو شکست حیاتی دیگر در خط لوله‌ی زیرنویس هوش مصنوعی اشاره کرد که پیش از مشکل کپشن‌های منجمد رخ داده بودند:

شکست اول: انحراف زمانی (Timing Drift)
زمان‌بندی‌های دست‌نویس هرگز با گفتار مولد مطابقت ندارند. توسعه‌دهنده در ابتدا از زمان‌بندی‌های اسکریپت استفاده می‌کرد، مثلاً: [0.0, 3.2, "He snored through our entire honeymoon."]. اما مدل‌های ویدیوی مولد ریتم خاص خود را دارند؛ آن‌ها ممکن است به‌طور غیرمنتظره مکث کنند یا جملات کوتاه را سریع بگویند. این امر باعث می‌شد ویدیوها به اندازه یک ثانیه یا بیشتر از هم فاصله بگیرند (Drift). تنها منبع قابل اعتماد برای زمان‌بندی، خودِ فایل صوتی است که باید با استفاده از مدلی مانند whisper.load_model("small") برای تبدیل فایل wav به متن استخراج شود.

شکست دوم: عدم تطابق متنی (Text Mismatches)
پس از حل مشکل زمان‌بندی، کلمات به مشکل تبدیل شدند. مدل Whisper اغلب کلمات را اشتباه می‌شنود (مثلاً "earplugs" به "Urplugs" تبدیل شد) و مدل‌های ویدیویی گاهی کلمات را به‌طور کامل حذف می‌کنند. این وضعیت باعث شد برای هر جمله سه نسخه وجود داشته باشد: اسکریپت (کلمات درست، زمان‌بندی غلط)، ترنسکریپت (زمان‌بندی درست، کلمات غلط) و خروجی مطلوب (هر دو درست).

راه حل این بود که به‌جای برخورد با آن‌ها به عنوان پاسخ‌های رقیب، آن‌ها را با هم ترکیب کنند. توسعه‌دهنده یک تابع align پیاده کرد: اگر تعداد بخش‌ها مطابقت داشت، زمان‌بندی صوتی را با متن اسکریپت جفت می‌کرد. اگر تعدادشان متفاوت بود، متن اسکریپت را در بازه‌ی زمانی گفته شده، بر اساس وزن تعداد کلمات، پخش می‌کرد. این تلاش برای حذف خطاهای دستی در اتوماسیون، یادآور رویکرد DX Builder در حذف نیاز به مهندسی پرامپت برای نورپردازی است که هدفش کاهش دخالت‌های انسانی خطا‌برانگیز در فرآیندهای تولیدی است.

قانون رگرسیون

توسعه‌دهنده تنها با اعمال یک قانون رگرسیون سخت‌گیرانه متوجه مثبت کاذب (False Positive) شد: تست‌ها را در هر دو جهت اجرا کنید. یک اصلاحیه باید ورودی‌های بد را رد کند و هم‌زمان ورودی‌های شناخته‌شده‌ی خوب را همچنان بپذیرد. تست کردنِ صرفاً روی باگی که تازه دیده‌اید، نسخه‌ای برای ارسال اصلاحیه‌ای است که ویژگی‌های مجاور و سالم را خراب می‌کند.

این یک حالت شکست رایج است که در آن توسعه‌دهندگان تست‌های خودشان را می‌نویسند و وقتی تست‌ها پاس می‌شوند، خوشحال می‌شوند. اگر ورودی و خروجی مورد انتظار هر دو از یک ذهن در یک لحظه بیرون آمده باشند، توافق بین آن‌ها هیچ چیزی را ثابت نمی‌کند. توسعه‌دهنده اکنون اصرار دارد که مجموعه داده‌های واقعی (Real Corpus) را اجرا کند و ببیند برای مواردی که دست نزده است، چه تغییراتی رخ داده است.

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

گام بعدی شما

• اگر از سیستم‌های خودکار زیرنویس استفاده می‌کنید، معیار تشخیص خطا را از «درصد زمان» به «تعداد کلمات در ثانیه» تغییر دهید.
• برای تراز کردن متن اسکریپت و خروجی مدل‌های ASR، از توابع Align به‌جای جایگزینی ساده استفاده کنید.
• مجموعه‌ای از داده‌های مرجع (Golden Set) بسازید تا هر تغییر در کد، باعث تخریب خروجی‌های سالم قبلی نشود.

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