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

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