في فيلم "الرجال في الأسود 2" (Men in Black II)، يزور العميل "J" العميل "K" في مكتب بريد يبدو عادياً. يفتح آلة فرز البريد ليكشف عن كائن فضائي بالداخل يقوم بفرز الرسائل بسرعة فائقة.
إنه مشهد سخيف بعض الشيء، لكنه يمنحنا طريقة مفيدة للتفكير في الذكاء الاصطناعي.
بين استلام شيء ما والقيام بإجراء بشأنه، غالباً ما يكون هناك قرار أصغر يجب اتخاذه: إلى أين ينتمي هذا؟
إذا اتخذت هذا القرار بشكل صحيح مبكراً، يمكن لبقية النظام أن تسلك المسار المناسب.
لقد كنت أفكر في ذلك الكائن الفضائي الصغير أثناء بنائي لبرمجيات الذكاء الاصطناعي.
يستقبل التطبيق سؤالاً حول الفواتير، وتقريراً عن خطأ برمجي، وصورة لمنتج، وطلباً لحجز عرض توضيحي. كل منها يتطلب معالجة مختلفة. ومع ذلك، قد ينتهي بنا الأمر بطلب نفس النموذج اللغوي الكبير لفحص كل شيء وتحديد ما سيحدث بعد ذلك. وهذا ليس فعالاً ولا اقتصادياً على الإطلاق.
لهذا السبب، أعتقد أن النماذج المتخصصة ستلعب دوراً أكبر بكثير في مستقبل الذكاء الاصطناعي. على سبيل المثال؛ تم بناء Jev لاتخاذ قرارات منظمة يمكن للبرمجيات التصرف بناءً عليها. وقد قامت Coinbase بتكييف Qwen3.5-9B خصيصاً لاكتشاف الاحتيال في خدمة Onramp الخاصة بها. يركز كل منهما على مهمة محددة، بنتائج يمكن قياسها.
https://x.com/brian_armstrong/status/2109412046244913643
أنا أبني طبقة الفرز
يمكن للطلبات المألوفة أن تنتقل مباشرة إلى سير عمل محدد. أما الطلبات التي تحتاج إلى مزيد من الاستدلال فتنتقل إلى نموذج آخر. وتُعلَّم الطلبات الغامضة لتوضيحها أو مراجعتها.
تكمن الفائدة المحتملة في منح كل طلب مقدار المعالجة الذي يحتاجه بالضبط. ثم يتعين علينا قياس ما إذا كان المُفرِّز يتخذ قرارات صحيحة بما يكفي لتبرير وجوده.
كانت نقطة انطلاقنا مع CludeMem. كنا نحاول تحديد ما يجب أن يتذكره الذكاء الاصطناعي، وما يجب أن يسترجعه، وما كان يستهلك الرموز (tokens) دون داعٍ. التفضيل الدائم، والتعليمات المؤقتة، والسؤال غير المحلول، كلها تستحق معاملة مختلفة. وقبل اتخاذ تلك القرارات، احتجنا إلى تصنيف المعلومات.
وهكذا ولدت فكرة طبقة التصنيف الأوسع. يمكن لنفس الخطوة أن تساعد في فرز طلب دعم، أو توجيه مستند، أو اختيار المتخصص الذي يجب أن يتولى مهمة ما.
صورة متحركة GIF
مع ظهور المزيد من النماذج المتخصصة، ستحتاج التطبيقات إلى تحديد أي المدخلات تستحق اهتمامها. وهذا هو الجزء الذي نبنيه: تصنيف ما يصل، والتعامل مع الحالات المألوفة محلياً، وتمرير الأصعب منها إلى النموذج المناسب أو عملية المراجعة.
إليكم Clude Cat (Cat تعني التصنيف 😉)
قبل تخزين ذكرى، أو استرجاع مستند، أو استدعاء أداة، أو توليد رد، عادة ما يكون هناك قرار يتعلق بنوع المعلومات التي نتعامل معها.
هذه القرارات موجودة في كل مكان.
تخيل أن شخصاً ما يكتب إلى شركة برمجيات:
"أين يمكنني تنزيل فاتورتي؟"
يمكن لوكيل ذكاء اصطناعي قراءة الرسالة، وفحص أدواته، والنظر في نية العميل، واتخاذ قرار بالبحث عن الفاتورة.
يمكن أن يبدو سير العمل الأكثر مباشرة هكذا:
رسالة → طلب مستند فوترة → التحقق من الحساب → استرجاع الفاتورة.
لا يزال بإمكان النموذج اللغوي كتابة الرد. بينما يمكن التعامل مع قرار التوجيه الأولي محلياً.
الآن لنغيّر الرسالة:
"تم تحصيل الرسوم مني مرتين، وحسابي مقفل، وأريد الإلغاء."
إرسال ذلك بثقة إلى سير عمل خاص بفاتورة واحدة سيخلق المزيد من العمل. هناك عدة مشاكل يجب حلها، وقد يتطلب الرد الصحيح توضيحاً أو تدخلاً بشرياً.
يحتاج المُفرِّز إلى صلاحية القول: "لا يمكنني تصنيف هذا بموثوقية."
وهذا جزء جوهري من المنتج. فالنظام الذي يرسل الطلبات بثقة إلى الوجهة الخاطئة يمكن أن يمحو ميزة السرعة التي يتمتع بها بسبب العمل اللازم لإصلاح أخطائه.
بالنسبة للعميل، الفائدة المرجوة هي تقليل الانتظار وتقليل التكرار.
وبالنسبة للمطور، إنه قرار صريح يمكنه فحصه واختباره وتغييره. يمكنه رؤية الفئة المحددة، وإصدار النموذج، ووقت المعالجة، وما إذا كان النظام قد امتنع عن اتخاذ قرار.
في الأساس، يبدأ التنفيذ النصي بنموذج صغير مُدرَّب مسبقاً يُسمى المُشفِّر (encoder).
يقوم بتحويل الرسالة إلى قائمة من الأرقام تمثل جوانب من معناها. يسمي المطورون هذا التمثيل بالتضمين (embedding).
عبارتا "أين فاتورتي؟" و"أحتاج نسخة من حسابي" تستخدمان كلمات مختلفة. لكن تمثيليهما الرقميين قد يظلان متشابهين بما يكفي ليتعرف النظام على أنهما نفس نوع الطلب.
تستخدم طبقة التصنيف هذه التمثيلات لتسجيل الفئات التي حددها المطور.
قمنا بتنفيذ نهجين. يقارن أحدهما الرسالة الواردة بأمثلة من كل فئة. بينما يتعلم الآخر الحدود بين الفئات من أمثلة موسومة.
في النهج المُكيَّف (fitted)، نُبقي المُشفِّر ثابتاً وندرب طبقة قرار أصغر فوقه. لسنا بحاجة إلى تدريب نموذج أساسي جديد لكل تطبيق.
لا يزال يتعين على المطور تحديد معنى الفئات وربطها بإجراءات مفيدة. فلا يستطيع المُصنِّف اختراع أقسام الشركة، أو سياسة الاسترداد، أو صلاحيات الحساب.
كما أنه يحتاج إلى سياسة قبول.
الفئة ذات النتيجة الأعلى قد تظل تطابقاً ضعيفاً. وقد تتساوى فئتان تقريباً. وقد يشبه طلب غير مألوف شيئاً مألوفاً.
نتائجنا المحلية الحالية ليست احتمالات معايرة. النتيجة 0.92 لا تعني تلقائياً "احتمال صحة بنسبة 92%".
يجب أن نختبر ما يحدث عندما تتحكم هذه النتائج في القرارات.
لذلك يميز المخرج بين فئة مقبولة، وطلب يحتاج إلى مراجعة، وفشل تقني. كما تحتاج المهلات الزمنية، والإلغاءات، وأخطاء النماذج إلى معالجة يمكن التنبؤ بها.
هذا هو الجانب الهندسي المحيط بالمُفرِّز. وهو ما يحدد ما إذا كان تطبيق آخر يمكنه استخدام النتيجة بأمان واتساق.
أجرينا تجربة على 770 طلباً مصرفياً لمعرفة ما إذا كان هذا النهج يمكن أن يقلل من عبء عمل النماذج التوليدية.
قام الإعداد الأول بإرسال كل طلب إلى نموذج Qwen2.5 7B يعمل محلياً للتصنيف.
واستخدم الثاني مُصنِّفنا المحلي أولاً، ثم أرسل الطلبات غير المحلولة إلى Qwen.
وكانت النتائج كالتالي:
- انخفضت استدعاءات Qwen من 770 إلى 227.
- زادت التصنيفات الصحيحة من 535 إلى 642.
- ارتفعت الدقة عبر جميع المدخلات من 69.5% إلى 83.4%.
- انخفض مجموع أوقات الاستعلام المقاسة من 299.7 ثانية إلى 87.7 ثانية.
تجنبت المرحلة المحلية 543 استدعاءً لـ Qwen، أي انخفاض بنسبة 70.5%.
ظل التخزين المؤقت مفعلاً، وتم تشغيل النهج المباشر قبل النهج المدمج. وتستثني أرقام التوقيت عمليات الإعداد والتسخين. لقد قسنا التصنيف فقط، دون توليد ردود نهائية للعملاء أو الدفع لمزود نموذج.
تصف هذه الأرقام هذا الإعداد تحديداً. وهي لا تثبت تفوقاً على كل نموذج لغوي كبير (LLM) ولا تؤكد توفيراً للعملاء.
اختبرت تجربة منفصلة لاحقة مُصنِّفاً محلياً مُكيَّفاً على 24 نية للسفر وبيئة العمل.
من أصل 720 طلباً، قبل 688 محلياً. ومن بينها، كان 681 صحيحاً وسبعة خاطئة. وترك 32 للمراجعة.
يمنحنا هذا قياسين مختلفين:
- التغطية: تعامل مع 95.6% من الطلبات محلياً.
- دقة القبول: كان صحيحاً في 99.0% من القرارات التي قبلها.
كلاهما يجب أن يكون ضمن النتيجة. فالمُصنِّف يمكنه تحقيق دقة مذهلة بمجرد قبول عدد قليل من الطلبات السهلة.
اختبرنا أيضاً 100,000 مدخل غير مألوف كان ينبغي أن يقع خارج فئاته المدعومة. وكان دقيقاً في أكثر من 94% من الحالات.
يبقى إدراك ما لا يعرفه النظام جزءاً من العمل.
والسرعة تحتاج إلى نفس العناية. في اختبار منفصل لوحدة المعالجة المركزية الدافئة، استغرق المُصنِّف المصرفي الكامل حوالي 1.8 مللي ثانية لكل طلب عند الوسيط على شريحة M4 Max. وشمل ذلك الترميز (tokenisation)، والتضمين، والتقييم.
واستثنى تنزيل النموذج وتشغيله. إنه قياس للتصنيف، وليس الوقت اللازم لحل طلب المستخدم بالكامل. كما أنه لا يثبت نفس الأداء على هاتف أو حاسوب محمول عادي.
يناسب Jev هذه المناقشة لأنه يعالج بالفعل فئة مشابهة من القرارات.
توثق TypeSafe نموذج Jev كأداة للأحكام المحدودة، بما في ذلك الاختيار بين الخيارات المتاحة وتوجيه الطلبات إلى الكود العادي، أو النماذج المتخصصة، أو البشر. \توثيق توجيه النوايا الخاص بـ Jev\
الدور الذي أراه لـ Jev هو مسار تصعيد اختياري للطلبات التي لا يستطيع المُصنِّف المحلي حلها بموثوقية.
البنية التي نعمل نحوها بسيطة:
طلب وارد → تصنيف محلي → الطلبات المألوفة تسلك مساراً محدداً؛ الطلبات غير المؤكدة تنتقل إلى Jev، أو نموذج آخر، أو مراجعة بشرية.
بدون Jev، يمكن لنفس مرحلة التصنيف المحلية إعادة الطلبات غير المحلولة إلى النموذج اللغوي الكبير الحالي للتطبيق، أو خطوة التوضيح، أو عملية المراجعة.
يتحكم المطور في الفئات، وعتبات القبول، والخطة البديلة. ويمكنه إدخال المُصنِّف المحلي في سير عمل موجود وقياس القرارات التي يمكنه توليها.
اليوم، يعمل تكامل Jev في الوضع الخفي (shadow mode)، حيث يقارن القرارات عبر خمسة مواضيع واسعة دون تغيير سلوك التطبيق. الخطوة التالية هي اختبار ما إذا كان التصعيد الانتقائي يحسن سير العمل بالكامل. نتائج Qwen أعلاه ليست معياراً لأداء Jev.
هذا ما نحتاج إلى قياسه: تقليل استدعاءات النماذج غير الضرورية، ومعالجة أسرع للطلبات المألوفة، ومسار صريح للحالات التي تحتاج إلى مزيد من الاهتمام.
بدأنا في توسيع نفس النهج ليشمل الصور.
تخيل شركة تستلم إيصالاً، ولقطة شاشة لخطأ، وصورة لمنتج. كل منها يحتاج إلى مسار معالجة مختلف.
يمكن أن يذهب الإيصال إلى استخراج بيانات الإيصالات. ويمكن أن تدخل لقطة الشاشة في سير عمل الدعم. وتدخل صورة المنتج في سير عمل الكتالوج. بينما تذهب الصورة غير المؤكدة للمراجعة.
المُصنِّف يختار الوجهة. أما قراءة إجمالي الشراء، وتشخيص الخطأ، وتحديد تفاصيل المنتج، فتبقى مهام منفصلة.
يستخدم تنفيذنا التجريبي للصور مُشفِّر CLIP مُدرَّباً مسبقاً لإنتاج تمثيل رقمي للصورة.
نجح مرشح بحثي مُكيَّف في تصنيف 19 من أصل 20 صورة لمنتجات غذائية بشكل صحيح في اختبار تشخيصي صغير. كما أرسل جميع صور أوراق الفاصوليا الثلاثين للمراجعة.
كان الخطأ هو تصنيف لوحة المعلومات الغذائية والرمز الشريطي لزجاجة ما على أنها إيصال.
يمكنك رؤية المشكلة. فكلاهما يمكن أن يحتوي على نص كثيف، وأرقام، وتخطيطات مستطيلة. نحن بحاجة إلى أمثلة تُعلّم النظام الحد الفاصل الذي يهم تطبيقنا.
هذه العينة ضيقة جداً لتأكيد جاهزية الإنتاج. فالوسوم كانت مستمدة من مجموعة البيانات بدلاً من التحكيم المستقل، ولم تكن هناك أمثلة جديدة للإيصالات أو لقطات الشاشة في الاختبار. يستخدم العرض التوضيحي العام خط أساس منفصلاً، لذا لا ينبغي نسب نتيجة المرشح المُكيَّف إليه.
كانت معالجة الصور أثقل أيضاً من تصنيف النصوص. استغرقت المعالجة الوسيطة الدافئة حوالي 36 مللي ثانية في Node و197 مللي ثانية في Chromium على شريحة M4 Max. ويحتاج المتصفح أولاً إلى حوالي 85 ميبي بايت من أصول النموذج، بالإضافة إلى بيئة التشغيل الخاصة به.
التنفيذ المحلي لا يزال له تكاليف. حجم التنزيل، والذاكرة، ووقت البدء، وأداء الجهاز، كلها عوامل يجب أن تدخل في التقييم.
المنتج الذي أتخيله يتناسب مع تطبيق موجود حيث يقرر ما يحدث بعد ذلك.
يحدد المطور الفئات، ويقدم أمثلة تمثيلية، ويربط الوجهات، ويختار ما يجب حدوثه عندما يكون التصنيف غير مؤكد.
يجب أن يراقب النشر الأول سير العمل الحالي دون تغيير نتيجته. يمكننا بعد ذلك مقارنة القرارات المقترحة بالنتائج المؤكدة قبل السماح للمُصنِّف بالتحكم في التوجيه.
نحتاج إلى فحص الأخطاء المقبولة بنفس دقة فحص الطلبات المرفوضة. وإلا فقد يختفي القرار الخاطئ الواثق خلف نتيجة مطمئنة.
كما تحتاج عمليات التدريب، والمعايرة، والاختبار إلى بيانات منفصلة. التدريب يُعلّم الفئات. المعايرة تختار قواعد القبول. واختبار محمي يتحقق من النتيجة المجمدة.
بمجرد أن يؤثر خطأ في الاختبار على النموذج التالي، يصبح هذا المثال بيانات تطوير. ويحتاج التقييم التالي إلى اختبار جديد.
يمنح الكائن الفضائي الصغير في فارز البريد الناس طريقة لتخيل المهمة. وبناء نسخة مفيدة يعني معرفة المدخلات التي يمكنه التعامل معها بدقة، ومتى يجب أن يطلب المساعدة، وما تكلفة أخطائه.
الخطوة التالية هي سير عمل تمثيلي بوسوم مستقلة وسجل لكل نتيجة. نحتاج إلى قياس عدد الطلبات التي تسلك المسار المحلي، وعدد الطلبات التي تصل إلى نموذج آخر، وعدد الأخطاء، وما إذا كان التطبيق بالكامل أصبح أسرع أو أرخص بعد احتساب تلك الأخطاء.
حان الوقت للتوسع ومنح هذا النموذج المحلي بعض القوة الإضافية.
