מודל AI נשמע מצוין בעברית? מבחן עיוור קטן יכול לחשוף את הטעות

|כותב: מערכת QUASA|5 דק׳ קריאה| 1
מודל AI נשמע מצוין בעברית? מבחן עיוור קטן יכול לחשוף את הטעות

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

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

בונים מדגם מהעבודה האמיתית

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

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

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

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

מגדירים רובריקה לפני ההרצה

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

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

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

מריצים את אותן משימות בדירוג עיוור

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

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

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

מודדים את המחיר עד לתוצר שמיש

תשובה עסקית בעברית עשויה להיראות מהירה להפקה אך לדרוש עבודת תיקון ממושכת לפני שימוש.

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

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

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

קובעים תנאי מעבר או עצירה

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

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

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

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

קראו גם:

שיתוף:

כתבות קשורות

הירשמו לניוזלטר שלנו

קבלו את החדשות האחרונות על Web3, ‏AI וקריפטו ישירות לתיבת הדואר.

0