רובוטריקים הסבר: 7 סודות להגברת דיוק המודלים היום

פרויקטים רבים של שנאי מגיעים לנקודה שבה אובדן האימון נראה בריא, אך דיוק האימות נשאר קבוע. ראיתי את זה קורה עם מסווגי טקסט, מערכות חיפוש ומודלים של מסמכים. הסיבה היא לעתים נדירות פרמטר אחד חסר. איכות נתונים, אסימון, עיצוב תשומת לב, הערכה ובחירות אימון משפיעות לעתים קרובות זה על זה. שבעת התרגולים האלו נותנים לי דרך ברורה לשפר מודל שנאי מבלי להסתמך על ניחושים. ## 1. התחל עם תוויות נקיות יותר. רובאי יכול ללמוד תבניות מתוויות שגויות באותה קלות שבה הוא לומד תוויות שימושיות. אם ערכת ההדרכה מכילה כללים מעורבים, רשומות כפולות או קטגוריות מעורפלות, המודל עלול להניב תוצאות לא יציבות. אני מתחיל בסקירת תווית קטנה: - קרא מדגם אקראי מכל כיתה. - בדוק אם נעשה שימוש באותו כלל בכל התוויות. - הסר רשומות כפולות או כמעט כפולות. - סמן דוגמאות לא ברורות במקום להכריח אותן להיכנס לכיתה. - סקירת דגימות שהמודל חוזה בביטחון נמוך. דוגמה מעשית מגיעה מסיווג רגשות. ביקורת עשויה להכיל גם שבחים וגם ביקורת: > "המצלמה חדה, אבל הסוללה גרועה." אם המשימה היא סנטימנט כולל, התווית צריכה כלל ברור. אם המשימה היא סנטימנט מבוסס היבט, אותו משפט צריך תוויות נפרדות למצלמה ולסוללה. מודל לא יכול לפתור מדיניות תיוג שאנשים לא הגדירו. אני מעדיף מערך נתונים קטן יותר עם תוויות עקביות על פני מערך נתונים גדול יותר מלא בהחלטות מעורבות. ## 2. השתמש בטוקניר שמתאים לנתונים Tokenization שולט במה שהמודל יכול לראות. אסימון גרוע עלול לפצל קודי מוצר, מונחים רפואיים, שמות משתמש או שמות תוכנה לחתיכות קטנות רבות. זה מגדיל את אורך הרצף ויכול להסתיר דפוסים שימושיים. אני בודק שלושה תחומים: - כיצד מפוצלות מילים נפוצות - כיצד מפוצלים מונחי תחום נדירים - באיזו תדירות המודל מגיע לאורך הרצף המרבי נניח שמערך נתונים תמיכה מכיל קודי מוצר כגון RX-4500-Pro. אם הטוקנייזר מפרק את הקוד לפרגמנטים לא קשורים, המודל עשוי להתקשה להבחין בין מוצר אחד למשנהו. הוספת מונחי תחום לאוצר המילים יכולה לעזור, בתנאי שהמונחים החדשים מופיעים לעתים קרובות מספיק כדי להצדיק את השינוי. האסימון צריך להתאים גם לטקסט המשמש במהלך הפריסה. מודל שאומן על משפטים נקיים עשוי להתנהג בצורה שונה כאשר משתמשים שולחים קיצורים, אימוג'ים, שגיאות כתיב או מועתקים יומני מערכת. אני בודק את הטוקנייזר לפני האימון עם טבלה קטנה של תשומות נפוצות. בדיקה פשוטה זו יכולה לחשוף בעיה לפני שהיא צורכת שעות של חישוב. ## 3. התייחס לאורך הרצף כבחירת מודל קלט ארוך יותר לא תמיד מייצר תחזיות טובות יותר. זה יכול להוסיף תוכן לא קשור, להעלות את השימוש בזיכרון ולהקשות על האופטימיזציה. אני שואל שאלה ישירה: איזה חלק מהקלט מכיל את הראיות הדרושות למשימה? עבור סיווג דוא"ל, הנושא והחלק הראשון של ההודעה עשויים לשאת אותות שימושיים. לניתוח מסמכים משפטיים, סעיף מפתח עשוי להופיע לקראת הסוף. לתמיכת לקוחות, הודעת המשתמש האחרונה עשויה להיות חשובה יותר מאשר חסימת שיחה ישנה. אפשרויות שימושיות כוללות: - קיצור טקסט סביב עדויות ידועות - פיצול מסמכים ארוכים לקטעים - שימוש בחלונות חופפים - סיכום קטעים ארוכים לפני סיווג - שילוב תחזיות ברמת הקטע טעות נפוצה היא להגדיר אורך מקסימלי גדול ולהניח שהמודל ישתמש בכל אסימון היטב. אני בודק את התפלגות האורך במערך הנתונים ומשווה אותו לתוצאות אימות. אם רוב הדגימות קצרות, מגבלה גדולה עשויה להוסיף עלות מבלי להוסיף אות. ## 4. התאם את תשומת הלב למשימה תשומת לב עצמית מאפשרת לכל אסימון להשתמש במידע מאסימונים אחרים. הדגם עדיין זקוק להגדרת תשומת הלב הנכונה עבור העבודה. לצורך סיווג, מקודד דו-כיווני כמו BERT יכול לבחון את ההקשר משני צידי המילה. ליצירת טקסט, מפענח משתמש בתשומת לב סיבתית כך שהוא לא קורא אסימונים עתידיים במהלך חיזוי. מודל המיועד לתפקיד אחד עשוי לתפקד בצורה גרועה כאשר נאלץ לתפקיד אחר ללא שינויים מתאימים. אני גם בודק את מסכת הקשב. אסימוני ריפוד לא אמורים להשפיע על התוצאה. בזוג משפטים, יש לטפל במידע המפריד והקטע באופן עקבי. שגיאת מיסוך קטנה יכולה לייצר יומני אימונים סבירים תוך פגיעה בתוצאות ההערכה. עבור משימה של צמד משפטים, אני בודק דוגמאות שבהן סדר המילים משנה את המשמעות: > "הספק אישר את הבקשה." > "הבקשה אישרה את הספק." מודל שימושי צריך להגיב למערכת היחסים שהשתנתה, לא רק למילים המשותפות. דפוסי קשב אינם הסבר מלא להתנהגות המודל, אך הם יכולים לעזור לחשוף אם מבנה הקלט מטופל כמצופה. ## 5. כוונון עדין עם תוכנית אימונים יציבה כוונון עדין עובד לרוב טוב יותר כאשר קצב הלמידה קטן ולוח הזמנים של האימונים נשלט. קצב למידה גדול עשוי לשנות ייצוגים שימושיים שהוכשרו מראש מהר מדי. שיעור קטן מאוד עלול להשאיר את השכבות הספציפיות למשימה לא מאומנות. אני בדרך כלל משווה כמה הגדרות במקום לחפש ברשת ענקית: - קצב למידה - גודל אצווה - מספר תקופות - שלבי חימום - דעיכה במשקל - קצב נשירה - צבירת שיפוע ההגדרה הטובה ביותר תלויה בגודל מערך הנתונים ובקושי המשימה. מערך נתונים קטן עלול להתאים יותר מדי לאחר מספר תקופות בלבד. מערך נתונים גדול עשוי להזדקק להכשרה נוספת, אך עקומת האימות צריכה להנחות את ההחלטה. אני עוקב אחר: - אובדן אימונים - אובדן אימות - דיוק - ציון F1 - היזכרות לכל כיתה - ביטחון חיזוי דיוק לבדו יכול להסתיר ביצועים חלשים בכיתות קטנות יותר. אם מערך נתונים של הונאה מכיל 95% עסקאות רגילות, מודל שמנבא "נורמלי" עבור כל רשומה יכול להראות דיוק גבוה תוך כשל במשימה בפועל. מאקרו F1 וזכרון ממעמד המיעוטים נותנים תצוגה שימושית יותר. עצירה מוקדמת יכולה לעזור כאשר ביצועי האימות מפסיקים להשתפר. אני שומר מחסומים על סמך המדד התואם את יעד המוצר, לא רק ההפסד הנמוך ביותר באימון. ## 6. צמצם דליפה ובדוק את פיצול הנתונים דליפת נתונים יכולה לגרום לדגם להיראות מדויק במהלך הבדיקה ולא אמין לאחר השחרור. זה קורה כאשר מידע ממערך ההערכה מגיע לאימון באמצעות כפילויות, רשומות משתמש, אירועים עתידיים או שלבי עיבוד מקדים. אני משתמש בפיצולים שמשקפים את האופן שבו המודל יקבל נתונים חדשים. עבור מסווג הודעות לקוח, פיצול אקראי עשוי להציב הודעות מאותו לקוח הן בערכות הדרכה והן במערכות אימות. המודל עשוי ללמוד את הרגלי הכתיבה של הלקוח במקום את המשימה הכללית. פיצול ברמת המשתמש נותן הערכה כנה יותר. עבור נתונים מבוססי זמן, אני מתאמן על רשומות קודמות ומאמת על רשומות מאוחרות יותר. זה חשוב לחיזוי ביקוש, סיווג חדשות וניטור מערכת, שבהם הדפוסים יכולים להשתנות. אני גם מתאים שלבי עיבוד מקדים על סט האימונים בלבד. עדכוני אוצר מילים, כללי נורמליזציה, בחירת תכונה וסטטיסטיקות נתונים לא צריכים להשתמש ברשומות אימות או בדיקה. ביקורת שימושית שואלת: - האם קיימים טקסטים כפולים על פני פיצולים? - האם רשומות מאותו משתמש מופיעות בחלוקות מרובות? - האם חותמת זמן חושפת את התווית? - האם נעשה שימוש בערכת הבדיקה לבחירת היפרפרמטרים? - האם דגימות סינתטיות מבוססות על נתוני הערכה? ציון נמוך יותר אך אמין הוא שימושי יותר מציון גבוה שנוצר עקב דליפה. ## 7. בדוק מקרים קשים, לא רק מקרים ממוצעים. דיוק האימות הממוצע אינו מראה היכן המודל נכשל. אני יוצר קבוצות בדיקה ממוקדות המייצגות את המצבים שסביר להניח שמשתמשים ישלחו. עבור מודל טקסט, קבוצות אלו עשויות לכלול: - הודעות קצרות - הודעות ארוכות - שגיאות הקלדה - שפות מעורבות - שלילה - סרקזם - שמות נדירים - מונחי מוצר חדשים - כוונות מרובות בהודעה אחת - קלט ריק או כמעט ריק. מטריצת בלבול יכולה להראות ששתי תוויות מעורבות לעתים קרובות. הדוגמאות שמאחורי הדפוס הזה בדרך כלל מציעות את הפעולה הבאה: שפר תוויות, הוסף דוגמאות הדרכה, שנה את הטקסונומיה או התאם את פורמט הקלט. ציוני ביטחון גם צריכים טיפול. מודל יכול להיות מאוד בטוח ועדיין לטעות בטקסט לא מוכר. אני משווה ביטחון עם נכונות בפועל על ערכת אימות ושקול שיטות כיול כאשר האפליקציה משתמשת בספים. לדוגמה, מערכת תמיכה עשויה לנתב הודעות אוטומטית רק כאשר הביטחון גבוה. מקרים קרובים לסף יכולים להגיע למבקר אנושי. עיצוב זה עובד לרוב טוב יותר מאשר לאלץ כל תחזית לנתיב אוטומטי. ## זרימת עבודה מעשית בה אני משתמש כאשר הדיוק נמוך מהיעד, אני נמנע משינוי של חמישה משתנים בבת אחת. זה מקשה להסביר את התוצאה. התהליך שלי נראה כך: 1. הגדר את מדד היעד ואת העלות של כל שגיאה. 2. בדיקת תוויות, כפילויות ויתרת כיתות. 3. סקור את האסימון ואורך הרצף. 4. בנה פיצול נתונים נקי ומותאם למשימות. 5. הפעל קו בסיס קטן עם הגדרות קבועות. 6. שנה גורם מרכזי אחד בכל פעם. 7. השוו תוצאות לפי כיתה ולפי קבוצת מקרים קשים. 8. שמור את השינוי רק כאשר הוא משפר את מדד היעד מבלי ליצור דפוס כשל חדש. קו בסיס עשוי להיות מקודד מיומן מראש עם ראש סיווג פשוט. זה נותן לי נקודת התייחסות. אם שינוי מורכב לא יכול לנצח את ההתייחסות הזו על ערכת אימות נקייה, אני לא שומר אותו פשוט כי תהליך האימון נראה מתקדם יותר. דיוק השנאים משתפר בדרך כלל באמצעות שרשרת של החלטות קטנות הניתנות לבדיקה. תוויות טובות יותר תומכות בתשומת לב טובה יותר. טיפול טוב יותר בקלט תומך בכוונון עדין יציב יותר. פיצול הערכה הוגן מראה אם ​​הרווחים צפויים להימשך מחוץ לנתוני האימונים. כשאני מתמקד בראיות במקום במספרי Leaderboard מבודדים, שיפור המודל הופך קל יותר למדידה וקל יותר לתחזוקה.

מערכות בינה מלאכותיות רבות מתקשות כאשר משפט מכיל מספר משמעויות, מילים רחוקות או מידע הפרוס על פני מסמך ארוך. מודל עשוי לזהות כל מילה בצורה נכונה אך לפספס את הקשר ביניהם. פער זה עלול להוביל לתרגומים חלשים, תשובות שגויות וסיכומים לא ברורים. רובוטריקים עוזרים להפחית בעיה זו על ידי בחינת האופן שבו מילים קשורות זו לזו. כשאני מבקש ממערכת בינה מלאכותית להסביר סעיף חוזה, לתרגם פסקה או לענות על שאלה לגבי דוח, המודל לא מתייחס לכל מילה כאל פריט מבודד. הוא משווה בין המילים ונותן תשומת לב רבה יותר לחלקים שמעצבים את המשמעות. ### תשומת לב עוזרת למודל לקרוא את ההקשר התכונה העיקרית מאחורי רובואי נקראת קשב. שקול את המשפט הזה: "מריה נתנה את הספר לאנה כי היא סיימה לקרוא אותו." המילה "היא" עשויה להתייחס למריה או אנה. מודל שפה צריך ללמוד את המילים שמסביב לפני בחירת פרשנות. תשומת הלב מאפשרת למודל להשוות את "היא" למילים אחרות במשפט ולהעריך אילו קשרים סבירים יותר. תהליך זה מתרחש בחלקים רבים של הטקסט. ניתן לקשר מילה ליד סוף פסקה למילה ליד ההתחלה. מודלים של שפה ישנים עיבדו לעתים קרובות טקסט בסדר קבוע, מה שהפך מערכות יחסים למרחקים ארוכים יותר למעקב. רובוטריקים יכולים לסקור מערכות יחסים רבות בו זמנית. זה נותן למודל מידע נוסף לפני שהוא מנבא את המילה הבאה או מייצר תשובה. ### שכבות קשב מרובות לוכדות אותות שונים. רובאי אינו מסתמך על דפוס קשב אחד. הוא משתמש במספר ראשי קשב, וכל ראש יכול להתמקד בסוג אחר של חיבור. ראש אחד עשוי לעקוב אחר דקדוק. אחר עשוי להתמקד בשמות, תאריכים או מיקומים. ראש נפרד עשוי לחבר שאלה עם הקטע שמכיל את תשובתה. כאשר אני בודק כלי בינה מלאכותית עם הודעת תמיכת לקוחות, הדפוסים הללו יכולים לעזור למערכת לזהות: - הנושא העיקרי של הלקוח - המוצר או השירות המעורבים - הפעולה המבוקשת - טון ההודעה - הפרטים הדרושים לתשובה שימושית המודל משלב את האותות הללו על פני רבדים רבים. כל שכבה משנה את הייצוג הפנימי של הטקסט, ועוזרת למערכת לבנות תצוגה עשירה יותר של הקלט. הדיוק אינו נובע מכלל אחד. זה מגיע ממערכות יחסים קטנות רבות המעובדות יחד. ### רובוטריקים מטפלים בהקשר ארוך יותר. שאלה קצרה עשויה לדרוש מידע ממסמך ארוך. ייתכן שסוכן תמיכה יצטרך למצוא תנאי אחריות במרחק מספר עמודים מתלונת הלקוח. חוקר עשוי לשאול שאלה התלויה בפרטים המפוזרים על פני מספר חלקים בדוח. רובוטריקים שימושיים במקרים אלה מכיוון שהם יכולים להשוות כמות גדולה יותר של טקסט במהלך העיבוד. הדגם עשוי לחבר שם מוצר בפסקה אחת עם תאריך, מצב או חריג בפסקה אחרת. זה לא אומר שהמערכת מבינה כל מסמך ארוך כהלכה. כניסות ארוכות עדיין יכולות ליצור פרטים שהוחמצו, תשובות חוזרות או חיבורים מורכבים. איכות התוצאה תלויה בדגם, בנתוני ההדרכה, בהנחיה ובאופן אספקת המסמך. ### הדרכה נותנת למודל דפוסים לשימוש רובוטריקים לומדים מאוספים גדולים של טקסט, קוד, תמונות, אודיו או נתונים אחרים. במהלך האימון, המודל חוזה תוכן חסר או עוקב ומתאים את ההגדרות הפנימיות שלו כאשר החיזוי שגוי. מודל שפה עשוי לראות משפטים כגון: "החבילה הגיעה באיחור כי משאית המשלוח..." הוא לומד שמילים כמו "תנועה", "מזג אוויר" או "מסלול" עשויות לעקוב אחר המשפט. לאחר עיבוד דוגמאות רבות, המודל בונה תבניות סטטיסטיות לגבי שפה ומשמעות. BERT היא דוגמה ידועה. הוא תוכנן לקרוא מילים ביחס למילים סביבן, מה שעזר במשימות כמו הבנת חיפוש וסיווג טקסט. מודלים של GPT משתמשים בעיצובי Transformer כדי ליצור טקסט צעד אחר צעד. מערכות תרגום משתמשות גם במודלים של Transformer כדי להשוות מילים בשתי שפות. מערכות אלו לא מאחסנות כל תשובה כרשימה פשוטה. הם לומדים דפוסים שעוזרים להם להעריך תפוקות מתאימות לתשומות חדשות. ### קלט טוב יותר יכול לשפר את התוצאה גיליתי שלעתים קרובות אנשים מאשימים את מודל הבינה המלאכותית כאשר הבעיה האמיתית היא קלט לא ברור. רובאי יכול לעבד הקשר, אבל הוא עדיין צריך הקשר שימושי. זרימת עבודה מעשית נראית כך: 1. ציין את המשימה בשפה ישירה. 2. ספק את טקסט המקור או הנתונים. 3. הסבירו את הפורמט הרצוי. 4. הוסף מגבלות, כגון ספירת מילים או קהל. 5. בקשו מהמודל להפריד בין עובדות ידועות לנקודות לא ודאות. 6. בדקו את התשובה מול המקור המקורי. לדוגמה, "סיכום דוח זה" משאיר אפשרויות רבות פתוחות. בקשה ברורה יותר עשויה לומר: "סכם את הדו"ח בחמש נקודות תבליטים. כלול את הממצא העיקרי, שתי דמויות תומכות, מגבלה אחת, ושמות הסעיפים שבהם מופיע המידע." הבקשה השנייה נותנת למודל יעד ברור יותר. הרובוטריק יכול למקד את תשומת הלב שלו בפרטים החשובים למשימה. ### דיוק עדיין זקוק לביקורת אנושית רובוטריקים משפרים חיזוי וטיפול בהקשר, אך הם אינם מבטיחים מידע נכון. מודל יכול להפיק תשובה שוטפת עם תאריך שגוי, טענה לא נתמכת או חריג חסר. חברה המשתמשת בבינה מלאכותית לשירות לקוחות עשויה לאפשר למערכת לסווג הודעות נכנסות, בזמן שאדם סוקר תשובות הכוללות החזרים כספיים, גישה לחשבון או רשומות רגישות. כלי מידע רפואי עשוי לסייע בארגון המחקר, אך איש מקצוע מוסמך עדיין צריך להעריך את התוצאה. אני מתייחס לפלט שנאי כאל טיוטה עובדת, לא כהוכחה. אני בודק שמות, מספרים, ציטוטים, מקורות והוראות לפני השימוש בתוכן. רובוטריקים משפרים את דיוק הבינה המלאכותית על ידי מתן דרך חזקה יותר למודלים לחבר מילים, תמונות ופיסות מידע אחרות. תשומת לב עוזרת לזהות מערכות יחסים שימושיות. שכבות מרובות מזהות דפוסים שונים. הכשרה בקנה מידה גדול נותן למודל אותות שפה ומשימה לעבוד איתם. התוצאות הטובות ביותר מגיעות משלושה חלקים שפועלים יחד: מודל מוכשר, קלט ברור ובדיקה מדוקדקת. הטכנולוגיה יכולה להפוך את תגובות הבינה המלאכותית לרלוונטיות ועקביות יותר, אבל שיקול הדעת האנושי נשאר חלק מהתהליך.

צוותים רבים מנסים לשפר את דיוק המודל על ידי שינוי אלגוריתמים או הוספת שכבות נוספות. גישה זו עלולה להחמיץ את הבעיה האמיתית. תוויות גרועות, נתונים חלשים, דליפת נתונים וחוסר התאמה בין נתוני אימון והתנהגות משתמשים משפיעים לעתים קרובות יותר. אני מתחיל עם הנתונים והדרך שבה המודל ישמש. שבעת השלבים הללו נותנים לי דרך מעשית לשיפור הדיוק מבלי להפוך את הפרויקט לתרגיל ניחוש. ### 1. הגדר את המטרה בצורה ברורה מודל לא יכול ללמוד דפוס שימושי ממטרה מעורפלת. נניח שאני בונה מערכת שמזהה משלוחים מאוחרים. התווית יכולה להיות: - החבילה הגיעה לאחר התאריך שהובטח - החבילה הגיעה באיחור של יותר מיומיים - הלקוח הגיש תלונה - סטטוס המשלוח עודכן לאחר הזמן הצפוי. כל הגדרה יוצרת מערך נתונים אחר ותוצאה שונה. אני כותב את כלל המטרה במשפט אחד לפני אימון המודל. אני גם בודק האם הכלל תואם את המטרה העסקית. לצוות שירות לקוחות עשוי להיות אכפת מתלונות, בעוד שלצוות לוגיסטי עשוי להיות אכפת מתאריכי אספקה. יעד ברור נותן למודל משימה ברורה. ### 2. בדוק את איכות התוויות שלך דגם יכול ללמוד רק מהדוגמאות שהוא מקבל. אם לדוגמאות רבות יש תווית שגויה, הדיוק עשוי להישאר נמוך גם כאשר האלגוריתם נבחר היטב. אני בדרך כלל סוקר מדגם אקראי של רשומות ביד. עבור מודל סיווג דוא"ל, אני עשוי לבדוק הודעות המסומנות כ"ספאם" ו"לא דואר זבל". אם מספר הודעות דוא"ל לקידום מתויגות כהודעות רגילות, נתוני ההדרכה זקוקים לתשומת לב. בדיקות שימושיות כוללות: - ספירת תוויות חסרות - חפש תוויות סותרות - השוואה בין תוויות מסוקרים שונים - סקירת דוגמאות ליד גבול ההחלטה - הסרת רשומות עם משמעות לא ברורה סקירה קטנה יכולה לחשוף דפוסים שתרשים אינו מציג. במקרה נפוץ אחד של תמיכת לקוחות, הודעות על החזרים וביטולים הוצבו לעתים קרובות באותה קטגוריה. המודל לא פשוט עשה שגיאות אקראיות. זה היה למידה מקטגוריות שאנשים הגדירו בצורה לא עקבית. ### 3. הסר דליפת נתונים דליפת נתונים מתרחשת כאשר המודל מקבל מידע שלא יהיה זמין בעת ​​ביצוע חיזוי. ציון המבחן עשוי להיראות חזק, בעוד שהביצועים יורדים לאחר הפריסה. תארו לעצמכם לחזות האם בקשת הלוואה תאושר. אסור להופיע בין תכונות הקלט שדה המציג את סטטוס האישור הסופי. אותה בעיה יכולה להתרחש בדרכים פחות ברורות. כרטיס תמיכה עשוי להכיל "תאריך סגור", או שרשומה רפואית עשויה לכלול תוצאה שנוספה לאחר זמן החיזוי. אני שואל את השאלה הזו עבור כל תכונה: > האם הערך הזה קיים ברגע המדויק שבו המודל עושה את החיזוי שלו? אם התשובה היא לא, אני מסיר את התכונה או מעצב מחדש את צינור הנתונים. בעיות מבוססות זמן דורשות טיפול נוסף. פיצול אקראי של מבחן רכבת עשוי להציב שיאים עתידיים בערכת האימונים ושיאים ישנים יותר בערכת המבחנים. פיצול מבוסס זמן נותן לעתים קרובות אומדן כנה יותר לחיזוי ביקוש, זיהוי הונאה וחיזוי נטישת לקוחות. ### 4. התאם את מדד ההערכה למשימה הדיוק שימושי כאשר השיעורים מאוזנים והעלות של כל טעות דומה. משימות מעשיות רבות אינן עומדות בתנאים אלו. אם רק 1% מהעסקאות הן הונאה, מודל שמתייג כל עסקה כבטוחה יכול להגיע לדיוק של 99% מבלי למצוא הונאה. במקרה כזה, אני בוחן גם: - דיוק - ריקול - ציון F1 - שטח מתחת לעקומת הדיוק-recall - מטריצת בלבול. מערכת סקר בית חולים עשויה להזדקק ל-recall חזק מכיוון שלחמצת מקרה אפשרי יש עלות גבוהה. מערכת ניהול סקירה עשויה לתת משקל רב יותר לדיוק כדי לצמצם הסרות מיותרות. אני בוחר את המדד לאחר שדיברתי על העלות של חיוביות שגויות ושליליות שגויות עם האנשים שמשתמשים בתחזיות. המדד הטוב ביותר הוא זה שמחובר להחלטה, לא זה שמייצר את המספר הגדול ביותר. ### 5. שפר את התכונות תכונות טובות יותר יכולות לעזור לדגם פשוט לבצע ביצועים טובים. תכונות נוספות לא תמיד עוזרות. חלקם מוסיפים רעש, חוזרים על אותו מידע או מתארים דפוס שלא יהיה קיים לאחר הפריסה. עבור מודל ביקוש קמעונאי, תכונות שימושיות עשויות לכלול: - מכירות קודמות לפי מוצר - יום בשבוע - תקופות חגים - נתוני מזג אוויר מקומיים - זמינות מלאי - סטטוס קידום מכירות חותמת זמן גולמית עשויה להיות פחות שימושית משדות נפרדים עבור שעה, יום חול ועונה. נתוני טקסט עשויים להפיק תועלת מניקוי, קבוצות מילים משמעותיות או מונחים ספציפיים לתחום. אני בודק תכונות בקבוצות קטנות ורושם את התוצאה. כך קל יותר להבין אילו שינויים עוזרים. זה גם מונע מהפרויקט להפוך לרשימה ארוכה של ניחושים. יצירת תכונה חייבת לכבד את זמן החיזוי. אם נעשה שימוש במכירות עתידיות כדי לחזות ביקוש מוקדם יותר, הניקוד לא ייצג שימוש בפועל. ### 6. כוונן את המודל עם תהליך אימות הוגן הגדרות המודל יכולות להשפיע על התוצאות, אך הכוונון צריך לבצע תהליך מבוקר. אני מחלק את הנתונים לקבוצות הדרכה, אימות ומבחנים. ערכת האימונים מתאימה לדגם. ערכת האימות עוזרת להשוות הגדרות. ערכת הבדיקה נשארת ללא נגיעה עד לבדיקה הסופית. הגדרות שימושיות עשויות לכלול: - קצב למידה - עומק עץ - מספר עצים - חוזק רגוליזציה - גודל אצווה - סף החלטה אימות צולב יכול לעזור כאשר מערך הנתונים קטן. עבור נתונים תלויי זמן, אני משתמש בפיצולים המשמרים את סדר האירועים במקום ערבוב של רשומות עבר ועתיד. דוגמה מעשית מגיעה מסיווג תמונה. מודל עשוי לשנן את הרקע של תמונות אימון במקום ללמוד את האובייקט עצמו. שינוי הגדרות הדגם לא יפתור את הבעיה. תמונות מגוונות יותר, הגדלה מתאימה ופיצול נתונים טוב יותר עשויים להשפיע יותר. ### 7. מעקב אחר ביצועים לאחר פריסה מודל יכול לבצע ביצועים טובים במהלך הבדיקה ולאבד את הדיוק מאוחר יותר. שינויים בהתנהגות הלקוחות, תכונות המוצר משתנות ומערכות איסוף נתונים עשויות להתעדכן. אני עוקב אחר: - דיוק חיזוי - סוגי שגיאות - ערכי קלט חסרים - התפלגות תכונות - איזון מעמדי - בטחון חיזוי - שינויים בהתנהגות המשתמש נניח שמודל תמיכה הוכשר על הודעות על יישום שולחן עבודה. לאחר שחרור נייד, משתמשים מתחילים להשתמש במונחים חדשים ולדווח על בעיות שונות. ייתכן שנתוני ההדרכה הישנים כבר לא מייצגים שאלות נוכחיות. אני קובע לוח זמנים לביקורת ומגדיר תנאי להסבה. שינוי פתאומי בנתוני הקלט עשוי לדרוש חקירה לפני עדכון המודל. אימון מחדש מבלי לבדוק את הסיבה יכולה לחזור על אותה בעיה עם נתונים חדשים יותר. ### זרימת עבודה מעשית כשאני צריך לשפר את דיוק המודל, אני מבצע את הסדר הבא: 1. אשר את יעד החיזוי 2. סקור תוויות וערכים חסרים 3. בדוק אם יש דליפה 4. בחר מדדי הערכה 5. שפר או הסר תכונות 6. כוונן את המודל עם פיצול הוגן 7. עקוב אחר תוצאות לאחר שחרור הזמנה זו חוסכת זמן ומודדת נתונים לפני מודלים מורכבים. מודל קטן יותר עם תוויות נקיות ותהליך הערכה הוגן יכול להיות שימושי יותר ממודל גדול יותר שהוכשר על נתונים לא ברורים. הדיוק הוא תוצאה של כל התהליך. כשמופיעות שגיאות, אני לא מסתכל רק על האלגוריתם. אני בודק את הדוגמאות, התוויות, התזמון של כל תכונה, ואת ההחלטה שהתחזית תומכת בה.

פרויקטים רבים של שנאים נכשלים מסיבות פשוטות: המשימה מעורפלת מדי, הקלט מוכן בצורה גרועה או פלט המודל מתקבל ללא בדיקה. ראיתי צוותים מבלים שעות בשינוי מודל כאשר הנחיה ברורה יותר, תוויות טובות יותר או קלט קצר יותר היו פותרים את הבעיה העיקרית. שנאי יכול להתמודד עם טקסט, תמונות, אודיו וקוד. התוצאות שלו תלויות באופן שבו אני מגדיר את המשימה, מכין את הנתונים, בוחר את המודל ובודק את הפלט. שבעת התרגולים האלו נותנים לי נקודת התחלה אמינה יותר. 1. הגדירו משימה ברורה אחת אני מתחיל בשאלה ספציפית: - האם אני צריך סיווג טקסט? - האם אני רוצה ליצור תקציר? - האם הדגם צריך לחלץ שמות, תאריכים או קודי מוצר? - האם המערכת צריכה לייצר תשובה? - האם זה צריך לתרגם טקסט משפה אחת לאחרת? קשה למדוד בקשה רחבה כמו "להבין משוב לקוחות". אני יכול לעשות את זה שימושי יותר על ידי שינוי זה ל: > "סווג כל ביקורת כחיובית, ניטרלית או שלילית, והחזר את הסיבה העיקרית." שינוי זה משפיע על המודל, נתוני ההדרכה, פורמט הפלט ושיטת ההערכה. משימה ברורה גם עוזרת לי להימנע משימוש במודל מחולל גדול לבעיית סיווג פשוטה. 2. התאם את הדגם לעבודה דגמי שנאים שונים בנויים לסוגי עבודה שונים. מודל מקודד כגון BERT יכול לעבוד היטב עבור סיווג, חיפוש והתאמת טקסט. מודל מפענח יכול ליצור טקסט, קוד או תגובות מובנות. מודל מקודד-מפענח יכול לתמוך במשימות כמו תרגום וסיכום. אני לא בוחר דגם רק בגלל שהוא פופולרי. אני בודק: - שפת הקלט - אורך הקלט המקסימלי - מטרת ההדרכה של המודל - פורמט התגובה הנדרש - החומרה הזמינה - הרישיון ותנאי השימוש - רמת הדיוק הדרושה לדוגמה, צוות תמיכה שרק צריך לתייג כרטיסים כ"חיוב", "כניסה" או "בעיה טכנית" עשוי להשתמש במודל סיווג קטן יותר. עוזר כתיבה עשוי להזדקק למודל מחולל. האפשרות הקטנה יותר יכולה להיות קלה יותר להפעלה, בדיקה ותחזוקה. 3. נקה ועצב את הקלט שנאי לא רואה טקסט באותו אופן שאני רואה. הוא מקבל אסימונים, מסכות קשב וערכים מספריים אחרים. בעיות קלט קטנות יכולות להשפיע על הפלט. לפני שליחת טקסט לדגם, אני בודק אם: - שדות ריקים - רווחים חוזרים - תווים שבורים - תוויות רמקולים לא ברורות - תוכן כפול - הוראות נסתרות בתוך נתוני משתמש - טקסט החורג ממגבלת המודל נניח שאני בונה מסווג סקירה. שתי התשומות הללו עשויות לשאת אותה משמעות: > "המשלוח איחר, אבל המוצר עובד היטב." > "משלוח מאוחר. המוצר עובד היטב." מודל עשוי להתייחס אליהם בצורה שונה כאשר נתוני האימון מכילים סגנונות כתיבה לא עקביים. אני שומר על הפורמט יציב ככל האפשר ומשמר הקשר שימושי. עבור מערכת צ'אט, אני מתייג כל תפקיד בצורה ברורה: טקסט מערכת: תשובה באמצעות מדריך המוצר המצורף. משתמש: כיצד אוכל לשנות את כתובת המשלוח שלי? הקשר: [טקסט מדריך למוצר] מבנה ברור נותן לדגם אות טוב יותר מאשר בלוק ארוך של תוכן מעורב. 4. השתמש בהנחיות ובדוגמאות מדויקות הנחיה אמורה לומר לדגם מה לעשות, ממה להימנע וכיצד לעצב את התוצאה. לעתים קרובות אני כולל דוגמה אחת או שתיים כאשר למשימה יש סגנון ספציפי. הוראה חלשה עשויה לומר: > "עיין בהודעה זו." גרסה ברורה יותר יכולה לומר: > "סווג את ההודעה כחיוב, גישה לחשבון, מסירה או אחר. החזר תווית אחת וסיבה קצרה אחת. אל תיצור עובדות שאינן בהודעה." דוגמאות יכולות להפחית את הווריאציות: הודעת טקסט: אני לא יכול להיכנס לאחר שינוי הסיסמה שלי. תווית: גישה לחשבון סיבה: המשתמש מדווח על בעיית כניסה. ההנחיה הטובה ביותר היא לא תמיד הארוכה ביותר. הוראות נוספות יכולות להתחרות במשימה העיקרית. אני מסיר כל שורה שלא עוזרת לדגם להחליט, לכתוב או לעצב את התשובה. עבור תוכן שנוצר, אני מגדיר את רמת הקהל ורמת הקריאה. הסבר על מוצר עבור משתמשים חדשים לא אמור להישמע כמו עבודת מחקר. הערה טכנית למהנדסים יכולה לכלול מונחים שיבלבלו קורא כללי. 5. שליטה בהקשר ובאורך הקלט הקשר ארוך יכול לעזור למודל למצוא פרטים, אך לא תמיד יותר טקסט מייצר תשובה טובה יותר. קטעים לא רלוונטיים עשויים להסיח את דעתו של המודל או לדחוף מידע שימושי מעבר לתשומת הלב היעילה שלו. אני מחלק מסמכים גדולים לקטעים קטנים יותר ומחזיר את הקטעים הקשורים לשאלת המשתמש. כל סעיף יכול לכלול כותרת קצרה והפניה למקור. עבור עוזר מדיניות חברה, אני עשוי לאחסן: טקסט סעיף: חלון החזר טקסט: לקוחות יכולים לבקש החזר כספי תוך 30 יום מהרכישה. מקור: מדיניות החזרים כספיים, עמוד 2 כאשר משתמש שואל על החזרים, המערכת יכולה לשלוח את הסעיף הרלוונטי במקום את מדריך המדיניות המלא. קבעתי גם אורך תגובה ברור. בקשה כמו "הסבר את זה בשלוש נקודות באמצעות אנגלית פשוטה" קלה יותר לשליטה מאשר "תן תשובה מפורטת". כאשר הקלט ארוך, אני בודק אם המודל עדיין משתמש במידע ליד ההתחלה, האמצע והסוף. בדיקה פשוטה זו יכולה לחשוף בעיות הקשר לפני שמשתמשים מדווחים עליהן. 6. מבחן עם ערכת הערכה קטנה ושימושית אני לא מסתמך על כמה דוגמאות מוצלחות. אני יוצר ערכת מבחנים שמשקפת את השאלות שסביר שהמשתמשים ישאלו. עבור מודל שירות לקוחות, הסט עשוי לכלול: - בקשות ברורות - הודעות קצרות - שגיאות כתיב - מספר בעיות בהודעה אחת - בקשות עם פרטים חסרים - שאלות מחוץ לתחום המערכת - מידע רגיש שלא אמור להופיע בתגובה אני משווה את פלט הדגם עם תשובה או תווית שאושרו על ידי אדם. לצורך סיווג, אני יכול לעקוב אחר דיוק, דיוק, זכירה ובלבול בין תוויות. לדור, אני סוקר את הדיוק העובדתי, הרלוונטיות, הטון והפורמט. מקרה מבחן שימושי נראה כך: קלט טקסט: הכרטיס שלי חויב פעמיים עבור אותה הזמנה. תווית צפויה: חיוב פעולה צפויה: בקש את מספר ההזמנה ותאריך התשלום. ``` אני מקליט את גרסת הדגם, הבקשה, פורמט הקלט וההגדרות. כאשר תוצאה משתנה, אני יכול לאתר את הסיבה במקום לנחש. 7. הוסף אמצעי הגנה וסקור את הפלט שנאי יכול להפיק טקסט שוטף המכיל שגיאה. דקדוק טוב אינו הוכחה שהתשובה נכונה. אני מוסיף בדיקות שמתאימות למשימה: - דורש קבוצה קבועה של תוויות - אימות JSON לפני השימוש בו - חסימת טענות שאינן נתמכות - הצג קטעי מקור לתשובות עובדתיות - מסווה נתונים אישיים בעת הצורך - שלח מקרים לא ודאיים לאדם - שמור יומנים ללא אחסון נתונים שאינם נחוצים עבור עוזר תמיכה במוצר, ייתכן שאדרוש מכל תשובה להשתמש במידע ממדריך המוצר. אם המדריך אינו מכיל תשובה, על העוזר לומר שחסר לו מספיק מידע ולהציע ערוץ תמיכה. אני גם בודק תשומות חריגות. משתמש יכול להדביק הנחיה שמנסה לשנות את הכללים של האסיסטנט. המערכת צריכה לשמור נתונים נפרדים מהוראות ולהחיל בקרות גישה מחוץ למודל. דפוס מעשי אחד הוא שימוש בספי ביטחון לסיווג. אם הדגם בטוח שכרטיס נוגע לחיוב, האוטומציה עשויה להימשך. אם התוצאה אינה ודאית בין חיוב וגישה לחשבון, איש צוות יכול לבדוק זאת. תוצאות שנאי טובות יותר מגיעות בדרך כלל מתהליך שלם, לא מהגדרה אחת או מבחירת דגם אחת. אני מגדיר את המשימה, בוחר מודל מתאים, מכין תשומות נקיות, מנחה את התגובה, שולט בהקשר, בודק מקרי משתמש אמיתיים וסוקר פלטים לא ודאיים. תרגיל התחלה שימושי הוא פשוט: קח עשרים דוגמאות טיפוסיות ממקרה השימוש המיועד, כתוב את התוצאות הצפויות והפעל את אותה הנחיה או מודל כנגד כולן. הפערים הופכים קלים יותר לראות. משם, אני יכול לשפר את הנתונים או ההוראות לפני שינוי המערכת כולה. לכל שאלה בנוגע לתוכן מאמר זה, אנא צור קשר עם איימי וו: amy.wu@ihuagroup.com/WhatsApp +8613612662976.

Vaswani, A et al (2017) Attention Is All You Need Devlin, J et al (2018) BERT אימון מקדים של רובוטריקים דו-כיווניים עמוקים להבנת שפה Liu, Y et al (2019) RoBERTa A Robustly Optimized BERT Pretraining Approach Raffel, C et al (2020) Transformer Text-to-Text Wolf, T et al (2020) רובוטריקים עיבוד שפה טבעית עדכנית Kaplan, J et al (2020) חוקי קנה מידה עבור מודלים של שפה עצבית