Promptfoo או DeepEval: בדיקות תקינות אינן תחליף לתקיפה

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

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

מה נבדק בכל מסלול

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

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

מטריצת כשל־לכלי מונעת כפל בדיקות

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

• שינוי בפרומפט או בספק: כאשר אותם מקרי ייחוס רצים מול כמה תצורות, מטריצת Promptfoo מאפשרת למקם כישלון בצירוף המסוים של מקרה, פרומפט וספק. צוות QA יכול להחזיק את מקרי הייחוס ואת ההתנהגות הצפויה.
• תשובה שאינה מבוססת על ההקשר: ביישום RAG צריך למסור לבדיקה גם את ההקשר שנשלף. מדד איכות ב־DeepEval מתאים כאשר בדיקת Python כבר ניגשת לרכיב השליפה, לתשובה ולנתוני הייחוס.
• חשיפת מידע או עקיפת הרשאה: כאן נדרש ניסיון מכוון להגיע למידע או לפעולה שאינם מותרים למשתמש הבדיקה. צוות AppSec מגדיר את גבול הגישה, וסריקת התקיפה בוחנת אם קלט עוין מצליח לחצות אותו.
• פעולה של סוכן: בחירת כלי שגויה לבקשה לגיטימית היא כשל איכות; הפעלת אותו כלי בעקבות הוראה שהוחדרה לתוכן חיצוני היא כשל בגבול האמון. שני המקרים מצדיקים בדיקות נפרדות.

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

שפת ההגדרה קובעת מי יתחזק את הבדיקות

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

ב־DeepEval אפשר לבנות מקרה בדיקה לצד פונקציות היישום ונתוני הבדיקה שלו. תיעוד ה־CI של DeepEval מציג שילוב עם pytest באמצעות assert_test והרצה ב־deepeval test run; מדד שנכשל יכול להכשיל את הבנייה. הדבר שימושי במיוחד כאשר שינוי בקוד השליפה או הסוכן צריך להיבדק יחד עם התוצאה שהוא מייצר. העלות התחזוקתית היא שהקריטריונים נמצאים בקוד, ולכן מי שסוקר אותם צריך להבין את סביבת הבדיקות.

תבנית CI: איכות בכל שינוי, תקיפה לפי סיכון

צינור משולב יכול להריץ בדיקות איכות קצרות בכל שינוי רלוונטי, ולהפעיל תקיפה ממוקדת כשהשינוי נוגע לגבול אמון. מדריך ה־CI של Promptfoo מציג פקודת eval לבדיקות איכות, פקודת redteam run לסריקת אבטחה ושימוש בסריקות מתוזמנות. אותו סדר עבודה אפשרי גם כשבדיקות האיכות נכתבות ב־DeepEval והתקיפות רצות ב־Promptfoo.

1. בכל שינוי רלוונטי: להריץ אוסף קטן ויציב של תרחישים עסקיים מרכזיים. צוות Python יכול להשתמש במדדי DeepEval לתשובות מבוססות הקשר, וצוות שמשווה פרומפטים וספקים יכול להריץ Promptfoo eval. מקרה בעל תוצאה חד־משמעית, כמו מבנה פלט מחייב, מתאים לשער חוסם.
2. כשמשטח הסיכון משתנה: הוספת כלי לסוכן, מקור תוכן שנשלף, הרשאה או ערוץ קלט חיצוני מצדיקים תקיפות הקשורות לשינוי. מקור RAG חדש, למשל, מעורר שאלה על הזרקת הוראות דרך תוכן שנשלף; שינוי בגישה למסמכים מעורר שאלה על חשיפת מידע בין משתמשים. בחירת התרחישים צריכה לשקף את גבול האמון שהשתנה.
3. בריצה מתוזמנת ולפני שחרור משמעותי: להריץ כיסוי רחב יותר מול תצורת היישום המיועדת לפריסה. ריצה כזאת נותנת מקום לניסיונות יקרים או איטיים יותר ולבחינת התנהגות שעשויה להשתנות גם בלי שינוי קוד מקומי.

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

שערי פריסה ועלות: שני אילוצים לאותה תוכנית

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

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

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

קראו גם:

• בדיקות לסוכן AI: תשובה נכונה לא מוכיחה שהתהליך עובד