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

מודלים של בינה מלאכותית גנרטיבית הם כלים רבי עוצמה, אבל יש להם מגבלות. הגמישות והישימות שלהם עלולות לפעמים להוביל לתוצאות לא צפויות, כמו תוצאות לא מדויקות, מוטות או פוגעניות. עיבוד תמונה (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 מספק מסנני בטיחות מובנים שעוזרים לטפל בבעיות נפוצות במודלים של שפה, כמו שפה רעילה ודברי שטנה, ופועל למען הכללה והימנעות מסטריאוטיפים. עם זאת, כל אפליקציה עלולה להציב בפני המשתמשים שלה קבוצה שונה של סיכונים. לכן, כבעלי האפליקציה, אתם אחראים להכיר את המשתמשים שלכם ואת הנזקים הפוטנציאליים שהאפליקציה עלולה לגרום, ולוודא שהאפליקציה משתמשת במודלים של שפה בצורה בטוחה ואחראית.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השלבים הבאים