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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  טיפ מתקדם

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השלבים הבאים

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