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