If you have ever uploaded a resume to an applicant tracking system and wondered why a human never saw it, you already un

إذا سبق لك أن رفعت سيرة ذاتية إلى نظام تتبع المتقدمين (ATS) وتساءلت لماذا لم يراها بشر أبدًا، فأنت تدرك بالفعل مشكلة "الصندوق الأسود" في التوظيف القائم على الذكاء الاصطناعي. تخفي معظم أدوات تقييم السير الذاتية منطقها خلف لوحات تحكم البرمجيات كخدمة (SaaS) ورسائل الرفض المهذبة. لكن HackerRank سلكت مسارًا مختلفًا؛ إذ إن أداة Hiring Agent الخاصة بها مفتوحة المصدر، مما يعني أنه يمكن لأي شخص فتحها وتتبع الكود ورؤية كيف يحول نموذج لغوي كبير (LLM) ملف PDF ورابط GitHub إلى رقم بدقة. لقد فعل أحد المطورين ذلك تمامًا، وما وجده لم يكن إطار عمل توظيف مصقولًا، بل كان مرآة تظهر لنا مدى سهولة تحويل الآراء الشخصية إلى قواعد مؤتمتة.

ما وراء الكواليس

إن مسار العمل بسيط بشكل مخادع. يتم تحويل السيرة الذاتية للمرشح من تنسيق PDF إلى Markdown، ثم يتم تحليلها إلى هيكل JSON صارم يحتوي على حقول لتاريخ العمل، والمهارات، والتعليم، والمشاريع الجانبية. تقوم سكربتات Python بنقل البيانات من مرحلة إلى أخرى، ولكن التفكير الفعلي يحدث داخل سلسلة من الأوامر (prompts). يحصل كل قسم على أمر خاص به؛ حيث يقرأ النموذج اللغوي الكبير البيانات المهيكلة، ويطبق قواعد التقييم المكتوبة بلغة إنجليزية بسيطة، ثم يعيد درجة تقييم.

هذه البنية أمر بالغ الأهمية. فالجهد الأكبر لا يكمن في خوارزميات ذكية أو حلقات تدريب، بل يكمن في صياغة الأوامر. بتغيير بضع صفات في مجموعة التعليمات، يمكن للمهندس نفسه أن يتحول من مرشح قوي إلى مرشح ضعيف. وهذا ما يجعل الأداة هشة، ولكنه يجعلها صادقة أيضًا. فمعظم موردي حلول التوظيف بالذكاء الاصطناعي لن يسمحوا لك أبدًا برؤية الأوامر، لكن نموذج HackerRank الأولي يكشف الحقيقة: أن تقييم السير الذاتية كان دائمًا يعتمد على معايير التقييم (rubric)، وليس على الكود.

طغيان نسبة الـ 35 بالمئة

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

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

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

عندما لا تؤتي التعليمات ثمارها

تحاول معايير التقييم أيضًا مكافأة الخبرة في الشركات الناشئة، حيث يقترح الأمر صراحةً منح نقاط إضافية للمؤسسين ومهندسي المراحل المبكرة. يبدو هذا منطقيًا من الناحية النظرية، فغالباً ما يقوم قدامى المحاربين في الشركات الناشئة بأدوار متعددة وينجزون المهام تحت الضغط. لذا أجرى المختبر تجربة؛ حيث أخذ سيرة ذاتية واحدة ولم يغير فيها شيئًا سوى المسمى الوظيفي الأحدث، وشغلها عبر الأداة ثلاث مرات بثلاثة مسميات مختلفة: Senior Java Engineer، وFounding Engineer، وCo-founder / CTO.

لم تتغير الدرجات تقريبًا. لقد تجاهل النموذج اللغوي الكبير التعليمات فعليًا.

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

نقاط بلا هدف

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

ملف LinkedIn يستحق نقطة واحدة بالضبط. ليس بناءً على جودة الملف، ولا عدد التوصيات، ولا عمق التاريخ الوظيفي. مجرد وجود رابط (URL) في السيرة الذاتية يضيف نقطة واحدة إلى المجموع. وفي الوقت نفسه، تُعد المشاركة في Google Summer of Code مستحقة لخمس نقاط. وإذا كان لدى المرشح مستودعات منسوخة (forked repositories) على GitHub، فإن الوكيل يتجاهل أي نسخة (fork) لديها أقل من خمس نسخ خاصة بها.

كل قاعدة من هذه القواعد تمثل حكماً قيمياً صريحاً يتخفى في هيئة معامل رقمي هادئ. لماذا يستحق التواجد على LinkedIn نقطة من الأساس؟ إنه يشير إلى أن المرشح يعرف كيفية ملء شبكة اجتماعية، وليس إلى قدرته على تصميم نظام موزع (distributed system). لماذا تستحق GSoC خمسة أضعاف رابط LinkedIn؟ ربما لأن كاتب الأمر (prompt author) يحترم البرنامج، وهذا الاحترام أصبح الآن سياسة توظيف. ولماذا وضع الحد عند خمس نسخ (forks)؟ قد تحل أداة يستخدمها عشرة أشخاص مشكلة دقيقة وحرجة، ولكن بموجب هذا النظام، قد يبدو الأمر وكأنها غير موجودة أصلاً.

هذه الأرقام لا تنبثق من تحليل الانحدار (regression analysis)، بل اختارها أفراد. قرر شخص ما أن المشاركة في المصادر المفتوحة (open source) تمثل أكثر من ثلث قيمة المهندس، وقرر شخص آخر أن ملف LinkedIn يستحق نقطة واحدة. عندما تقوم بأتمتة هذه التخمينات، فإنك تمنحها سلطة البرمجيات.

كل أمر (Prompt) هو تحيز

الجزء الأصعب في بناء وكيل لتقييم السير الذاتية ليس تحليل ملفات PDF أو استدعاء واجهة برمجة تطبيقات (API)، بل هو تحديد ما يهم حقاً. كل كلمة في أمر التقييم (scoring prompt) هي حكم قيمي حول ما يجعل المهندس جيداً. هل يجب أن تفوق المشاريع الجانبية الوظائف الأساسية أهمية؟ هل يجب أن يكون للكود العام أهمية أكبر من عمل الشركات الخاص؟ هل يجب أن يكون لملف التواصل الاجتماعي أي أهمية على الإطلاق؟ لا توجد إجابات صحيحة رياضياً لهذه الأسئلة، بل توجد تفضيلات ثقافية فقط.

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

استخدمها كمرآة، لا كمرشح (Filter)

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

إذا كنت تبني تقنيات توظيف، فادرسها بعناية؛ فهي تظهر مدى سرعة تحول القواعد التعسفية إلى حراسة آلية (automated gatekeeping). وإذا كنت مرشحاً، فتذكر أن هذه الأنظمة ليست عرافات (oracles). إنها مجرد جداول بيانات مُغلفة بلغة طبيعية، وهي تحمل افتراضات من كتب الأوامر.

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