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

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

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

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

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

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

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

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

מחזור הטמעת המודל

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

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

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

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

  • כדאי לדבר עם מגוון רחב של משתמשים פוטנציאליים מאוכלוסיית היעד שלך לגבי האפליקציה והמטרה שלה, כדי לקבל נקודת מבט רחבה יותר על הסיכונים הפוטנציאליים ולהתאים את הקריטריונים לגיוון לפי הצורך.
  • ה-AI Risk Management Framework שפורסם על ידי המכון הלאומי לתקנים וטכנולוגיה (National Institute of Standards and Technology) של ממשלת ארה"ב (NIST) מספק הנחיות מפורטות יותר ומשאבי למידה נוספים בנושא ניהול סיכונים ב-AI.
  • הפרסום של DeepMind על הסיכונים האתיים והחברתיים לנזק ממודלים של שפה מתואר בפירוט הדרכים שבהן אפליקציות של מודלים של שפה יכולות לגרום נזק.

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

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

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

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

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

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

    טיפ מתקדם

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השלבים הבאים