ישיבת מוצר, יום שלישי. מישהו אומר: "בואו נוסיף צ'אט חכם שעונה ללקוחות". כולם מהנהנים, כי זה נשמע מתקדם וגם המתחרים עושים משהו דומה. אף אחד לא שואל מה בדיוק הצ'אט הזה אמור לענות, על סמך איזה מידע, ומה קורה ביום שהוא ממציא תשובה.
AI במוצר מצדיק את עצמו במקרים רבים, אבל ההחלטה צריכה להתקבל על סמך כמה שאלות פשוטות ולא על סמך הלחץ להיראות מודרניים. כך אנחנו מסתכלים על זה.
קודם כל, מה המשתמש מנסה לעשות
פיצ'ר AI טוב מתחיל מבעיה של משתמש שיש לה היום עלות מדידה: משפטים שאנשים מקלידים שוב ושוב, מסמכים שמישהו קורא ידנית, פניות שמישהו ממיין. אם אתם לא מצליחים לתאר את העבודה הידנית שהפיצ'ר מחליף, עדיין אין לכם פיצ'ר, רק רעיון.
כדאי לכתוב משפט אחד: "היום X אנשים עושים Y ידנית, והפיצ'ר יאפשר להם Z". אם המשפט הזה לא נכתב בקלות, עוצרים וחוזרים לשאול משתמשים.
חמש שאלות לפני שמתחילים
1. כמה עולה טעות? מודל שפה טועה לפעמים, ולעיתים בביטחון מלא. בסיכום פנימי של פגישה טעות היא מטרד. בהמלצה על מינון תרופה, בחישוב מס או בהחלטה רגולטורית היא בעיה אמיתית. ככל שהטעות יקרה יותר, יידרש אדם שמאשר לפני שהפלט מגיע ליעדו.
2. יש לכם נתונים אמיתיים? פיצ'ר שמבוסס על המסמכים, ההיסטוריה או הידע של החברה (RAG, חיפוש במסמכים, ניתוח חוזים) תלוי באיכות החומר. מסמכים מפוזרים, מיושנים או סותרים לא יהפכו לתשובות טובות בגלל מודל טוב יותר. לפעמים העבודה הראשונה היא ניקוי התוכן, והיא קובעת את התוצאה יותר מבחירת המודל.
3. איך תדעו שהתשובה נכונה? לפני כתיבת קוד, אספו עשרות דוגמאות אמיתיות עם התשובה שהייתם רוצים לקבל. זה סט הבדיקה שלכם. בלעדיו כל שינוי בפרומפט או במודל הוא ניחוש, ואף אחד לא יודע אם הגרסה החדשה טובה מהקודמת או רק נראית כך בדוגמה האחרונה שהופיעה.
4. מה העלות והזמן לכל שימוש? כל קריאה למודל עולה כסף ולוקחת זמן, ושניהם גדלים עם נפח השימוש. פיצ'ר שמשתמשים מפעילים פעם בשבוע שונה לגמרי מפיצ'ר שרץ על כל שורה בטבלה. חשבו את זה מראש לפי השימוש הצפוי, כולל המקרה שהפיצ'ר מצליח יותר ממה שתכננתם.
שימו לב גם לעקביות. אותה שאלה יכולה להניב ניסוחים שונים בכל פעם, ולכן במקום שבו נדרשת תשובה זהה (למשל קטגוריה בטופס) מגבילים את הפלט לרשימה סגורה של ערכים ולא נותנים למודל לנסח חופשי.
5. לאן המידע הולך? אם מעבדים נתונים אישיים, פיננסיים או סודות מסחריים, צריך להחליט איפה המודל רץ ומה נשמר. לפעמים מספיק שירות ענן עם הגדרות מתאימות, ולפעמים יש דרישה שהמידע לא יצא מהארגון, ואז בוחנים מודל on-prem. ההחלטה הזו משפיעה על הארכיטקטורה כולה, ולכן מקבלים אותה בתחילת הדרך.
איפה AI בדרך כלל מצדיק את עצמו
התבנית החוזרת היא משימה שדורשת קריאה או הבנה של טקסט חופשי, ושבה אדם יכול לבדוק את התוצאה מהר יותר ממה שלקח לו לייצר אותה:
- חילוץ שדות ממסמכים (חשבוניות, חוזים, טפסים) והצגתם לאישור.
- חיפוש ותשובות מתוך בסיס ידע פנימי, עם הפניה למקור כך שאפשר לוודא.
- מיון וניתוב פניות, כשיש סיווג ברור ואפשר לתקן טעויות.
- טיוטות שאדם עורך לפני שליחה.
- תמלול וקול, כשהתוצאה משמשת כבסיס ולא כמסמך משפטי.
פיצ'רים של AI שעובדים טוב במוצר חולקים בדרך כלל שלושה תנאים: יש נתונים אמיתיים לבדוק עליהם, יש סט בדיקה קבוע שמודד אם שינוי שיפר או הזיק, ויש נקודה שבה אדם מאשר לפני שהתוצאה משפיעה על לקוח. כשאחד מהשלושה חסר, הפיצ'ר נראה טוב בדמו ומאכזב בשימוש.
גם כשמחליטים להשתמש ב-AI, לא כל חלק בפיצ'ר צריך להיות AI. בחילוץ נתונים מחשבונית, למשל, המודל מזהה את השדות והקוד הרגיל בודק שהסכומים מסתכמים, שהתאריך תקין ושהספק קיים במערכת. החלוקה הזו מקטינה טעויות ועלות, כי המודל עושה רק את מה שאי אפשר לכתוב ככלל.
איפה עדיף שלא
כשיש כלל שאפשר לכתוב, כתבו אותו. חישוב מחיר, בדיקת הרשאה ותנאי קבלה לתוכנית הם דטרמיניסטיים, זולים ומהירים, וקל לבדוק אותם. מודל שפה במקומם מוסיף עלות, אי-ודאות ונקודת כשל, בלי שום יתרון.
עדיף גם לוותר כשהנתונים לא קיימים והציפייה היא שה-AI יחליף את ההגדרה. מודל לא יפתור לכם ארגון שלא החליט איך הוא רוצה לסווג לקוחות. ולא כדאי להכניס אותו להחלטה שיש לה השלכות משפטיות או כספיות ישירות על אדם, כשאין בתהליך מישהו שבודק ומאשר.
סיבה נוספת לוותר היא שהפיצ'ר נבנה כדי שיהיה כתוב "מבוסס AI" בעמוד המוצר. משתמשים מזהים די מהר כשפיצ'ר איטי, לא עקבי או לא מועיל, והוא מוריד את האמון גם בשאר המוצר. פיצ'ר רגיל שעובד טוב מוכר יותר מפיצ'ר AI שעובד בערך.
איך מתחילים נכון כשהתשובה היא כן
מתחילים מגרסה צרה: תהליך אחד, סוג מסמך אחד, קהל משתמשים קטן. מריצים אותה מול סט הבדיקה, מוסיפים בהתחלה אדם שמאשר כל פלט, ומודדים כמה פעמים אישר כפי שהוא, כמה פעמים תיקן וכמה פעמים דחה. הנתונים האלה אומרים אם אפשר לצמצם בהדרגה את הפיקוח.
אם הפיצ'ר הוא סוכן (agent) שמבצע פעולות במערכת ולא רק עונה על שאלות, הכללים מחמירים: הרשאות מצומצמות למה שהסוכן צריך, יומן של כל פעולה שביצע, ואישור אנושי לפעולות שאי אפשר לבטל, כמו שליחת מייל ללקוח, מחיקה או תשלום.
חשוב לתכנן גם נתיב נסיגה: מה המשתמש רואה כשהמודל לא בטוח או לא זמין. פיצ'ר טוב ממשיך לתפקד גם ברגע הזה, ולו בגרסה פשוטה. על עיקרון הגרסה הקטנה כתבנו גם בMVP: כמה קטן זה מספיק קטן, והוא נכון כפליים כשהתוצאה לא צפויה מראש. ואם אתם מתלבטים איפה AI עוזר גם בתהליך הפיתוח עצמו, יש על כך מאמר נפרד: AI בפיתוח תוכנה.
השורה התחתונה
AI מצדיק את עצמו כשיש בעיה אמיתית, נתונים אמיתיים, דרך למדוד איכות ומחיר טעות שאפשר לחיות איתו. כשחסר אחד מאלה, כלל פשוט או שינוי בתהליך עדיף וזול יותר. רצוי להתחיל בגרסה קטנה עם אדם בלולאה ולהרחיב לפי מה שהמדידה מראה. כדאי גם לעקוב מהיום הראשון אחרי עלות הקריאות, כך שהחשבון החודשי לא יהיה הפתעה.
אם יש לכם פרויקט שמערב AI ואתם רוצים לבנות אותו מהאפיון ועד ההפעלה, בית תוכנה כולל ניהול מוצר, פיתוח ועיצוב.
