تصور کنید در معماری خود یک مرز سخت ایجاد کنید: تمام تیکت‌های پشتیبانی بازار را فوراً دریافت و ذخیره کنید، اما پردازش هوش مصنوعی را تنها زمانی ارسال کنید که عامل‌های انسانی بتوانند تأخیر را تحمل کنند. با انتقال کارهای خلاصه‌سازی و برچسب‌گذاری به شغل‌های LLM دسته‌ای (Batch LLM jobs)، یک تیم مهندسی کوچک می‌تواند هزینه‌های عملیاتی خود را به‌شدت کاهش دهد. این رویکرد تضمین می‌کند که پاسخ کندِ یک ارائه‌دهنده هوش مصنوعی، هرگز به یک نقطه شکست در کل سیستم یا یک منبع داده‌ای غیرقابل‌اتکا (System of Record) تبدیل نشود.
همان‌طور که در تحلیل قبلی ما درباره‌ی mcp-retrieval و بهینه‌سازی دسترسی مدل‌ها به وب از طریق دور زدن APIهای گران‌قیمت اشاره کردیم، این تغییر معماری بر هزینه و پایداری خط لوله داده‌های داخلی تمرکز دارد. برای بسیاری از کسب‌وکارها، «صندوق ورودی» (Inbox) مرز حیاتی است، نه خودِ مدل. اگر مشتری شکایتی درباره وضعیت سفارش ثبت می‌کند، به تاییدیه فوری نیاز دارد، اما عامل پشتیبانی برای دریافت برچسب مسیریابی تولید شده توسط هوش مصنوعی، می‌تواند یک ساعت صبر کند.
معماری دسته‌ای
به نقل از یک راهنمای فنی منتشر شده در ۲۰ اوت ۲۰۲۶، قابل‌اعتمادترین گردش‌کار، مسیر دریافت داده (Intake Path) را از مسیر پردازش هوش مصنوعی جدا می‌کند. این کار تضمین می‌کند که پردازش‌های هم‌زمان، درخواست‌های مشتری، تأخیر مدل، اعتبارسنجی خروجی‌های ساختاریافته و به‌روزرسانی‌های پنل عامل را در یک «دامنه شکست» (Failure Domain) واحد قرار ندهد. با این تفکیک، مسیر دریافت تیکت می‌تواند به سرعت به پایان برسد، در حالی که پردازش هوش مصنوعی با ساعت داخلی خودش پیش می‌رود.
این جداسازی محیطی طبیعی برای اپراتورها ایجاد می‌کند تا پیش از اجرا، تعداد توکن (Token) — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — را تخمین بزنند، حجم اجرای شبانه را بررسی کنند، وضعیت شغل‌ها را ردیابی نمایند و نتایج پذیرفته‌شده را استخراج کنند. در واقع، فرآیند هوش مصنوعی از یک وابستگی شکننده در لحظه، به یک شغل پس‌زمینه قابل مدیریت تبدیل می‌شود.
مرزهای یکپارچه‌سازی
برای تیم‌های توسعه‌دهنده با Node.js، ابزار Infrai به عنوان یک گزینه معتبر معرفی شده است؛ زیرا کارهای دسته‌ای را از طریق HTTP ساده ارائه می‌دهد. این ویژگی نیاز به مدیریت نسخه‌های پیچیده SDK یا کتابخانه‌های کلاینت در داخل سرویس را حذف می‌کند. یکپارچه‌سازی در اینجا بر اساس یک مانیفست اکتشافی عمومی (Public Discovery Manifest) است که متد زنده، مسیر، طرح درخواست (Request Schema)، طرح پاسخ، اطلاعات صورت‌حساب و نمونه‌ها را بدون نیاز به کلید API گزارش می‌دهد.
قوت اصلی Infrai در محدوده یکپارچه‌سازی است، نه لزوماً ادعای ارزان‌ترین بودن. داشتن یک سطح REST به این معناست که یک سرویس TypeScript می‌تواند بدون افزودن SDK فروشنده، از fetch استفاده کند. این تجمیع عملیاتی اجازه می‌دهد یک کلید و یک صورت‌حساب، هم مرز پردازش دسته‌ای و هم سایر قابلیت‌های بک‌اند را پوشش دهد که برای توسعه‌دهندگان تک‌نفره (Solo Operators) بسیار کاربردی است.
پیاده‌سازی منطق ارسال
برای تضمین پایداری در محیط عملیاتی، فرآیند ارسال باید از محدودیت‌های فنی سخت‌گیرانه‌ای پیروی کند. بدنه درخواست برای یک یکپارچه‌سازی تولیدی باید از طرح قابلیت‌های زنده (Live Capability Schema) بیاید، نه از فهرستی که از یک مقاله کپی شده باشد.
جزئیات کلیدی پیاده‌سازی عبارتند از:
- قراردادهای مبتنی بر اکتشاف: سیستم باید مانیفست عمومی را برای یافتن متد و مسیر دقیق بررسی کند. سیستم باید یک Payload مطابق با طرح را از
BATCH_PAYLOADبخواند و آن را ارسال نماید. سطح اکتشاف، خود-توصیف‌گر (Self-describing) است و به هیچ کلیدی نیاز ندارد. - تکرارناپذیری (Idempotency): هر ارسال به یک متد صریح و یک کلید تکرارناپذیری (مثلاً
marketplace-ticket-triage-runId) نیاز دارد تا از پردازش تکراری در هنگام تلاش‌های مجدد (Retries) جلوگیری شود. - مدیریت خطا: سیستم باید به هدرهای
Retry-Afterبرای محدودیت‌های نرخ (Rate Limits) ۴۲۹ احترام بگذارد. در صورت نبود این هدر، باید از استراتژی عقب‌نشینی نمایی (Exponential Backoff) — شروع از ۵۰۰ میلی‌ثانیه و دو برابر شدن در هر تلاش — تا ۵ مرتبه استفاده کند. اگر محدودیت نرخ پس از ۵ تلاش همچنان فعال بود، سیستم باید خطا (Error) صادر کند. - پیش‌بینی توکن: اپراتورها باید پیش از اجرای حجم بالای داده (Backlog)، توکن‌ها را تخمین بزنند تا هزینه‌ها را پیش‌بینی کنند. اگرچه دسته‌بندی می‌تواند هزینه‌ها را برای کارهای غیرلحظه‌ای کاهش دهد و از هزینه‌های هم‌زمان در ساعات پیک جلوگیری کند، اما صرفه‌جویی واقعی بسته به اندازه پرامپت، طول خروجی و مدل انتخابی متفاوت است.
گیت پذیرش
یک شغل دسته‌ای پذیرفته‌شده، به معنای یک تصمیم تجاری پذیرفته‌شده نیست. بر اساس مستندات این راهنما، «JSON معتبر» با «خروجی ساختاریافته صحیح» متفاوت است. یک مرحله پذیرش مجزا باید نتایج هوش مصنوعی را بر اساس قوانین تجاری محلی اعتبارسنجی کند، پیش از آنکه داده‌ها به پنل عامل برسند. این موضوع حیاتی است زیرا ممکن است درخواستی توسط ارائه‌دهنده پذیرفته شود، اما خروجی تجاری نهایی آن غیرقابل استفاده باشد. در واقع، تمرکز صرف بر کاهش هزینه بدون در نظر گرفتن معیارهای کیفی، می‌تواند منجر به شکست کل سیستم شود؛ موضوعی که در تحلیل ما درباره خطاهای رایج گیت‌وی‌های هوش مصنوعی به تفصیل بررسی شده است.
این گیت باید به پرسش‌های دامنه پاسخ دهد:
- کامل بودن: آیا هر تیکت ارسالی دقیقاً یک نتیجه دارد؟
- همسویی با تاکسونومی: آیا برچسب مسیریابی در تاکسونومی (دسته‌بندی) فعلاً مستقر شده وجود دارد؟
- اعتبارسنجی فرمت: آیا شناسه‌های مورد نیاز، رشته‌هایی با فرمت مورد انتظار هستند؟
- نگاشت مستاجر: آیا خروجی را می‌توان بدون حدس زدن به یک مستاجر (Tenant) بازار متصل کرد؟
اگر هر یک از این بررسی‌ها شکست بخورد، مورد مذکور برای بررسی انسانی قرنطینه می‌شود. این کار مانع از آن می‌شود که یک پاسخ با فرمت درست اما محتوای غلط، به‌طور خاموش صف پشتیبانی را منحرف کند. لایه انتقال (Transport Layer) نمی‌تواند درباره این قوانین تجاری تصمیم بگیرد؛ این‌ها باید توسط اپلیکیشن مدیریت شوند.
نحو در برابر معنای تجاری
دو لایه متمایز از اعتبارسنجی وجود دارد: نحو (Syntax) و معنای تجاری. طرح JSON می‌تواند یک برچسب گم‌شده یا نوع مقدار غیرمنتظره را رد کند، اما نمی‌تواند تشخیص دهد که یک مرجع سفارش به‌ظاهر درست، متعلق به مستاجر آن تیکت است یا خیر. همچنین نمی‌تواند تشخیص دهد که آیا خلاصه‌سازی، درخواست واقعی مشتری را نادیده گرفته است یا نه.
یک تیکت را در نظر بگیرید که شامل پیام فروشنده، پاسخ نقل‌شده خریدار و دو مرجع سفارش است. یک نتیجه از نظر ساختاری معتبر همچنان می‌تواند خطاهای زیر را داشته باشد:
- اتصال مرجع خریدار به فروشنده.
- انتخاب برچسب مسیریابی که هنگام نوشتن پرامپت وجود داشت اما اکنون بازنشسته شده است.
- خلاصه‌سازی پاسخ نقل‌شده به‌جای جدیدترین پیام.
عامل پذیرش باید تیکت و مستاجر را از رکورد همبستگی (Correlation Record) خودش استخراج کند، برچسب بازگشتی را با نسخه منجمد شده تاکسونومی برای آن اجرا مقایسه کند و مراجع استخراج‌شده را با رکوردهایی که مستاجر به آن‌ها دسترسی دارد، بسنجد. تنها پس از آن است که به‌روزرسانی نهایی برای پنل عامل ساخته می‌شود.
این مسیر طولانی‌تر، عمدی است. این نشان می‌دهد که چرا یک پوش (Envelope) دسته‌ای مستقل از ارائه‌دهنده نمی‌تواند جایگزین اعتبارسنجی دامنه شود. هیچ تضمین طرح در سطح ارائه‌دهنده در حال حاضر برای بازاری با تاکسونومی‌های متغیر کافی نیست، مگر اینکه قرارداد هم انطباق طرح و هم اعتبارسنجی تجاری آگاه از مستاجر را پوشش دهد.
مقایسه ارائه‌دهندگان
انتخاب مرز مناسب به زیرساخت فعلی تیم و میزان پذیرش ابزارهای خاص هر ارائه‌دهنده در اپلیکیشن بستگی دارد.
| گزینه | مورد استفاده مناسب | نکته منفی |
|---|---|---|
| Infrai | تیم‌های کوچک که ارسال دسته‌ای روی REST و صورت‌حساب تجمیعی را در یک سطح گسترده بک‌اند می‌خواهند. | برای چت‌های لحظه‌ای انتخاب نکنید؛ وقتی تأخیر منعطف نیست از مسیر Completion معمولی استفاده کنید. |
| OpenAI Direct | محصولاتی که عمداً به یک ارائه‌دهنده متصل شده‌اند و حاضرند قرارداد آن ارائه‌دهنده را در مرز اپلیکیشن نگه دارند. | هنگام تغییر ارائه‌دهنده، باید آداپتور بازنویسی شود. |
| Anthropic Direct | تیم‌هایی که ارزیابی می‌کنند یک رابطه مستقیم با متخصص را به عنوان مرز اصلی اجرا قرار دهند. | باید قرارداد دسته‌ای و رفتار خروجی ساختاریافته را با تست‌های (Fixtures) خود بسنجند. |
| Google Vertex AI | تیم‌هایی که از پیش این پلتفرم را به عنوان مرز کنترل‌شده AI خود ارزیابی کرده‌اند. | باید الزامات منطقه‌ای، مدل‌ها و شرایط دسته‌ای را پیش از تعهد بررسی کنند. |
| AWS Bedrock | تیم‌هایی که تصمیم پلتفرمی آن‌ها از پیش بر محور AWS Bedrock است. | همسویی با پلتفرم ممکن است مهم‌تر از داشتن یک آداپتور HTTP خنثی باشد. |
| BullMQ + Direct | تیم‌هایی که به زمان‌بندی سفارشی نیاز دارند و آماده مدیریت Workerها، سیاست‌های تلاش مجدد و ذخیره‌سازی وضعیت هستند. | کنترل بیشتر به معنای کدنویسی بیشتر برای صف و مالکیت عملیاتی است. |
زمانی از ارائه‌دهنده مستقیم استفاده کنید که کنترل‌های خاص آن ارائه‌دهنده برای محصول حیاتی باشد. برای داده‌های تحت نظارت (Regulated Data)، الزامات امنیتی و حریم خصوصی را ارزیابی کنید؛ شباهت APIها به معنای حل شدن این بررسی‌ها نیست.
عملیاتی کردن تحویل
برای اجرای این مدل به صورت یک محصول شبانه، تیم‌ها باید یک حلقه عملیاتی منضبط را دنبال کنند. پیش از هر اجرا، نسخه تاکسونومی را منجمد کنید، توکن‌ها را برای Payload مورد نظر تخمین بزنید و تعداد ورودی‌ها را ثبت کنید. ارسال را با یک کلید تکرارناپذیری پایدار که از اجرای منطقی مشتق شده (نه تلاش پردازشی)، انجام دهید.
پس از دریافت نتایج، سیستم باید شناسه‌های تیکت ارسالی و بازگشتی را پیش از تجزیه فیلدهای دامنه، تطبیق (Reconcile) دهد. اعتبارسنجی باید با این ترتیب دقیق رخ دهد:
۱. اعتبارسنجی نحو/طرح: تشخیص شکست‌های ساختاری در مراحل اولیه ارزان‌تر است.
۲. بررسی‌های مستاجر: اطمینان از تعلق داده‌ها به حساب درست.
۳. بررسی‌های تاکسونومی: اطمینان از به‌روز بودن برچسب‌ها.
موارد رد شده باید با دلیل واضح ذخیره شوند تا اپراتورها بتوانند روی آن‌ها اقدام کنند. در نهایت، ردیف‌های پذیرفته‌شده را در یک به‌روزرسانی تکرارناپذیر منتشر کنید تا اجرای مجدد خروجی‌ها باعث تکرار کار نشود.
جداسازی مسیر لحظه‌ای
بسیار حیاتی است که مرز دسته‌ای هرگز با جعبه پاسخ (Reply Box) تلاقی نکند. اگر یک عامل انسانی یا مشتری منتظر متن تولید شده است، یک فراخوانی Completion معمولی لازم است. دسته‌بندی صرفاً برای بک‌لاگ‌های شبانه، بازپروری تاکسونومی یا غنی‌سازی غیرهم‌زمان است. این روش برای تعاملاتی که پاسخ فوری می‌طلبند، مناسب نیست. این یک سبک‌سنگین کردن (Trade-off) مرکزی است و هیچ گردش‌کار حجمی نمی‌تواند آن را حذف کند.
معیارها (Metrics) نیز باید جدا بمانند تا سلامت سیستم را به اشتباه نشان ندهند:
- معیارهای تریژ شبانه: سن بک‌لاگ، تعداد نتایج پذیرفته‌شده، تعداد نتایج رد شده و وضعیت تکمیل.
- معیارهای چت مشتری: تأخیر درخواست (Latency).
ترکیب این دو معیار، هر دو را سالم‌تر از آنچه هستند نشان می‌دهد. این یک تمایز کوچک با پیامدی بزرگ است.
پرسش نهایی ساده است: آیا تیم پشتیبانی همچنان می‌تواند تیکت‌های جدید را دریافت و بخواند در حالی که اجرای هوش مصنوعی در جریان است؟ اگر بله، مرز دسته‌ای در جای درست است. در غیر این صورت، آن را به پایین‌دست منتقل کنید. وقتی این مرز با سیستم شما سازگار شد، با معناشناسی خطای Infrai شروع کنید تا Worker شما پاسخ‌های قابل تلاش مجدد و غیرقابل تلاش را به‌طور صریح مدیریت کند.
گام بعدی شما
- بررسی کنید کدام بخش‌های گردش‌کار پشتیبانی شما نیاز به پاسخ لحظه‌ای ندارند و آن‌ها را به صف‌های دسته‌ای منتقل کنید.
- یک لایه اعتبارسنجی «پذیرش» (Admission Gate) بین خروجی مدل و دیتابیس نهایی طراحی کنید تا خطاهای معنایی وارد پنل کاربر نشوند.
- از کلیدهای تکرارناپذیری (Idempotency Keys) در ارسال‌های حجیم استفاده کنید تا از هزینه‌های مضاعف ناشی از Retryهای اشتباه جلوگیری کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو