הנחיות בטיחות

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

אפשר להשתמש במודלים שמסופקים על ידי Gemini API למגוון רחב של אפליקציות של AI גנרטיבי ועיבוד שפה טבעית (NLP). השימוש בפונקציות האלה זמין רק דרך Gemini API או אפליקציית האינטרנט של Google AI Studio. השימוש ב-Gemini API כפוף גם למדיניות בנושא שימוש אסור ב-AI גנרטיבי ולתנאים ולהגבלות של Gemini API.

חלק מהסיבות לכך שמודלים גדולים של שפה (LLM) כל כך שימושיים הוא שהם כלים יצירתיים שיכולים לטפל במשימות שונות שקשורות לשפה. לצערנו, המשמעות היא גם שמודלים גדולים של שפה יכולים ליצור פלט שלא ציפיתם לו, כולל טקסט פוגעני, חסר רגישות או לא מדויק מבחינה עובדתית. בנוסף, הרבגוניות המדהימה של המודלים האלה מקשה על חיזוי מדויק של סוגי הפלט הלא רצויים שהם עשויים ליצור. ‫Gemini API תוכנן בהתאם לכללי ה-AI של Google, אבל האחריות לשימוש אחראי במודלים האלה מוטלת על המפתחים. כדי לעזור למפתחים ליצור אפליקציות בטוחות ואחראיות, Gemini API כולל סינון תוכן מובנה והגדרות אבטחה שניתנות להתאמה אישית ב-4 מימדים של פגיעה. מידע נוסף זמין במדריך בנושא הגדרות בטיחות.

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

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

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

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

הסבר על סיכוני הבטיחות באפליקציה

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

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

כדאי לשקול לבצע שינויים כדי לצמצם את סיכוני הבטיחות

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

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

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

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

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

  טיפ למתקדמים

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

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

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

ביצוע בדיקות בטיחות שמתאימות לתרחיש השימוש

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

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

• השוואה של רמת הבטיחות כוללת תכנון של מדדי בטיחות שמשקפים את האופנים שבהם האפליקציה יכולה להיות לא בטוחה בהקשר של האופן שבו סביר שהיא תשמש, ולאחר מכן בדיקה של הביצועים של האפליקציה במדדים באמצעות מערכי נתונים להערכה. מומלץ לחשוב על הרמות המינימליות המקובלות של מדדי הבטיחות לפני הבדיקה, כדי ש-1) תוכלו להעריך את תוצאות הבדיקה בהשוואה לציפיות האלה ו-2) תוכלו לאסוף את מערך הנתונים של ההערכה על סמך הבדיקות שמעריכות את המדדים שהכי חשובים לכם.

  טיפים מתקדמים

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

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

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

    טיפים מתקדמים

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

מעקב אחרי בעיות

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

השלבים הבאים

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