הנחיות בנושא בטיחות ודיוק עובדתי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  טיפ למתקדמים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השלבים הבאים

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