GLiNER 2 يُظهر كيف تلحق المرمِّزات المدمجة بنماذج LLM في استخراج الكيانات المسمّاة والتصنيف

فيما تنشغل السوق بنقاش وكلاء الذكاء الاصطناعي ونماذج LLM الأكبر حجمًا باستمرار، تعزز في معالجة اللغات الطبيعية التطبيقية فئة أخرى من النماذج بهدوء. تُظهر سلسلة UniNER → GLiNER → GLiNER 2 أن استخراج الكيانات وتصنيف النصوص وهيكلتها يكفيها في كثير من الأحيان مرمِّز مدمج يعمل بسرعة أكبر وتكلفة أقل ودون الارتباط بواجهة API خارجية.

لماذا يهم هذا الأمر

بالنسبة لكثير من فرق المنتجات، لا تكمن المسألة في أن يستدل النموذج بأسلوب أنيق، بل في أن يعثر باستمرار على الأسماء والتواريخ والشركات وفئات الطلبات أو الحقول داخل المستند. وفي مثل هذه السيناريوهات، كثيرًا ما تكون نماذج LLM التوليدية أكثر مما يلزم: فهي أغلى في الاستدلال، وأبطأ في الاستجابة، وتضيف مخاطر تشغيلية مثل واجهات API الخارجية وKV-cache وعدم استقرار زمن الاستجابة.

في هذا السياق تحديدًا عاد الاهتمام بالمرمِّزات zero-shot القادرة على حل المهام المعلوماتية الضيقة دون إعادة تدريب كاملة لكل نوع جديد من الكيانات.

الخطوة الأولى المهمة في هذا المسار جاءت من UniNER. فقد استخدم المؤلفون ChatGPT أداةً للوسم، وبيّنوا أن hard-label distillation لا تعمل فقط وسيلةً لخفض كلفة التدريب، بل أيضًا وسيلةً للحصول على نموذج صغير متخصص قادر على مجاراة المعلّم، بل التفوق عليه في مجاله. ومع ذلك بقيت مشكلة قديمة في UniNER: فالنموذج ظل انحداريًا ذاتيًا (autoregressive)، ويولّد الإجابة رمزًا تلو الآخر في جوهره. أي إن الجودة تحسنت، لكن تعقيد فك الترميز الزائد لم يختفِ.

من UniNER إلى GLiNER

جاءت الخطوة التالية مع GLiNER، وتبيّن أنها أهم من مجرد تحسين إضافي في المقاييس. فبدلًا من توليد النص، انتقل النموذج إلى مقارنة المقاطع النصية (spans) بقائمة من التسميات في فضاء كامن مشترك. يُرمَّز النص والتسميات بواسطة Transformer ثنائي الاتجاه، ثم يبحث النموذج عن التطابقات بين المقاطع المرشحة وأوصاف الكيانات. وهذا يزيل ذيل التوليد بأكمله: لا حاجة إلى فك ترميز (decoder)، ولا إلى تدفق رموز في المخرجات، ولا إلى انتظار أن يُكمل النموذج كتابة إجابته. وفي مهام NER المفتوحة المجال يبدو هذا حلًّا هندسيًا نظيفًا للغاية.

أظهر GLiNER الأصلي، المبني على DeBERTa، أن مرمِّزًا مدمجًا بمئات الملايين من المعاملات يمكنه منافسة نماذج LLM الأثقل بكثير في NER من نوع zero-shot. وتشدد الورقة البحثية على أن هذه البنية لم تفد في التعرف على الكيانات وحده. فقد نمت حولها سريعًا مجموعة كاملة من التفرعات المتخصصة: لاستخراج العلاقات (relation extraction)، وربط الكيانات (entity linking)، وتصنيف النصوص. وأكد ذلك الفكرة الرئيسية في GLiNER: إذا اختُزلت المهمة في مطابقة النص مع مخطط من التسميات، فليس من الضروري دائمًا استخدام نموذج توليدي كبير.

ما الذي يغيّره GLiNER 2

لا يحاول GLiNER 2 إعادة ابتكار البنية الأساسية، فهدفه مختلف. يأخذ المؤلفون خلاصة جهود المنظومة بأكملها ويجمعونها في واجهة واحدة schema-driven، يصف فيها المستخدم الكيانات والحقول وخيارات القيم وبنية النتيجة، ويعيد النموذج مخرجًا منظمًا جاهزًا في تمريرة واحدة. وهذا يحوّل مجموعة النماذج المتفرقة إلى أداة موحدة لسيناريوهات الإنتاج، حيث تهم بساطة خط المعالجة والتشغيل المحلي وكلفة يمكن التنبؤ بها.

• واجهة واحدة لـ NER والتصنيف واستخراج العلاقات والتحليل البنيوي
• تمريرة أمامية واحدة (forward pass) بدلًا من عدة سلاسل استدلال منفصلة
• سياق أطول لمعالجة المستندات الكبيرة وقوائم التسميات الطويلة
• دعم أوصاف التسميات عندما تكون أسماء الكيانات ملتبسة أو مرتبطة بمجال معين
• نموذج بحجم 205 ملايين معامل يمكن نشره محليًا دون الاعتماد على واجهة API خارجية

لكن مع التوحيد يعود المقايضة المألوفة. فكلما زاد عدد المهام والتسميات ودرجة التعميم التي نحاول جمعها في واجهة واحدة، ارتفع خطر تراجع الجودة في كل مهمة فرعية على حدة. ووفق ما ورد في التحليل، يتفوق GLiNER 2 على نماذج LLM الثقيلة في السرعة وسهولة النشر، لكنه في NER الخالص من نوع zero-shot يتخلف عن GLiNER الأصلي، وفي بعض اختبارات التصنيف لا يبلغ مستوى GPT-4o. ولا يجعل ذلك النموذج ضعيفًا، بل يثبّت مقايضة هندسية صريحة: عناء أقل في البنية التحتية وكلفة أدنى، لكن ليس أقصى جودة ممكنة.

ماذا يعني هذا

يُظهر GLiNER 2 أن سوق معالجة اللغات الطبيعية بدأت من جديد تقدّر الكفاءة إلى جانب الشمولية. فبالنسبة للفرق التي تعالج المستندات والتذاكر والاستمارات وتدفقات الأخبار بكميات كبيرة، قد تصبح هذه المرمِّزات بديلًا عمليًا لواجهات LLM API: ليست بديلًا في كل المهام، بل طبقة عمل سريعة حيث تهم السرعة والخصوصية والنتيجة التي يمكن التنبؤ بها.