عندما تبدأ لأول مرة في البناء باستخدام الذكاء الاصطناعي، فإن الأصوات الأعلى صخباً تشير جميعها إلى نفس المكان: النموذج. يقولون: اختر النموذج الصحيح، وسينضبط كل شيء آخر تلقائياً. ولكن بعد بضعة أسابيع من تجاربي الخاصة، يمكنني أن أقول لك إن هذا ليس صحيحاً ببساطة. إن الاختيار بين النماذج اللغوية الكبيرة المتاحة أمر مهم، لكنه يمثل ربما عشرين بالمائة فقط من المهمة. أما الباقي فهو عمل متعلق بالأنظمة؛ إنه يتعلق بالبنية التحتية، والحرفية، والاختبار المستمر. لقد أدركت ذلك مبكراً، وقد أعاد هذا الإدراك تشكيل طريقة تعاملي مع كل مشروع منذ ذلك الحين.
النموذج هو مجرد البداية
من السهل فهم سبب هوس المبتدئين بالنماذج. تَعِد ملاحظات الإصدار بقدرات استنتاج أفضل، ونوافذ سياق (context windows) أكبر، ومخرجات أكثر دقة. هذه التحسينات حقيقية، لكنها أيضاً عامة الأغراض. فالنموذج المتطور لن يعرف تلقائياً سياسة الاسترداد الخاصة بشركتك، ولن يقوم بتنسيق الردود لتطبيق الهاتف الخاص بك بشكل موثوق ما لم تخبره بكيفية القيام بذلك، ولا يمكنه سحب بيانات المخزون المباشرة من العدم.
لقد تعلمت هذا بالطريقة الصعبة. استخدم نموذجي الأولي الأول نموذجاً قوياً، وأنتج فقرات جميلة وواثقة، لكنها كانت خاطئة تماماً في بعض الأحيان. بدا النص احترافياً لأن النموذج قد أتقن النبرة، لكنه لم يكن يملك وصولاً إلى المعلومات الحالية. لقد قضيت أياماً في مقارنة معايير أداء النماذج، بينما كان ينبغي علي التفكير في مسارات البيانات (data pipelines) وحقن السياق (context injection). لم يكن النموذج معطلاً، بل كان النظام المحيط به غير مكتمل. هذا التمييز هو كل شيء عندما تنتقل من مرحلة العروض التجريبية (demos) إلى البرمجيات التي يعتمد عليها الناس فعلياً.
الأوامر (Prompts) هي كود، وليست مجرد اقتراحات
تقع الأوامر (Prompts) عالية الجودة في قلب أي تطبيق ذكاء اصطناعي موثوق. في البداية، كنت أعامل الأوامر كأنها استعلامات بحث—قصيرة، وعفوية، ومتفائلة. كنت أطلب من النموذج "تلخيص هذا" أو "كن مفيداً" وآمل الحصول على أفضل نتيجة. كانت النتائج تتأرجح بشدة بين المفيد وغير ذي الصلة، ولم يكن لدي أدنى فكرة عن السبب.
الآن، أعامل الأوامر كأنها برامج خفيفة الوزن. الأمر الجيد يحدد الدور، ويحدد تنسيق المخرجات، ويتضمن أمثلة عند الضرورة، ويضع الحدود. إذا كنت أريد JSON، فأنا أطلب JSON وأعرض المخطط (schema). إذا كنت بحاجة إلى إجابة موجزة، فأنا أحدد الطول صراحةً وأمنع المقدمات (preamble). التكرار والتحسين (Iteration) أمران بالغا الأهمية؛ فأنا أحتفظ بسجل مستمر للأوامر ومخرجاتها، مع تغيير متغير واحد في كل مرة. يمكن لصفة واحدة غامضة في الأمر أن تغير سلوك سير العمل بأكمله. هذه الحساسية تتطلب الدقة، لا التخمين.
المدخلات الرديئة تؤدي لمخرجات رديئة (Garbage In, Garbage Out)
استرجاع البيانات الموثوق هو المكان الذي تموت فيه العديد من مشاريع الذكاء الاصطناعي في صمت. أصبح "التوليد المعزز بالاسترجاع" (Retrieval-Augmented Generation)، أو ما يعرف بـ RAG، هو النمط القياسي لمنح النماذج إمكانية الوصول إلى البيانات الخاصة أو الحالية. الفكرة بسيطة: جلب المستندات ذات الصلة، وحشرها في نافذة سياق النموذج، وترك النموذج يستنتج الحقائق. لكن التطبيق العملي أكثر تعقيداً.
قضيت وقتاً في تصحيح أخطاء قاعدة معرفة بسيطة كانت تستمر في إرجاع نتائج غير ذات صلة. كان النموذج جيداً، لكن طبقة الاسترجاع (retrieval layer) كانت هي التي تفشل. كانت أجزاء البيانات (chunks) صغيرة جداً ومجردة من السياق، كما تم إنشاء التضمينات (embeddings) دون تنظيف العناوين المكررة. وجد البحث عن التشابه نصوصاً قريبة تقنياً لكنها تجيب على السؤال الخطأ. تطلب الإصلاح إعادة التفكير في استراتيجية تقسيم البيانات (chunking strategy)، وإضافة فلاتر البيانات الوصفية (metadata filters)، وإدخال خطوة إعادة الترتيب (re-ranking). بمجرد استقرار عملية الاسترجاع، تحسنت إجابات النموذج على الفور. كان الدرس واضحاً: لا يمكنك إصلاح عملية استرجاع بيانات سيئة باستخدام نموذج أفضل؛ بل يجب عليك بناء مسار البيانات (pipeline) بشكل صحيح.
لا يمكنك تحسين ما لا يمكنك قياسه
التقييم المستمر هو العادة التي تفصل بين التجارب والمنتجات. عندما بدأت، كنت أقيم بناءً على "الانطباع العام" (vibe). كنت أقرأ خمس مخرجات، وأومئ برأسي موافقاً، ثم أمضي قدماً. هذا ينجح حتى يطرح المستخدم السؤال السادس ويحصل على شيء غريب.
الآن، أقوم ببناء مجموعات تقييم صغيرة لكل ميزة. أجمع استعلامات المستخدمين الحقيقية، وأحدد السلوك المتوقع، وأجري فحوصات آلية مقابلها. أراقب حدوث "الانحراف" (drift): فالأمر البرمجي الذي كان يعمل الشهر الماضي قد يتدهور بعد تحديث النموذج أو بعد تغيير البيانات الأساسية. أفصل بين تقييم الأسلوب وبين الدقة الواقعية. فالمظهر الاحترافي أمر جيد، لكن الصحة والدقة أمر إلزامي. بدون هذه الحلقة، فأنت تطلق منتجك بناءً على الأمل، والأمل ليس استراتيجية اختبار.
اعرف حدود الآلة
إن فهم حدود النماذج قد أنقذني من تقديم وعود مبالغ فيها وعدم الوفاء بها. فهذه الأنظمة لها قيود حقيقية. نوافذ السياق (Context windows) أصبحت أكبر مما كانت عليه، لكنها لا تزال تملك حدوداً قصوى، وحشوها بالكامل يؤدي إلى تدهور الأداء عند الأطراف. النماذج تهلوس، خاصة في المواضيع المتخصصة حيث تكون بيانات التدريب شحيحة. كما أنها تواجه صعوبة في الحسابات الدقيقة وأنواع معينة من المنطق متعدد الخطوات، وهي حساسة لصياغة الأسئلة.
التكلفة والسرعة هما أيضاً من القيود. فالنموذج الذي يولد نثراً مثالياً في عشر ثوانٍ قد يكون غير قابل للاستخدام في واجهة دردشة فورية. أقوم الآن بربط الميزات بميزانيات زمن الاستجابة (latency budgets) في وقت مبكر. إذا كانت المهمة تتطلب استجابة في أقل من ثانية، فقد أقوم بحساب الإجابات مسبقاً، أو استخدام التخزين المؤقت (cache) بكثافة، أو استخدام نموذج أصغر للمسودة الأولى ونموذج أكبر فقط للتحسين. العمل ضمن القيود هو جزء أساسي من الهندسة، والذكاء الاصطناعي ليس استثناءً.
البناء من أجل أشخاص حقيقيين
أنا أدرس حالياً تطبيقات النماذج اللغوية الكبيرة (LLM) وهندسة البرمجيات بهدف بسيط: بناء أدوات يستخدمها الناس كل يوم. قد يبدو هذا بديهياً، لكن الفجوة بين النموذج الأولي المثير