אמזון בנתה מגייס AI שלימד את עצמו לשנוא נשים. אני בניתי כזה שלא יכול.

בשנת 2014, צוות מהנדסי למידת מכונה באדינבורו התיישב לפתור את גיוס העובדים בהיקף של אמזון. מזינים למערכת 100 קורות חיים, ומקבלים בחזרה את חמשת המובילים, מדורגים מכוכב אחד עד חמישה כוכבים — כמו דירוג מוצרים. אלגנטי. יעיל. ותוך שלוש שנים, הם גילו שהמערכת לימדה את עצמה שהיות אישה היא מאפיין פוסל.

ה-AI העניש קורות חיים שהכילו את המילה "נשים" — כמו ב"קפטנית מועדון השחמט לנשים". הוא הוריד בדירוג בוגרות של שני קולג'ים לנשים בלבד. לא משום שמישהו הורה לו לעשות זאת. אלא משום שכשמאמנים מודל על עשר שנים של נתוני גיוס מתעשייה שנשלטת על ידי גברים, "היות גבר" הופך, סטטיסטית, לאחד המנבאים החזקים ביותר של "היות מגויס".

אני זוכר שקראתי את הכתבה החושפנית של רויטרס כשהיא פורסמה. כבר הייתי שקוע עמוק בבניית מערכות של גרפים של ידע ב-VeriPrajna, והתגובה הראשונה שלי לא הייתה הלם — היא הייתה זיהוי. במשך חודשים טענתי שלמנועי מתאם סטטיסטי אין שום עסק בקבלת החלטות על פוטנציאל אנושי. סיפור אמזון לא היה אנומליה. הוא היה הכרח מתמטי. וזה קידש בי את האמונה שכל הגישה הארכיטקטונית לגיוס עובדים באמצעות AI היא שבורה — לא בשוליים, אלא ביסוד.

הבעיה אינה ההטיה. היא הארכיטקטורה.

הנה מה שרוב האנשים טועים בו לגבי כישלון אמזון: הם חושבים שהמהנדסים היו רשלנים. הם לא היו. הם היו מבין מהנדסי ה-ML הטובים בעולם. כשהם גילו את ההטיה המגדרית, הם ניסו לתקן אותה. הם תכנתו במפורש את המודל להתעלם ממונחים ספציפיים למגדר. והמודל מצא דרכים לעקוף זאת.

זהו המושג של משתני פרוקסי, וזה הדבר שמדיר שינה מעיניי בלילות. מודלים של למידה עמוקה הם מגלי-דפוסים בלתי-נלאים. הסירו את המילה "אישה" מהקלט, והמודל ייאחז במבנה המשפט. מחקרים מראים שקורות חיים של גברים נוטים להשתמש בפעלים כמו "ביצעתי" ו"כבשתי", בעוד שקורות חיים של נשים נוטים לשפה קהילתית יותר. המודל רואה ש"ביצעתי" מתואם עם "מגויס" ומשחזר בשקט את ההטיה המגדרית דרך בלשנות בלבד.

המהנדסים של אמזון לא הצליחו להסיר בצורה כירורגית את ההטיה מבלי להרוס את יכולת החיזוי של המודל. אז הם חיסלו את הפרויקט כולו.

אי אפשר לתקן מערכת שמפלה במקרה. צריך לבנות מערכת שאינה יכולה להפלות מעצם התכנון.

המשפט הזה היה כוכב הצפון שלי במשך שלוש שנים. וזו הסיבה שבנינו את מנוע הגיוס של VeriPrajna על גרפים של ידע במקום על רשתות נוירונים.

מדוע כל מגייס AI לומד בסופו של דבר להפלות?

אני צריך שתבינו משהו על אופן הפעולה של למידה עמוקה בגיוס עובדים, כי אופן הכישלון הוא נוגד-אינטואיציה.

רשת נוירונים אינה מבינה מה פירוש "Python". היא אינה יודעת ש-Python היא שפת תכנות שימושית למדעי הנתונים. היא יודעת רק שהמחרוזת "Python" הופיעה לעתים קרובות בקורות החיים של אנשים שגויסו. אם "לקרוס" הופיע גם הוא לעתים קרובות — אולי בגלל מתאמים סוציו-אקונומיים בין ספורט מסוים לבתי ספר מסוימים שמזינים חברות מסוימות — המודל עשוי לשקלל את "לקרוס" באותה מידה כמו "Python".

זהו מתאם המתחזה לאינטליגנציה. המודל אינו מסיק על סיבה ותוצאה. הוא מוצא דפוסים וממטב אותם. והנה החלק המרושע: הגברת הטיה פירושה שמודלים אלה לא רק משכפלים הטיות היסטוריות — הם מגזימים אותן. אם גברים היוו 60% מכוח העבודה בנתוני האימון, המודל עשוי לדחוף לגיוס של 80% או 90% גברים כדי למקסם את ציון הדיוק שלו.

ניהלתי שיחה עם משקיע פוטנציאלי בשלב מוקדם, שאמר לי, "פשוט השתמש ב-GPT-4 לסינון קורות חיים. כולם עושים זאת." שאלתי אותו: אם תזין את אותם קורות חיים ל-GPT-4 פעמיים, האם תקבל את אותו ציון? הוא השתהה. התשובה היא לא — LLMs הם סטוכסטיים. הם אינם דטרמיניסטיים. הרץ את אותו קלט פעמיים, קבל שני פלטים שונים. בתרחיש של ביקורת, זה לא מוזרות. זה כשל ציות.

חומות הרגולציה נסגרות

זה כבר לא תיאורטי. ממשלות ראו את סיפור אמזון והן מחוקקות.

חוק NYC Local Law 144, שנכנס לתוקף ביולי 2023, מחייב כל מעסיק המשתמש בכלי אוטומטי לקבלת החלטות תעסוקה לעבור ביקורת הטיה עצמאית שנתית. לא ביקורת עמומה של "בדקנו הוגנות" — אלא ביקורת ספציפית וכמותית. החוק מחייב חישוב של שיעורי בחירה ויחסי השפעה עבור כל קטגוריה של גזע, מוצא אתני ומין. אם שיעור הבחירה עבור קבוצה מוגנת מחולק בשיעור של הקבוצה הנבחרת ביותר יורד מתחת ל-0.8 — "כלל ארבע-חמישיות" — זו ראיה לכאורה להשפעה מפלה.

הEU AI Act הולך רחוק יותר. הוא מסווג מערכות AI המשמשות לגיוס עובדים כסיכון-גבוה — אותה קטגוריה כמו מכשירים רפואיים ותשתיות קריטיות. סעיף 13 דורש שמערכות אלה יהיו "שקופות מספיק כדי לאפשר למשתמשים לפרש את פלט המערכת". סעיף 14 מחייב פיקוח אנושי — היכולת לעקוף החלטות AI. אבל אי אפשר לעקוף באופן משמעותי החלטה שאינך מבין.

ותחת GDPR, סעיף 15(1)(h) מעניק לנשואי המידע את הזכות לגשת ל"מידע משמעותי על ההיגיון הכרוך" בהחלטות אוטומטיות. פסקה 71 מזכירה במפורש את הזכות "לקבל הסבר על ההחלטה שהתקבלה".

נסו להסביר את ההחלטה של רשת נוירונים. קדימה. "נוירון 4,502 נורה בעוצמה 0.8" אינו הסבר משמעותי. גם "המודל קבע שאתה התאמה של 73%" ללא פירוט נוסף אינו כזה.

הפער בין המורכבות הטכנית לבין הדרישה המשפטית להסבר פשוט הוא המשבר המרכזי של טכנולוגיית ה-HR המודרנית.

כתבתי על נוף רגולטורי זה לעומק רב יותר בהגרסה האינטראקטיבית של המסמך הלבן שלנו, שסוקרת בדיוק כיצד כל רגולציה חלה על ארכיטקטורות AI שונות.

מה אם ה-AI כלל לא יכול היה לראות מגדר?

כאן אני צריך לספר לכם על הלילה שבו הכול התחבר לי.

התנסינו בגישות שונות להפחתת הטיה — אימון יריב, הגברה קונטרה-פקטואלית, ערכת הכלים הרגילה. וישבתי במשרד שלנו ב-11 בלילה, בוהה בתצוגה גרפית על המסך שלי, כשעברה בי אחת מאותן תובנות מובנות-מאליהן-בדיעבד: ניסינו ללמד את המודל להתעלם מהטיה. מה אם נבנה ארכיטקטורה שבה הטיה כלל לא יכולה להיכנס למנוע ההסקה?

בגרף של ידע, נתונים מאוחסנים כצמתים (ישויות) וקשתות (קשרים). צומת של אדם מתחבר לצמתים של מיומנויות. צמתים של מיומנויות מתחברים לצמתים אחרים של מיומנויות דרך קשרים סמנטיים. הגרף יודע ש"PyTorch" היא ספרייה ל"למידה עמוקה", שהיא תת-קבוצה של "בינה מלאכותית". כך שאם משרה דורשת "ניסיון ב-AI" ומועמד מציין "PyTorch", הגרף מתחקה אחר הנתיב ומוצא התאמה — אפילו מבלי שמילת המפתח "AI" מופיעה בשום מקום בקורות החיים.

הנה ההחלטה הארכיטקטונית הקריטית: כשאלגוריתם ההתאמה שלנו רץ, הוא פועל על תת-גרף מוגבל. גרף ההסקה הזה מכיל מיומנויות, תפקידים, רמות ניסיון והסמכות. הוא מוציא במפורש צמתים של שם, מגדר, מוצא אתני, כתובת ותאריכי סיום לימודים.

ההטיה אינה מדוכאת. היא מנותקת מבנית. אין נתיב מ"מועמד" ל"מגדר" ל"תפקיד" משום שצומת המגדר אינו קיים בגרף שהאלגוריתם יכול לראות.

השוו זאת למודל של למידה עמוקה, שקולט את כל הטקסט הגולמי. אפילו אם תסירו את שדה ה"מגדר", המודל קורא "מועדון שחמט לנשים" ומסיק מגדר. במערכת שלנו, ה-LLM שמנתח את קורות החיים ממפה את "מועדון שחמט לנשים" לצומת מנוטרל: (:Activity {type: "Strategy Club", role: "Leadership"}). המאפיין המגדרי מוסר לפני שהוא נכנס למנוע ההסקה.

אני זוכר את הוויכוח בצוות על כך. אחד המהנדסים שלי התנגד בתוקף — הוא חשב שאנחנו מאבדים אות בעל ערך על ידי הסרת ההקשר. "מה אם מועדון השחמט לנשים הוא למעשה תחרותי יותר מהרגיל?" נקודה הוגנת. אבל לא מיטבנו למקסום חילוץ מידע. מיטבנו להוגנות תחת בחינה משפטית. ואני מעדיף לפספס אות שולי מאשר לבנות מערכת שלומדת להעניש מחצית מהאוכלוסייה.

כיצד באמת מודדים כישרון ללא הטיה?

אנחנו לא מנבאים מי יצליח. אנחנו מודדים מרחק מיומנויות — הפער הגיאומטרי בין מה שיש למועמד לבין מה שמשרה דורשת. זה מעביר את הגיוס מהסתברות סובייקטיבית למדידה אובייקטיבית.

מערכות מסורתיות למעקב אחר מועמדים משתמשות בלוגיקה בוליאנית: האם קורות החיים מכילים את מילת המפתח "Java"? כן או לא. זה שביר וטיפשי. זה מפספס כל מי שמשתמש בטרמינולוגיה שונה לאותה מיומנות.

אנחנו משתמשים בשיכוני גרף — אלגוריתמים כמו Node2Vec שלומדים ייצוג וקטורי לכל מיומנות באונטולוגיה שלנו. מיומנויות שמופיעות יחד לעתים קרובות בגרף (כמו "Python" ו"Pandas") נמצאות קרובות זו לזו במרחב הווקטורי. מיומנויות שאינן קשורות (כמו "Python" ו"הקזת דם") נמצאות רחוקות זו מזו.

כדי לנקד מועמד, אנחנו מחשבים דמיון קוסינוס בין קבוצת וקטורי המיומנויות של המועמד לבין קבוצת וקטורי הדרישות של המשרה. זה נותן לנו קרדיט חלקי. מועמד שחסר לו "Tableau" אבל יש לו "Power BI" מקבל ציון דמיון גבוה משום שאותם צמתים הם שכנים סמנטיים באשכול "בינה עסקית". חיפוש מילות מפתח היה נותן להם אפס.

אנחנו מוסיפים שכבה של דמיון ז'קרד עבור חפיפת מיומנויות גולמית ומרחק גיאודזי — חישובי נתיב-קצר-ביותר דרך הגרף — עבור ניתוח פערים. אם משרה דורשת Kubernetes ולמועמד יש Docker, הגרף מוצא את הנתיב: Docker → Containerization → Orchestration → Kubernetes. מרחק: 3 קפיצות. פרשנות: ניתן להכשרה. אם המרחק הוא 6+ קפיצות, זהו פער קשה.

ציון מרחק המיומנויות הסופי הוא מדד מבוסס-כשירות בלבד, עיוור לחלוטין לדמוגרפיה. אנחנו לא מנחשים מי טוב. אנחנו מודדים כמה הם קרובים.

לפירוט הטכני המלא של אלגוריתמים אלה — כולל המתמטיקה שמאחורי דמיון הקוסינוס ומודל הניקוד המשולב שלנו — ראו את מאמר המחקר שלנו.

רגע "ה-SQL החסר"

הבה אמחיש זאת עם משהו שקרה במהלך הבדיקות.

הרצנו פרופיל מועמד דרך מגייס קופסה-שחורה סטנדרטי ודרך המערכת שלנו. הקופסה השחורה דחתה את המועמד. ללא נימוק. (מאוחר יותר קבענו שהמועמד למד בקולג' קטן ופחות מוכר — עונש ייחוס קלאסי.)

המערכת שלנו החזירה את זה: "למועמד חסר ניסיון מפורש ב-SQL. עם זאת, ניתוח הגרף מראה ניסיון נרחב עם Pandas DataFrames ו-R dplyr. מרחק הגרף בין DataFrames ל-SQL הוא קצר (מושג משותף: מניפולציית נתונים). המלצה: ראיון. יכולת העברה גבוהה."

אותו מועמד — זה שהקופסה השחורה השליכה — היו לו כל המיומנויות שהמשרה דרשה. הוא פשוט השתמש במילים שונות לתאר אותן. והוא למד בבית ספר שהקופסה השחורה לא ראתה מספיק ממנו בנתוני האימון שלה כדי לראות בו "מוצלח".

זה מה שאני מתכוון כשאני אומר שגרפים של ידע מרחיבים את מאגר הכישרונות. הם מוצאים אנשים שיש להם את הכשירויות אבל לא את הייחוס או את אוצר המילים המדויק. וזה משפר באופן טבעי את הגיוון — לא באמצעות מכסות או התאמות, אלא באמצעות מדידה טובה יותר.

מה קורה כשהמערכת מסמנת בעיה?

אנשים שואלים אותי: "מה אם המערכת שלך עדיין מייצרת תוצאות מוטות?" זו שאלה הוגנת, והייתי חושד בכל מי שיטען שהמערכת שלו מושלמת.

הנה ההבדל: כשקופסה שחורה מייצרת תוצאות מוטות, אתה תקוע. אתה יכול לראות את ההשפעה המפלה במספרים, אבל אינך יכול לראות מדוע. האם אלה שמות האוניברסיטאות? המיקודים? סגנון הכתיבה? אתה מנפה באגים במערכת עם מיליוני פרמטרים וללא לוגיקה קריאה.

כשהמערכת שלנו מייצרת אנומליה סטטיסטית — נניח, יחס השפעה מתחת ל-0.8 עבור קבוצה דמוגרפית מסוימת — אנחנו יכולים להתחקות אחריה. אנחנו יכולים לזהות את צמתי הגרף הספציפיים הגורמים לפער. אולי תיאור משרה דורש הסמכה יקרה מסוימת שמתואמת עם מעמד סוציו-אקונומי. אנחנו יכולים לראות זאת, לסמן זאת, וצוות הגיוס יכול להחליט האם ההסמכה הזו באמת נחוצה או שזו רק דרישה מורשת שאיש לא הטיל בה ספק.

קופסת הזכוכית לא אומרת שהמערכת תמיד צודקת. היא אומרת שכשהיא טועה, אתה יכול לגלות מדוע ולתקן זאת.

ל-LLM עדיין יש עבודה — רק לא את החשובה

עליי להבהיר: אנחנו כן משתמשים ב-LLMs. אנחנו לא לודיטים. אבל אנחנו משתמשים בהם כפי שהיית משתמש במתרגם — לקריאה וכתיבה, לא לשיפוט.

הארכיטקטורה שלנו אוכפת הפרדת אחריות קפדנית. ה-LLM מטפל בתפיסה: הוא קורא טקסט לא-מובנה של קורות חיים ומחלץ ישויות. "תיאמתי צוות של 5 מפתחים לבניית אפליקציית React Native" הופך לנתונים מובנים — מיומנות: React Native, מיומנות: הובלת צוות, הקשר: פיתוח מובייל. ה-LLM מנרמל מילים נרדפות: "ReactJS" ו"React.js" ממופים שניהם לאותו צומת.

אבל ה-LLM לעולם אינו מקבל החלטת גיוס. כל ההתאמה, הניקוד והדירוג מתרחשים דרך מעבר גרף דטרמיניסטי. אותו גרף בתוספת אותה שאילתה שווה אותה תוצאה, בכל פעם. אנחנו גם משתמשים ב-LLM בקצה הפלט — הוא מייצר הסברים קריאים לבני אדם, אבל רק מעובדות מאומתות-גרף. הוא אינו יכול להזות התאמת מיומנות שהגרף אינו תומך בה.

אני חושב על ה-LLM כעל העיניים והפה של המערכת, בעוד שגרף הידע הוא המוח. לא היית נותן לפה שלך לקבל החלטות במקומך. (טוב, רובנו לא היינו.)

בין מה אנחנו באמת בוחרים?

כפי שאני רואה זאת, התעשייה נמצאת בפרשת דרכים. נתיב אחד מוביל למודלים גדולים יותר, יותר פרמטרים, יותר אטימות — ומשחק אינסופי של תופסת עם הטיה שממשיכה למצוא משתני פרוקסי חדשים לנצל. הנתיב האחר מוביל להסקה מובנית, מדידה סמנטית, ומערכות שיכולות להסביר את עצמן לרגולטור, למגייס, או למועמד שנדחה.

דיברתי עם מנהלי משאבי אנוש בחברות שעדיין משתמשות בכלי סינון של קופסה שחורה. הם יודעים את הסיכון. הם קראו על אמזון. אבל החלפת ארכיטקטורות מרגישה יקרה ולא ודאית, אז הם ממשיכים לטלא. הם מוסיפים "שכבות הפחתת הטיה" מעל מערכות מוטות ביסודן. הם שוכרים יועצים לביצוע ביקורות שנתיות שמספרות להם מה שבור מבלי לתת להם את הכלים לתקן זאת.

נתונים הם מראה. אם תאמן מודל על העבר, תשכפל את העבר. בעולם השואף לשוויון, שכפול העבר הוא תנאי כישלון.

אני לא הולך לסיים את זה בהסתייגות. ביליתי שנים בבניית זה, ראיתי את החלופה נכשלת בצורה מרהיבה, ואני בטוח במסקנה: עתיד ה-AI של הגיוס אינו נוגע לניבוי מי יצליח על סמך מי שהצליח בעבר. הוא נוגע למדידת המרחק האמיתי בין מה שמישהו יכול לעשות לבין מה שמשרה דורשת — ולהפוך את המדידה הזו לשקופה, דטרמיניסטית, וחסרת יכולת מבנית להפלות.

אתה יכול להמשיך לנבא את העבר. או שאתה יכול להתחיל למדוד את העתיד.