רוב הפיילוטים של AI לא נכשלים — הם פשוט לא מסתיימים. מריצים הדגמה, היא נראית טוב על עשר דוגמאות, מישהו שואל "אבל מה עם המקרים המסובכים", ואין תשובה כי אף אחד לא הגדיר מה בודקים. המדריך הזה הוא תוכנית בדיקה עסקית: איך להגדיר פיילוט כך שבסופו יש טבלה עם מספרים, ומהטבלה נגזרת החלטה. הוא לא מסביר מה זה מודל שפה ולא איך בונים RAG — הוא מסביר מה בעל התהליך צריך לדרוש לפני שמישהו מתחיל לבנות.
מגדירים פעולה ומשתמש — ואת החלופה הקיימת
פיילוט בודק פעולה אחת שמשתמש אחד מבצע, ומשווה אותה לאיך שהיא מתבצעת היום. שלושת החלקים חייבים להיות כתובים במשפט אחד לפני שממשיכים:
| חלק | שאלה | דוגמה (המחשה) |
|---|---|---|
| הפעולה | מה בדיוק המערכת תעשה? מענה מתוך ידע, סיוע בניסוח, עיבוד מסמך, או החלטה מוגדרת? | "לענות על שאלות של נציגי שירות על נהלי החזרות, מתוך מסמכי הנהלים" |
| המשתמש | מי מבצע את הפעולה, באיזה הקשר, וכמה פעמים? האם הוא יודע לשפוט תשובה? | "נציג שירות בשיחה עם לקוח, כמה פעמים בשעה; מכיר את התחום ויזהה תשובה שגויה" |
| החלופה הקיימת | איך זה קורה היום, כמה זמן זה לוקח, ומה הטעות הנפוצה? | "הנציג מחפש במסמך PDF או שואל עמית; לוקח כמה דקות; הטעות הנפוצה — נוהל ישן" |
לפני שממשיכים לפיילוט, שאלה אחת: האם החלופה הקיימת ניתנת לשיפור בלי AI? חיפוש טוב יותר במסמכים, מסמך נהלים מעודכן, או טופס מובנה פותרים לפעמים את אותה בעיה בזול ובאופן צפוי. ארבע השאלות שמכריעות אם AI מתאים לצורך — איכות נדרשת, נתונים, עלות וחלופה — מפורטות בעמוד השירות. שילוב AI במוצר — האם AI מתאים לצורך, ומה כולל הפיילוט
מה ייחשב הצלחה? איכות, זמן, שימוש ועלות
תנאי ההצלחה נקבעים לפני הפיילוט, בכתב, עם בעל התהליך — האדם שאחראי על התוצאה העסקית, לא על הטכנולוגיה. ארבעה מדדים, ולכל אחד יעד שבעל התהליך ממלא:
| מדד | איך מודדים | היעד (ממלא בעל התהליך) |
|---|---|---|
| איכות | שיעור התשובות בסט התרחישים שאדם מוסמך היה מאשר כנכונות ושלמות; בנפרד — שיעור התשובות השגויות שנאמרו בביטחון | "לפחות ___ מתוך ___ תרחישים מאושרים; לא יותר מ-___ תשובות שגויות בביטחון" |
| זמן | זמן הפעולה עם המערכת לעומת החלופה הקיימת, כולל הזמן לבדוק את התשובה | "קצר מהחלופה ב-___ לפחות, כולל בדיקה" |
| שימוש | כמה מהמשתמשים בקבוצת הניסיון חוזרים להשתמש אחרי השבוע הראשון, בלי שמבקשים מהם | "___ מתוך ___ משתמשים פעילים בשבוע השלישי" |
| עלות | עלות השימוש (קריאות למודל, שליפה, אחסון) לכל פעולה, ותחזית לפי נפח הפעולות החודשי | "לא יותר מ-___ לפעולה; לא יותר מ-___ לחודש בנפח מלא" |
נתוני בדיקה וגבולות
הפיילוט נבדק על סט תרחישים — אוסף של מקרים אמיתיים או מייצגים, עם התשובה או התוצאה שאדם היה מקבל. הסט נבנה לפני שבונים את המערכת, על ידי מי שמכיר את התחום ולא על ידי מי שבונה, ומכיל בכוונה את מה שהדגמות נוטות להשמיט:
- המקרים הרגילים — רוב הסט, מתפלגים כמו השימוש האמיתי.
- מקרי קצה — ניסוח לא ברור, שאלה שנוגעת בשני נהלים, מידע סותר במקורות.
- שאלות שאין להן תשובה במקורות — התשובה הנכונה היא "לא יודע" או הפניה לאדם, וזה נבדק כמו כל תרחיש אחר.
- ניסיונות להוציא מהמערכת מה שלא מותר — מידע של לקוח אחר, פעולה ללא הרשאה.
- חלק מהסט נשמר בצד ולא נחשף לבונים עד הבדיקה הסופית — אחרת המערכת "לומדת" את המבחן.
לצד הסט מגדירים גבולות: לאילו מקורות המערכת רשאית לגשת, ובאיזו הרשאה — אותה הרשאה של המשתמש שמולו היא פועלת, לא יותר; אילו נתונים מותר להעביר לספק המודל ואילו לא (ומה המסלול החוזי שלו לגבי שימוש בנתונים); מה נשמר בלוגים ולכמה זמן. אם הנתונים כוללים מידע אישי, ההגדרות האלה נסגרות עם מי שאחראי על פרטיות בארגון לפני הפיילוט ולא אחריו.
מה עושים כשהמערכת נכשלת? אי-ודאות, הסלמה ואישור פעולה
מערכת AI תיכשל בחלק מהמקרים — זו לא שאלה של אם אלא של איך. ההבדל בין פיילוט שאפשר לאשר לפיילוט שמסוכן להמשיך הוא מה המערכת עושה ברגע הכשל. שלושה מנגנונים, וכל אחד נבדק בסט התרחישים:
| מנגנון | מה המערכת עושה | מה בודקים |
|---|---|---|
| אי-ודאות | כשאין תשובה במקורות או כשהמקורות סותרים — אומרת זאת, מציגה את המקור שמצאה, ולא משלימה מהדמיון | כל השאלות חסרות התשובה בסט: כמה מהן קיבלו "לא יודע" וכמה קיבלו תשובה מומצאת |
| הסלמה לאדם | במקרים מוגדרים — נושא רגיש, לקוח כועס, שאלה מחוץ לתחום — מעבירה לאדם עם סיכום של מה שכבר נאמר | התרחישים שמוגדרים להסלמה אכן הוסלמו; הסיכום שהועבר נכון ושלם |
| אישור פעולה | כל פעולה שמשנה נתונים, שולחת הודעה ללקוח או מחייבת כסף — מוצגת לאדם לאישור לפני ביצוע, לפחות בפיילוט | אף פעולה רגישה לא בוצעה בלי אישור; הפעולות שהוצעו היו נכונות |
דף ניסוי — תבנית עם קריטריוני קבלה
כל מה שלמעלה מתכנס לדף אחד, שנחתם על ידי בעל התהליך לפני שמתחילים. זו התבנית; הדוגמאות ממולאות להמחשה בלבד.
| סעיף | תוכן (דוגמה) |
|---|---|
| פעולה · משתמש · חלופה | מענה על שאלות נהלי החזרות · נציג שירות בשיחה · חיפוש ב-PDF או שאלה לעמית |
| מקורות מותרים | מסמכי הנהלים בגרסה הנוכחית בלבד; ללא גישה לנתוני לקוחות |
| קבוצת ניסיון ומשך | ___ נציגים ממשמרת אחת, ___ שבועות |
| סט תרחישים | ___ שאלות אמיתיות מתועדות (מאושרות לשימוש) + ___ מקרי קצה + ___ שאלות ללא תשובה במקורות; ___ מהן שמורות לבדיקה סופית |
| קריטריוני קבלה | איכות: ≥ ___ מאושרות, ≤ ___ שגויות בביטחון · זמן: קצר מהחלופה ב-___ · שימוש: ___ מתוך ___ בשבוע 3 · עלות: ≤ ___ לפעולה |
| קלט לדוגמה | "לקוח קנה לפני 40 יום ורוצה להחזיר, יש קבלה" |
| פלט מצופה | ציטוט הסעיף הרלוונטי, תשובה אם ההחזרה אפשרית לפי הנוהל, והפניה לסעיף החריגים — עם קישור למסמך |
| כשל לדוגמה (שנבדק) | "מה המדיניות למוצרים שנקנו באתר של השותף?" — אין על זה נוהל. תשובה נכונה: "אין לי מידע על זה בנהלים, להעביר למנהל משמרת". תשובה כושלת: הסקה ממדיניות אחרת. |
| פעולות שדורשות אישור | אין — בפיילוט המערכת רק עונה, לא מבצעת |
| מי שופט, מי מחליט | שופט: ראש צוות שירות על כל תרחיש · מחליט: מנהל השירות (בעל התהליך), במועד קבוע בסוף הפיילוט |
ההחלטה אחרי הפיילוט: להמשיך, לתקן, לצמצם או להפסיק
הפיילוט נגמר בתאריך שנקבע, לא כשהתוצאות טובות. בתאריך הזה בעל התהליך מקבל אחת מארבע החלטות, לפי הטבלה שהתקבלה:
| החלטה | מתי | מה הצעד הבא |
|---|---|---|
| להמשיך | כל ארבעת הקריטריונים עברו, ומנגנוני הכשל עבדו בכל התרחישים שנועדו להם | הגדרת מה נדרש לפרודקשן — הרשאות לכל המשתמשים, ניטור, תקציב שימוש, תהליך עדכון ותמיכה — כפרויקט נפרד עם היקף משלו |
| לתקן | האיכות קרובה ליעד, והכשלים מתרכזים בדפוס מזוהה (מקור חסר, סוג שאלה אחד) | סבב אחד קצר ומוגדר — מה מתקנים, ובדיקה חוזרת על החלק השמור של הסט. לא "עוד קצת" |
| לצמצם | המערכת טובה בחלק מהתרחישים וגרועה באחרים, וההפרדה ביניהם ברורה | מגבילים את התחום למה שעובד (למשל רק נהלים, לא תמחור), ומסלימים את השאר לאדם כברירת מחדל |
| להפסיק | האיכות רחוקה מהיעד, או שהעלות לפעולה גבוהה מהחלופה, או שהמשתמשים לא חזרו — ואין דפוס שאפשר לתקן | מתעדים מה נבדק ומה נמצא, כדי שהשאלה הבאה תתחיל מכאן ולא מאפס. זו תוצאה לגיטימית של פיילוט — זו הסיבה שעושים אותו |
מה אנחנו עושים בשלב הזה
לפני שמשלבים AI במוצר אנחנו מגדירים איתכם את דף הניסוי: פעולה, משתמש וחלופה; תנאי הצלחה עם בעל התהליך; סט תרחישים וגבולות; והתנהגות בכשל. אחר כך בונים את הפיילוט בהיקף המוגדר, מריצים אותו עם קבוצת הניסיון, ומגישים את הטבלה — תרחישים, ציון, עלות — שעליה מתקבלת ההחלטה. מה כולל הפיילוט, איך בודקים איכות וכשלים, ומה נדרש כדי להפוך אותו למוצר יציב — בעמוד השירות, כולל מה בדיוק בנינו במקרים שפורסמו. שילוב AI במוצר עם תהליך בדיקה ברור
כשה-AI הוא חלק ממוצר חדש שעוד לא יצא — הפיילוט הוא חלק מהגדרת הגרסה הראשונה, וההחלטה אחריו קובעת אם היכולת נכנסת ל-MVP או נדחית. כשהוא מתווסף למערכת עסקית קיימת — הוא נכנס לאותה אנטומיה של מערכת: הרשאות, נתונים, אינטגרציות וניטור. פיתוח MVP — איך מגדירים ובונים גרסה ראשונה
מה מערכת עסקית כוללת מעבר למסכים — ולאן יכולת AI נכנסת בה — במקטע האנטומיה בעמוד פיתוח התוכנה. פיתוח תוכנה בהתאמה אישית — אנטומיה של מערכת