משתמש כותב שאלה פשוטה בתוך מוצר SaaS, והמערכת מחזירה תשובה שנשמעת בטוחה אך מבוססת על מסמך ישן, על נתונים של חשבון אחר או על הנחה שהמודל המציא. זו נקודת הכשל שאנו רואים שוב ושוב כשמדברים על חמישה שימושים לסוכני AI. הערך אינו בעצם היכולת של מודל לבצע פעולה. הערך הוא ביכולת להפעיל פעולה נכונה, בהקשר הנכון, עם הרשאות, מקורות, מדידה וגבולות ברורים.
סוכן AI הוא רכיב שמקבל יעד, אוסף מידע או מפעיל כלים, ומחליט על רצף צעדים כדי להשלים משימה. בתוך מוצר קיים הוא יכול לגשת ל-API, לחפש במאגר ידע, לקרוא נתונים מורשים או ליצור טיוטה לפעולה. אבל ככל שהוא מקבל יותר עצמאות, כך עולה הצורך בתכנון תפעולי: מי רשאי לבקש מה, על אילו נתונים, באילו תנאים, ואיך יודעים שהתוצאה הייתה נכונה.
להלן חמישה שימושים מעשיים. בכל אחד מהם, הסוכן אינו תחליף ללוגיקה עסקית או לבקרות מערכת. הוא שכבה שמקצרת עבודה אנושית, כל עוד המערכת שומרת על שליטה.
חמישה שימושים לסוכני AI במוצר SaaS חי
1. סיוע תמיכה שמבוסס על מידע מאומת
שימוש טבעי הוא סוכן שמסייע לצוות תמיכה להבין פנייה, לאתר מידע במאגר הידע ובחשבון הלקוח, ולהציע תשובה או צעד הבא. הוא יכול לסכם היסטוריית פניות, לזהות מוצר או גרסה רלוונטיים, ולהציג לצוות את המקורות שעליהם הסתמך.
המלכודת כאן היא לתת לסוכן לענות מתוך ידע כללי בלבד. במוצר עם תיעוד שמשתנה, הגדרות שונות לכל לקוח ותוכניות שירות שונות, תשובה כללית היא לעיתים תשובה שגויה. הפתרון הוא RAG, כלומר Retrieval-Augmented Generation: לפני יצירת התשובה, המערכת מאתרת קטעי מידע רלוונטיים ממקורות מאושרים ומעבירה אותם למודל.
גם RAG לבדו לא מספיק. החיפוש חייב להיות מסונן לפי tenant, משתמש והרשאות. אם סוכן תמיכה יכול לראות מידע פנימי או פרטים של לקוח אחר, הוא עלול לחשוף אותם בתשובה. לכן ההרשאות צריכות להיאכף בשכבת הנתונים וה-API, לא רק בהוראה בתוך ה-prompt. בנוסף, תשובה טובה צריכה להציג ציטוטים למסמכים או לרשומות הרלוונטיות. כך הנציג יכול לבדוק אותה לפני שליחה, והמשתמש יכול להבין מה הבסיס שלה כשמדובר בתשובה ישירה בתוך המוצר.
2. חקירת נתוני מוצר בלי לתת גישה חופשית למסד הנתונים
מנהלי מוצר, Customer Success ומנהלי חשבונות רוצים לעיתים לשאול שאלות כמו: אילו משתמשים הפסיקו להשתמש בפיצ'ר מסוים, מה השתנה בשבוע האחרון, או אילו תקלות חוזרות אצל לקוח מסוים. סוכן יכול לתרגם שאלה לשאילתות מוגדרות מראש, להצליב נתונים ולהחזיר תשובה קריאה עם פירוט.
כאן חשוב להפריד בין סוכן חוקר לבין משתמש עם גישת SQL בלתי מוגבלת. מתן גישה ישירה למסד הנתונים עלול ליצור שאילתות יקרות, לחשוף נתונים רגישים ולהחזיר מסקנות מטעות בגלל הבנה חלקית של הסכימה העסקית. במקום זאת, אנו ממליצים לחשוף לסוכן כלים מצומצמים: endpoints או queries מאושרים עם פרמטרים מוגדרים, סינון הרשאות ומגבלות תוצאה.
למשל, במקום לתת לסוכן גישה לכל טבלאות האירועים, אפשר לספק כלי שמחזיר מדדי שימוש לפי חשבון וטווח תאריכים. במקום גישה למידע אישי, אפשר להחזיר נתונים מצרפיים או מזהים ממוסכים. הסוכן עדיין יכול לעזור לחקור, אבל אינו הופך לנתיב עוקף למודל ההרשאות שלכם.
גם כאן יש צורך בהסבר. תשובה כגון "השימוש ירד" אינה מספיקה. הסוכן צריך לציין את טווח הזמן, את ההגדרה של מדד השימוש ואת הנתונים שעליהם הסתמך. לעיתים נכון יותר להחזיר "אין מספיק נתונים כדי לקבוע" מאשר לייצר אבחנה משכנעת אך לא מבוססת.
3. טיפול מבוקר בתהליכים תפעוליים
סוכן יכול להכין או לבצע פעולות בתוך המוצר: פתיחת קריאת שירות, עדכון סטטוס, איסוף פרטים חסרים, יצירת טיוטת מסמך או ניתוב משימה לצוות המתאים. זהו שימוש יעיל במיוחד כשיש רצף החלטות קטן שחוזר על עצמו, אך הוא אינו תמיד מועמד טוב לאוטומציה מלאה.
ההבחנה החשובה היא בין פעולה הפיכה לפעולה בעלת השלכה עסקית. הצעת טיוטה לתגובה היא פעולה בסיכון נמוך יחסית. שינוי הרשאה, מחיקת נתון, הפעלת חיוב או שליחת הודעה חיצונית בשם משתמש הם פעולות שדורשות אישור מפורש, תיעוד ולעיתים גם כלל עסקי רגיל שאינו תלוי במודל.
תכנון נכון כולל מצב "תכנן ואז אשר": הסוכן מציג מה הוא עומד לעשות, אילו נתונים ישתנו ומדוע, ורק לאחר אישור הוא מפעיל את ה-API. לכל פעולה צריכה להיות עקבת ביקורת - מי ביקש אותה, מה הסוכן הציע, אילו כלים הופעלו ומה הוחזר. כאשר משהו משתבש, לא מספיק לדעת שהתשובה הייתה לא טובה. צריך לדעת באיזה שלב התקבלה החלטה שגויה.
4. ניתוח מסמכים ותהליכי בדיקה עם מקור ברור
במוצרים שעובדים עם מסמכים, הסוכן יכול לחלץ פרטים מטפסים, להשוות בין גרסאות, לזהות שדות חסרים ולהציג חריגות לבדיקה אנושית. זה יכול לקצר עבודה ידנית משמעותית, בעיקר כאשר המבנה של המסמכים דומה אך אינו אחיד לחלוטין.
עם זאת, חילוץ מידע הוא לא אמת מוחלטת. מסמך סרוק באיכות נמוכה, ניסוח דו-משמעי או נתון שמופיע בשני מקומות יכולים להוביל לפרשנות שגויה. לכן תוצאה טובה אינה רק שדה ממולא. היא כוללת ערך, מקור מדויק בתוך המסמך, ורמת ודאות או סימון לבדיקה במקרה של חוסר התאמה.
במקום לכתוב ערכים ישירות למערכת הליבה, עדיף ברוב המקרים להציג מסך אימות או להפעיל כללי validation רגילים לפני שמירה. אפשר להשתמש במודל כדי להציע, אך השכבה הדטרמיניסטית של המערכת היא זו שמחליטה אם פורמט, טווח ותנאי עסקי תקינים. זה פחות מרשים בדמו, אבל הרבה יותר אמין בייצור.
5. סוכן פנימי לצוות הפיתוח וה-R&D
גם בתוך צוות טכני, סוכן יכול להועיל: סיכום incident, איתור שירותים שמושפעים משינוי, הכנת טיוטת תיעוד או מיפוי תלות בין רכיבים. כאשר הוא מחובר למקורות הנכונים, הוא מקצר את זמן ההתמצאות במערכת מורכבת.
אבל סוכן כזה חייב לעבוד עם מקורות גרסה ותיעוד עדכניים. אם הוא מסתמך על README ישן או על קוד שאינו נמצא בענף הפעיל, הוא עלול להציע תיקון לא רלוונטי. גם חשיפת קוד, סודות מערכת או לוגים רגישים מחייבת הפרדת גישות ברורה. לא כל מי שיכול לשאול שאלה צריך לקבל גישה לכל repository, לכל ticket או לכל סביבת ייצור.
במקרה הזה, המדד החשוב אינו כמה תשובות הסוכן מחזיר. השאלה היא האם הוא מקצר עבודה בלי להכניס סיכון חדש: האם הוא מפנה לקבצים ולמקורות נכונים, האם ההמלצות שלו נבדקות, והאם אפשר לזהות במהירות תשובה שגויה לפני שמיישמים אותה.
מה צריך לבנות סביב הסוכן
הטעות הנפוצה היא להתמקד בבחירת המודל ולדלג על הארכיטקטורה שמסביבו. במוצר חי, האמינות נקבעת בעיקר על ידי איכות הנתונים שנשלפים, פילטרי הרשאות, הגדרות הכלים, טיפול בכשלונות ומדידה שוטפת.
לכן לפני הרחבת שימוש בסוכנים, כדאי להגדיר סט תרחישי evals. evals הם מבחנים חוזרים שבודקים כיצד המערכת מגיבה לשאלות ומשימות מייצגות: תשובה שאמורה להישען על מקור מסוים, בקשה שאמורה להיחסם לפי הרשאה, שאילתה שעלולה להיות יקרה, או פעולה שדורשת אישור. בלי מבחנים כאלה, שינוי קטן ב-prompt, במודל או בחיפוש יכול לפגוע בהתנהגות בלי שאיש יגלה זאת עד שלקוח יתלונן.
יש גם שיקול עלות וזמן תגובה. סוכן שמפעיל כמה קריאות מודל, חיפוש וכלי API עשוי לתת תוצאה טובה יותר, אך להיות איטי ויקר יותר. לפעמים נכון להשתמש בזרימה קצרה וקבועה. לפעמים המשימה באמת מצריכה תכנון רב-שלבי. ההחלטה צריכה להתבסס על סוג המשימה, רמת הסיכון והערך למשתמש, לא על הרצון לתת לסוכן יותר חופש.
ב-DevCo Solutions אנו מתחילים מבדיקת הזרימה שכבר רצה: מה המשתמש רואה, מאיפה המידע מגיע, מה מותר לסוכן לעשות, ואיך נמדדת איכות לאורך זמן. אם יש לכם פיצ'ר AI חי שאינו מספק תשובות עקביות, ציטוטים, הרשאות או שליטה תפעולית, השלב הבא הוא למפות את נקודות הכשל ולתעדף תיקונים. אפשר לקבוע שיחת סקירה קצרה דרך טופס יצירת הקשר באתר.