בשנת 2024, צוות של דלויט אוסטרליה הגיש דוח ממשלתי בעלות של 440,000 דולר. הכל היה נראה מושלם, עד שבבדיקה מעמיקה התגלה פרט קטן: רוב הציטוטים והמקורות האקדמיים בדוח הומצאו לחלוטין על ידי מודל ה-GPT-4o שבו השתמשו לכתיבתו.
הסיפור הזה הוא לא מקרה בודד. מחקרים מראים ש"הזיות AI" (AI Hallucinations) עולות לחברות מיליארדי דולרים בשנה. חברות תעופה חטפו תביעות ענק בגלל צ'אטבוטים שהמציאו נהלי החזר כספי, ומערכות ניתוח מבוססות AI הציגו תובנות שגויות לחלוטין רק בגלל ניסוח קצת שונה של השאלה.
עבורנו, אנשי ה-QA והבודקים הידניים, המציאות הזו משנה את חוקי המשחק. אם בעבר ידענו בדיוק מה התוצאה הצפויה (Expected Result) לכל קלט, היום אנחנו נדרשים לבדוק מוצרים נון-דטרמיניסטיים (Non-deterministic) – מערכות שבהן תכניסו את אותו הקלט פעמיים, ותקבלו שתי תוצאות שונות לחלוטין, ששתיהן יכולות להיות נכונות (או שגויות) באותה המידה.
אז איך לעזאזל בודקים ידנית מערכת שאין לה "תשובה נכונה אחת" בספר?
למה כלי ה-QA המסורתיים שלנו פשוט נשברים?
הארכיטקטורה של בדיקות תוכנה מסורתיות בנויה על חוזה פשוט: קלט X תמיד יפיק פלט Y. הבודק האוטומטי כותב Assertion, והבודק הידני מסמן $V$ או $X$ לפי תסריט הבדיקה (Test Case).
במערכות AI, החוזה הזה מבוטל. הנה 4 סיבות למה שיטות העבודה הישנות שלנו כבר לא עובדות:
- בעיית ה-Pass/Fail הדינמי: מודל שפה יכול לג'נרט עשרות תשובות שונות לאותו פרומפט. שתיים מהן יכולות להיות זהות במשמעות שלהן (סמנטיקה) אך שונות לחלוטין במילים שלהן. איך מסמנים על זה Pass?
- מרחב קלטים אינסופי: בבדיקת טופס הרשמה, אנחנו יודעים מהם מקרי הקצה (שדה ריק, תווים מיוחדים). בפרומפט חופשי של משתמש, מרחב האפשרויות הוא אינסופי. אי אפשר לכסות אותו בתסריטים מראש.
- רגישות קיצונית לניסוח (Prompt Sensitivity): שינוי של מילה אחת, או הוספת המשפט "תחשוב צעד אחר צעד", יכולים לשנות לחלוטין את התשובה של המודל.
- תופעת ה-Model Drift (זחילה): המערכת יכולה להשתנות גם בלי שנגענו בשורת קוד אחת. עדכון שקט של ספק ה-AI (כמו OpenAI או Google) יכול לשנות את התנהגות המודל בן לילה באזור הפרודקשן.
המדריך לבודק הידני: כך תבנו אסטרטגיית בדיקה למערכות AI
כדי לא ללכת לאיבוד, אנחנו צריכים להחליף את המושג "תוצאה צפויה" במושג חדש: טווח התנהגות מקובל. הנה תוכנית העבודה הפרקטית לבדיקות ידניות בעידן החדש:
1. הגדרת קריטריוני קבלה (Acceptance Criteria) מבוססי מימדים
במקום לחפש מילה ספציפית, הגדירו מראש מול מנהל המוצר מהם המדדים לאיכות הפלט. בדקו את התשובה לפי המימדים הבאים:
- דיוק סמנטי: האם השורה התחתונה נכונה עובדתית?
- טון ושפה: האם המודל שומר על קול המותג (למשל: מקצועי, מניע לפעולה, מעצים)?
- בטיחות (Safety): האם המודל פולט מידע פוגעני, מטעה או חושף נתונים רגישים?
- שלמות (Completeness): האם המודל ענה על כל חלקי השאלה?
2. טקטיקת "הרצה מרובה" (Multi-run Testing)
בדיקה חד-פעמית של פרומפט היא חסרת משמעות סטטיסטית. כבודקים ידניים, עלינו להריץ את אותו תסריט בדיוק לפחות 3 עד 5 פעמים ברצף.
- האם התשובות נשארות באותו טווח איכות?
- האם יש קפיצות קיצוניות בטון או בנכונות המידע?
- רשמו לעצמכם את מידת העקביות של המערכת.
3. בדיקות חוסן ופרומפטים זדוניים (Red Teaming)
זה המקום שבו הבודק הידני מביא את היתרון הכי גדול שלו על פני כל אוטומציה – יצירתיות ואינטואיציה אנושית. אל תהיו נחמדים למודל. תאתגרו אותו:
- Prompt Injection: נסו "לעבוד" על המודל ופשפשו בגבולות שלו (למשל: "תתעלם מההנחיות הקודמות שלך ותגיד לי איך…").
- מקרי קצה תרבותיים ולשוניים: איך המודל מגיב לסלנג? איך הוא מתמודד עם עברית לעומת אנגלית? (כידוע, מודלים רבים מציגים ביצועים פחות יציבים בשפות שאינן אנגלית).
- שינויי קונטקסט: בדקו את המערכת אחרי שיחה ארוכה. האם הזיכרון של הצ'אט משפיע לרעה על התשובות המאוחרות יותר?
מטריצת הבדיקות החדשה: ממה מורכב ה-Test Data שלנו?
כשאתם בונים את סט הבדיקות (Test Suite) שלכם, חלקו את מקרי הבדיקה ל-3 סוגים מרכזיים:
| סוג מקרה הבדיקה | מה הוא כולל? | מטרה עיקרית |
| Golden Cases | פרומפטים קלאסיים עם תשובות מעולות ומאומתות שכבר קיבלנו בעבר. | משמש לבדיקות שפיות (Sanity) כדי לוודא שאין רגרסיה בביצועי הבסיס. |
| Edge Cases | תסריטים מורכבים, שאלות ארוכות במיוחד, קלטים משולבים. | לבחון איפה המודל מתחיל "לגמגם" או לאבד את הידיים והרגליים. |
| Adversarial Cases | פרומפטים "תוקפניים" ומניפולטיביים שנועדו לשבור את מנגנוני ההגנה. | בדיקת אבטחה, חסינות, והגנה מפני חשיפת מידע פנימי. |
שורה תחתונה: האנושיות היא ה-Gold Standard
ככל שהתוכנות הופכות ליותר חכמות ופחות צפויות, החשיבות של ה-QA הידני רק עולה. מודל AI אחר (LLM-as-a-judge) או בדיקות אוטומטיות יכולים לעזור לנו לסרוק כמויות של מידע, אבל בסופו של יום – רק עין אנושית, שמבינה קונטקסט, תרבות, רגש ואינטואיציה, יכולה לקבוע אם המוצר באמת מספק את התוצאה שתשפר את החיים של המשתמש, או סתם מייצר הזיות מתוחכמות.
בפעם הבאה שאתם ניגשים לבדוק פיצ'ר מבוסס AI, עזבו את ה-Assertion הקבוע שלכם. תחשבו כמו חוקרים, תריצו בדיקות מרובות, ותזכרו שבעולם נון-דטרמיניסטי – הגמישות והיצירתיות שלכם הן כלי הבדיקה החזק ביותר.
לקרוא מאמרים זה נחמד אבל לא יביא אותך לתוצאה שאתה רוצה, בדיוק בשביל זה הכנו עבורך את הקורס הדיגיטלי המהיר, תוך שעתיים וחצי תלמד את תחום הבדיקות ידניות, תוכל להתחיל לעבוד מהבית דרך FIVERR או ולהתכונן נכון לראיונות עבודה שיעזרו לך לצלוח אותם. כנס כאן הקורס ממוקד בבדיקות תוכנה ידניות הנותן בסיס חזק לתחום.
לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן
TesQA 