تصور کنید می‌خواهید یک کتاب ۳۰۰ صفحه‌ای را ترجمه کنید، اما هوش مصنوعی در اواسط راه یا پاسخ نمی‌دهد و یا نام شخصیت‌ها را فراموش می‌کند. ۳۰۰ صفحه؛ این همان آستانه معمولی است که در آن ترجمه‌های مدل‌های زبانی بزرگ (LLM) یا به خطای Time-out منجر می‌شود و یا به یک آشفتگی روایی تبدیل می‌گردد. در ۵ سپتامبر ۲۰۲۶، تیم LectuLibre با طراحی سیستمی که متون حجیم را بدون گسستن رشته‌ی روایت تکه‌تکه می‌کند، این سد فنی را شکست.
ابعاد چالش
یک کتاب معمولی ۳۰۰ صفحه‌ای حدود ۹۰ تا ۱۲۰ هزار کلمه دارد. در دنیای توکن‌ها، این حجم به تقریباً ۱۲۰ تا ۱۶۰ هزار توکن (Token) تبدیل می‌شود — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد. طبق گزارش این تیم، با وجود اینکه مدل‌های Claude 3 پنجره زمینه (Context Window) ۲۰۰ هزار توکنی دارند، ارسال کل کتاب در یک درخواست API غیرعملی است. این کار کند است، هزینه زیادی دارد و اغلب به دلیل پدیده‌ای به نام «رقیق شدن توجه» (Attention Dilution)، کیفیت ترجمه را به شدت پایین می‌آورد.
بسیاری از توسعه‌دهندگان تصور می‌کنند پنجره زمینه بزرگ، راهکاری جادویی برای اسناد طولانی است. اما ارسال ۱۵۰ هزار توکن به‌صورت یک‌جا اغلب باعث می‌شود مدل فصل‌های ابتدایی را فراموش کند یا پاراگراف‌ها را به‌طور کامل نادیده بگیرد. این چالش درست زمانی رخ می‌دهد که مدل‌هایی مانند Claude 3 در حال جابه‌جا کردن مرزهای هوش هستند؛ همان‌طور که در پوشش پیشین ما از پیشتازی Claude Fable 5.1 در شاخص‌های هوش (Intelligence Index v4.2) دیدیم، قدرت استدلال لزوماً به معنای مدیریت بی‌نقص حافظه در حجم‌های بسیار بالا نیست.
سه دیوار سخت در پیاده‌سازی ساده‌لوحانه
تیم LectuLibre در ابتدا وقتی سعی کرد کل کتاب‌ها را به Claude ارسال کند، با سه مانع مشخص مواجه شد:
- محدودیت نرخ درخواست (Rate Limits): درخواست‌های تک‌مرحله‌ای با ۱۵۰ هزار توکن، باعث بروز مکرر خطاهای Time-out و خطاهای ۴۲۹ (Too Many Requests) می‌شد.
- هزینه: پردازش ۱۵۰ هزار توکن در هر درخواست با مدل Opus، بیش از ۱۳ دلار برای هر کتاب هزینه داشت، در حالی که بخش زیادی از ورودی به دلیل تکرار زمینه (Context) هدر می‌رفت.
- کیفیت: زمینه‌های طولانی باعث می‌شد مدل ردپای فصل‌های ابتدایی را گم کند و در نتیجه، اصطلاحات و نام شخصیت‌ها در طول کتاب ناهماهنگ شوند.
تصور کنید بخواهید کتابی را با بریدن تصادفی کاغذها ترجمه کنید. ممکن است یک جمله را از وسط نصف کنید و هوش مصنوعی را مجبور کنید تا معنای هر دو تکه را به‌صورت مستقل حدس بزند. این دقیقاً همان اتفاقی است که در تکه‌بندی ساده‌ی پاراگراف‌ها رخ می‌دهد.
تلاش اول: تکه‌بندی ساده‌ی پاراگراف‌ها
استراتژی اولیه آن‌ها ساده بود: تقسیم متن به قطعاتی در حدود ۱۰ هزار توکن با استفاده از یک عبارت منظم (Regex) برای جداسازی بر اساس خطوط خالی دوگانه (\n\s*\n). آن‌ها پاراگراف‌ها را تا زمانی که حد توکن پر می‌شد، به هم می‌چسباندند.
این رویکرد برای اسناد کوچک جواب می‌داد اما برای کتاب‌ها شکست خورد. این روش در مرز هر تکه، جملات را می‌برید. یک جمله واحد می‌توانست بین دو تکه تقسیم شود و باعث می‌شد مدل دو نیمه از یک جمله را به دو شکل متفاوت ترجمه کند. علاوه بر این، زمینه (Context) فصل‌های قبلی کاملاً از بین می‌رفت و جریان روایت تخریب می‌شد.
مشکل شمارش توکن‌ها
در ابتدا، تیم از یک تخمین «سریع و سرسری» استفاده می‌کرد: تقسیم تعداد کاراکترها بر چهار. این روش، به‌ویژه برای زبان‌های غیرانگلیسی، غیرقابل اعتماد بود. LectuLibre این تخمین‌های تقریبی را با tiktoken جایگزین کرد؛ توکنایزری که توسط OpenAI استفاده می‌شود و با توکنایزر Claude سازگار است.
آن‌ها با استفاده از کدگذاری cl100k_base به شمارش دقیق توکن‌ها دست یافتند. این دقت برای باقی ماندن در محدوده API و تخمین دقیق هزینه هر پروژه ترجمه حیاتی بود.
حل شکاف مرزی
برای جلوگیری از گم کردن زمینه توسط مدل در فواصل بین تکه‌ها، تیم دو مکانیزم خاص را پیاده‌سازی کرد:
۱. پنجره‌های هم‌پوشان و زمینه (Overlap and Context Windows):
- پنجره‌های هم‌پوشان: هر تکه جدید شامل چند پاراگراف از تکه قبلی است تا تداوم متن حفظ شود. در نسخه نهایی و اصلاح‌شده، آن‌ها از هم‌پوشانی ۳۰۰ تا ۵۰۰ توکنی (حدود ۲ تا ۳ جمله) استفاده کردند تا اثرات مرزی را به‌طور مجازی حذف کنند.
- ادغام مقدمه (Preamble): آن‌ها یک مقدمه به هر تکه اضافه کردند. این مقدمه شامل عنوان کتاب، نام نویسنده و واژه‌نامه‌ای از اصطلاحات تکراری بود تا مدل همواره در مسیر درست باقی بماند.
۲. احترام به مرزهای جملات:
- تکه‌بندی آگاه از جمله (Sentence-Aware Splitting): تیم متوجه شد که تکه‌بندی بر اساس پاراگراف‌ها به تنهایی هنوز می‌تواند یک پاراگراف طولانی را از وسط جمله ببرید. چون ابزار
nltk.sent_tokenizeبرای کتاب‌های حجیم بسیار کند بود، آن‌ها یک جداکننده مبتنی بر Regex با الگوی(?<=[.!?])\s+پیاده کردند تا ابتدا پاراگراف‌ها را به جملات خرد کند. - تکه‌بندی متوالی: با تکه‌بندی جملات به همراه هم‌پوشانی (به جای پاراگراف‌ها)، آن‌ها تضمین کردند که هیچ جمله‌ای هرگز بین دو درخواست API مختلف تقسیم نشود.
حفظ یکپارچگی روایت
یکپارچگی در بازه‌های طولانی — مانند یکسان نگه داشتن نام یک شخصیت از فصل ۱ تا فصل ۲۰ — همچنان یک مانع اصلی است. حتی با وجود هم‌پوشانی، مدل می‌تواند جزئیات را در طول صدها صفحه فراموش کند.
LectuLibre این مشکل را با استفاده از Claude 3 Sonnet حل کرد. آن‌ها پیش از شروع ترجمه اصلی، از مدل خواستند تا یک واژه‌نامه از اصطلاحات و نام‌های کلیدی را از نمونه‌هایی از فصل‌ها (۲۰ هزار کاراکتر اول) استخراج کند. مدل را طوری هدایت کردند که این موارد را در قالب جفت‌های «Original: Translation» فرمت کند.
این واژه‌نامه در پرامپت سیستمی (System Prompt) تک‌تک تکه‌ها تزریق می‌شود. برای مثال، این کار تضمین می‌کند شخصیتی به نام «John» در تمام کتاب به صورت «Juan» ترجمه شود و در اواسط کتاب به «Jean» یا «Giovanni» تغییر نکند.
خط لوله فنی (Technical Pipeline)
به نقل از گزارش dev.to، معماری نهایی بر پایه یک خط لوله ناهمگام (Asynchronous) با استفاده از کلاینت پایتون Anthropic است. این سیستم برای تاب‌آوری و کارایی طراحی شده است:
- کنترل هم‌زمانی (Concurrency Control): آن‌ها از یک Semaphore برای محدود کردن هم‌زمانی به سه درخواست هم‌زمان استفاده کردند تا از فشار بیش از حد به API جلوگیری کنند.
- مدیریت خطا: خط لوله منطق تلاش مجدد (Retry) با عقب‌نشینی نمایی (
2 ** attempt + random.random()) را برای مدیریتRateLimitErrorو سایر استثناهای گذرا پیاده کرده است. آن‌ها حداکثر ۵ تلاش مجدد برای هر تکه تعیین کردند. - انعطاف در مدل: در حالی که از
claude-3-haiku-20240307برای توسعه کم‌هزینه استفاده شد، کاربران نهایی می‌توانند بین Haiku برای سرعت، Sonnet برای تعادل و Opus برای آثار ادبی پیچیده انتخاب کنند. - مهندسی پرامپت: پرامپت سیستمی، هوش مصنوعی را به عنوان یک «مترجم حرفه‌ای کتاب» تعریف می‌کند و به آن دستور می‌دهد که فرمت، لحن و استایل را حفظ کرده و در عین حال به واژه‌نامه ارائه شده پایبند باشد.
بنچمارک‌های عملکرد و هزینه
برای یک رمان معمولی ۱۰۰ هزار توکنی، تیم دریافت که تکه‌های ۸,۰۰۰ تا ۱۲,۰۰۰ توکنی بهترین تعادل را بین کیفیت و زمینه ایجاد می‌کنند. تکه‌های کوچک‌تر زمینه زیادی را از دست می‌دادند و تکه‌های بزرگ‌تر به آستانه افت کیفیت نزدیک می‌شدند.
تفاوت هزینه و سرعت بین مدل‌ها بسیار چشمگیر بود:
- Claude 3 Haiku: حدود ۰.۱۵ دلار برای هر کتاب (ترجمه در کمتر از ۲ دقیقه).
- Claude 3 Sonnet: حدود ۱.۵۰ دلار برای هر کتاب (ترجمه در حدود ۵ دقیقه).
- Claude 3 Opus: حدود ۹.۰۰ دلار برای هر کتاب.
در مقابل، یک درخواست تک‌مرحله‌ای با تمام زمینه برای Opus بیش از ۱۳ دلار هزینه داشت و مکرراً به دلیل Time-out شکست می‌خورد. تیم اشاره کرد که استفاده از کل پنجره زمینه باعث می‌شد مدل بعد از ۱۰ هزار توکن اول، شروع به حذف پاراگراف‌ها و جابه‌جا کردن شخصیت‌ها کند.
سبک‌سنگین کردن (The Trade-off)
تیم پذیرفت که ۵٪ توکن‌های بیشتری را به دلیل هم‌پوشانی (Redundancy) مصرف کند. آن‌ها این هزینه را بهای یک بیمه ارزان برای جلوگیری از «اثرات مرزی» دانستند که معمولاً ادبیات ترجمه شده توسط AI را تخریب می‌کند.
این تغییر در رویکرد، صنعت را از تکیه بر اندازه خام پنجره زمینه به سمت «ارکستراسیون داده‌های ساختاریافته» سوق می‌دهد. این ثابت می‌کند که برای محتوای بلند با دقت بالا، خط لوله (Pipeline) مهم‌تر از حداکثر حد توکن مدل است.
برای توسعه‌دهندگان، این بدان معناست که تمرکز باید از «مدل چقدر می‌تواند نگه دارد» به «چگونه می‌توانم زمینه درست را در زمان درست به مدل بدهم» تغییر کند.
منتظر تکامل بعدی در این حوزه باشید: پیاده‌سازی «خلاصه‌های فصلی» که به عنوان یک حافظه جاری برای مدل در حین پیشروی در دست‌نویس عمل می‌کند. با تولید خلاصه هر فصل در حین ترجمه و گنجاندن آن در تکه‌های بعدی، سیستم می‌تواند یک حافظه پایدار از قوس روایتی داستان بسازد.
گام بعدی شما
- اگر توسعه‌دهنده هستید، به جای افزایش Context Window، روی پیاده‌سازی Overlap Windows برای اسناد طولانی تمرکز کنید.
- برای حفظ یکپارچگی در پروژه‌های ترجمه، ابتدا یک واژه‌نامه (Glossary) استخراج کرده و آن را در هر درخواست تکرار کنید.
- از مدل‌های کوچک‌تر مثل Haiku برای پیش‌پردازش و استخراج ساختار، و مدل‌های بزرگ‌تر برای ترجمه نهایی استفاده کنید.
گفتگو