اگر امروز برای خلاصه‌سازی متون طولانی از درخواست‌های تک‌مرحله‌ای استفاده می‌کنید، احتمالاً با خطاهای پیش‌بینی‌نشده و هزینه‌های تکراری دست‌وپنجه نرم می‌کنید. تصور کنید یک API خلاصه‌سازی متن در Node.js دارید که درخواست‌های تک و غول‌آسا را با یک خط لوله‌ی «شمارش-تکه‌بندی-خلاصه‌سازی-ترکیب» جایگزین می‌کند تا مقالات بیش از حد بزرگ را به‌طور قابل‌اعتمادی مدیریت کند. در حالی که یک درخواست بزرگ واحد به دلیل نبود پیچیدگی‌های زیرساختی جذاب به نظر می‌رسد، اما اپلیکیشن را در وضعیتی قرار می‌دهد که باید حدس بزند آیا ورودی با محدودیت‌ها سازگار است یا خیر، و باعث می‌شود تلاش‌های شکست‌خورده برای تکرار، بسیار هزینه‌بر باشند. انتقال به این معماری خط لوله تضمین می‌کند که تأخیر و هزینه‌های توکن به‌جای کرش کردن اپلیکیشن در هنگام عبور از محدودیت‌های ورودی، در گام‌های پیش‌بینی‌پذیر رشد کنند. این رویکرد شاید کمتر «باهوشانه» به نظر برسد، اما استقرار و بهره‌برداری از آن بسیار آسان‌تر است.
بسیاری از توسعه‌دهندگان سعی می‌کنند متون طولانی را بر اساس تعداد کاراکتر یا کلمات برش دهند، اما این روش اساساً معیوب است. دو رشته متنی با طول یکسان می‌توانند به تعداد توکن‌های متفاوتی تبدیل شوند؛ به این معنا که یک جداکننده بر اساس کاراکتر، اغلب بودجه ورودی را پیش از آنکه مدل فرصتی برای تولید پاسخ داشته باشد، پر می‌کند. برای حل این مشکل، سیستم باید با توکن‌سازی (Tokenization) — شبیه به بریدن یک کیک طولانی به تکه‌های کوچک برای اینکه مدل بتواند آن‌ها را هضم کند — آغاز شود. به نقل از مستندات فنی این آزمایش، سرویس Infrai از طریق نقطه اتصال /v1/ai/tokens/count این امکان را فراهم می‌کند تا جداکننده به‌جای کاراکتر، بر اساس توکن‌ها عمل کند. نکته مهم این است که طرح دقیق درخواست شمارش توکن باید از مستندات فعلی API یا قراردادهای اکتشافی استخراج شود، نه اینکه از پست‌های قدیمی کپی شود.
ساخت یک خلاصه‌ساز آماده برای محیط تولید (Production)، مستلزم فراتر رفتن از مهندسی ساده‌ی پرامپت است. چالش اصلی، عبارت‌بندی پرامپت نیست، بلکه محدودیت‌های ارزیابی و مرزهای اپلیکیشن است. کاتالوگ مدل‌ها و یک مجموعه کوچک از داده‌های واقعی محصول باید تعیین‌کننده انتخاب مدل باشند، در حالی که مرز اپلیکیشن سایر موارد را تعیین می‌کند. با تبدیل شناسه مدل (Model ID) به یک پیکربندی استقرار — که از /v1/models یا /v1/models/{id} انتخاب شده و برای منطقه مورد نیاز (آمریکا یا اروپا) تأیید شده است — توسعه‌دهندگان می‌توانند مدل‌ها را بر اساس در دسترس بودن منطقه‌ای یا عملکرد روی داده‌ها، بدون ویرایش کد منبع تعویض کنند. این امر تضمین می‌کند که تغییر مدل یک تصمیم استقرار است، نه یک ویرایش در کد.
مکانیزم کاهش دو مرحله‌ای
این معماری برای اطمینان از اینکه خروجی نهایی محدود و قابل مدیریت باقی می‌ماند، از یک فرآیند سخت‌گیرانه در دو مرحله پیروی می‌کند:
- مرحله اول: مقاله به تکه‌های محدود تقسیم می‌شود. هر تکه با یک دستورالعمل ثابت و یک قرارداد خروجی یکسان به مدل ارسال می‌شود. مدل موظف است یک شیء JSON فشرده شامل عنوان، خلاصه‌ی متنی، نکات کلیدی (Bullets) و یافته‌های اصلی برگرداند، در حالی که نام‌ها، اعداد، صلاحیت‌ها و موارد اختلاف‌نظر موجود در منبع را حفظ کند.
- مرحله دوم: سیستم تنها اشیاء JSON مرحله اول را دریافت می‌کند — نه متن اصلی مقاله را — تا یک شیء نهایی و یکپارچه با همان ساختار تولید کند.
این طراحی باعث می‌شود تلاش‌های مجدد (Retries) محلی شوند. اگر یک تکه شکست بخورد، سیستم فقط همان بخش خاص را تکرار می‌کند، نه کل فرآیند سند را. برای جلوگیری از دست رفتن زمینه (Context) بین تکه‌ها — مثلاً وقتی شخصی در یک بلوک معرفی شده و در بلوک بعدی با ضمیر به او اشاره می‌شود — این آزمایش پیشنهاد می‌کند که از یک هم‌پوشانی (Overlap) کوچک بین تکه‌ها استفاده شود.
بهینه‌سازی هم‌پوشانی و پایداری JSON
از آنجایی که یک مقدار واحد برای هم‌پوشانی ممکن است برای مقالات، ترنسکریپت‌ها و مستندات فنی به‌طور یکسان عمل نکند، این مقدار باید از یک مجموعه ارزیابی نماینده استخراج شود. این فرآیند شامل مراحل زیر است:
- تغییر مقدار هم‌پوشانی.
- ثبت نکات کلیدی تکراری.
- ردیابی ارجاعات گم‌شده.
- انتخاب کوچک‌ترین هم‌پوشانی که معیارهای پذیرش محصول را برآورده می‌کند.
برای جلوگیری از خطاهای شکننده در تجزیه رشته‌ها، سیستم یک قرارداد JSON «ساده و خسته‌کننده» را تحمیل می‌کند. کلیدهای پایدار باعث می‌شوند اعتبارسنجی، ذخیره‌سازی و رندرینگ در مراحل بعدی ساده شود. اپلیکیشن باید صراحتاً پاسخ‌هایی را که فاقد خلاصه هستند، یا به‌جای آرایه‌ای از نکات، یک مقدار تک‌مقدار (Scalar) برگردانده‌اند، یا حاوی مقادیر غیررشته‌ای در آرایه‌ها هستند، رد کند. در اینجا صرفاً سینتکس JSON کافی نیست و اعتبارسنجی سخت‌گیرانه در سطح TypeScript ضروری است تا تضمین شود قرارداد رعایت شده است.
طبق گزارش این آزمایش، استفاده از کلاینت‌های سازگار با OpenAI انعطاف‌پذیری را در انتخاب ارائه‌دهنده افزایش می‌دهد. تأکید ویژه‌ای بر تنظیم maxRetries: 0 شده است تا مالکیت تلاش‌های مجدد در لایه منطق اپلیکیشن باقی بماند. این کار اجازه می‌دهد برنامه خطاهای HTTP 429 (درخواست‌های بیش از حد) را با استفاده از عقب‌نشینی نمایی (Exponential Backoff) یا هدر Retry-After سرور مدیریت کند. هرگاه سرور مقدار Retry-After را ارائه دهد، اولویت با آن است؛ در غیر این صورت، سیستم از فرمولی مانند 500 * 2 ** attempt استفاده می‌کند.
برای جلوگیری از ایجاد عملیات منطقی جدید در هنگام تکرارها، یک کلید Idempotency پایدار باید با استفاده از هش SHA-256 از مدل، مرحله و ورودی مشتق شود. اگر JSON نهایی در یک پایگاه داده یا سیستم انتشار نوشته شود، این شناسه عملیاتی پایدار باید به آن запись منتقل شود تا یکتایی (Uniqueness) تضمین گردد. تکرارهای تولید و حذف تکرارهای نوشتن، از مرزهای متفاوتی محافظت می‌کنند.
جزئیات پیاده‌سازی و هم‌روندی
در یک پیاده‌سازی متمرکز با TypeScript، برنامه تکه‌های محدود را به عنوان آرگومان‌های خط فرمان می‌پذیرد تا منطق تکه‌بندی از فراخوانی Chat Completions جدا شود. فرآیند هر تکه را به‌صورت متوالی خلاصه‌سازی کرده، نتایج را ترکیب می‌کند و هر پاسخ را اعتبارسنجی می‌نماید.
در مورد عملکرد، این طراحی عمداً در ابتدا از «دکمه هم‌روندی» (Concurrency) اجتناب می‌کند. درخواست‌های متوالی یک خط مبنای خوانا فراهم کرده و داده‌های تأخیر (Latency) پاکی تولید می‌کنند. موازی‌سازی محدود تنها باید پس از اندازه‌گیری نرخ خطای 429 و تأخیرهای انتهایی (Tail Latency) اضافه شود. افزودن هم‌روندی در مراحل اولیه، صرفه‌جویی در چند خط زمان را با مدل هزینه و تکرار بسیار دشوارتری معاوضه می‌کند. علاوه بر این، سیستم باید در مواجهه با خطاهای API غیر از 429 متوقف شود، به‌جای اینکه آن‌ها را به عنوان نویزهای قابل تکرار پنهان کند، زیرا SDK وضعیت پاسخ و جزئیات خطای مورد نیاز برای اصلاحات واقعی 4xx را حفظ می‌کند.
تحلیل Trade-off ارائه‌دهندگان
انتخاب بین ادغام مستقیم با فروشنده و استفاده از یک قرارداد مشترک، یک موازنه است. این انتخاب بستگی به این دارد که آیا رفتار یک مدل خاص، یک نیاز محوری محصول است یا اینکه انعطاف‌پذیری اولویت دارد:
- OpenAI Direct: زمانی منطقی است که یک مدل OpenAI در ارزیابی محصول برنده شود و دسترسی مستقیم حیاتی باشد. هزینه آن این است که اپلیکیشن یک رابطه اختصاصی با OpenAI دارد.
- Anthropic Direct: زمانی استفاده می‌شود که رفتار خاص مدل Claude یک نیاز صریح محصول باشد. هزینه آن مالکیت یک ادغام دیگر با ارائه‌دهنده است.
- Google Gemini Direct: زمانی استفاده می‌شود که مدل Gemini روی مجموعه داده‌های محصول بهترین عملکرد را داشته باشد. هزینه آن مالکیت یک ادغام دیگر است.
- Infrai: زمانی منطقی است که بخواهید یک قرارداد سازگار با OpenAI را ثابت نگه دارید در حالی که فروشنده پشتیبان تغییر می‌کند. این اجازه می‌دهد یک مرز اپلیکیشن از تعویض فروشنده جان سالم به در ببرد.
طبق گزارش، این انتزاع (Abstraction) بسیار ارزشمندتر از کاهش اندک قیمت‌های گذرا در مدل‌ها است. این رویکرد در مدیریت هزینه‌ها با مدل‌های سنتی توکن‌محور متفاوت است و یادآور تغییر استراتژی Oxlo.ai در پردازش داده‌هاست که برای ساده‌سازی خلاصه‌سازی اسناد طولانی، به سمت مدل‌های نرخ ثابت حرکت کرد. با این حال، نویسنده اشاره می‌کند که چنین پلتفرم‌هایی ممکن است برای پروژه‌های مبتنی بر صدا به‌دلیل محدودیت‌های فعلی در بازشناسی گفتار (ASR) و منطقه‌ای بودن جلسات صوتی بلادرنگ مناسب نباشند. همچنین، به‌دلیل نبود نقطه اتصال اختصاصی برای نظارت (Moderation)، بررسی متون یا تصاویر مستلزم استفاده از یک مدل چت با fallback به JSON-schema است. ارتقای کیفیت تصاویر (Upscaling) نیز به Lanc محدود است. این مرزها مانع از ساخت یک خلاصه‌ساز متنی نمی‌شوند، اما تیمی را که تصور می‌کند هر جریان کاری رسانه‌ای متعلق به یک پلتفرم واحد است، متوقف می‌کنند.
چارچوب ارزیابی
قبل از استقرار، این آزمایش استدلال می‌کند که عبارت «خلاصه‌ساز کند است» یک تشخیص معتبر نیست. توسعه‌دهندگان باید معیارهای دقیقی را اندازه‌گیری کنند تا مشکلات ورودی‌های بزرگ را از مشکلات مدل‌های پرحرف و مشکلات هم‌روندی تفکیک کنند:
- معیارهای توکن: توکن‌های ورودی، توکن‌های خروجی و تعداد تکه‌ها در هر سند.
- تأخیر: تأخیر سرتاسری (End-to-End) و تأخیر به‌ازای هر تکه.
- نرخ خطا: تکرار خطای 429، شکست‌های تجزیه JSON، شکست‌های طرحواره (Schema) و شکست‌های ترکیب (Combine).
تست‌ها باید با چهار نوع سند متمایز آغاز شود: یک مقاله کوتاه، یک متن طولانی دارای تیترها، یک ترنسکریپت با عبارات تکراری و یک پست فنی با ادعاهای عددی. بررسی نهایی باید تضمین کند که نام‌ها و اعداد دقیقاً به منبع بازمی‌گردند و صلاحیت‌ها در مرحله ادغام حفظ شده‌اند. بسیار حیاتی است که تأیید شود نکات تکراری حذف شده‌اند و عنوان تولید شده، قطعیت کاذب اضافه نکرده است. یک خلاصه تکه ممکن است تمیز به نظر برسد، در حالی که مرحله ترکیب به‌طور بی‌صدا جمله‌ای را حذف کند که معنا را تغییر می‌دهد؛ بنابراین، اعتبار میانی و وفاداری نهایی (Faithfulness) نیاز به بررسی‌های جداگانه دارند.
این رویکرد تمرکز را از تنظیم پرامپت به مهندسی سیستم تغییر می‌دهد. با اولویت دادن به مرز اپلیکیشن و اندازه‌گیری به‌جای رتبه‌بندی مدل، توسعه‌دهندگان می‌توانند ابزاری بسازند که استقرار و بهره‌برداری از آن در مقیاس بالا آسان‌تر باشد. قانون نهایی استقرار ساده است: ورودی‌های کوتاه مستقیماً به Chat Completions می‌روند؛ ورودی‌های طولانی از مسیر شمارش توکن، خلاصه‌سازی تکه‌های محدود و یک مرحله ادغام عبور می‌کنند و JSONهای میانی را برای محلی نگه داشتن تکرارها حفظ می‌کنند. ابتدا جریان کنترل را کپی کنید، سپس آن را با داده‌های محصول تنظیم کنید.
گام بعدی شما
- پیاده‌سازی یک لایه اعتبارسنجی JSON سخت‌گیرانه برای جلوگیری از کرش کردن اپلیکیشن در هنگام تغییر مدل.
- اندازه‌گیری مقدار بهینه هم‌پوشانی (Overlap) روی مجموعه‌ای از ۵۰ سند واقعی از دیتای محصول خودتان.
- جایگزینی منطق
maxRetriesداخلی SDK با یک سیستم Exponential Backoff سفارشی برای مدیریت بهتر خطاهای 429.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو