TL;DR
- אנוטציות לא ניתנות להרחבה. ניהול מנוע נתוני אנוטציות הוא יקר, גוזל זמן ובעייתי.
- דיברנו על כך בפוסט הקודם שלנו כאן. המסקנה? הפיכת מערכי נתונים לניתנים לפרשנות היא חיונית למניעת כשלים קריטיים במודל ולהימנעות מיצירת תוכן מזיק.
אז אם כך, מדוע אנוטציות כל כך קריטיות לרוב חברות הבינוע המלאכותי?
כשמשהו עדיף על כלום
לכל מעריצי הארי פוטר שם בחוץ, בניית מערכת AI יכולה להרגיש כמו שיעור שיקויים. לפעמים, השילוב הנכון של נתונים, אלגוריתמי אימון וקנה מידה יוצר מודל מדהים. אבל להבין את המתכון המדויק - אילו נתונים להשתמש, איזה מודל לנסות, אילו אלגוריתמי אימון להפעיל ואילו היפרפרמטרים לכוונן - זה קשה להפליא.
עבור רוב החברות שמפרסות מערכת AI חדשה, הגישה הפשוטה ביותר היא לאסוף תוויות למשימה הנדונה.
- מאמנים רובוט חדש? אספו ותייגו מסלולים (תיבות תוחמות, פילוח וכו').
- מיישרים LLM עם תקני בריאות או משפט? אספו מספר פלטים של מודלים ובקשו מבני אדם לדרג אותם לפי העדפה כדי לאמן מודל תגמול עבור RLHF או לכוונן LLM ישירות עם DPO.
- מחפשים אנשים בסרטונים? אספו תיבות תוחמות.
- מסווגים חלקים פגומים? תייגו תמונות כפגומות או לא.
גישה זו עובדת היטב בהתחלה כי משהו תמיד עדיף על כלום. מסטארטאפים ללא נתונים ועד ארגונים עם אקסהבייטים של נתונים, רוב הצוותים מתחילים באיסוף תוויות כי הקמת אב טיפוס עובד היא העדיפות העליונה. הגישה הידנית הזו נמשכת עד שהיא מפסיקה לעבוד. בדרך כלל רק כשהרווחים מהוספת תוויות נוספות פוחתים, חברות בודקות שיטות אחרות כמו אימון מקדים, מודלים גדולים יותר או בדיקת מערכי נתונים. בדיקת נתונים עדיין נחוצה, אבל היא בדרך כלל מגיעה אחרי שמודל בסיס כבר פונקציונלי.
תזוזו מהר, תייגו מהר יותר
חברות מחליטות בחוכמה לשלוח MVP גס ולחזור על התהליך. לכך, אנחנו אומרים שתהליך התיוג שלכם צריך לנוע מהר כמו פיתוח ה-AI שלכם.
לכן ב-Interpret AI, אנחנו בונים Agentic Annotations. זה פשוט:
- ספקו הנחיה אחת המתארת איך אתם רוצים שהנתונים שלכם יתויגו.
- חזרו על כמה דוגמאות מגוונות שנבחרו על ידי מודל היסוד שלנו.
- כשאתם מוכנים, תייגו מראש את שאר מערך הנתונים העצום שלכם אוטומטית - אין יותר צוואר בקבוק אנושי.
שירותי תיוג מסורתיים כמו Scale AI, Surge ו-Labelbox כולם חולקים את אותה הבעיה הבסיסית: בן אדם חייב לבדוק ולתייג כל דגימת נתונים בודדת. זה צוואר הבקבוק שאחרים מנסים לפתור על ידי זריקת יותר אנשים על הבעיה. אנחנו מאמינים שאחרי שכמה דוגמאות מתויגות, השאר צריך להיות אוטומטי. חברות שמנסות להגיע מ-0 ל-1 פשוט צריכות תוויות מספיק טובות כדי להניע את גלגל התנופה.
מה התפיסה?
מובן מאליו שתיוגים ידניים באיכות גבוהה הם בדרך כלל טובים יותר מתיוגים מקדימים אוטומטיים. עם זאת, תיוג ידני יכול לקחת חודשים, בעוד שתיוגים מקדימים יכולים להסתיים בימים או אפילו שעות. צוותי ML לעתים קרובות מנסים להימנע מתוויות ידניות יקרות על ידי שימוש ב-judge-LLMs, מודלי יסוד כמו SAM, או טכניקות אחרות כדי לקבל תוצאות "מספיק טובות". האמונה שלנו, עם זאת, היא שצוותים שבונים מוצרים חדשים נהנים הכי הרבה מהתמקדות בפיתוח המודל שלהם, לא בבניית פלטפורמות תיוג פנימיות.
ארבעה שלבים למוצר AI עובד
חברות שרוצות שמערכות ה-AI שלהן יפתרו צרכי לקוחות אמיתיים צריכות לשאול ארבע שאלות בסיסיות:
- הגדירו את המשימה: מה המודל AI שלכם צריך לעשות? (למשל, לקבוע מדיניות לרובוטים, לזהות איומי אבטחת סייבר, ליצור טקסט תמיכת לקוחות).
- זהו את הנתונים: אילו נתונים נדרשים כדי לאמן את המודל שלכם? (למשל, מסלולי רובוטים, תמונות של סחורה פגומה, דוגמאות של תמיכת לקוחות טובה ורעה).
- הקימו תהליך הערכה: איך תעריכו את המודל שלכם על בנצ'מרקים ועם לקוחות? בעוד שתיוג ידני הגיוני עבור מערכי נתונים קטנים וקריטיים, Agentic Annotations מציעים אלטרנטיבה תקפה להשגת תוצאות מוכנות לשוק הרבה יותר מהר.
- אבחנו ביצועים נמוכים: מה הגורם השורשי כשהמודל שלכם נכשל? האם זו בעיית נתונים או בעיית מודלינג? פלטפורמת בדיקת נתונים יכולה לזהות פערי נתונים או אנומליות.
בעוד שכל השאלות הללו חיוניות, ב-Interpret, אנחנו עוזרים עם (3) ו-(4). להערכה (3), מפתחים יכולים להשתמש ב-Agentic Annotations שלנו כדי לתייג נתונים במהירות ולבדוק מודלים. לאבחון ביצועים נמוכים (4), כשמודל לא עובד כצפוי, פלטפורמת בדיקת הנתונים שלנו הופכת את הנתונים שלכם לאינטראקטיביים כך שתוכלו להבין מה גורם לבעיה.
תעדוף הבנת נתונים, הערכת מודלים וחזרות תיוג מהירות יעמידו את הצוות שלכם על המסלול המהיר ביותר למוצר AI עובד.