בינה מלאכותית בארגונים דורשת יותר ממהנדס בינה מלאכותית

הטמעת בינה מלאכותית בארגונים: למה מהנדס מצוין עדיין לא מספיק

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

ההדגמה, שהציגה קרן הגידור ברידג'ווטר בכנס AI Engineer NYC ב־13 באוקטובר, ממחישה את אחד האתגרים המרכזיים של הטמעת בינה מלאכותית בארגונים: מערכת יכולה להפיק תשובה משכנעת בלי להבין איזה מידע עדיין תקף, מה מחייב את הארגון ומה נחשב ראיה מספקת. כדי להגדיר זאת דרושים לא רק מהנדסים, אלא גם אנשים שמכירים את העסק ומוסמכים לקבל בו החלטות.

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

השקעה בהכשרת אנשים, לא רק בפיתוח סוכנים

אנטרופיק מקדמת תוכנית בהיקף של 100 מיליון דולר שנועדה לסייע לארגונים להפיק ערך מבינה מלאכותית. במרכזה עומדת הכשרת אנשים, וב־2 באוקטובר הכריזה החברה על Claude Frontier Academy, שמטרתה להכשיר 10,000 מהנדסי הטמעה של בינה מלאכותית מתקדמת עד סוף 2027.

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

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

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

הטמעת בינה מלאכותית בארגונים מתחילה בהגדרת משמעות

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

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

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

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

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

המקרה של ברידג'ווטר: יותר מקורות, אבל בעיקר מקורות מתאימים

בהדגמה של סם גרין מברידג'ווטר, הסוכן המחובר לרשת הסתמך על חומרים מיולי בתשובה לשאלה שנשאלה באוקטובר. לאחר חיבורו ל־Vault, מאגר ושכבת גישה למידע לא־מובנה שעוצבו בהכוונה אנושית, הוא חיפש חומרים מ־1 עד 8 באוקטובר והסתמך על שבעה מסמכים במקום אחד או שניים.

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

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

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

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

איך הופכים ניסיון מקצועי למבחן הנדסי

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

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

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

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

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

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

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

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

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

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

ידע עסקי אינו משאב שאפשר לבקש “לפי הצורך”

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

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

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

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

אבטחה ואחריות צריכות להיבנות לתוך השימוש

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

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

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

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

מה למדוד לפני שמרחיבים את ההטמעה

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

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

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

סיכום: חלוקת העבודה שמאפשרת להפיק ערך

חמש שאלות שכדאי לשאול לפני הפרויקט הבא

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

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

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