Oluwa.io
كل الكتابات
·قراءة 6 دقائقمنهجية منتجات الذكاء الاصطناعيتطبيقات نماذج اللغةالتقييماتالهندسة

من الموجّه إلى المنتج: تحويل نماذج اللغة الكبيرة إلى تطبيقات حقيقية

منهجية عملية لبناء تطبيقات نماذج اللغة الكبيرة: التقييمات، وحواجز الأمان، وميزانيات زمن الاستجابة والتكلفة، وإشراك الإنسان، ومعرفة ما لا ينبغي أتمتته.

بقلم Vitor Lima

الموجّه الذي ينجح في بيئة تجريبية هو عرض توضيحي، لا منتج. والفجوة بين الاثنين هي حيث تموت معظم مشاريع الذكاء الاصطناعي بهدوء. إن بناء تطبيقات نماذج اللغة الكبيرة التي تصمد أمام المستخدمين الحقيقيين يرتبط بالكتابة الذكية للموجّهات بقدر أقل مما توحي به العروض التوضيحية، ويرتبط بانضباط البرمجيات الاعتيادي بقدر أكبر بكثير. لقد أطلقنا ما يكفي من هذه المنتجات — Youp و MadaiOps والآن Linea — لتكون لدينا آراء حول ما يسدّ تلك الفجوة فعلاً. ولا شيء من ذلك برّاق.

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

ابدأ بالتقييمات، لا بالموجّهات

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

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

بضعة آراء نتمسك بها بحزم:

  • قيّم بناءً على النتائج، لا الصياغة. لأي شيء منظّم — الاستخلاص، التصنيف، التوجيه — تحقّق من النتيجة المُحلّلة، لا من التشابه النصي. أما بالنسبة للنص المفتوح، فإن استخدام نموذج لغوي كحَكَم مع معيار تقييم محكم أمر جيد، لكن تحقّق أولاً من صحة الحَكَم مقابل حفنة من التصنيفات البشرية، وإلا فأنت تقيس ذوق نموذج واحد فحسب.
  • احتفظ بملف للانتكاسات. كل فشل في الإنتاج يصبح حالة اختبار دائمة. هكذا تبقى مجموعة تقييماتك صادقة — إذ تنمو تماماً في الاتجاهات التي يدفعها إليها الواقع.
  • أرشِف نسخ تقييماتك مع موجّهاتك. الموجّه بدون مجموعة تقييماته هو تغيير برمجي غير مُختبَر.

إن بنيت شيئاً واحداً من هذا المقال، فابنِ هذا. كل ما يأتي لاحقاً يعتمد على قدرتك على الإجابة: هل حسّن ذلك الأمور؟

حواجز الأمان أرخص من الاعتذارات

تفشل النماذج بطرق لا تفشل بها البرمجيات الاعتيادية. فهي تخترع واجهة برمجية غير موجودة، أو توافق على فرضية خاطئة قدّمها مستخدم، أو تُخرج بيانات JSON تبدو سليمة بحقل مُتوهَّم. حواجز الأمان هي الطبقة التي تلتقط ذلك قبل أن يصل إلى مستخدم، أو الأسوأ، إلى خطوة تنفيذ.

فكّر في ثلاثة مواضع.

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

هذا الموضع الثالث هو حيث يكمن الخطر الحقيقي. في Linea، وكلاء أتمتة سير العمل لدينا، يمكن للنموذج اقتراح إجراءات — استدعاء واجهة برمجية، أو نقل سجل، أو إرسال رسالة. الاقتراح والتنفيذ خطوتان منفصلتان عمداً. كل إجراء ذي أثر جوهري يمرّ عبر عقد مُحدَّد النوع وفحص للسياسة قبل تشغيل أي شيء، وتتطلب الإجراءات المدمِّرة أو غير القابلة للتراجع بوابة تأكيد صريحة. الوكيل الذي يقترح الشيء الخاطئ هو مشكلة تجربة مستخدم يمكنك تحسينها بالتكرار. أما الوكيل الذي يفعل الشيء الخاطئ فهو حادثة. أبقِ نمطَي الفشل هذين على جانبين متقابلين من حدّ صارم.

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

اجعل زمن الاستجابة والتكلفة ضمن الميزانية كأنهما ميزات

زمن الاستجابة والتكلفة ليسا أمرين تقيسهما في النهاية. إنهما قيدان تصمّم في مواجهتهما منذ البداية، لأنهما يغيّران البنية المعمارية، لا الفاتورة فحسب.

حدّد ميزانيات صريحة لكل إجراء يواجه المستخدم: هدف زمن استجابة عند النسبة المئوية 95، وسقف تكلفة لكل استدعاء. وبمجرد تدوينها، تصبح قرارات التصميم أسهل. بعض الأنماط التي نلجأ إليها مراراً:

  • اختر حجم النموذج المناسب لكل خطوة. معظم خطوط المعالجة تحتوي على خطوة أو خطوتين تحتاجان فعلاً إلى النموذج المتقدم، وعدة خطوات يتولاها نموذج أصغر وأسرع بشكل جيد. توجيه التصنيف البسيط إلى نموذج رخيص وحجز النموذج المكلف للخطوة الاستدلالية الصعبة هو أعلى تحسين عائداً متاح، وعادة ما يحسّن زمن الاستجابة أيضاً.
  • بثّ الرمز الأول. في أي شيء حواري، يهيمن على زمن الاستجابة المُدرَك زمنُ الوصول إلى الرمز الأول. الاستجابة المبثوثة التي تستغرق أربع ثوانٍ تبدو أفضل من استجابة حاجبة تستغرق ثانيتين.
  • خزّن مؤقتاً بقوة. التخزين المؤقت للموجّهات على سياق النظام المستقر، والتخزين المؤقت الاعتيادي للنتائج على المدخلات المتكررة. جزء لا يُستهان به من حركة المرور في الإنتاج شبه مكرر.

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

أبقِ الإنسان في الحلقة، عن قصد

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

النمط الذي خدمنا أفضل ما يكون هو التصعيد المُقيَّد بالثقة. يتعامل النظام تلقائياً مع الأغلبية الواثقة، ويوجّه الأقلية غير المؤكدة إلى شخص، مع إرفاق استدلال النموذج ليقرر الإنسان في ثوانٍ لا في دقائق. في MadaiOps، تمرّ عمليات الطلبات ضمن المعطيات الطبيعية؛ وأي شيء شاذ يظهر لمُشغّل مع سياقه بدلاً من أن يُنفَّذ بصمت. المراجِع ليس مربّياً للآلة. بل ينفق انتباهه فقط حيث يكون نادراً وثميناً.

قاعدة أخيرة: قِس تصحيحات الإنسان وأعد تغذيتها في مجموعة تقييماتك وموجّهاتك. النظام الذي يُشرك الإنسان في الحلقة ولا يتعلم من بشره ليس سوى دفع مرتين مقابل العمل نفسه.

اعرف ما لا ينبغي أتمتته

أصعب حُكم في هذا التخصص هو ضبط النفس. ليس كل مهمة ينبغي تسليمها إلى نموذج، والنضج هو معرفة أيها يُترك وشأنه.

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

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

شكل العمل

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

الخبر السار هو أن هذا عمل مألوف. إنه يكافئ الغرائز نفسها التي تصنع برمجيات جيدة من أي نوع: قِس قبل أن تغيّر، واحتوِ نطاق الانفجار، واحترم وقت مستخدميك. النموذج جديد. أما الحِرفة فليست كذلك.