מתי להוסיף יכולות AI לאפליקציה שלכם — ומתי לוותר עליהן

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

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

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

למה רוב יכולות ה-AI המוברגות נכשלות בשקט

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

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

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

המבחן הכן: האם זו באמת בעיה ל-AI?

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

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

היכן AI באמת שייך באפליקציה

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

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

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

היכן להשאיר את ה-AI במנוחה

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

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

מפה מהירה: לבנות, לוותר, או לעשות מאוחר יותר

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

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

תזמון: גם יכולת AI טובה יכולה להתווסף מוקדם מדי

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

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

איך להוסיף יכולת AI בלי חרטות

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

1. 1
   כתבו את המשימה במשפט אחד

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

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

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

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

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

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

התמונה הגדולה: AI הוא כלי, לא אסטרטגיה

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

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

שאלות נפוצות