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