ترجمه زیرنویس با مدل‌های زبانی: جایگزینی اعتبارسنج‌های قطعی با پرامپت‌های پیچیده

تصور کنید مسئولیت مقیاس‌بندی ترجمه زیرنویس‌های یک سریال به ۱۶ زبان مختلف را بر عهده دارید؛ سخت‌ترین بخش کار، ترجمه اولیه نیست، بلکه شناسایی دقیق شکست‌های خاص و اصلاح تنها خطوط آسیب‌دیده است، بدون آنکه بقیه محتوا تخریب شود. طبق گزارش فنی منتشر شده در وب‌سایت dev.to در ۶ اوت ۲۰۲۶، این واقعیت به این معناست که یک سامانه ترجمه زیرنویس در سطح تولید (Production-grade) نمی‌تواند برای تضمین دقت، تنها به یک پرامپت «ایده‌آل» یا «کامل» تکیه کند.

همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چگونه Apify خط لوله‌های پیچیده داده‌های LLM را خودکار می‌کند اشاره کردیم، این گردش‌کار نشان می‌دهد که عبور از مرحله نمونه اولیه (Prototype) به محیط عملیاتی، نیازمند تغییر رویکرد از «امید به احتمال» به «مهندسی قطعی» (Deterministic Engineering) است. در دنیای زیرنویس، یک ترجمه ممکن است از نظر معنایی درست باشد، اما اگر از حد مجاز کاراکتر در ثانیه (CPS) فراتر رود یا همراستایی خود را با شناسه (ID) زیرنویس از دست بدهد، عملاً از نظر کاربردی بی‌فایده است.

تضاد اهداف در ترجمه

ترجمه زیرنویس یک مسئله ساده تبدیل متن به متن نیست؛ بلکه یک مسئله چندهدفه با اولویت‌های مشخص است. سیستم باید تعادلی میان دقت معنایی، همراستاسازی زیرنویس، ثبات اصطلاحات و خوانایی (CPS) ایجاد کند.

فراتر از معنای پایه، سیستم باید تضمین کند که هر زیرنویس مبدأ دقیقاً با شناسه (ID) صحیح همراستا باقی بماند و شکست خطوط و علائم نگارشی طبق کنوانسیون‌های خاص هر زبان باشد. خروجی باید کاملاً عاری از نویزهای فرمت‌بندی یا توضیحات اضافی مدل باشد و فشرده‌سازی متن نباید منجر به حذف اطلاعاتی شود که داستان را تغییر می‌دهد.

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

برای حل این تضادها، نویسنده یک سلسله‌مراتب اولویت سخت‌گیرانه تعریف کرده است:

• اولویت ۱: دقت و کامل بودن معنایی.
• اولویت ۲: همراستاسازی زیرنویس و ثبات اصطلاحات.
• اولویت ۳: خوانایی و CPS.
• اولویت ۴: صیقل دادن سبک نوشتاری.

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

سقف کیفیت در برابر کف کیفیت

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

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

برای جلوگیری از این اتفاق، مرحله اول بر موارد زیر تمرکز می‌کند:

• دقت معنایی، کامل بودن و بیان طبیعی.
• بافت (Context)، ارجاعات (Coreference) و روابط شخصیت‌ها.
• جزئیات حیاتی مانند نفی‌ها، اعداد و زمان.
• نام شخصیت‌ها و اصطلاحات کلیدی.

در مقابل، اعتبارسنج‌های قطعی (Deterministic Validators) از «کف کیفیت» (Quality Floor) محافظت می‌کنند. این‌ها بررسی‌های نرم‌افزاری غیر-LLM هستند که موارد زیر را شناسایی می‌کنند:

• شناسه‌های (ID) گم‌شده یا تکراری
• خروجی‌های خالی یا ساختارهای نامعتبر
• تخطی از حد مجاز CPS یا طول متن
• تکرار علائم نگارشی یا نشت زبان مبدأ (Script Leakage)

با حذف این بارها از پرامپت، مدل می‌تواند روی ظرافت‌های معنایی و بافت تمرکز کند، به جای اینکه سعی کند لیستی از ۲۰ ممنوعیت مختلف فرمت‌بندی را به خاطر بسپارد.

مدیریت اولویت‌ها در مهندسی پرامپت

افزودن دستورات منفی (مثلاً «محتوا را حذف نکن») اغلب زمانی که محدودیت‌ها با هم در تضاد باشند، شکست می‌خورد. برای مثال، دستور «مختصر باش» می‌تواند با «اطلاعات را حذف نکن» در تضاد باشد. یک ساختار پرامپت موثرتر، وظیفه را بر اساس سطوح اولویت سازماندهی می‌کند:

• [وظیفه]: ترجمه زیرنویس‌های مبدأ به زبان مقصد برای زیرنویس‌های روی صفحه ویدیو.
• [ترتیب اولویت]: لیست صریح سلسله‌مراتب از دقت معنایی تا صیقل دادن سبک.
• [محدودیت‌های سخت]: قوانین اجباری مانند تضمین اینکه هر آیتم ورودی دقیقاً یک آیتم خروجی داشته باشد، عدم تغییر در اصطلاحات تأیید شده و پیروی دقیق از ساختار خروجی بدون افزودن توضیحات.
• [محدودیت‌های نرم]: اهداف بهینه‌سازی مانند استفاده از نحو طبیعی زبان مقصد، ترجیح عبارات محاوره‌ای و اجتناب از تکرارهای غیرضروری.
• [زمینه و اصطلاحات]: ارائه بافت مرتبط با داستان و روابط بین شخصیت‌ها.
• [پروتکل خروجی]: بازگرداندن فرمت پایداری که توسط نرم‌افزار قابل تجزیه (Parse) باشد.

شکست تضمین‌های ساختاری

حتی با دستورات صریح، LLMها مکرراً خطوط را با هم ادغام می‌کنند یا معنا را از یک ID به ID دیگر منتقل می‌کنند. نویسنده اشاره می‌کند که یک محدودیت در تولید (Generation Constraint)، یک تضمین قطعی نیست. ممکن است یک LLM تعداد صحیح IDها را برگرداند، اما معنای زیرنویس ۱۰۲ را زیر زیرنویس ۱۰۳ قرار دهد.

برای مقابله با این موضوع، سیستم از رویکرد «تشخیص هدفمند» (Targeted Diagnosis) استفاده می‌کند. به جای اینکه از مدل بخواهد «درباره کل ترجمه تامل کند»، سیستم سوالات عینی می‌پرسد:

• «آیا هیچ خط زیرنویسی گم شده است؟»
• «کدام خط حاوی نشت زبان مبدأ است؟»
• «آیا یک اصطلاح تأیید شده در یک خط خاص گم شده است؟»
• «آیا به نظر می‌رسد یک زیرنویس حاوی محتوای ID مجاور باشد؟»
• «کدام خط از حد مجاز خوانایی خود فراتر رفته است؟»

این روش اجازه می‌دهد سیستم خطاها را بر اساس نوع مسیریابی کرده و تنها خطوط مشکل‌دار را بازبینی کند، که ریسک وارد کردن خطاهای جدید به بخش‌هایی که قبلاً درست بودند را کاهش می‌دهد. گردش‌کار عملیاتی این مسیر را دنبال می‌کند: ترجمه مرحله اول $\rightarrow$ اعتبارسنجی قطعی و بررسی‌های مبتنی بر LLM $\rightarrow$ شناسایی IDهای آسیب‌دیده و نوع خطا $\rightarrow$ بازبینی تنها خطوط مشکل‌دار $\rightarrow$ اعتبارسنجی مجدد.

مدیریت CPS و اصطلاحات

فشرده‌سازی برای خوانایی (CPS) به عنوان یک سیگنال تشخیص تلقی می‌شود، نه مجوزی برای حذف متن. وقتی یک سوال کوتاه چینی مانند «کی آن را گرفت؟» در زبان دیگر به شدت گسترش می‌یابد، فرآیند بازبینی باید به این سوالات پاسخ دهد:

• آیا اطلاعات حذف شده از روی صحنه یا بافت (Context) واضح است؟
• آیا یک نفی، عدد، رابطه یا اقدام کلیدی حذف شده است؟
• آیا لحن گوینده تغییر کرده یا یک ارجاع صریح به ابهام کشیده شده است؟

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

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

این رویکرد در مدیریت واژگان تخصصی بسیار موثر است، مشابه استراتژی‌هایی که برای حذف روانی کاذب در ترجمه از طریق تغذیه کدبیس به کار می‌رود تا دقت فنی متن حفظ شود.

ظرافت‌های زبانی

در حالی که معماری سیستم در ۱۶ زبان مشترک است، کنترل‌های کیفیت تخصصی هستند. تشخیص‌دهنده‌ای که برای یک زبان کار می‌کند، ممکن است برای زبان دیگر مثبت کاذب (False Positive) تولید کند.

• انگلیسی: تمرکز بر گسترش متن، ترتیب کلمات متأثر از چینی، نحو بین-خطی، نام‌ها، ارزها و فرم‌های خطاب.
• ژاپنی: نیازمند مدیریت گفتار جنسیتی، سطوح ادب، ضمایر اول‌شخص و عبارات پایان جمله. چون با چینی در کاراکترها مشترک است، سیستم باید از تلقی کردن هر کاراکتر CJK به عنوان نشت زبان چینی اجتناب کند.
• کره‌ای: تمرکز بر پسوندهای احترام‌آمیز (Honorifics)، ترتیب کلمات، پایان جملات و نشت اسکریپت. تغییرات طبیعی در ترتیب کلمات به طور خودکار به عنوان عدم همراستایی خط طبقه‌بندی نمی‌شوند.
• اسپانیایی: اولویت با جنسیت گرامری، تطابق تعداد، علائم نگارشی خطاب (Vocative) و کنوانسیون‌های علامت سوال است.

حلقه بازخورد و تست رگرسیون

بهبود سیستم از طریق یک حلقه بازخورد سخت‌گیرانه اثبات شده است. نویسنده «نرخ ویرایش کاراکتر» (مقدار متنی که ویراستاران انسانی تغییر داده‌اند) را برای اندازه‌گیری موفقیت ردیابی کرد.

در یک تست روی پنج زبان، نرخ ویرایش کاراکتر هنگام انتقال از ترجمه مستقیم به گردش‌کار «عامل ترجمه» (Translation-Agent) به شدت کاهش یافت. نتایج به شرح زیر بود:

با این حال، نویسنده هشدار می‌دهد که نرخ ویرایش یک معیار تقریبی (Proxy) است، نه یک معیار کامل. تغییر یک کاراکتر که یک نفی را اصلاح کند، بسیار حیاتی‌تر از تغییر ۱۰ کاراکتر در علائم نگارشی است. برای رفع این مشکل، سیستم از یک تاکسونومی خطا استفاده می‌کند:

• ریسک بالا: معنای معکوس، هویت اشتباه یا تخریب روابط شخصیت‌ها.
• ریسک متوسط: حذفیات، خطاهای اصطلاحی، اعداد اشتباه یا ارجاعات زمانی نادرست.
• مشکلات تجربه (Experience): عبارت‌بندی غیرطبیعی یا CPS بیش از حد.
• ریسک پایین: علائم نگارشی، فاصله‌گذاری و فرمت‌بندی.

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

گام بعدی شما

• اگر از LLM برای کارهای ساختاریافته استفاده می‌کنید، اعتبارسنج‌های نرم‌افزاری (Deterministic) را جایگزین دستورات «نکن» در پرامپت کنید.
• برای پروژه‌های ترجمه، یک سلسله‌مراتب اولویت (مانند دقت معنایی > خوانایی) تعریف کنید تا مدل در هنگام تضاد اهداف، مسیر درست را انتخاب کند.
• به جای بازبینی کلی، از مدل بخواهید سوالات تشخیص هدفمند (Targeted Diagnosis) را برای خطوط خاص پاسخ دهد.

اما مدیریت هزینه‌های استنتاج در چنین سیستم‌های چندمرحله‌ای چالش دیگری است — به تحلیل ما درباره بهینه‌سازی هزینه GPU و اینکه چگونه شرکتی مانند Oxlo.ai با قیمت‌گذاری درخواست‌محور هزینه‌های استنتاج را مدیریت کرده است مراجعه کنید.