سود:
- تعیین می کند که پردازش دسته ای برای کدام بار کاری مناسب است
- مبادله هزینه/تأخیر بین پردازش همزمان، ناهمزمان و دسته ای را درک می کند
- یک گردش کار دسته ای قوی طراحی می کند که custom_id را با نتایج مطابقت می دهد
اکثر ادغام های LLM بر روی سناریوهای "زنده" تمرکز می کنند که در آن کاربر در مقابل صفحه منتظر پاسخ است. اما اکثر بارهای کاری حرفه ای در واقع زنده نیستند: برچسب گذاری هزاران سند در طول شب، خلاصه کردن کل مجموعه داده ها، طبقه بندی کل تماس های ضبط شده در بایگانی. در این مسائل، هیچ کس انتظار پاسخ فوری ندارد. نکته مهم این است که کار را ارزان و قابل اعتماد به پایان برسانید. دسته ای دقیقا برای این حجم کاری است. در این واحد، تفاوت بین پردازش همزمان، ناهمزمان و دستهای را یاد خواهید گرفت، زمانی که دستهای انتخاب مناسبی است و جریانی قوی که با اطمینان custom_id و نتایج مطابقت دارد.
سه حالت کار
حالت
چگونه کار می کند
تاخیر
هزینه معمولی
شغل مناسب
همزمان
شما یک درخواست می کنید و منتظر پاسخ هستید
ثانیه
استاندارد
چت زنده، دستیار فوری
ناهمزمان
شما کار را در صف قرار می دهید و پس از اتمام کار به شما اطلاع داده می شود.
ثانیه - دقیقه
استاندارد
وظایف پس زمینه، مراحل اتوماسیون
دسته ای
هزاران درخواست را در یک بسته ارسال می کند، سپس نتایج را دریافت می کند
دقیقه - ساعت
معمولا با تخفیف
مشاغل با حجم بالا و تحمل تاخیر
پردازش دسته ای این است: شما صدها/هزاران درخواست را به عنوان یک "کار" به ارائه دهنده ارسال می کنید. ارائه دهنده آنها را با سرعت خود پردازش می کند و پس از تکمیل همه نتایج را به صورت انبوه برمی گرداند. در عوض شما دو چیز دریافت می کنید: (1) هزینه واحد به طور کلی کمتر، (2) توانایی حرکت دادن حجم بالا بدون نیاز به مقابله با محدودیت سرعت. قیمت این است که نتایج فورا به دست نمی آیند، اما پس از مدتی.
چه زمانی دسته بندی کنیم، چه زمانی نه؟
تصمیم به یک سوال خلاصه می شود: آیا کاربر اکنون منتظر نتیجه است؟
- نه، من می توانم آن را نگه دارم → نامزد دسته ای. برچسبگذاری شبانه، خلاصهسازی دستهای، طبقهبندی بایگانی، غنیسازی دادهها، ارزیابی (Eval) اجرا.
- بله، منتظر روی صفحه ← همگام سازی. چت زنده، مشاوره فوری، کمک در پر کردن فرم ها.
نکته: دو حالت می توانند در یک محصول با هم وجود داشته باشند. کاربر به طور همزمان در چت زنده کار می کند. شب ها تمام صحبت های آن روز را برای تحلیل کیفی در اختیار گروه قرار می دهید. جداسازی «نیاز زندگی» از «نیاز جمعی» اولین تصمیم معماری است.
آناتومی جریان دسته ای قوی
مهمترین قانون فنی پردازش دسته ای تطبیق نتیجه است.
- به هر درخواست یک «شناسه_سفارشی» منحصربفرد بدهید. این شناسه ایجاد شده شماست که درخواست را شناسایی می کند (به عنوان مثال، invoice-2026-07-18-000431).
- کار را ارسال کنید. همه درخواست ها در یک بسته قرار می گیرند. هر کدام custom_id خود را دارند.
- وضعیت را نظرسنجی کنید شما در فواصل زمانی تا زمانی که کار "انجام شد" وضعیت را درخواست می کنید.
- نتایج را با «شناسه_سفارشی» مطابقت دهید. نتایج ممکن است به ترتیبی متفاوت از دستور ارسال بازگردانده شوند. بنابراین هرگز با موقعیت مطابقت نداشته باشید، بلکه با custom_id هر نتیجه مطابقت دارد.
- نوع هر نتیجه را بررسی کنید. یک درخواست ممکن است موفق شود، یکی ممکن است شکست بخورد، ممکن است منقضی شود. فرآیند مبتنی بر موفقیت/شکست.
{ "requests": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "طبقه بندی صورتحساب. فقط JSON برگردانده شود.", "messages": "[{":":role" "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5"، "max_tokens": 128، "system": "Classify invoice. Returnmes "[JSONsrole"." "content": "{{invoice_text_2}}" }] } } ]}
احتیاط: مطابقت نتایج بر اساس ترتیب ارسال، اشتباه شماره یک در دسته بندی است. صف حفظ نشده است. بدون custom_id نمیتوانید با اطمینان بدانید که کدام نتیجه متعلق به کدام سند است - تطبیق اشتباه بیصدا منجر به دادههای اشتباه میشود.
قالب های قابل کپی
# قانون تولید custom_id (یکتا و قابل ردیابی) قالب: <isture>-<date>-<sequence>. به عنوان مثال: request-20260718-000431قانون: هرگز در کار تکرار نکنید. شناسه رکورد منبع را در آن جاسازی کنید.
# کارت کار دسته ای (الگوی زمان بندی) نام شغل: .............تعداد سوابق: .............مدل: ............. (کار ساده → مدل سریع) حداکثر_توکن ها در هر درخواست: .............تحمل زمان تحویل مورد انتظار: ......... ساعت کلید تطبیق نتیجه: custom_idدر صورت خطا: سعی مجدد / صف / گزارش
# درخواست تک درخواست به صورت دسته ای (کوتاه و شماتیک) این سند را طبقه بندی کنید. فقط این JSON را برگردانید و نظر دهید:{"category":"...", "urgency":"low|medium|high"}سند: """{{document}}"""
# شبه کد پردازش نتیجه برای هر نتیجه: if result.status == "موفقیت": رکورد = find(custom_id) save(record, result.output) در غیر این صورت: add_to_fail(custom_id, result.error) # سپس دوباره امتحان کنید
اعلان ضعیف / اعلان قوی (طراحی کار دسته ای)
# ضعیف (طراحی شکننده) 10000 سند را به ترتیب با مدل قوی ارسال کنید، نتایج بازگشتی را به ترتیبی که میرسند ذخیره کنید.
# STRONG (طراحی بادوام) ارسال 10000 سند در یک دسته با یک مدل سریع. به هر سند یک custom_id منحصر به فرد حاوی شناسه سورس رکورد بدهید. نتایج را با custom_id مطابقت دهید. موارد شکست خورده را در صف قرار دهید و دوباره امتحان کنید. در پنجره شب اجرا کنید. تحمل تحویل 6 ساعت
نسخه قدرتمند؛ انتخاب مدل، کلید تطبیق، مدیریت خطا و زمانبندی را از پیش تعریف میکند. این تفاوت در پردازش ایمن ده ها هزار رکورد است.
سه کیف کوچک
مورد 1 - برچسب گذاری در شب. یک تیم تجارت الکترونیک 200000 بررسی محصول را در برچسبهای احساسی مرتب میکند. پخش زنده همزمان مشمول محدودیتهای سرعت بود و هزینه بر بود. آنها کار را به صورت دسته ای با یک مدل سریع در شب حمل کردند. هزینه واحد کاهش یافت، کل مجموعه صبح آماده بود و هیچ مشکل محدودیت سرعت وجود نداشت.
مورد 2 - سردرگمی نظم. یک گروه تحقیقاتی 5000 مقاله را چکیده کردند، اما نتایج را به ترتیبی که رسیدند در فایلها نوشتند. از آنجایی که نتایج با ترتیب متفاوتی برگردانده شد، تقریباً 900 چکیده از 5000 چکیده به مقاله اشتباهی پیوند داده شد. آنها آن را مجدداً به custom_id تغییر دادند. مشکل حل شد و این تجربه به قانون دائمی تبدیل شد: "همیشه custom_id در دسته."
مورد 3 - حالت آماده به کار زنده در حالت اشتباه. یک تیم پشتیبانی تلاش کرد تا به صورت دسته ای پاسخ های زنده ای را که کاربر انتظار داشت روی صفحه نمایش دهد. کاربران آن را رها کردند زیرا نتایج چند دقیقه بعد رسید. آنها کار زنده را به همگام سازی بازگرداندند و تنها تحلیل کیفیت شبانه را در دسته باقی گذاشتند. درس: دسته برای آماده به کار زنده نیست.
اشتباهات رایج
- نتایج مطابق با موقعیت: ترتیب حفظ نمی شود. از custom_id استفاده کنید.
- انتقال کار زنده به دسته: کاربر نمی تواند چند دقیقه صبر کند. دسته ای برای کارهای تحمل تاخیر است.
- عدم رسیدگی به موارد خطا: برخی از درخواست ها ممکن است شکست خورده/منقضی شده برگردند. آن را در یک صف جداگانه قرار دهید و دوباره امتحان کنید.
- رفلکس قوی استفاده از مدل در دسته: مدل سریع + دسته ارزان ترین ترکیب در کارهای ساده است.
- عدم قابلیت ردیابی custom_id: اگر هیچ سابقه منبعی در شناسه تعبیه نشده باشد، پیوند دادن به نتیجه دشوار می شود.
- فراموش کردن بررسی وضعیت: انتظار نتایج قبل از پایان کار. وضعیت تکمیل را بررسی کنید.
عمیق تر: نظارت بر دسته و مدیریت شکست جزئی
بالغترین جنبه پردازش دستهای این است که به ذهنیت متفاوتی نسبت به تماسهای فردی نیاز دارد: یک کار دستهای یک «فرایند» است، نه یک «رویداد». فرض اینکه ده ها هزار درخواست همگی موفق شوند، شکننده است. طراحی واقع گرایانه از همان ابتدا شکست جزئی را می پذیرد. وضعیت هر نتیجه می تواند متفاوت باشد: موفقیت آمیز، ناموفق (به عنوان مثال ورودی نامعتبر)، لغو شده یا منقضی شده است. یک جریان قوی، وضعیت هر نتیجه را به طور جداگانه پردازش می کند، خرابی ها را در یک "صف امتحان مجدد" جداگانه قرار می دهد و آن صف را جداگانه اجرا می کند.
روش دوم طراحی برای ناتوانی است (اینکه دو بار اجرای یک کار ضرری ندارد). اگر یک دسته قطع شد و آن را مجدداً راه اندازی کردید، نباید دو بار رکوردهای پردازش شده را دوباره پردازش کنید و بنویسید. اتصال custom_id به رکورد منبع شما در اینجا نیز کار می کند: "آیا این رکورد قبلاً پردازش شده است؟" قبل از ذخیره نتیجه بررسی از تایپ مضاعف جلوگیری می کند.
سومین نکته این است که پخشهای زنده را به صورت دستهای متحیر کنید. برخی از مشاغل دارای ابعاد زنده و دسته ای هستند: وقتی کاربر یک سند را بارگیری می کند، یک خلاصه اولیه سریع (همگام) به آنها ارائه می دهید و همان سند را برای تجزیه و تحلیل عمیق تر در شب (دسته ای) دوباره پردازش می کنید. جداسازی آگاهانه این دو حالت، هم تجربه کاربر و هم هزینه را بهینه میکند.
در نهایت، بچینگ نیز راهی برای مقابله با محدودیت سرعت است (واحد 8). ارسال حجم بالا در جریان همزمان زنده ثابت 429 را تولید می کند، در حالی که ارسال همان حجم به انتقال دسته ای فشار را به زمان بندی خود ارائه دهنده محدود می کند و کار را قابل پیش بینی تر می کند.
به طور خلاصه
پردازش دسته ای به طور کلی یک حالت ارزان تر و قوی تر برای بارهای کاری با تحمل تاخیر و حجم بالا است. تصمیم او این بود که "آیا کاربر اکنون منتظر نتیجه است؟" سوال را تعیین می کند حیاتی ترین قانون فنی این است که به هر درخواست یک custom_id منحصربفرد بدهید، نتایج را بر اساس شناسه به جای مکان تطبیق دهید، و موفقیت/شکست هر نتیجه را جداگانه بررسی کنید.
وظیفه کاربردی
یک کار با حجم بالا (به عنوان مثال طبقه بندی بایگانی) را انتخاب کنید. (1) در مورد زنده یا جمعی بودن این اثر تصمیم بگیرید و آن را توجیه کنید. (2) یک قالب custom_id طراحی کنید (شامل رکورد منبع). (3) کارت کار دسته ای (مدل، max_tokens، تحمل، خط مشی خطا) را پر کنید. (4) شبه کد پردازش نتیجه را بنویسید تا شامل درخواست های ناموفق باشد.
چک لیست
- [ ] من می توانم حالت های همزمان، ناهمزمان و دسته ای را در محور هزینه/تاخیر تشخیص دهم.
- [ ] من می توانم با پرسیدن سوال درست تصمیم بگیرم که آیا یک شغل برای دسته ای مناسب است یا خیر.
- [ ] من به هر درخواست یک custom_id منحصر به فرد می دهم و نتایج را بر اساس شناسه مطابقت می دهم.
- [ ] من می توانم نتایج ناموفق/منقضی شده را جداگانه مدیریت کنم.
- [ ] من مزایای انتخاب یک مدل سریع در کارهای دسته ای ساده را می دانم.