פיצ'ר AI יכול להיראות מצוין בדמו וליצור בעיה אמיתית שבוע אחרי ההשקה: הוא מחזיר תשובה משכנעת אך שגויה, מציג מידע מחשבון אחר, לא מספק מקור שאפשר לבדוק, או מגיב לאט ובעלות שלא מתאימה לשימוש יומיומי. עתיד פיתוח תוכנה בעזרת AI לא יוכרע לפי היכולת לייצר יותר קוד בפחות זמן. הוא יוכרע לפי היכולת של צוותי פיתוח לקחת אחריות על מה שקורה אחרי שהקוד פוגש משתמשים אמיתיים.
עבור CTO או מייסד SaaS, זו נקודה מעשית מאוד. AI מקצר חלקים מעבודת הפיתוח, אך הוא גם מגדיל את מספר ההחלטות שצריך לבקר: איזה מידע נכנס להקשר, מי רשאי לראות אותו, מתי המערכת צריכה להימנע מתשובה, ואיך יודעים אם שינוי שחרר בעיה לפרודקשן. קוד שנוצר מהר הוא יתרון רק כאשר המערכת סביבו נשארת נשלטת, מדידה ואמינה.
עתיד פיתוח תוכנה בעזרת AI: פחות הקלדה, יותר הנדסה
כתיבת קוד היא רק שכבה אחת בפיתוח מוצר. כלי AI כבר יכולים להציע פונקציות, בדיקות בסיסיות, שאילתות, תיעוד או תיקונים נקודתיים. בעבודה נכונה, זה חוסך זמן במשימות חוזרות ומאפשר למהנדסים להתקדם מהר יותר. אבל הצעה שנראית נכונה אינה בהכרח מתאימה לארכיטקטורה, למודל ההרשאות או לכללי העסק של המוצר.
הסיכון אינו רק באג תחבירי. AI עלול להציע קוד שעובד בתרחיש המקומי אך עוקף אימות הרשאות, מכפיל קריאות ל-API, חושף מידע ביומנים, או מטפל באופן שגוי בכשל חלקי של שירות חיצוני. אלה בעיות שלא תמיד מתגלות בבדיקת מסך ידנית. הן מתגלות כאשר עומס גדל, כאשר לקוח גדול מגיע, או כאשר נתונים אמיתיים מורכבים יותר מהנתונים ששימשו בפיתוח.
לכן תפקיד המפתח הבכיר אינו נעלם. הוא זז למקום שבו הערך גבוה יותר: פירוק דרישה מעורפלת להחלטות הנדסיות, הגדרת גבולות מערכת, בדיקת השלכות אבטחה ועלות, ובניית מנגנונים שמאפשרים לגלות כשל לפני שהלקוח מגלה אותו. גם מנהלי מוצר נדרשים לדיוק גבוה יותר. במקום להסתפק בבקשה כמו "להוסיף צ'אט חכם", צריך להגדיר מהי תשובה טובה, מתי אסור למערכת לענות, ומה המשתמש צריך לראות כדי לסמוך עליה.
מהירות אינה תחליף להבנת המערכת
כאשר AI מייצר קוד במהירות, קל לדלג על שאלות שנראות איטיות: האם יש בעלות ברורה על הנתונים? האם השירות הזה יכול להיכשל? האם אפשר לשחזר החלטה שהתקבלה לפני חודש? האם שינוי במבנה מסמך ישפיע על החיפוש? אלו אינן שאלות תיאורטיות. הן קובעות אם אפשר לתחזק את המוצר אחרי כמה גרסאות, כמה צוותים וכמה סוגי לקוחות.
במוצרים קיימים, הבעיה נפוצה במיוחד כאשר מוסיפים יכולת AI מעל מערכת ותיקה. יש כבר משתמשים, ארגונים, תפקידים, מסמכים, אינטגרציות וכללי גישה. מודל השפה אינו מכיר את ההקשר הזה מעצמו. הוא מקבל רק את המידע שהמערכת שולחת אליו. אם שכבת ההרשאות או איסוף המידע חלשים, ניסוח Prompt טוב לא יפתור את הבעיה.
RAG בפרודקשן הוא מערכת מידע, לא רק Prompt
RAG הוא תהליך שבו המערכת מאתרת מידע רלוונטי ממאגר פנימי ומעבירה אותו למודל השפה כדי לנסח תשובה. על הנייר זה נשמע פשוט: שואלים שאלה, מחפשים מסמכים ומקבלים תשובה. בפרודקשן, כל שלב דורש החלטות שאפשר לבדוק.
ראשית, צריך לדעת אילו מסמכים נכנסו למאגר, באיזו תדירות הם מתעדכנים, ואיך הם מפוצלים ליחידות חיפוש. פיצול גס מדי מחזיר הקשר רחב ולא מדויק. פיצול קטן מדי עלול להפריד בין משפט לתנאי שמסביר אותו. לאחר מכן צריך להפעיל סינון הרשאות לפני שהמידע מגיע למודל, ולא לסמוך על הוראה טקסטואלית שאומרת למודל לא לחשוף מידע.
שנית, תשובה צריכה להציג את המקורות שעליהם הסתמכה, כאשר הדבר מתאים לחוויית המוצר. ציטוט אינו קישוט. הוא מאפשר למשתמש לבדוק את המידע, ולצוות להבין אם הבעיה נבעה מאחזור מסמך לא נכון או מניסוח לא נכון של המודל. בלי מקורות, כל תשובה שגויה נראית כמו קופסה שחורה.
שלישית, המערכת צריכה לדעת לא לענות. אם לא נמצא מקור מספיק רלוונטי, אם למשתמש אין הרשאה למידע הנדרש, או אם השאלה אינה בתחום הנתמכת, תשובת ברירת המחדל צריכה להיות שקופה וזהירה. תשובה חלקית עם ניסוח בטוח עלולה להזיק יותר מהודאה ברורה בחוסר מידע.
הרשאות חייבות להיות חלק מהאחזור
במוצר SaaS מרובה לקוחות, הפרדת מידע אינה תוספת לשלב האחרון. היא תנאי בסיסי לאחזור. כל שאילתה צריכה לשאת הקשר ברור של ארגון, משתמש, תפקיד והרשאות רלוונטיות. הסינון צריך להתרחש לפני בחירת המסמכים, וגם בגישה לכל מקור שמוצג למשתמש.
יש מקרים שבהם מסננים לפי tenant בלבד, וזה מספיק. במערכות עם תיקי לקוחות, תפקידים פנימיים או מידע רגיש בתוך אותו ארגון, נדרשת רמת פירוט גבוהה יותר. הבחירה תלויה במודל הנתונים ובסיכון העסקי, אבל העיקרון קבוע: אין להניח שהמודל ישמור על גבולות שהמערכת לא אכפה טכנית.
Evals הופכים איכות מטענה לתהליך
אחת הבעיות הקשות במוצרי AI היא התחושה שהכול עובד עד שמשתמש שולח שאלה לא צפויה. הדרך לצמצם אותה היא evals - סט בדיקות מובנה שבוחן את איכות התשובות לאורך זמן. במקום לשאול באופן כללי אם הצ'אט "חכם", מגדירים שאלות מייצגות ובודקים מה אמור לקרות בכל אחת מהן.
סט כזה צריך לכלול שאלות שיש להן תשובה במקורות, שאלות עם ניסוחים שונים לאותו צורך, שאלות שאין להן תשובה, ושאלות שבהן המשתמש אינו מורשה לקבל את המידע. אפשר לבחון אם המסמך הנכון אותר, אם התשובה נתמכת במקור, אם הציטוט תקין, אם זמן התגובה סביר ואם העלות נשארת בגבול שהוגדר.
Evals אינם מבטיחים שלא יהיו טעויות. הם כן הופכים שינוי ממבצע המבוסס על תחושת בטן לשינוי שאפשר להשוות לגרסה הקודמת. אם מעדכנים מודל, Prompt, מנגנון חיפוש או מבנה מסמכים, אפשר לזהות אם השיפור במקום אחד פגע בתרחיש אחר. זה חשוב במיוחד בצוותים שבהם כמה אנשים משנים את אותה יכולת לאורך זמן.
הארכיטקטורה צריכה לנהל גם עלות וזמן תגובה
כל בקשה ל-AI היא שרשרת: אימות משתמש, איסוף הקשר, חיפוש, לעיתים קריאה לשירותים נוספים, פנייה למודל, עיבוד התשובה ותיעוד. עיכוב קטן בכל שלב מצטבר. גם העלות מצטברת כאשר שולחים יותר מדי טקסט, מפעילים מודל גדול לכל שאלה, או מבצעים קריאות כפולות ללא צורך.
אין תשובה אחת נכונה לכל מוצר. לפעמים נדרש מודל איכותי יותר עבור פעולה רגישה, ולפעמים אפשר להשתמש במסלול פשוט וזול לשאלות מידע קצרות. לעיתים cache יכול לקצר זמן ועלות, אך הוא מחייב מדיניות ברורה של תוקף, הפרדת משתמשים ומניעת החזרת מידע לא נכון. הבחירה צריכה להישען על נתוני שימוש אמיתיים, לא על הנחות.
כדאי למדוד לכל בקשה לפחות את זמן התגובה, כמות המסמכים שאותרו, עלות משוערת, תוצאת ההרשאה, המקורות שהוצגו ותוצאת הבדיקה כאשר היא קיימת. מדידה כזו אינה רק כלי תפעולי. היא מאפשרת לקבל החלטות מוצר: אילו שאלות משתמשים באמת שואלים, איפה המאגר חסר, ואילו תקלות דורשות טיפול בשכבת הנתונים ולא ב-Prompt.
כך משתנה תהליך הפיתוח בצוותים חזקים
בעתיד הקרוב, צוותי פיתוח לא יפסיקו לכתוב קוד. הם יעבדו אחרת. משימות קטנות יותר יתחילו מהצעה של AI, אך שינוי משמעותי ידרוש הגדרה מפורשת יותר של תנאי הצלחה, בדיקות אוטומטיות, סקירת קוד ויכולת תצפית בפרודקשן. ככל שקל יותר ליצור שינוי, כך חשוב יותר לדעת מה השינוי עשה בפועל.
ב-DevCo Solutions אנחנו רואים שהפער בין דמו לפרודקשן כמעט אף פעם אינו נובע רק מבחירת מודל. בדרך כלל הוא נמצא באחזור שלא מחזיר את המקור הנכון, בהרשאות שאינן מחוברות למסלול הנתונים, בחוסר בציטוטים, או בהיעדר evals שמתריעים על נסיגה באיכות. הטיפול הנכון מתחיל באבחון של המערכת הקיימת ובבניית סדר עדיפויות ברור, לא בהחלפה אוטומטית של כל הרכיבים.
הצעד הבא אינו להוסיף עוד כלי AI לתהליך. בדקו אם הפיצ'ר שכבר נמצא במוצר שלכם יכול להסביר מאיפה הגיעה כל תשובה, להוכיח שהרשאות נאכפות, ולמדוד איכות לפני שחרור גרסה. אם התשובה אינה ברורה, אפשר לפנות דרך טופס יצירת הקשר באתר ולקבוע שיחת סקירה קצרה של המערכת הקיימת.