ביקורת מערכת AI: איכות, ביצועים, אבטחה

ביקורת מערכת AI: היכן איכות התשובות נשברת

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

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

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

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

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

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

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

אפקט מדיד: איכות התשובות, מהירות, עמידות

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

איכות התשובות באחוזים

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

זמן התגובה תחת עומס

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

עמידות לכשלים

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

עומס על התשתית

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

צפיות לאחר עדכונים

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

פורמטים של ביקורת: בדיקה מהירה, ניתוח מלא, בקרה

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

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

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

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

כיצד נבנית העבודה: מהגדרת המשימה ועד מסירת הדוח

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

1. קריטריונים וגבולות הבדיקה. קובעים תרחישים, סף שגיאות מותר ומחלקות של תשובות אסורות. בפלט — מטריצת קבלה, שלפיה מתקבלת התוצאה.
2. איסוף מדדים על המצב הנוכחי. גובים השהיית תגובה, שיעור סירובים וסוגיהם, עלות עיבוד שאילתה אחת. זהו קו הבסיס שאליו משווים את כל המשך.
3. סכמת הבדיקה. מתארים אילו רכיבים מבודדים, היכן מחליפים מקורות חיצוניים, וכיצד משחזרים תנאים זהים בין הרצות.
4. מערך שאילתות בדיקה. אוספים קורפוס של פניות אמיתיות ומקרי קצה: קלט ריק, הקשר ארוך, הנחיות סותרות, ניסיון לעקוף איסורים.
5. תיקונים. מתקנים הנחיות מערכתיות, תיוג מסמכים, ספי חיתוך וכללי סינון. כל תיקון מלווה בהרצה — ההשפעה נראית, ולא משוערת.
6. הרצת בקרה. אותו מערך על גרסה חדשה, השוואה לקו הבסיס לפי מדדים ומחלקות כשלים; פערים מנותחים עד שהתמונה מתכנסת.
7. מסירת נהלים. מוסרים סכמת בדיקה, מערך שאילתות בדיקה, קונפיגורציה ויומן החלטות — לפיהם המערכת תתקבל בפעם הבאה, כבר בלעדינו.

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

חבילת מסמכים: מפת סיכונים, מדיניות גישה, נהלים

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

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

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

מקרה בוחן: איכות התשובות עלתה מ-61% ל-94% בתוך חודשיים

נקודת ההתחלה

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

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

מה שינו

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

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

התוצאה

בתוך חודשיים איכות התשובות עלתה מ-61% ל-94%, ושיעור הסירובים ירד מ-11% ל-1.8%. שיעור הפניות שהעוזר סגר בעצמו עלה מ-48% ל-79% — העומס על הקו הראשון ירד כמעט בחצי.

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

מה לעשות אם הפתרון כבר בפרודקשן ואסור לשנות אותו

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

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

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

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

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

ספקות טכניים נפוצים: פרטיות, תיוג, נפח נתונים

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

כיצד לבדוק פרטיות נתונים בלי להוציא החוצה?

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

האם הביקורת עצמה עלולה לגרום לדליפת נתונים דרך שאילתות?

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