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