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

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

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

מה אני קורא הטמעה

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

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

החלטה 1: מתחילים מתהליך, לא מכלי

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

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

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

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

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

החלטה 3: מחליטים איזה מקור מידע קובע

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

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

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

החלטה 4: אוטונומיה היא מדרגה, ומרוויחים אותה

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

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

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

החלטה 5: מגדירים מה נחשב הצלחה, ומודדים את התוצאה עצמה

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

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

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

החלטה 6: בוחרים את הכלי רק עכשיו

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

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

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

החלטה 7: בונים דרך לעצור, ומתעדים כל כשל

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

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

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

תוכנית של 90 יום להטמעה ראשונה

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

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

חמש טעויות שאני רואה שוב ושוב

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

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