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

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

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

כשבונים אפליקציות באמצעות מודלים גדולים של שפה, מומלץ לפעול לפי השלבים הבאים:

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

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

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

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

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

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

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

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

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

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

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

  טיפ מתקדם

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השלבים הבאים

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