קודם מפרידים בין שני מושגים
AI for Testing
שימוש במודלים ובכלים חכמים כדי לנתח דרישות, להציע בדיקות, ליצור נתונים, לסייע בכתיבת קוד, לזהות דפוסים בכשלים ולתעד תוצאות.
Testing AI Systems
בדיקת מוצר שמבוסס על Machine Learning, Generative AI או LLM. כאן בודקים לא רק פונקציונליות, אלא גם איכות תשובה, עקביות, בטיחות, הטיות, פרטיות והתנהגות לאורך זמן.
אלו תחומים משלימים, אבל הם דורשים שאלות שונות. כלי AI יכול לעזור לכתוב בדיקה רגילה של checkout. לעומת זאת, אם המוצר הוא צ'אט שממליץ ללקוח על פעולה פיננסית, צריך לבדוק את ההמלצה עצמה, את המקורות שלה, את הגבולות שלה ואת הנזק האפשרי מתשובה שגויה.
איך משתמשים ב־AI בתהליך הבדיקות
ניתוח דרישות ומיפוי סיכונים
אפשר להזין תיאור פיצ'ר ולבקש מהמודל לזהות הנחות, שאלות פתוחות, מקרי קצה ותלויות. התוצאה היא נקודת פתיחה לדיון, לא מסמך מאושר. המודל אינו מכיר את כללי העסק, היסטוריית התקלות או מגבלות המערכת, אלא אם נתנו לו את המידע הנכון.
יצירת תרחישים ונתוני בדיקה
AI שימושי ליצירת וריאציות: גבולות מספריים, קלט רב לשוני, פורמטים שגויים, קומבינציות הרשאות ונתוני JSON. לאחר היצירה בודקים שאין מידע אישי, שהדוגמאות חוקיות ושהכיסוי מתאים לסיכון. עשר וריאציות רלוונטיות עדיפות על מאה תרחישים כלליים.
סיוע בכתיבת אוטומציה
מודל יכול ליצור fixture, לנסח assertion, להמיר בדיקה מ־Selenium ל־Playwright או להסביר שגיאת TypeScript. הוא עלול גם להמציא מתודה, להשתמש ב־selector שביר, להסתיר race condition או לבדוק טקסט שאינו הדרישה העסקית. קוד שנוצר עם AI חייב לעבור review, הרצה ותחזוקה כמו כל קוד אחר. הרחבה מעשית נמצאת במדריך בדיקות אוטומציה.
ניתוח לוגים וכשלים
כאשר יש stack traces, network logs ותוצאות רבות, AI יכול לקבץ כשלים דומים, לסכם סימנים חוזרים ולהציע כיווני חקירה. אסור לשלוח למודל ציבורי סודות, מידע אישי, tokens או קוד רגיש. כדאי גם לשמור קישור לראיות המקוריות כדי שהסיכום לא יחליף את הנתונים.
הדרך הנכונה למדוד כלי AI אינה כמה טקסט הוא יצר, אלא כמה זמן חקירה הוא חסך בלי להגדיל את הסיכון לטעות.
איך בודקים מערכת AI או LLM?
מערכת רגילה שואפת לתת אותה תוצאה לאותו קלט. מערכת AI עשויה להחזיר ניסוחים שונים, להיות רגישה להקשר ולהשתנות לאחר החלפת מודל או עדכון נתונים. לכן עוברים מבדיקה של תשובה בודדת להערכה של טווח התנהגויות, מדדים וסיכון.
| סיכון | מה בודקים | דוגמת גישה |
|---|---|---|
| הזיות | עובדות, ציטוטים ומקורות שהמערכת ממציאה | מערך שאלות עם אמת ידועה, בדיקת מקורות וסף לסירוב |
| הטיה והוגנות | פער בתוצאה בין קבוצות או ניסוחים שקולים | השוואת קבוצות, counterfactual tests וביקורת מומחים |
| Prompt injection | ניסיון לעקוף הוראות ולחשוף מידע או כלים | קלט עוין, red teaming ובדיקת הרשאות בפועל |
| דליפת מידע | חשיפת PII, סודות או תוכן שאינו מורשה | סיווג מידע, canary data ובדיקת isolation בין משתמשים |
| Drift | ירידה באיכות עקב שינוי נתונים, מודל או התנהגות משתמשים | גרסת בסיס, מדדים קבועים וניטור לאורך זמן |
| ביצועים ועלות | זמן תגובה, זמינות, tokens ועלות לתרחיש | עומסים מייצגים, percentiles ותקציב עלות |
Oracle problem: מי קובע מה נכון?
במוצרים רבים אין תשובה אחת מושלמת. לכן בונים rubric שמגדיר ממדים כמו דיוק, רלוונטיות, שלמות, סגנון ובטיחות. חלק מהבדיקות יכולות להיות דטרמיניסטיות, למשל קיום disclaimer או איסור חשיפת מספר חשבון. אחרות דורשות הערכה אנושית או LLM as a Judge. גם שופט מבוסס מודל צריך כיול מול בני אדם, בדיקת עקביות וגרסה קבועה.
בדיקות דאטה ומודל
איכות הקלט משפיעה ישירות על המערכת. בודקים שלמות, כפילויות, ערכים חסרים, ייצוג קבוצות, data leakage ושינוי בהתפלגות. במודלים מסווגים משתמשים במדדים כגון precision, recall ו־false positive rate לפי ההשפעה העסקית. במערכת GenAI בונים evaluation set שמייצג משימות אמיתיות, שפות, משתמשים ומקרי קצה.
אבטחה, פרטיות ו־red teaming
לא מסתפקים בבקשה מהמודל להיות בטוח. בודקים את כל המערכת: הרשאות לכלים, גישה למקורות, סינון קלט ופלט, isolation, audit logs ואפשרות לעצור פעולה מסוכנת. Red teaming מנסה בכוונה לעקוף מגבלות באמצעות ניסוחים עקיפים, קלט רב שלבי, מסמכים זדוניים ושילוב שפות.
תהליך עבודה מעשי לבדיקת פיצ'ר AI
מגדירים מטרה ונזק
מה המערכת אמורה לעזור לעשות, למי, ומה יקרה אם היא טועה, מסרבת או פועלת ללא הרשאה.
מפרקים את הארכיטקטורה
מודל, prompt, retrieval, מקורות מידע, כלים, filters, APIs ושכבת UI. כל חלק יוצר תקלות אחרות.
בונים evaluation set
דוגמאות רגילות, גבולות, קלט עוין, שפות, משתמשים ותרחישים מהייצור. שומרים גרסה כדי להשוות בין שינויים.
מגדירים מדדים וספים
דיוק, בטיחות, שיעור סירוב, latency ועלות. סף צריך להתחבר לסיכון ולא למספר שנראה טוב בדוח.
משלבים הערכה אוטומטית ואנושית
חוקים קבועים למה שאפשר, מודל שופט לאחר כיול, וביקורת מומחה לתשובות מורכבות או בסיכון גבוה.
בודקים שינוי מול baseline
כל החלפת prompt, מודל, מקור או tool יכולה לשפר מדד אחד ולפגוע באחר. משווים על אותו מערך נתונים.
מנטרים בייצור
אוספים משוב, דגימות כשל, drift, latency ועלות. נתוני ייצור חוזרים למערך ההערכה לאחר ניקוי והגנת פרטיות.
מה צריך ללמוד כדי לעבוד ב־AI Quality?
- יסודות QA, ניהול סיכונים ותכנון בדיקות.
- API, JSON, SQL, logs ויכולת לחקור מערכת מעבר למסך.
- Python או TypeScript ברמה שמאפשרת לבנות evaluations ואוטומציה.
- מושגי ML בסיסיים: dataset, training, inference, classification, precision, recall ו־drift.
- מושגי GenAI: prompts, context, embeddings, RAG, tool calling ו־guardrails.
- אבטחת AI: prompt injection, data leakage, permissions ו־red teaming.
- תקשורת: יכולת להסביר מגבלה, מדד וסיכון לאנשי מוצר ופיתוח.
פרויקט תיק עבודות טוב יכול להיות evaluation קטן למערכת שאלות ותשובות. מגדירים 30 עד 50 משימות, rubric, תוצאות בסיס, בדיקות אבטחה ודוח קצר שמסביר את הממצאים. המטרה אינה להציג מודל מושלם. המטרה היא להראות שיטת עבודה שמחברת בין דרישה, ראיה וסיכון.
שאלות נפוצות על AI ו־QA
איך AI משתלב בעבודת QA?
AI יכול לסייע בניתוח דרישות, הצעת מקרי קצה, יצירת נתוני בדיקה, כתיבת שלד לאוטומציה, סיכום לוגים ומיון כשלים. הוא מאיץ עבודה, אבל אינו מחליף הבנת מוצר, בדיקת עובדות וביקורת אנושית.
מה ההבדל בין AI for Testing לבין Testing AI?
AI for Testing הוא שימוש בכלי AI כדי לשפר את תהליך הבדיקות. Testing AI הוא בדיקת המערכת החכמה עצמה, כולל איכות התשובות, אמינות, הטיות, אבטחה, פרטיות ושינוי התנהגות לאורך זמן.
איך בודקים מערכת שאין לה תמיד תשובה אחת נכונה?
מגדירים קריטריונים, קבוצות נתונים ומדדים במקום להסתמך על תשובה אחת. משלבים בדיקות אוטומטיות, הערכה אנושית, דוגמאות גבול, השוואה לגרסת בסיס וניטור בסביבת הייצור.
האם צריך להיות מומחה למידת מכונה כדי לבדוק AI?
לא כדי להתחיל, אבל צריך להכיר מושגים כמו training data, inference, probabilistic output, precision, recall, drift ו־LLM evaluation. ככל שהסיכון במוצר גבוה יותר, נדרשת הבנה עמוקה יותר ושיתוף פעולה עם מומחי נתונים ואבטחה.