مدل‌های مسیریاب‌محور در برابر ترجمهٔ ساده؛ تعادلی میان دقت و تأخیر

اگر برای هر پیام کاربر در یک بات چندزبانه، از گران‌ترین مدل موجود استفاده می‌کنید، احتمالاً نیمی از بودجهٔ استنتاج خود را دور می‌ریزید. طبق گزارشی که در ۱۵ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، نگاه به پشتیبانی چندزبانه به‌عنوان یک مسئلهٔ ترجمه، نه تنها هزینه‌ها را ۳ برابر می‌کند، بلکه باعث شکست سیستم در مواجهه با زبان‌های پیچیده مثل تامیلی یا مالایی می‌شود.

بسیاری از تیم‌ها صرفاً یک لایهٔ ترجمه را به یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — متصل می‌کنند. این رویکرد پدیدهٔ «تغییر کد» (Code-switching) را نادیده می‌گیرد؛ وضعیتی که کاربر در یک جمله از دو زبان استفاده می‌کند. برای مثال، مشتری‌ای در جنوب شرق آسیا ممکن است بنویسد: «boleh tolong check my order ah؟» که ترکیبی از مالایی و انگلیسی است. در این حالت، خط لوله‌های تک‌زبانه ورودی را به‌عنوان خطا شناسایی کرده و کیفیت تعامل را پیش از آنکه مدل اصلی پیام را پردازش کند، تخریب می‌کنند.

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

برای حل این مشکل، یک معماری مسیریاب‌محور بر اساس سه محور اصلی پیاده‌سازی شده است:

۱. لایه‌بندی مدل‌ها بر اساس زبان

همه زبان‌ها به توان محاسباتی یکسانی نیاز ندارند. انگلیسی با ساختار ساده SVO (فاعل-فعل-مفعول) و صرف‌های حداقلی، نسبتاً ساده است و یک مدل زبانی کوچک (SLM) می‌تواند کیفیت آن را به‌خوبی حفظ کند. اما زبان‌هایی مثل عربی، مالایی و تامیلی پیچیدگی‌های صرفی (Morphological Complexity) دارند که برای حفظ صحت، به مدل‌های بزرگ‌تر نیاز دارند. این چالش‌ها به‌ویژه در زبان‌های جنوب شرق آسیا مشهود است، مشابه آنچه در تلاش‌های Paxa Labs برای حل نقاط کور زبانی در اسناد تجاری تایلند مشاهده شد.

• سایز مدل: بررسی‌ها نشان داد مدل‌های کلاس ۳.۵ میلیارد پارامتری برای حفظ کیفیت انگلیسی کافی هستند، اما برای زبان‌های سخت‌تر به لایهٔ ۷ میلیارد پارامتری نیاز است.
• بهبود صحت: طبق مستندات، یک خط لوله منتشر شده، زبان‌های کم‌منبع را پیش از طبقه‌بندی از طریق مسیر «ترجمه به انگلیسی» هدایت می‌کند. این کار باعث شده امتیاز Macro-F1 در لایه‌های پایین از حدود ۰.۴۶ به ۰.۶۸ ارتقا یابد.
• بهره‌وری هزینه: ارسال تمام زبان‌ها به یک مدل پیشرو (Frontier Model)، باعث اتلاف هزینه و افزایش تأخیر (Latency) برای زبان انگلیسی می‌شود، در حالی که همزمان خدمات ضعیفی به زبان‌های پیچیده ارائه می‌دهد.

۲. مسیریابی وظایف در هر گام

تصمیمات مسیریابی باید در هر نوبت گفتگو (Single Turn) رخ دهد، چون وظایف مختلف نیاز به لایه‌های متفاوتی دارند.

• طبقه‌بندی و جست‌وجو: درخواستی مثل «سفارشم را چک کن» یک وظیفه ساده است که نیاز به مدل‌های سبک دارد.
• ترکیب و تحلیل (Synthesis): درخواستی مثل «توضیح بده چرا تراکنشم شکست خورد و یک پاسخ بنویس» یک وظیفه پیچیده است که نیاز به استدلال مدل‌های بزرگ‌تر دارد.

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

۳. انطباق منطقه‌ای و تأخیر

قوانین اقامت داده‌ها، مانند PDPA در سنگاپور (و قوانین مالزی که در مسیر مشابهی است)، شفافیت در محل پردازش داده‌ها، حذف اطلاعات حساس (PII) و توافق‌نامه‌های «عدم آموزش» (No-train terms) با ارائه‌دهندگان را الزامی می‌کند.

• زیرساخت: تیم استنتاج را در منطقه (میزبانی در سنگاپور روی Tencent Cloud) انجام می‌دهد تا کاملاً با استانداردهای PDPA همراستا باشد.
• ریاضیات تأخیر: در اینجا، الزامات اقامت داده و تأخیر در واقع یک تصمیم واحد هستند. نگه داشتن استنتاج در منطقه، همزمان هم قوانین PDPA را پاس می‌کند و هم تأخیر را زیر آستانهٔ ۳۰۰ میلی‌ثانیه نگه می‌دارد تا گفتگو طبیعی بماند.
• معماری: انتقال داده‌ها به خارج از منطقه، علاوه بر نقض قوانین رگولاتوری، عملکرد سیستم را تخریب می‌کند. بنابراین «محل اجرای مدل» یک تصمیم معماری کلیدی است، نه یک یادداشت حاشیه‌ای برای کاهش هزینه.

این سیستم تنها زمانی کار می‌کند که مدل‌ها به‌عنوان یک «پیچ تنظیم» دیده شوند، نه یک تعهد سخت و تغییرناپذیر. مدیریت بیش از ۲۵ مدل پشت یک نقطهٔ اتصال (Endpoint) سازگار با OpenAI، اجازه می‌دهد لایهٔ مدل یک زبان تنها با تغییر یک جدول پیکربندی (Routing Table Config) عوض شود، نه یک چرخهٔ خرید و استقرار طولانی. این حقیقتِ غیرجذاب اما حیاتی است که باعث موفقیت مسیریابی می‌شود: تغییر لایه‌ها یک تغییر در تنظیمات است، نه یک مهاجرت زیرساختی.

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

تنها چالش باقی‌مانده، نظارت است. امتیازات کیفی کلی (Global Quality Scores) معمولاً شکست‌ها در زبان‌های کم‌منبع را می‌پوشانند. ممکن است انگلیسی بی‌نقص باشد اما زبان تامیلی یک هفته دچار افت کیفیت شود و هیچ‌کس متوجه نشود تا زمانی که مشتری شکایت کند. راهکار فعلی، حرکت به سمت نظارت بر Macro-F1 برای هر لایهٔ زبانی است تا از این «افت خاموش» (Silent Drift) جلوگیری شود.

گام بعدی شما

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

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

اما مدیریت این حجم از مدل‌ها در مقیاس بالا، چالش‌های جدیدی در حافظه ایجاد می‌کند — به تحلیل ما درباره‌ی KV Cache و بهینه‌سازی استنتاج مراجعه کنید.