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

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

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

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

מסקנה ראשית

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

מדוע “הכנס הכל לעת עתה” נכשל?

1. יומני התכתבות קודמים אינם ידע מלכתחילה.

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

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

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

2. קלט מלא של מידע פנימי גורם ל"דילול רשמי"

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

בדרך כלל מתרחשים הדברים הבאים:

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

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

3. לא ניתן להשתמש בהכללות ללא ידיעת כללים ארגוניים גם אם הם נכונים.

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

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

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

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

דוגמה 1 לכשל: כיוון שגוי עקב כשל בחיבור VPN

  • סימפטום: “לא ניתן להתחבר ל-VPN מהבית”
  • תשובת AI: “אנא אתחל את הגדרות רשת מערכת ההפעלה והפעל מחדש.”
  • בפועל: הסיבה היא שלילת אישור בצד תשתית האימות, ולא ניתן לפתור אותה בצד המשתמש.

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

דוגמה 2 לכשל: הצעה להפרת תקנות ביישומי תוכנה

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

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

דוגמה 3 לכשל: אותה שאלה, התשובה משתנה בכל פעם

  • סימפטום: “מהם השלבים להגדרת העברת אימייל?”
  • תשובת AI: תלוי ביום
  • בפועל: דף נוהל פעולה ישן ודף נוהל חדש קיימים במקביל

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

אז מה לעשות: הפעל את לולאת KCS עם סיוע בינה מלאכותית

הפתרון האמיתי הוא לא להחליף את KCS ב-AI. האצת KCS עם AI.

מה זה KCS?

KCS (Knowledge-Centered Service) הוא תפיסה תפעולית המתעדת את הידע שנוצר בתחום המענה לפניות, עושה בו שימוש חוזר וממשיכה לשפר אותו. הדבר החשוב הוא לא ``לכתוב מסמך לאחר פתרון הבעיה’’, אלא להטמיע עדכון ידע בפעולת פתרון הבעיה עצמה. הסיבה לכך ש-KCS עוברת הערכה מחדש בעידן RAG היא פשוטה: איכות יעד החיפוש קובעת במידה רבה את איכות התשובות.

סיפור קצר: סיפור ישן, אבל יעיל.

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

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

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

תצורה מינימלית עבור פעולת KCS

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

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

בשטח, ריאלי להרחיב בהדרגה את היקף היישום בלופ הבא.

  1. המשתמש שואל תחילה AI
  2. אם AI לא פותר את הבעיה, הסלמה לשירות דלפק (SD)
  3. המרת רשומות התכתבות SD לידע באמצעות תבניות המתאימות לקריאה על ידי AI
  4. הוסף רק ידע רשמי מאושר ונבדק למקורות נתונים של AI
  5. שיעור התגובה העיקרי של הבינה המלאכותית ושיעור התשובה הנכונה עולה עם פניות דומות

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

אזורים שניתן להשאיר לבינה מלאכותית

  • אשכול שאילתות דומות
  • יצירת טיוטת תשובות (עם ראיות)
  • ציין פריטים חסרים (“מערכת ההפעלה היעד אינה ידועה”, “דרישות מוקדמות של הרשות אינן צוינו” וכו')
  • הצגת מועמדים לשילוב ידע כפול

אזורים שבהם בני אדם צריכים להיות אחראים

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

גם אם תנסה להשאיר זאת ל-AI, ה-AI לא יוכל להגיב כראוי.

נקודות מעשיות

יש לזכור את הנקודות הבאות בפועל.

צד פעולת הידע

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

צד בינה מלאכותית

  • הנחו את התלמידים במפורש לספק רציונל לתשובותיהם בהנחיה.
  • אל תאפשר שימוש במקורות לא רשמיים/לא מורשים ביצירת תשובות.

תפעול משופר

  • קבע את האמצעים לאיסוף התשובות השגויות של AI ושלב יצירת ידע לשיפור בפעולות רגילות.

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

התשובה ל"האם ניתן להחליף אותו?"

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

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

  • איזה ידע לאמץ כרשמי?
  • מי מבטיח איכות?
  • מי יעצור אותך כשתעשה טעות?

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

סיכום

הרעיון ש``אם תכלול את כל היומנים, תהפוך לחכם יותר’’ הוא אשליה. הסיבה האמיתית לכך שה-Service Desk AI תקוע היא לא כמות הידע, אלא היעדר ממשל הידע.

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

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

חומרי עזר