פיצ'ר AI יכול להיראות מצוין בדמו ועדיין להיכשל ביום הראשון אצל לקוח. הוא עונה תשובה משכנעת אך לא נכונה, מצטט מקור לא רלוונטי, חושף מידע מחשבון אחר או מגיב לאט מדי ובעלות שאי אפשר לשלוט בה. במקרים רבים זו אינה רק בעיית מודל או prompt. זו תוצאה של דרישות מוצר שלא הגדירו מה הפיצ'ר רשאי לעשות, על איזה מידע הוא מסתמך ואיך נדע שהוא עובד. המדריך להגדרת דרישות מוצר שלפניכם מתמקד בדיוק בנקודות האלה.
כשמגדירים דרישות לפיצ'ר AI או RAG, לא מספיק לכתוב "המשתמש ישאל שאלה ויקבל תשובה". RAG הוא מנגנון שמאתר מידע רלוונטי ממקורות פנימיים ומעביר אותו למודל כדי לנסח תשובה. לכן הדרישה חייבת לכסות גם את איכות האיתור, גם את גבולות ההרשאה, גם את אופן הצגת המקורות וגם את דרך המדידה לאחר השחרור.
מדריך להגדרת דרישות מוצר: מתחילים מהסיכון
מסמך דרישות טוב אינו רשימת מסכים או תיאור כללי של חוויית משתמש. הוא החלטה משותפת של מוצר, R&D ואבטחת מידע על ההתנהגות שנחשבת תקינה במצבי אמת. לפני שמדברים על רכיבים טכניים, צריך להגדיר את הסיכון שהפיצ'ר אמור לצמצם.
לדוגמה, "לאפשר ללקוחות לשאול שאלות על המסמכים שלהם" הוא יעד עסקי. הוא אינו דרישת מוצר מספקת. דרישה מדויקת יותר יכולה להיות: משתמש בעל הרשאת צפייה בפרויקט יקבל תשובות המבוססות רק על מסמכים בפרויקטים שהוא מורשה לראות, עם קישורים למקורות ששימשו לתשובה. אם אין מקור מספיק, המערכת תאמר זאת ולא תשלים מידע.
ניסוח כזה כבר מייצר החלטות שאפשר לפתח, לבדוק ולתפעל. הוא גם חושף מוקדם שאלות שקשה לתקן לאחר ההשקה: האם הרשאה היא ברמת ארגון, חשבון, פרויקט או מסמך? מה קורה כאשר מסמך נמחק? האם תשובה יכולה להסתמך על מידע ישן? האם משתמש יכול לבקש סיכום של מאות מסמכים, ומה מגבלת העלות והזמן במקרה כזה?
להגדיר משתמש, פעולה והקשר
דרישות מוצר טובות מתארות תרחיש, לא רק יכולת. במקום לכתוב "המערכת תתמוך בשאלות", הגדירו מי שואל, על איזה מידע, באיזו פעולה עסקית ומה נחשב תוצאה שימושית.
במוצר SaaS, אותו ניסוח שאלה יכול לקבל תשובה שונה לפי החשבון, התפקיד, הפרויקט והזמן שבו נשאלה השאלה. לכן ההקשר אינו פרט יישומי שמוסיפים בסוף. הוא חלק מהדרישה עצמה. אם מנהל ארגון יכול לראות נתונים מכל הצוותים אך משתמש רגיל רואה רק את הפרויקט שלו, מנגנון האיתור חייב לקבל את הזהות וההרשאות לפני שהוא מחפש מסמכים, לא אחרי שהמודל כבר קיבל אותם.
כדאי לנסח לכל תרחיש את שלושת המרכיבים: המשתמש וההרשאות שלו, הפעולה שהוא מבצע, והתוצאה המצופה. למשל: "משתמש תמיכה בעל גישה לחשבון מסוים מבקש הסבר על תקלה. המערכת מחזירה תשובה ממסמכים ומקריאות שירות של אותו חשבון בלבד, ומציגה את המקורות שעליהם הסתמכה." זהו בסיס ברור לבדיקות ולמימוש.
דרישות שליליות הן חלק מהתוצר
בפיצ'רי AI, חשוב להגדיר במפורש גם מה אסור למערכת לעשות. אלו אינן הערות שוליים. הן דרישות פונקציונליות לכל דבר.
המערכת לא תציג תוכן שאין למשתמש הרשאה אליו. היא לא תנסח עובדה כאשר לא נמצאה ראיה מתאימה במקור מורשה. היא לא תציג citation שנראה תקין אך אינו תומך בטענה שנכתבה. והיא לא תשלח למודל נתונים רגישים שאינם נדרשים כדי לענות על הבקשה.
ההבחנה הזו חיונית כי מודל שפה בנוי להשלים טקסט בצורה סבירה. אם הדרישה אינה מגדירה מתי לעצור, הוא עשוי ליצור תשובה שנשמעת בטוחה. ההתנהגות הרצויה במצב של חוסר מידע אינה כישלון חוויית משתמש. לעיתים זו בדיוק התשובה האמינה ביותר: "לא מצאנו מקור מספיק כדי לענות על כך."
מפרידים בין דרישות מוצר להחלטות מימוש
מסמך דרישות אינו צריך לקבוע מראש באיזה מודל להשתמש, כמה chunks יהיו בכל מסמך או איזה vector database יותקן. אלו החלטות ארכיטקטורה. עם זאת, המסמך כן חייב להגדיר את התוצאה שהארכיטקטורה נדרשת לספק.
לדוגמה, "המערכת תשתמש ב-RAG" היא החלטת מימוש חלקית ולא דרישת מוצר. דרישה טובה יותר היא: "לכל טענה עובדתית בתשובה יוצג מקור זמין למשתמש, והמקור יוביל לתוכן שתומך בטענה." צוות הפיתוח יכול לבחור את דרך המימוש, אך אינו יכול לוותר על התוצאה.
הפרדה זו גם מאפשרת שינוי טכנולוגי בלי לשנות את ההבטחה למשתמש. אפשר להחליף מודל, לשנות שיטת אינדוקס או לשפר retrieval בלי לייצר אי-ודאות מול מוצר ולקוחות. מנגד, יש מקרים שבהם פרט טכני כן צריך להיכנס לדרישה: כאשר הוא משפיע ישירות על פרטיות, עלות, זמינות או זמן תגובה.
מגדירים איכות לפני שבונים מסך
אחת הטעויות היקרות היא להשיק פיצ'ר ואז לשאול אם התשובות טובות. בלי מדד מוגדר מראש, כל דיון הופך לאוסף צילומי מסך ודעות. משתמש אחד אומר שהתשובה מועילה, משתמש אחר מציג תשובה שגויה, ואין דרך לדעת אם שינוי שיפר או פגע במערכת.
לכן יש להגדיר evals - בדיקות שיטתיות של איכות התשובות - כחלק מהדרישות. סט evals הוא אוסף של שאלות ודוגמאות מייצגות, עם ציפייה ברורה לכל אחת: מהי התשובה הנכונה או אילו מקורות חייבים להופיע, איזה מידע אסור לחשוף, ומתי התוצאה הנכונה היא הימנעות מתשובה.
הסט צריך לכלול שאלות פשוטות, שאלות מעורפלות, שאלות שעלולות לחרוג מהרשאות ושאלות שאין להן תשובה במקורות. חשוב לשלב מידע עדכני ומידע ישן, מסמכים קצרים וארוכים, ושאלות שנשמעות דומות אך מתייחסות לחשבונות שונים. אחרת תקבלו מדד יפה שמכסה רק את הדמו.
אין מדד איכות אחד שמתאים לכל מוצר. לפעמים הדיוק העובדתי הוא העיקר; במקרים אחרים, מניעת חשיפת מידע היא תנאי סף, גם אם היא מגדילה את מספר התשובות הזהירות. לעיתים חשוב יותר לצטט מקור מדויק מאשר לספק ניסוח אלגנטי. הדרישה צריכה לקבוע את סדר העדיפויות הזה במפורש.
ביצועים ועלות הם דרישות מוצר, לא הפתעה תפעולית
תשובה איכותית שאורכת זמן רב מדי תישאר ללא שימוש. תשובה מהירה שמפעילה שרשרת קריאות יקרה מדי עלולה להפוך את הפיצ'ר לבעיה עסקית. לכן הגדירו טווחי תגובה צפויים לפי סוג פעולה, וכן מה קורה כאשר הפעולה מורכבת במיוחד.
אין מספר נכון לכל מוצר. חיפוש קצר במסמכים פנימיים שונה מסיכום של היסטוריית פעילות ארוכה. ההחלטה תלויה בשאלה אם המשתמש ממתין בתוך זרימת עבודה קריטית, אם ניתן להציג תוצאה חלקית, ואם הפעולה מתבצעת לעיתים נדירות או בהיקף גדול. העיקר הוא להגדיר גבול: מתי המערכת מחזירה תשובה קצרה יותר, מתי היא מבקשת לצמצם את השאלה, ומתי היא מבצעת עיבוד אסינכרוני במקום להשאיר את המשתמש מול טעינה ממושכת.
גם העלות דורשת הגדרה מעשית. יש לקבוע אילו פעולות דורשות אימות נוסף, אילו בקשות יוגבלו, ואילו נתונים נרשמים לצורך ניטור. לא חייבים לחשוף למשתמש את כל המורכבות, אבל הצוות חייב לזהות חריגות לפני שהן הופכות לחשבון בלתי צפוי או לפגיעה בביצועים.
מנסחים קריטריוני קבלה שאפשר לבדוק
קריטריון קבלה טוב מתאר התנהגות נצפית. "התשובות יהיו מדויקות" אינו ניתן לבדיקה ללא פרשנות. לעומת זאת, אפשר לקבוע שבתרחישי eval מוגדרים, תשובה תיחשב תקינה רק אם היא מבוססת על מקור מורשה, כוללת citation כאשר נדרש, ואינה מכילה טענה שאין לה תמיכה במקור.
גם הרשאות דורשות בדיקות קבלה מפורשות. בדקו משתמשים מאותו ארגון עם תפקידים שונים, משתמשים מארגונים שונים, גישה למסמך שההרשאה אליו השתנתה, ומסמך שנמחק לאחר שכבר נכנס לאינדקס. אם הבדיקה מסתיימת רק בשאלה "האם הצ'אט ענה?", אתם בודקים את החלק הקל.
כדאי להגדיר גם מה נרשם לצורכי אבחון: מזהה בקשה, זהות החשבון בהקשר מצומצם, מסמכים שנשלפו, החלטות סינון, זמן תגובה ועלות משוערת. הרישום חייב לכבד פרטיות ולא לשמור תוכן רגיש ללא צורך, אך בלעדיו קשה מאוד להבין מדוע התקבלה תשובה בעייתית.
תהליך עבודה שמקטין הפתעות
לפני פיתוח, אנו ממליצים לבצע מעבר קצר וממוקד על תרחישי השימוש, מקורות המידע, מודל ההרשאות ומקרי הקצה. לאחר מכן אפשר לתרגם את ההחלטות לדרישות, לקריטריוני קבלה ולסט evals ראשוני. רק אז נכון לבחור או לעדכן את רכיבי המימוש.
המסמך אינו צריך להיות ארוך כדי להיות שימושי. הוא צריך להיות מספיק מדויק כדי שמוצר, פיתוח ובדיקות יבינו את אותה התנהגות, ובמיוחד את מצבי הכישלון. במערכת AI חיה, שינוי קטן ב-retrieval, ב-prompt או במקור מידע יכול לשנות את התוצאה. לכן דרישות והערכה אינן שלב חד-פעמי לפני השקה, אלא מנגנון שמאפשר לשחרר שינויים בשליטה.
אם פיצ'ר AI או RAG כבר נמצא אצל לקוחות ואין לכם דרך ברורה להסביר מה הוא רשאי לענות, מאילו מקורות ולפי איזה מדד הוא נבדק, התחילו בסקירה של הדרישות הקיימות מול התנהגות הייצור. ב-DevCo Solutions אפשר לפנות דרך טופס יצירת הקשר באתר כדי לקבוע שיחת סקירה קצרה וממוקדת.