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

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

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

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

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

1. הנדסת ייצור: לבנות שירות אמין סביב מודל משתנה

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

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

איכות האחזור קודמת לעיתים לאיכות הניסוח

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

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

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

זמן, עלות ויכולת תצפית הם חלק מהאיכות

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

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

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

2. מערכות סוכנים: אוטונומיה דורשת גבולות פעולה ברורים

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

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

חוזי כלים במקום חופש פעולה עמום

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

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

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

לשמור מצב, למנוע כפילויות ולדעת לעצור

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

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

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

3. ממשל בינה מלאכותית: להפוך מדיניות לבקרות שניתן לבדוק

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

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

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

מדיניות כקוד וראיות לביקורת

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

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

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

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

4. מדידת ערך: לבדוק תהליך עבודה, לא לספור תשובות

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

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

קו בסיס ועלות מלאה

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

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

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

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

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

תוכנית ל־90 יום: לייצר ראיות לפני שמרחיבים

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

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

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

ארבע המומחיויות במבט אחד

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

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

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