قبل أن تضيف الذكاء الاصطناعي إلى منتجك: ما الذي تقيسه أولًا

إضافة نموذج لغوي إلى منتج صارت سهلة تقنيًا: مفتاح، ونداء HTTP، وحقل نص. الصعب أن تجيب بعد أسبوع عن سؤال: هل صار المنتج أفضل؟

هذه الأشياء الثلاثة أُعدّها قبل أول استدعاء، وقد وفّرت عليّ إعادة كتابة أكثر من مرة.

1. مجموعة أمثلة صغيرة، مكتوبة بيدك

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

اجعل الأمثلة متنوعة عمدًا:

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

من دون هذه المجموعة، كل تعديل على التعليمات (prompt) يصبح تخمينًا: تصلح حالة رأيتها اليوم وتكسر ثلاثًا لا تراها.

2. تعريف مكتوب للفشل

اكتب في جملة أو جملتين ما الذي يجعل الإجابة خاطئة، لا ما الذي يجعلها جيدة. الجودة رأي؛ الفشل قابل للاتفاق عليه.

أمثلة على تعريفات صالحة:

• «اختلقت رقمًا لم يرد في المستند المعطى.»
• «تجاوزت الصيغة المطلوبة (JSON) فلم تُقرأ.»
• «أجابت عن سؤال خارج نطاق الخدمة بدل الاعتذار.»

ثم صنّف كل فشل إلى واحد من نوعين، لأن علاجهما مختلف تمامًا: فشل صياغة (شكل الناتج) يُعالج بالبنية والتحقق البرمجي، وفشل محتوى (المعلومة نفسها) يُعالج بتقييد المصدر أو بالرفض.

3. مسار للفشل داخل الواجهة

هذا ما يُنسى غالبًا. النموذج سيُخطئ ويتأخر وسيرفض أحيانًا، وواجهتك تحتاج مكانًا لهذه الحالات قبل أن تحدث:

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

الميزة المبنية على نموذج لغوي ليست ميزة إلا بعد أن تقرّر ماذا يحدث حين يخطئ.

ثم: غيّر شيئًا واحدًا في كل مرة

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

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

ملاحظة عن التكلفة

أضف عمودًا للتكلفة والزمن بجانب الجودة منذ البداية. النموذج الأكبر يحسّن النتيجة أحيانًا بفارق لا يلاحظه المستخدم، ويضاعف الفاتورة والزمن بفارق يلاحظه فورًا. القرار يحتاج الأعمدة الثلاثة معًا.