شرح hh.ru كيفية تصميم برومبتات الإنتاج لخدمات AI من دون مفاجآت

شاركت hh.ru ممارسة عملية حول كيفية كتابة الموجهات (prompts) لخدماتها القائمة على الذكاء الاصطناعي في بيئة الإنتاج. الفكرة الأساسية بسيطة: الموجه في المنتج ليس محادثة مع روبوت دردشة، بل هو نظام هندسي يتضمن قيودًا واختبارات وتصحيحًا مستمرًا.

الإنتاج ليس دردشة

في الاستخدام النموذجي لنماذج اللغة الكبيرة، كل شيء مرن جدًا: يطرح المستخدم سؤالاً، يحصل على إجابة، يعدّل الصياغة، يعيد تشغيل الحوار ويمضي قدمًا. في المنتج، لا يوجد هذا الترف. هنا، قد تصل إجابة واحدة فاشلة إلى آلاف المستخدمين، وقد تحطم السيناريو، وتخلق مخاطر سمعة، أو ببساطة تفسد معدل التحويل.

لذلك، الموجه في الإنتاج ليس عبارة واحدة مثل "اجعله جميلاً"، بل هو مجموعة من التعليمات المترابطة والبيانات والقواعد واستدعاءات الأدوات، وأحيانًا تمتد لمئات الأسطر. يسمي مؤلف المقالة هذا "معركة المهندس مع الببغاء العشوائي". النموذج لا يفهم المعنى بالطريقة التي يفهمها الإنسان؛ بل يتنبأ بالرمز التالي بناءً على الاحتمالات.

مهمة الفريق هي تقليل مساحة العشوائية قدر الإمكان: إعطاء النموذج دورًا واضحًا وسياقًا وقيودًا وصيغة إجابة متوقعة. كلما كانت هذه الحلقة مصممة بشكل أفضل، زادت فرص الحصول على نتيجة يمكن التنبؤ بها وآمنة ومفيدة للعمل الحقيقي. هذا هو السبب في أن العمل مع الموجهات يشبه بشكل متزايد التطوير العادي بدلاً من أن يكون تجربة إبداعية.

إطار العمل للموجه الجيد

في hh.ru، يوصون بكتابة التعليمات باللغة الإنجليزية، مع ترك أمثلة رسائل المستخدمين باللغة المنتج — في هذه الحالة، الروسية. السبب ليس فقط أن التعليمات باللغة الإنجليزية يتم تفسيرها غالبًا بدقة أكبر من قبل النموذج. اللغة الإنجليزية توفر أيضًا الرموز (tokens)، وفي الأنظمة التي تحتوي على آلاف وملايين المكالمات، هذا يؤثر بالفعل على التكلفة والكمون. تساعد القوالب والترميز أيضًا: markdown أو XML تجعل التعليمات الطويلة أكثر تنظيمًا وتقلل الغموض. يتضمن الإطار النموذجي عادةً دور النموذج والهدف والسياق وخطوات حل المشكلة وصيغة الإجابة.

• دور النموذج
• الهدف والمهمة المحددة
• سياق بيانات الإدخال
• خوارزمية الإجراء أو خطوات التحقق
• القيود وصيغة الإجابة

أمثلة التعلم من عدد قليل من الأمثلة (few-shot) خطيرة بشكل خاص. إنها تساعد النموذج حقًا على فهم المهمة بشكل أفضل، لكنها تتحول بسهولة إلى نموذج يبدأ في نقله آليًا إلى حالات جديدة. غالبًا ما يتمسك النموذج حرفيًا بالصيغ ويعيد إنتاجها خارج السياق. تقدم المقالة حالة توضيحية: أضافوا مثالاً على سؤال التوضيح للمرشح إلى موجه النظام، وبعدها بدأ الوكيل يطرحه حتى في الحالات التي كان غير مناسب تماماً.

"هل أنت مستعد لرحلات العمل إلى ريازان؟"

بعد ذلك، كان المساعد يسأل بشكل دوري عن الرحلات حتى في عروض الوظائف التي لم تكن الرحلات ضرورية.

خلاصة الفريق حاسمة: يجب حظر كل شيء محفوف بالمخاطر بشكل صريح. إذا كان على الروبوت ألا يناقش شركات أخرى أو يعبر عن رأيه أو ينحرف عن الموضوع أو ينفذ مهام غير ذات صلة، فيجب أن يكون هذا موضحًا بشكل مباشر. نصيحة عملية أخرى هي عدم الخوف من الموجهات الطويلة إذا تم تجميعها بشكل منطقي ولا تتناقض مع نفسها. من المهم أيضًا نقل التاريخ الحالي بشكل صريح وتعديل درجة الحرارة بعناية والتذكر بأن الموجهات يجب إعادة كتابتها دائمًا تقريبًا للنماذج المختلفة.

كيف يتم اختبارها

حتى الموجه الجيد لا يمكن اعتباره جاهزًا بعد تشغيل ناجح أو اثنين فقط. السلوك النموذجي ليس محددًا تماماً: مع طلبات متطابقة وماعاملات متطابقة، يمكن أن تختلف الإجابات قليلاً. لذلك، ضمان الجودة يشبه أكثر تقييم الهندسة للنظام من المراجعة اليدوية للنصوص. تحتاج إلى مجموعات كبيرة من حالات الاختبار وتشغيلات متعددة وتغطية سيناريوهات مستخدم مختلفة — تقريبًا كما في الاختبار الكلاسيكي، لكن مع تعديلات للطبيعة الاحتمالية للنموذج.

أثمن مصدر للاختبارات الجديدة هو سجلات المستخدمين الفعلية. هنا تظهر الأسئلة غير المتوقعة ومحاولات تحويل الروبوت بعيدًا والحالات الحدودية التي لم يتوقعها الفريق مسبقًا. مع تراكم هذه الحالات، يجب أن يتم تجديد مجموعة بيانات التقييم بشكل مستمر. خلاصة أخرى مهمة: يجب اختبار الموجهات في بيئة قريبة قدر الإمكان من الإنتاج. نماذج اللغة الكبيرة حساسة حتى للتغييرات الصغيرة في تنسيق الإدخال، لذا فإن البيئة "متطابقة تقريبًا" تعطي بسهولة شعورًا كاذبًا بالاستقرار.

ما يعنيه هذا

توضح مقالة hh.ru جيدًا أن هندسة الموجهات تتحول بسرعة إلى هندسة المنتج العادية. هنا، ينتصر ليس الطلب الأكثر إبداعًا، بل مزيج من البنية والقيود والتقييمات والسجلات والتحسين التكراري. بالنسبة للفرق التي تبني ميزات الذكاء الاصطناعي في الإنتاج، هذا إشارة: يجب أن يتم الآن إصدار الموجهات وفقًا للإصدارات واختبارها ومتابعتها حسب المقاييس وربطها بسيناريوهات المستخدمين الفعلية وتكييفها مع نماذج محددة بنفس جدية الكود.