مشروع الذكاء الاصطناعي التجريبي الذي لم يبلغ الإنتاج: ما الذي كان ينقصه في البيانات والتشغيل

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

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

العرض التوضيحي يثبت أن النموذج قادر على القراءة؛ أما الإنتاج فيسأل عن كل مستند

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

ضع ما كان لدى المشروع التجريبي بجوار ما يحتاجه طابور الإنتاج، فيتحول العمل الناقص إلى قائمة:

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

اكتب مجموعة القبول قبل أن تمسّ النموذج

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

يضع دليل Rules of Machine Learning من Google القياسَ قبل النموذج: القاعدة رقم 2 نصها «أولًا، صمّم المقاييس ونفّذها». وفي الاستخراج وتوجيه التذاكر، ليس المقياس درجة واحدة للمستند كله:

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

البيانات التي لا يمكن أن تغادر المحيط تغيّر البنية المعمارية، لا المورّد فقط

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

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

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

يفيد إخفاء البيانات (masking) حيث يتعيّن على سجلات التشغيل مغادرة منطقة مقيّدة. فـ Presidio، وهو إطار مفتوح المصدر نشأ في Microsoft، يكتشف البيانات الشخصية في النص ويُخفي هوية أصحابها، وتنص وثائقه على أنه، لأن الاكتشاف مؤتمت، لا ضمان بأنه سيعثر على كل المعلومات الحساسة. الإخفاء يضيّق نطاق الانكشاف؛ لكنه لا يغني عن إبقاء البيانات في الداخل.

المدخلات هي النصف غير البرّاق: مستندات ممسوحة وسلاسل رسائل ومرفقات

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

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

المدخلات الطويلة تحتاج إلى عناية خاصة. ففي ورقة Lost in the Middle المنشورة في TACL عام 2024، أظهر Liu وزملاؤه أن الأداء، في النماذج التي اختبروها، يكون غالبًا في أعلاه حين تقع المعلومة ذات الصلة في بداية سياق الإدخال أو نهايته، ويتراجع بشكل كبير حين تقع في منتصف سياق طويل. وتقسيم المستند الطويل حسب الأقسام، مع الاحتفاظ بالمصدر في كل جزء، خيار افتراضي أكثر أمانًا من افتراض أن النموذج يقرأ السياق كله بالتساوي، ومجموعة القبول تُظهر أيّ الأمرين يصحّ على مستنداتك.

المخرجات المهيكلة تحتاج إلى مخطط وأداة تحقق ومكان للإجابة الخاطئة

يقصر فك الترميز المقيَّد (constrained decoding) النموذجَ على JSON يطابق مخططًا: يدعمه vLLM تحت اسم structured outputs، ويدعمه llama.cpp عبر grammars. وهو يحسم شكل السجل، في حدود ميزات المخطط التي يدعمها الـ backend وما دام التوليد لا ينقطع عند حدّ الـ tokens، لكنه لا يحسم صحته: فالسجل سليم البنية قد يحمل مع ذلك تاريخًا خاطئًا.

تُفحص الصحة بعد النموذج، بشيفرة تثق بها الشركة أصلًا:

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

درجة الثقة التي يعلنها النموذج نفسه بوابة ضعيفة. فتقرير GPT-4 Technical Report من OpenAI، المنشور عام 2023، يُظهر أنه في اختبار معياري متعدد الخيارات كان النموذج المدرَّب مسبقًا عالي المعايرة، وأن مرحلة ما بعد التدريب خفّضت المعايرة. واليقين الذي يعلنه النموذج عن نفسه أو احتمال الـ token إشارةٌ تُختبر مقابل مجموعة القبول، لا عتبة يُوثق بها افتراضيًا.

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

التذاكر والمستندات مدخلات غير موثوقة للنموذج

تذكرة الدعم نص كتبه شخص من خارج الشركة، وقد يحمل المستند تعليمات وضعها مرسله عمدًا. وتضع قائمة OWASP Top 10 for LLM Applications 2025 حقن الموجّهات (prompt injection) في المرتبة الأولى، بما في ذلك الحقن غير المباشر، حيث تصل التعليمات داخل محتوى خارجي يعالجه النموذج، مثل موقع ويب أو ملف.

ثلاثة بنود من القائمة نفسها تتحول إلى قواعد تصميم لخط معالجة المستندات:

• حقن الموجّهات (Prompt injection): علِّم كل مستند وتذكرة على أنه محتوى غير موثوق، مفصولًا عن التعليمات الموجودة في قالب لا يستطيع المرسل تعديله
• المعالجة غير السليمة للمخرجات (Improper output handling): تحقّق من مخرجات النموذج قبل أن يتصرف أي نظام بناءً عليها، كما تتحقق من مدخلات المستخدم
• الصلاحيات المفرطة (Excessive agency): امنح خط المعالجة أقل صلاحية تحتاجها مهمته، فلا يستطيع نموذج يقرأ التذاكر إغلاق حسابات أو إرسال مدفوعات

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

ثبّت النموذج والموجّه والمحلّل في إصدار واحد

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

• أوزان النموذج بمجموعها الاختباري (checksum)، مع التكميم وإصدار خادم الاستدلال
• قالب الموجّه ومخطط المخرجات ومعاملات فك الترميز
• محرك OCR وقواعد التقسيم إلى أجزاء وأدوات التحقق
• نسخة مجموعة القبول التي قُيِّم الإصدار على أساسها

التثبيت لا يجعل المخرجات متطابقة. فقد أظهر Thinking Machines Lab في سبتمبر 2025 أن خادم الاستدلال قد يُرجع إكمالات مختلفة للموجّه نفسه عند ضبط temperature على الصفر، لأن نتيجة الطلب تعتمد على عدد الطلبات الأخرى التي تتشارك دفعته؛ ويُظهر المنشور نفسه أن kernels لا تتأثر بحجم الدفعة (batch-invariant) تزيل ذلك على حساب السرعة. وما لم يشغّل الخادم kernels كهذه، فقابلية تكرار النتائج تعني إعادة تشغيل مجموعة القبول مع كل إصدار ومقارنة الدرجات، لا توقّع نص متطابق.

التشغيل: السعة والطوابير والساعة التي يتوقف فيها خادم النموذج

تُخطَّط السعة بالـ tokens، لا بالمستندات. قِس توزيع طول المدخلات والمخرجات على الحركة الحقيقية، لأن مرفقًا طويلًا واحدًا قد يكلّف ما تكلّفه تذاكر قصيرة كثيرة، وزمن التوليد يزداد مع طول المخرجات.

تجمع أنظمة التقديم الطلبات في دفعات كي يبقى المسرِّع مشغولًا. وفي ورقة vLLM، المقدَّمة في SOSP 2023، أفاد Kwon وزملاؤه بأن تقسيم ذاكرة key-value المؤقتة الخاصة بآلية الانتباه إلى صفحات رفع الإنتاجية بمعامل يتراوح بين 2 و4 عند المستوى نفسه من زمن الاستجابة مقارنةً بالأنظمة التي قيّموها. والدفعات الأكبر ترفع الإنتاجية وترفع أيضًا زمن استجابة كل طلب، وهذا ما يستطيع طابور المكتب الخلفي أن يمتصه ولا تستطيعه خطوة تفاعلية، لذا يُفصل الاثنان:

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

الاحتياط هو ما يجعل تشغيل خط المعالجة قابلًا للتراجع عنه. تبقى العملية اليدوية القائمة اليوم هي الحدّ الأدنى، ويأخذ خط المعالجة العمل عنها حقلًا بعد حقل بدل أن يحلّ محلها في تاريخ واحد.

راقب الإجابات، لا الخوادم وحدها

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

• معدل الإحالة إلى طابور المراجعة وتصحيحات المراجعين لكل حقل ولكل نوع مستند ولكل إصدار
• عيّنة منتظمة من السجلات المؤتمتة يعيد أشخاص فحصها وفق معايير القبول
• انجراف المدخلات: مرسلون جدد، وقوالب جديدة، ومزيج اللغات، وطول المستندات
• إخفاقات أدوات التحقق حسب القاعدة، والتي قد تكشف صيغة جديدة قبل أن تتحرك مقاييس الدقة
• الـ tokens وساعات المسرِّع وعمر العناصر في الطابور لكل نوع مستند، بجوار زمن استجابة كل مرحلة

ينظّم Generative AI Profile من NIST، أي NIST AI 600-1 المنشور في يوليو 2024، هذا العمل ضمن الوظائف الأربع لإطاره AI Risk Management Framework (إطار إدارة مخاطر الذكاء الاصطناعي): الحوكمة (govern)، ورسم الخريطة (map)، والقياس (measure)، والإدارة (manage). والأسماء أقل أهمية من النتيجة: القياس بعد الإطلاق نشاط محدَّد صراحةً ومزوَّد بكوادره، لا شيء يقوم به فريق المشروع التجريبي حين يتسع وقته.

انشر تدريجيًا حسب الحقل ونوع المستند: وضع الظل، ثم المساعِد، ثم المؤتمت

تشغيل خط المعالجة لكل شيء في تاريخ واحد يجمع كل المخاطر في حدث واحد. أما النشر المرحلي فيُبقيها منفصلة:

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

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

الشركة التي توصل هذا إلى الإنتاج تطلب مستنداتك قبل أن تسأل عن النموذج الذي تفضّله

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

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

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

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

ما تستطيع amBrain إثباته علنًا فضلًا عن التكامل العامل في الإنتاج الموصوف في الملخص أعلاه: تبني amBrain البرمجيات منذ 2019. ونعمل بثلاث صيغ: تسليم كامل، أو فريق مخصص، أو مهندسون مدمجون في فريقك.