تتعثر النماذج اللغوية الكبيرة عندما تطلب منها القيام بالكثير من المهام في وقت واحد. إذا قمت بإلقاء ملف PDF مكون من خمسين صفحة في نافذة الدردشة وطلبت تحليلاً مهيكلاً، وتقييماً للمخاطر، وملخصاً تنفيذياً في نفس اللحظة، فستكون النتيجة عادةً سطحية، أو مشوشة، أو خاطئة تماماً. النهج الأفضل هو نهج ميكانيكي: قسّم المهمة إلى مراحل منفصلة. قم بتغذية مخرجات المرحلة الأولى مباشرة في المرحلة الثانية، وهكذا دواليك. تطلق شركة Anthropic على هذا النمط اسم "تسلسل الأوامر" (prompt chaining)، بينما تشير إليه Google باسم "خط المعالجة المتسلسل" (sequential pipeline). كلا الاسمين يصفان الشيء نفسه: خط تجميع حيث تتعامل كل محطة مع تحويل محدد.
كيف يبدو هذا في الممارسة العملية
بدلاً من أمر واحد ضخم، تقوم ببناء سلسلة من الخطوات الصغيرة والمركزة. تخيل فريق امتثال يعالج تقييمات أمن الموردين. الخطوة الأولى تستخرج النص الخام من ملف PDF ممسوح ضوئياً. الخطوة الثانية تحدد كل ذكر لمعايير التشفير وضوابط الوصول. الخطوة الثالثة تطابق تلك النتائج مع قائمة مراجعة داخلية. الخطوة الرابعة تصيغ مذكرة قصيرة للمسؤول الأمني. يقوم وكيل واحد بتحويل ملف PDF إلى نص، والوكيل التالي يستخرج بيانات محددة من ذلك النص، والوكيل الأخير يكتب ملخصاً بناءً على تلك البيانات. لا توجد أي من هذه الخطوات براقة، ولا تقوم أي منها بمهام متعددة؛ فكل جزء يؤدي وظيفة واحدة بإتقان.
لهذا السبب يظل تشبيه خط التجميع قائماً. في المصنع، لا يقوم عامل واحد بتجميع السيارة بأكملها. التخصص يحافظ على جودة عالية ويقلل من احتمالات الفشل. ينطبق المنطق نفسه على النماذج اللغوية؛ فالأمر الذي يطلب فقط استخراج JSON هو أقل عرضة للهلوسة من الأمر الذي يطلب أيضاً إبداء الرأي والتنسيق في نفس الطلب.
ابنِ بوابات، لا تخمينات
أضعف نقطة في أي سلسلة هي عملية التسليم. قد يعيد النموذج رفضاً مهذباً، أو كتلة من Markdown بدلاً من JSON، أو استجابة مبتورة. إذا تدفقت هذه "النفايات" إلى الخطوة الثانية، فستنهار السلسلة بأكملها. الحل هو "البوابة" (gate).
البوابة ليست استدعاءً للنموذج، بل هي كود برمجي بسيط. تكتب نصاً برمجياً (script) قصيراً يعمل بين الخطوات. قد يتحقق من طول المخرجات للتأكد من أنها ليست فارغة، أو قد يقوم بالتحقق من مخطط JSON (JSON schema validation) للتأكد من أن المفاتيح تطابق ما تتوقعه الخطوة الثالثة. كما يمكن لفحص التعبيرات النمطية (regex check) التحقق من وجود عنوان بريد إلكتروني أو حقل تاريخ بالفعل قبل بناء الأمر التالي. هذا يوقف الأخطاء قبل أن تهدر المال على مخرجات سيئة. تكلفة البوابة هي أجزاء من المليون من الثانية من وقت الحوسبة، بينما يكلف استدعاء LLM فاشل في مرحلة لاحقة استهلاك الـ tokens، وزيادة زمن الاستجابة، وإرهاق أعصابك.
فكر في الأمر كمركز فحص للجودة في أرض المصنع. لست بحاجة إلى ذكاء اصطناعي لعد القطع الصغيرة؛ أنت بحاجة إلى مسطرة.
متى تستخدم التسلسل، ومتى تتوقف
لا يناسب تسلسل الأوامر كل المشكلات. استخدمه عندما يكون للعمل خطوات ثابتة وقابلة للتكرار. التقارير المالية الشهرية، ومراجعة العقود الموحدة، وخطوط تحليل السجلات هي أمثلة جيدة. إذا كان بإمكانك كتابة الإجراء كقائمة مراجعة، فمن المحتمل أن تتمكن من تسلسله. يجب عليك أيضاً اللجوء إلى التسلسل عندما تحتاج إلى دقة عالية في العمل المعقد؛ فتقسيم المشكلة إلى مراحل يجبر النموذج على التعامل مع طبقة منطقية واحدة في كل مرة. أخيراً، السلاسل أسهل في تصحيح الأخطاء (debug) من الأوامر الضخمة الموحدة. فعندما يكون الملخص خاطئاً، تفحص عملية الاستخراج، وعندما يكون الاستخراج خاطئاً، تفحص النص المصدر. لديك مخرجات وسيطة لفحصها.
تجنب تسلسل الأوامر عندما لا تعرف الخطوات مسبقاً. الأبحاث الاستكشافية، أو العصف الذهني المفتوح، أو المهام التحقيقية لا تتبع خطاً مستقيماً. تجنب التسلسل أيضاً عندما تكون السرعة هي أولويتك الوحيدة؛ فالسلاسل تعمل بشكل متسلسل، حيث لا يمكن للخطوة الثانية أن تبدأ حتى تنتهي الخطوة الأولى. إذا كانت خطواتك لا تعتمد على بعضها البعض، فقم بتشغيلها بالتوازي بدلاً من ذلك. لا يوجد سبب لتسلسل ثلاث ترجمات مستقلة لنفس المستند.
فخ الجمود
المقابل لكل هذا الهيكل هو الجمود. السلسلة الثابتة لا يمكنها التكيف مع المواقف الجديدة. إذا أرسل مورد نموذجاً يحتوي على ستة حقول بينما تتوقع بوابة التحقق من المخطط خمسة فقط، فسيتوقف الخط. وإذا قام مستخدم بتحميل مستند Word بدلاً من PDF، فستتعطل الخطوة الأولى ولن يجد بقية السلسلة ما يعالجه.
والأسوأ من ذلك هو انتشار الأخطاء. الخطأ الذي يحدث في البداية يتدفق عبر السلسلة بأكملها. إذا قام مستخرج ملفات PDF بحذف رمز سالب من رقم مالي، فإن كل خطوة لاحقة ستتعامل مع هذا الرقم الخاطئ على أنه