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