מערכת AI לניבוי פגמים בקוד עם AUC-ROC 0.85+

חיזוי פגמים בקוד: היכן נשברת האיכות

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

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

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

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

חיזוי פגמים בקוד סוגר בדיוק את הפער הזה — מודל עם AUC-ROC גבוה מ-0.85 מדרג קבצים ומודולים לפי הסתברות לשגיאה, ותשומת הלב של הסוקרים עוברת למקום שבו היא משתלמת.

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

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

מה נותן המודל: אפקט מדיד על הסקירה והשחרורים

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

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

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

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

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

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

אפשרויות הטמעה: צינור, סקירה, הרצה ידנית

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

מגבלות משותפות

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

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

שלבי ההטמעה: מביקורת המאגר ועד למסירה

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

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

מה נשאר במאגר לאחר ההטמעה

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

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

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

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

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

הודות למה הושגה התוצאה

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

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

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

במה נבדל מודל מאומן מכללים סטטיים?

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

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

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

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

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

ספקות טכניים: איכות התיוג והתראות שווא

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

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

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

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

איזו רמה של התראות שווא מקובלת?

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

מה יקרה כשסגנון הקוד והתיוג ישתנו?

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

נדון במשימה: מה נדרש מכם כדי להתחיל

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

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

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