פיתוח סוכן AI לאוטומציה של תהליכים עסקיים

פיתוח סוכן AI: מדוע אב טיפוס לא מגיע לפרודקשן

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

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

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

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

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

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

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

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

• שיעור הפעולות האוטומטיות — תרחישים טיפוסיים (התאמת פרטי חשבון, ניתוח מכתב נכנס, הכנת ייצוא לפי נוהל) הסוכן סוגר במלואם, בלי נציג. בסביבה מוגבלת זה בדרך כלל 60–75% מהנפח, והשאר מגיע לאדם כשהוא כבר עם הקשר אסוף.
• זמן עיבוד הפנייה — סיווג ותשובה ראשונית אורכים שניות במקום שעות המתנה בתור; פניות לילה וסוף שבוע כבר לא מצטברות עד הבוקר.
• שגיאות בהזנת נתונים — הסוכן מעביר נתונים מהמסמך למערכת הרישום ישירות, בלי הקלדה ידנית, ונעלם סוג שלם של פגמים: שגיאות כתיב בפרטי חשבון וסכומים שנכנסו לשדה הלא נכון.
• תפוקת המחלקה — גדלה בלי הרחבת מצבת כוח האדם: אותו הרכב סוגר יותר פניות בימי שיא, והתור מטופל בתוך המשמרת.
• קליטת עובדים חדשים — הסוכן מציע את הצעד הבא לפי הנוהל ומביא את כרטיס הלקוח הנדרש, ולכן עובד חדש מגיע לנורמה בשבועות, לא בחודשים.
• עלות התהליך — יורדת לא בגלל צמצום אנשים, אלא בגלל שהשגרה מפסיקה לדרוש שעות עבודה ידניות: הוצאות אחסון ותחזוקת הסביבה לא גדלות יחד עם הנפח.

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

אפשרויות מימוש הסוכן והמגבלות שלהן

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

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

שלבי העבודה ההנדסית: מביקורת ועד מסירה

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

1. ביקורת תהליכים ונתונים. עוברים על כל תרחיש עיבוד, מסמנים מקורות, תדירות פניות והסתעפויות טיפוסיות. בתוצאה — מפת תהליך עם צווארי בקבוק, שבהם העבודה הידנית אוכלת את מירב הזמן.
2. תרשים אינטגרציה. קובעים לאילו מערכות הסוכן פונה לקריאה ולכתיבה, כיצד מועברים נתונים, מה קורה כאשר שירות חיצוני אינו זמין. תרשים האינטגרציה מאושר לפני תחילת הבנייה — תיקונים בשלב זה זולים יותר מאשר עריכה מחדש של הלוגיקה.
3. הגדרת הרשאות וגישות. הסוכן מקבל סט הרשאות מינימלי הכרחי, פעולות שינוי נתונים עוברות אישור, כל הפניות נרשמות ביומן. זה מאפשר להפריד מה הסוכן עושה בעצמו ומה הוא רק מציע.
4. בניית תרחישים. בונים לוגיקה שלב אחר שלב: ניתוח הבקשה הנכנסת, בחירת מקור הנתונים, יצירת התשובה, טיפול בכשלים. כל תרחיש מסתיים בתוצאה מובנת — כרטיס, מכתב או רשומה במערכת.
5. בדיקה על נתונים היסטוריים. מריצים את הסוכן על פניות שנצברו ומשווים את התשובות למה שעשו העובדים. מנתחים פערים: חלק סוגרים בשיפור התרחיש, חלק — בהבהרת הכללים.
6. עבודת ניסוי. מפעילים על זרם מוגבל במקביל לתהליך הנוכחי, בודקים את התוצאה ושומרים על בקרה ידנית במקרים שנויים במחלוקת. כך תקלה בתרחיש אחד לא משפיעה על כל נפח הפניות.
7. מסירת הפתרון ללקוח. מוסרים את המערכת המוגדרת, תיעוד של תרחישים ויומנים, מלמדים את הצוות לבצע תיקונים ולנתח תקלות. לאחר מכן התחזוקה מתבצעת בכוחות הלקוח או בתמיכה שלנו.

תיעוד, תרשימים ותקנות תחזוקה

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

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

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

מקרה בוחן: כיצד הסוכן הקל על עיבוד פניות נכנסות

היכן התהליך נתקע

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

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

מה בדיוק עשו

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

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

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

מדדים לאחר שלושה חודשים

שיעור הסגירות האוטומטיות של פניות הגיע ל-43% מכלל הזרם הנכנס. זמן התגובה הראשונה הצטמצם מ-6–9 שעות ל-4 דקות בשעות עבודה ועד 15 דקות בלילה. שיעור ההחזרות לתיקון ירד מ-21% ל-6% — בעיקר בזכות העובדה שהנציג מקבל את הפנייה עם הקשר אסוף.

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

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

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

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

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

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

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

ספקות טכניות נפוצות לפני תחילת הפרויקט

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

אילו הרשאות מקבל הסוכן?

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

כיצד לבדוק את איכות התשובות?

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

האם לא נהיה תלויים בספק מודל אחד?

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

מי אחראי לתוצאה לאחר המסירה?

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

מה להכין כדי שנחזור עם הערכה ותוכנית

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

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

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