מפתחי AI: איך בוחרים צוות לפיתוח AI שעובד בתוך מוצר?

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

מה ההבדל בין מתכנתי AI לבין חיבור למודל?

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

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

איך מגדירים הצלחה לפני הדמו?

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

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

אילו גבולות צריך להגדיר לסוכן?

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

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

מה כדאי לבקש בהצעת הפיתוח?

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

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