התשובה הקצרה: אל תתחילו מהמודל או מהכלי. התחילו מהחלטה או מתהליך שהארגון רוצה לשפר. פרויקט AI טוב לא נמדד לפי כמה מרשים הדמו, אלא לפי היכולת שלו להוריד זמן עבודה, לשפר איכות, לצמצם טעויות או לאפשר שירות שלא היה אפשרי קודם.
הגדירו בעיה שאפשר לראות ולמדוד
“אנחנו רוצים להשתמש ב‑AI” אינה הגדרת פרויקט. לעומת זאת, “צוות השירות משקיע בכל שבוע עשרות שעות בחיפוש תשובות בין מסמכים” כבר מגדיר משתמש, פעולה וכאב.
לפני שמפתחים, כתבו תשובה לארבע שאלות:
- מי מבצע היום את העבודה?
- מה נכנס לתהליך ומה אמור לצאת ממנו?
- איפה נוצר העיכוב, הסיכון או חוסר העקביות?
- איזה שינוי ייחשב הצלחה לאחר חודש של שימוש?
המדד לא חייב להיות פיננסי. הוא יכול להיות זמן טיפול, שיעור תשובות עם מקור, מספר פעולות ידניות או אחוז המקרים שמגיעים לאישור אנושי.
בדקו את המידע לפני שבודקים מודל
בפרויקטים רבים, הבעיה אינה יכולת המודל אלא מצב המידע. מסמכים כפולים, הרשאות לא ברורות, פורמטים משתנים ושפה פנימית לא מתועדת יפגעו גם במודל מצוין.
מיפוי מידע ראשוני צריך לכלול:
- מקורות המידע והבעלים שלהם
- רמת הרגישות וההרשאות
- תדירות העדכון
- דוגמאות למקרים פשוטים ומקרי קצה
- דרך לבדוק אם התוצאה נכונה
אם אין דרך להעריך תשובה, אין עדיין דרך בטוחה לתת למערכת שבנינו לפעול. הכי קל לפתור KPIs שבדיוק מראים מה שאנחנו רוצים שיראו, אבל האם הם באמת נכונים? האם הם משקפים את המציאות? במקרים רבים נשקיע יותר זמן בלסדר ולארגן את המידע הארגוני מאשר בלבנות את המערכות או המודלים עצמם.
בנו תרחיש שמוביל להחלטה
ניסוי טוב עונה על שאלה מוגדרת: האם ניתן לזהות את סוג המסמך בדיוק מספק? האם מערכת RAG מחזירה תשובה עם מקור נכון? האם סוכן יכול להשלים משימה בלי לרדת מתחת לסף טעויות מינימלי? לפני שמחליטים לפתח, כדאי לבדוק גם מתי מערכת מותאמת עדיפה על מוצר מדף.
הגדירו מראש שלוש תוצאות אפשריות: ממשיכים, משנים כיוון או עוצרים. עצירה אחרי ניסוי קטן היא תוצאה טובה יותר מהמשך אוטומטי לפרויקט יקר שאין לו בסיס. כך עבדנו גם במחקר Evoke, שבו כל איטרציה של המודל נבדקה בבדיקה עיוורת מול ביצועי מדיה.
השאירו אדם בלולאה במקום הנכון
לא כל שלב צריך אוטומציה מלאה. לעיתים הערך הגדול נמצא בהכנת טיוטה, מיון, איתור חריגה או איסוף מידע - בזמן שאדם מאשר את הפעולה הסופית.
כדאי לסווג פעולות לפי רמת הנזק האפשרית. פעולה הפיכה וזולה יכולה לקבל יותר אוטונומיה. פעולה שמשפיעה על כסף, לקוח או מידע רגיש צריכה בקרה, תיעוד ודרך ביטול. במערכת Agentic Selling, למשל, מתג כיבוי כללי ומצב בדיקה מונעים הודעות שנשלחות בטעות.
חשבו על פרודקשן כבר בניסוי
גם אב טיפוס צריך לקחת בחשבון: איזה מידע נכנס, איזה כלי הופעל, מה יצא ומי אישר. בלי לוגים ותצפיות קשה להבין אם המערכת משתפרת או רק נראית פעילה.
המעבר לפרודקשן דורש גם בעלות: מי מטפל בשגיאות? מי מנטר תקלות? מי מעדכן מקורות ידע? מי מאשר שינוי בפרומפט או במודל? התשובות האלה הן חלק מהמוצר, לא בירוקרטיה שמוסיפים בסוף. אפשר לראות איך ההחלטות האלה נראות בפועל במערכת Galila ובמעבר של פלטפורמת Amazon Arbitrage לפרודקשן, או לבחון מה כולל פיתוח תוכנה מותאמת אישית עם AI.
מסגרת החלטה פשוטה
התחילו בפרויקט כאשר הבעיה חוזרת, המידע נגיש, יש דרך למדוד תוצאה וקיים בעל תפקיד שיקבל אחריות. דחו את הפרויקט כאשר התהליך עצמו עדיין לא מוסכם, אין גישה למידע או שהצלחה מוגדרת רק כ“חדשנות”.
בצורה הזו נוכל לפתח ולהטמיע פתרונות AI רק כאשר הארגון מוכן אליהם באמת - עם מידע אמין ומאורגן, הרשאות, רגולציות וחלוקת תפקידים מסודרת.