اگر برای مدیریت داده‌های متنی حجیم در یک محصول SaaS هزینه می‌پردازید، احتمالاً با کابوس «دیوار متن» روبرو شده‌اید؛ جایی که یک توصیف دوخطی در کنار یک متن ۱۰ صفحه‌ای از قوانین بازی قرار می‌گیرد. این نوسان شدید در حجم ورودی، قیمت‌گذاری محصول را غیرممکن و هزینه‌های استنتاج را غیرقابل‌پیش‌بینی می‌کند.
به نقل از مستندات فنی این پروژه، توسعه‌دهنده یک سامانه تلخیص تخصصی طراحی کرده است که به‌جای استفاده از پرامپت‌های ثابت، از یک معماری پویا با دو حالت مختلف استفاده می‌کند. این رویکرد باعث می‌شود مرز بین منطق محصول و ارائه‌دهنده هوش مصنوعی کاملاً شفاف شود.
در دنیای واقعی، ورودی‌های کاتالوگ بازی‌ها بسیار نامنظم هستند؛ برخی شامل توصیفات کوتاه و برخی دیگر شامل یادداشت‌های به‌روزرسانی و سلب مسئولیت‌های حقوقی طولانی‌اند. ارسال هر دو نوع متن به یک پرامپت واحد، باعث ایجاد بدهی فنی می‌شود. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی هزینه‌های مدل‌های زبانی اشاره کردیم، جداسازی لایه منطق از لایه مدل، کلید مقیاس‌پذیری در محصولات کوچک است.
برای حل این مشکل، توسعه‌دهنده یک آداپتور (Adapter) — شبیه به یک تبدیل برق که اجازه می‌دهد دستگاه‌های مختلف به یک پریز وصل شوند — طراحی کرد. اپلیکیشن حالا فقط درخواست «تلخیص کوتاه» یا «تلخیص مفصل» می‌دهد و هرگز نام مدل خاصی را صدا نمی‌زند. به این ترتیب، اگر قیمت یا کیفیت یک مدل تغییر کند، تنها یک بخش از کد به‌روز می‌شود و کل سیستم مختل نمی‌گردد. این استراتژی شباهت زیادی به به‌کارگیری Endpointهای سازگار با OpenAI دارد که انعطاف‌پذیری سیستم‌های مدیریت داده را به‌شدت افزایش می‌دهد.
معماری دوحالته
این سیستم بر اساس دو نیاز واقعی در رابط کاربری (UI) عمل می‌کند:
- حالت کوتاه (Brief Mode): برای کارت‌های مرور و بررسی‌های سریع طراحی شده است. سقف خروجی ۱۲۰ توکن (Token) — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — است و دستورالعمل آن حذف تکرارها و حفظ حقایق در کمترین حجم ممکن است.
- حالت مفصل (Detailed Mode): برای صفحات کامل محصول یا ویرایشگران استفاده می‌شود. سقف خروجی در اینجا ۳۶۰ توکن است تا بافتار بیشتری ارائه دهد.
این حالت‌ها صرفاً برچسب نیستند، بلکه محدودیت‌های سخت‌گیرانه هستند. سیستم پیش از استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، مثل خودِ آشپزی و نه دوره‌ی آموزش آشپز — درخواست را اندازه می‌گیرد و هزینه را تخمین می‌زند تا با پلن کاربر همخوانی داشته باشد.
منطق تکه‌بندی معنایی
برای مدیریت متون طولانی بدون از دست دادن معنا، از استراتژی «اول اولویت با پاراگراف» استفاده شده است. تکه‌بندی کورکورانه بر اساس تعداد کاراکتر خطرناک است؛ زیرا ممکن است عنوان یک نسخه ویژه در یک تکه و محتویات آن در تکه‌ای دیگر قرار بگیرد و مدل دچار توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — شود. برای مقابله با این چالش، استفاده از معماری‌های چندمرحله‌ای در API راهکاری موثر برای کاهش توهمات در اتوماسیون‌های پیچیده است.
طبق گزارش توسعه‌دهنده، مراحل تکه‌بندی به این صورت است:
- تقسیم معنایی: متن در مرز پاراگراف‌ها (
\n\s*\n) شکافته می‌شود تا تفکیک بین داستان، مکانیک بازی و متون حقوقی حفظ شود. - تأیید توکن‌ها: پاراگراف‌ها به تکه کاندید اضافه شده و تعداد توکن‌ها بررسی می‌شود. شمارش کاراکتر برای تخمین اولیه است، اما گیت نهایی حتماً باید توکن‌سازی باشد. این رویکرد دقیق، یادآور تکنیک‌های تکه‌بندی توکن‌محور در Node.js است که از خطاهای API در متون حجیم جلوگیری می‌کند.
- مدیریت بودجه: این روند تا رسیدن به سقف ۶۰۰۰ توکن ادامه می‌یابد.
- جایگزین دقیق: اگر یک پاراگراف به‌تنهایی از بودجه بیشتر بود، سیستم آن را به جملات کوچک‌تر می‌شکند تا از بریدن تصادفی رشته‌های متنی و تخریب توالی‌های یونیکد جلوگیری کند.
خط لوله کاهش (Reduction Pipeline)
پس از تولید تلخیص‌های جزئی، یک مرحله «ترکیب نهایی» اجرا می‌شود تا کاربر با پنج تلخیص تکه‌تکه روبرو نشود. در این مرحله، مدل اجازه ندارد هیچ حقیقت جدیدی به متن اضافه کند.
یک نقطه شکست ظریف این است که تکه‌بندی ممکن است یک درخواست بیش از حد بزرگ را به انتهای خط لوله منتقل کند. برای جلوگیری از این اتفاق، سیستم تعداد تلخیص‌های جمع‌آوری‌شده را می‌شمارد و اگر از بودجه ترکیب بیشتر بود، آن‌ها را به‌صورت بازگشتی (Recursive) در دسته‌های کوچک‌تر کاهش می‌دهد؛ یعنی برخلاف یک اتصال ساده، از ساختار درختی استفاده می‌کند.
استراتژی ارائه‌دهنده و قابلیت جابه‌جایی
توسعه‌دهنده از Infrai به‌عنوان بک‌اند استفاده می‌کند زیرا رابط آن با OpenAI سازگار است و اجازه می‌دهد ۲۹۵ مسیر مختلف در ۲۰ ماژول را با یک کلید مدیریت کند. این موضوع به تیم‌های کوچک اجازه می‌دهد بدون پذیرش SDKها یا سیستم‌های پرداخت جدید، قابلیت‌های جدیدی اضافه کنند.
بر اساس بررسی منابع، انتخاب ارائه‌دهنده به محدودیت‌های تیم بستگی دارد:
- OpenAI، Anthropic یا Google Gemini: برای تیم‌هایی که به ویژگی‌های بومی یک مدل متعهد هستند، اما جابه‌جایی بعدی برای آن‌ها سخت خواهد بود.
- LiteLLM: گزینه‌ای متن‌باز و میزبانی شخصی برای تیم‌هایی که می‌خواهند لایه مسیریابی را خودشان مدیریت کنند.
- Infrai: برای تیم‌های کوچک که جابه‌جایی بین مدل‌ها و داشتن یک قرارداد ثابت برای ماژول‌های مختلف بک‌اند را اولویت می‌دانند.
جزئیات پیاده‌سازی
کد ارائه‌دهنده تنها به سه عملیات محدود شده است: countTokens (شمارش توکن)، estimate (تخمین هزینه و توکن) و complete (تکمیل چت).
برای مقابله با ناپایداری شبکه، تابعی به نام withRateLimitRetry پیاده شده است. این تابع تا ۴ بار تلاش می‌کند و در صورت دریافت خطای ۴۲۹ (درخواست‌های بیش از حد)، از استراتژی عقب‌نشینی نمایی (Exponential Backoff) با شروع از ۵۰۰ میلی‌ثانیه استفاده می‌کند.
مقیاس‌پذیری برای محیط عملیاتی
در حجم‌های پایین، تلخیص‌های همزمان راحت‌تر دیباگ می‌شوند، اما برای وارد کردن داده‌های انبوه، توسعه‌دهنده جداسازی «پذیرش» از «اجرا» را پیشنهاد می‌کند:
۱. پذیرش: ابتدا شمارش و قیمت‌گذاری آیتم انجام شود.
۲. پایداری: حالت انتخاب‌شده و هش منبع ذخیره شود تا یک توصیف به‌طور تصادفی دوبار تلخیص نشود.
۳. اجرا: پردازش در یک Worker پس‌زمینه و دور از درخواست وب انجام شود.
برای تضمین کیفیت، استفاده از یک مجموعه ارزیابی شامل ۹۰ توصیف (۳۰ کوتاه، ۳۰ معمولی و ۳۰ «زشت» با پاراگراف‌های حقوقی تکراری) توصیه شده است. این تست عینی، معیار تغییر مدل است، نه اعداد پنجره متنی که در دیتاشیت‌ها نوشته شده است.
این رویکرد، ادغام هوش مصنوعی را به مثابه «لوله‌کشی دقیق» برای داده‌های نامنظم می‌بیند. با برون‌سپاری زیرساخت‌های تکراری، یک SaaS تک‌نفره می‌تواند هر هفته ویژگی جدید منتشر کند بدون اینکه با هر تغییر در مدل، کل کد غنی‌سازی را بازنویسی کند.
گام بعدی شما
- اگر از مدل‌های مختلف استفاده می‌کنید، یک لایه آداپتور بین منطق برنامه و API مدل قرار دهید تا وابستگی شما به یک شرکت خاص نباشد.
- به‌جای تکیه بر تعداد کاراکتر، برای تخمین هزینه حتماً از توکن‌ساز (Tokenizer) مدل مورد نظر استفاده کنید.
- یک مجموعه داده «زشت» (Edge Cases) از ورودی‌های واقعی خود بسازید تا پیش از تغییر مدل، کیفیت خروجی را بسنجید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو