המודל המנטלי שלכם לבדיקות AI

מה נשאר ומה משתנה: מיפוי הידע שלכם בבדיקות אתרים לעולם החדש של מודלים גדולים של שפה (LLM).

אפליקציה לדוגמה

האפליקציה לדוגמה בסדרה הזו היא ThemeBuilder. כלי ThemeBuilder מוציא אובייקט JSON שמכיל מוטו שנוצר על ידי LLM ופלטת צבעים.

  • המוטו ולוח הצבעים צריכים להתאים לשם המותג, לתיאור, לקהל ולסגנון שהוזנו.
  • המוטו לא יכול להיות רעיל והוא צריך להיות קצר (עד 6 מילים).
  • הניגודיות בלוח הצבעים צריכה להיות נגישה, בהתאם להנחיות המינימליות של WCAG, עם יחס ניגודיות של 4.5:1.
קלטים ופלטים של ThemeBuilder.
ב-ThemeBuilder, המשתמש מזין שם חברה ותיאור, קהל יעד, טון ומצב רוח. הקצה הקדמי שולח את זה לשרת שלכם. השרת שלך משתמש במודל שפה גדול (LLM) כדי ליצור מוטו ופלטת צבעים שתואמים למותג.

הערכות אובייקטיביות וסובייקטיביות

איך בודקים ש-ThemeBuilder פועל כמו שצריך?

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

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

לדוגמה:

// Example rule-based eval: data format
function evaluateFormat(appOutput) {
  // Check if JSON is valid, colors are hex, no empty strings, motto is 6 words or fewer
  // Use deterministic tools like zod for schema validation
  return "PASS"; // or "FAIL"
}

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

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

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

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

‫—AI Engineering, Chip Huyen

לדוגמה:

// Example LLM-as-a-judge eval for a subjective quality like brand fit
async function evalBrandFit(userInput, appOutput) {
  const brandPrompt = `You are an expert brand strategist. Evaluate the
  following generated motto for the company whose target audience is
  ${userInput.audience}, and who describes itself as
  ${userInput.companyDescription}: ${appOutput.motto}`
  // Call the LLM judge
  const evalResult = evalWithLLM(brandPrompt);
  // Return the consolidated results
  return {
    mottoBrandFit: evalResult,
  };
}

// Helper that communicates with the LLM API
async function evalWithLLM(prompt) {
  // ... Call LLM with the prompt ...
  // ... Parse the resulting judgement ("PASS" or "FAIL") + rationale
  return {
    status: "PASS",
    rationale: "This motto perfectly captures the brand and tone, because..."
  };
}

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

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

סוגים אחרים של הערכות

אולי כדאי להשתמש בהערכות מבוססות-הפניה או בהערכות זוגיות.

מבוסס על הפניה

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

בזוגות

יכול להיות ששופט ייתן ציון PASS לשתי גרסאות שונות, גם אם אחת מהן טובה יותר מהשנייה. השיטה הזו פותרת את הבעיה על ידי הצגת שני פלטים (A ו-B) לאותו קלט לשופט, והנחיה לבחור מנצח.

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

Input: "Friendly cafe"

Pointwise evaluation:
Output A: "Come get coffee." // PASS
Output B: "Your morning smile in a cup." // PASS
2 PASS. Unconclusive!

Pairwise evaluation:
Output B wins. It captures the "friendly" tone more effectively than the generic Output A.

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

בדיקות רגילות באתר לעומת הערכות מבוססות-AI

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

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

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

שימוש בשכבות של בדיקות

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

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

  • כדי לבצע אוטומציה מלאה של בדיקות לאפליקציית ה-AI, אפשר להשתמש בהערכות מבוססות-כללים בשילוב עם הערכות של מודלים גדולים של שפה (LLM) כשופטים. כך תוכלו לזהות בעיות בתהליכי פיתוח ו-CI/CD יומיים, ולבדוק שהמועמדים להפצה עומדים ברף האיכות שהגדרתם.
  • מריצים בדיקות אינטגרציה ובדיקות רגרסיה כדי לוודא שהאיכות נשמרת גם בהיקף גדול.
  • הפעלת הערכות אנושיות ידניות כבדיקת קבלה.

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

ממשיכים לפתח את ההערכות

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

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

מה נמדד בהערכות שלכם?

לפני שמתכננים הערכות, חשוב להבין איך להעריך פלט. יש כמה מונחים שחשוב להכיר.

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

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

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

  • "האם הסלוגן הזה מתאים למותג?" המדד הוא PASS או FAIL.
  • "בסולם של 1 עד 5, עד כמה הסיסמה תואמת למותג?" המדד הוא מספר שלם בין אחת לחמש.

המעריך הוא הקוד או המודל שמקצים ניקוד לקריטריון. הבודקים קובעים את המדדים.