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

אך אם 70% מהחברות הגדולות בעולם, כך על-פי מחקר State of AI של פירמת דלויט, מעידות שהן טרם מיצו את הפוטנציאל שב-AI "רגיל", מן הסתם תחום ה-GenAI נמצא עוד יותר מאחור, שכן הבנייה וההטמעה שלו מורכבת מאוד ועדיין אין מספיק שיטות עבודה מומלצות (Best Practices).  צוותי הפיתוח מגששים לא אחת באפלה, ולפי הערכות שפורסמו באחרונה בכתב העת לעסקים של הרווארד היקף הכישלונות של הפרויקטים בתחום מגיע לכ-80%.

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

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

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

חלוקת הפרויקט לשלבים

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

בחירת המודל

שלב זה, הוא קריטי ונוגע לאמינות, דיוק ובטיחות התשובות שכלי ה-GenAI נועד לספק.הבחירה הרווחת כיום היא בין מודל השואב מידע מתוך בסיס נתונים מוגדר ותחום בהיקפו, ומייצר מתוך הבסיס הזה תשובות למשימות ספציפיות (Task Specific Model או TSM)  כגון מתן מענה לשאלות; סיכום טקסטים וניסוחם מחדש לבין מודל השואב ממקורות מידע גדולים כדי לבצע משימות רחבות היקף, אך שלעתים רמת הדיוק של התשובות שלו אינה מספקת (Large Language Model או LLM).

מודל ה-LLM נעדר לרוב ידע בתחום המומחיות הספציפי של הארגון. כדי להשלים את הפער, ניתן לבצע חיפוש בבסיס הנתונים הפנימי של הארגון לפי מילות מפתח וחיפוש סמנטי, ובכך לספק ל-LLM את ההקשר הספציפי הנדרש כדי לקבל תשובות מדויקות יותר. תהליך זה מתבצע באמצעות טכניקה ליצירה מבוססת איחזור (Retrieval-Augmented Generation או RAG), השואבת ממקורות מידע נוספים כדי לשפר את רמת הדיוק של תשובות ה-LLM. כחלק מהתהליך, רצוי גם להשתמש במודל ה-TSM כדי לבדוק את התשובות שהתקבלו ממודל ה-LLM. ממצאי ההשוואה שנערוך באמצעות ה-TSM בין התשובות שקיבלנו לבין ההקשר שסיפקה לנו טכניקת האיחזור, יבטיחו כי המשתמש ייהנה בסופו של דבר מתשובות מדויקות ואמינות.

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

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

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

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

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

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

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

יעלי דרשביץ תמרי היא סמנכ"לית מוצר ודליברי (CPO) ויוהן ברדוגו הוא ארכיטקט מערכות בבנק ONE ZERO