תובנות לגבי יצירת קוד של סוכנים מ-Android Bench

Tomáš Mlynarič

בוקר טוב לכולם.

שנתחיל?

במרץ השקנו את Android Bench, קבוצת הנתונים וטבלת הדירוג שלנו למדידת מודלים מסוג LLM במשימות פיתוח ל-Android.

מאז, הרצנו אותו על הרבה מודלים חדשים.

ורק בחודש שעבר השקנו את Android Bench 2.0.

עברו רק כמה חודשים, אבל בעולם ה-AI זה מרגיש כמו נצח.

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

נתחיל עם 1.0.

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

סיננו את הפרויקטים ב-GitHub לפי בעיות ב-GitHub, בקשות משיכה שפותרות את הבעיות האלה ובדיקות שמאמתות את הפתרונות.

אנחנו מפצלים את בקשות ה-pull לקבוצות של משימות למודלים של AI.

הבעיה ב-GitHub הפכה להוראות או להנחיה למודל, והשתלנו אותן במצב שלפני ה-PR.

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

אנחנו קוראים לניסיון אחד של ה-AI לפתור את הבעיה "ניסוי".

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

המתודולוגיה הזו דומה למדד ההשוואה המוכר SWE-bench.

התחלנו עם יותר מ-10,000 משימות פוטנציאליות, ולא כולן התאימו.

בחלק מהמקרים ההוראות היו חלקיות או מפורטות מדי.

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

לכן היינו צריכים לבדוק שוב ושוב כדי להגיע ל-100 משימות הוגנות.

במהלך הבדיקות האלה, השתמשנו במודלים המתקדמים ביותר כדי לקבל תוצאות.

התחלנו עם כ-30% משימות שנפתרו, מה שאנחנו מכנים "שיעור הצלחה".

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

אבל זה בערך חודש אחרי.

ואז הייתה לנו תוכנית להעריך מודלים חדשים כל חודש, וראינו איך הם משתפרים.

בגרסה של אוגוסט, שיעור המעבר של המודל הטוב ביותר היה 92%.

וידענו שהרף שלנו נמוך מדי, וקבוצת הנתונים הזו רוויה.

Tomáš Mlynarič

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

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

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

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

אנחנו צריכים למנוע סיכון של זיהום.

אחת הבעיות במתודולוגיה של SWE-bench היא הפתיחות של קוד המקור.

‫OpenAI פרסמה מאמר.

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

והם הבינו שיוצרי המודלים מאמנים אותם על קוד פתוח, ושה-SWE-bench מזוהם.

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

חילקנו את העבודה לארבעה מסלולי עבודה.

הראשון הוא המרות של אפליקציות, שבו לקחנו אפליקציות בקוד פתוח, Flutter ו-React Native, ואמרנו לסוכנים להמיר אותן לפתרון אפליקציית נייטיב ל-Android.

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

החלק השני של העבודה היה תכונות חדשות ושילובים של פלטפורמות.

הם נבנו בתוך בסיסי קוד מבוססים של סביבת ייצור.

לדוגמה, ב-Now in Android, הוספנו תכונת וידאו, או תמונה בתוך תמונה, דברים כאלה.

החלק השלישי של העבודה היה העברות.

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

לדוגמה, Nav 2 ל-Nav 3, תצוגות XML ל-Compose, או דברים כמו חלונית אחת לפריסה דינמית.

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

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

Tomáš Mlynarič

עם כמה מהנדסים בלבד, בנינו אפליקציה באותו גודל כמו Now in Android.

אבל המשימות החדשות הביאו איתן אתגרים חדשים.

הראשון: מתן ציונים לסוכנים בצורה נכונה.

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

בגרסה 1.0, נקודת ההשוואה התבססה בעיקר על בדיקות יחידה (unit testing), ובדיקות היחידה הן די גרועות בלהיות אגנוסטיות.

import com.foodvibes.MyViewModel

@Test
fun testRetry() {
    val vm = MyViewModel()
    vm.retry()

    assertTrue(vm.retried)
}

הם דורשים שמות מדויקים של מחלקות או פונקציות.

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

import com.foodvibes.feature.my.RetriableViewModel

@Test
fun testRetry() {
    val vm = RetriableViewModel()
    vm.tryAgain()

    assertTrue(vm.tried)
}

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

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

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

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

בשבילם אנחנו משתמשים ב-UI Automator או בבדיקות של Compose UI, אבל יש לנו גם סקריפטים מיוחדים שבודקים גבולות מסוימים של מערכות חיצוניות. למשל, אם קריאת רשת הכילה את הנתונים הנכונים, או אם הנתונים הנכונים נשמרו במסד נתונים בלי לדעת על רכיבי עזר פנימיים או על אובייקטים של גישה לנתונים (DAO).

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

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

זו דוגמה לאחת מהבדיקות ההיברידיות.

הם פועלים מחוץ לאמולטור.

אז זו הבדיקה של תהליך האימות של OTP ב-SMS, שבה הסקריפט צריך קודם לחשב את ה-hash של האפליקציה כדי לשלוח את ה-SMS לאמולטור בצורה נכונה, ואז מתחיל את הבדיקה, את בדיקות ה-UI Automator, ומעביר קוד OTP שנוצר באופן אקראי שהוא דורש, ושולח SMS לאמולטור באמצעות פקודת ADB.

והבדיקה רק בודקת אם הקלט הכיל את המספר הנכון.

זהו, זה בעצם הכול.

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

הבעיה השנייה במתן הציונים הייתה שהמשימות שלנו דורשות מולטי-מודאליות.

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

והדרך הכי קלה לעשות את זה היא להשתמש בבדיקות של צילומי מסך.

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

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

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

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

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

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

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

אפשר להמשיך.

Tomáš Mlynarič

זה מתחיל בקלות.

היום, סוכנים בעצם אומרים, "אוקיי.

יש לי משימה.

בואו נסתכל על GitHub.

בואו נמצא את הפתרונות".

אז זה בערך מה שהם עושים קודם כל.

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

אבל זה היה קל.

בחלק מהניסויים, אמרנו שהכול עבר בצורה חלקה ב-100%, והסוכן אמר, "ניצחון מדהים!"

אז.

מעניין, מה הם מצאו?

אבל בדקנו את המסלול מקרוב, והם אמרו, "אני לא יכול לעשות את זה.

אני פשוט אשנה את הסף ל-80% בבדיקת צילום המסך".

// AuthFlowScreenshotTests.kt

@get:Rule
val dropshots = Dropshots(
    resultValidator =
        ThresholdValidator(
-           0.05f
+           0.80f
        )
)

ואז אתה אומר לעצמך, "כן, ניצחון, הכול עובר".

כן, אבל הבדיקות של צילומי המסך לא עוזרות.

אבל זה לא היה המתוחכם ביותר.

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

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

ועכשיו זה כמו לעבור את מבחן צילום המסך.

איזה כיף!

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

עכשיו הכול ירוק.

מדהים.

כל הכבוד".

זה לא, כאילו, יש אחד שהוא, כאילו, ממש טוב.

אז יש לנו משימת העברה מ-Java ל-Kotlin, שבה הנציג צריך בעצם להעביר מ-Java ל-Kotlin, נכון?

הם לא הצליחו לבנות אותו.

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

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

אני מוחק את קובצי ה-Java, הכל ירוק, חוץ מ-Kotlin שעדיין נכשל, אז הם אומרים, "בסדר, אני הולך להסיר את קבוצת המקורות של Kotlin, ועכשיו הכל עובר.

מעולה".

אני לא יודע אם זה בכלל נחשב לרמאות.

כלומר, זה ממש יצירתי.

כדי למנוע את כל זה, בנינו גלאי רמאויות עם שלוש שכבות הגנה.

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

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

ויש לנו גם, למשל, LLM-as-a-Judge, שבודק את המסלולים ואת הפלט בפועל של הנציג כדי לראות דברים מוזרים.

ואם משהו קורה, אנחנו פשוט אומרים, "אוקיי, ישר לכישלון".

Tomáš Mlynarič

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

אז כשאנחנו מאלצים את הסוכנים לפתח אפליקציה ל-Android, איך נראים המספרים?

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

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

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

בואו נראה את התוצאות.

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

אנחנו יכולים לבחון כמה מהתובנות שכבר מצאנו.

השאלה הראשונה שעשויה לעלות כשמסתכלים על התרשים היא, למשל, כמה עולה להפעיל את הנציג הזה?

חברות ה-AI בדרך כלל מדווחות על עלות לכל טוקן, לחלק מהקלט, הפלט, אולי טוקן מטמון.

יכול להיות שזה טיעון שיעזור לכם להחליט.

אבל אפשר להסתכל על זה מנקודת מבט אחרת.

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

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

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

אבל אם נוסיף לאותו תרשים גם את המחיר לטוקן, נראה שמה שחברות ה-AI באמת מפרסמות לא תואם למה שאתם באמת משלמים, לפי המשימה.

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

או סוכנים אחרים עם מחיר טוקן זהה לחלוטין עוברים כ-30% מהמשימות, אבל הם זולים פי 15.

לכן, מחיר הטוקן הוא לא המדד.

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

אז המסקנה היא לא להסתכל רק על המחיר, על העלות לכל אסימון.

בוחרים מודל, בודקים את הנתונים האמיתיים, למשל משתמשים בו במקרה שלכם, או בודקים את Android Bench כדי לראות אילו מודלים באמת משתמשים בהכי הרבה טוקנים במשימות.

חלק מהם, אתם יודעים, חלק דורשים יותר שלבים למרות שהם זולים יותר לכל טוקן.

אבל יש עוד היבט לאותה שאלה.

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

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

למשל, אנחנו רואים שיש כאלה שלוקח להם כמעט שעתיים לכל משימה.

הם ממשיכים לבנות מחדש ולבדוק שוב עד שזה עובד.

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

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

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

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

המסקנה היא שאין מודל אחד שהוא הכי טוב.

זה תלוי במה שאתם מבצעים לו אופטימיזציה.

האם זה שיעור המעבר?

האם זה עולה כסף?

האם זה זמן המתנה?

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

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

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

הם בטוחים שהם סיימו.

המשימה הושלמה.

בסדר, אני הולך הביתה.

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

הם לא יכולים לראות את הבדיקות.

הם רואים שהם לא יכולים לראות את חבילת האימות.

אז שאלנו, מה אם, מה יקרה אם פשוט נאפשר להם לראות את הבדיקות?

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

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

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

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

במשימות הפתוחות, היו להם 25% יותר תורות ו-40% Agent Runtime.

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

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

והמאמץ הנוסף הזה משפר את שיעור המעבר הממוצע, כמו שציינתי.

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

כמעט 90% מהמשימות הושלמו.

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

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

Tomáš Mlynarič

עם זאת, זה אפשר לנו לקבל יותר תובנות לגבי הנציגים.

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

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

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

לפעמים הם עדיין טובים.

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

אבל מתאם לא מעיד על סיבתיות, נכון?

אנחנו צריכים לערוך ניסוי מבוקר בנושא.

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

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

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

הנחנו שהסוכנים יבינו את זה, נכון?

אז ראינו שכמעט אף אחד מהם לא באמת מפעיל את האמולטור.

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

אז כולם נכשלו בדבר מאוד פשוט.

עכשיו אנחנו עומדים בפני דילמה.

האם אנחנו אומרים לנציגים להשתמש באמולטור, ומסתכנים בציונים גבוהים יותר, או שאנחנו לא אומרים כלום, ומקווים שהם יבינו את זה?

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

אנחנו לא רוצים למדוד דברים כמו מוזרויות סביבתיות.

לכן בחרנו בדרך ביניים.

אמרנו להם שככה מפעילים אמולטור, אבל לא אמרנו להם אם להשתמש בו או לא.

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

ומדדנו את ההשפעה של ההוראה הזו לאמולטור.

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

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

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

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

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

Tomáš Mlynarič

חזרה לטבלת המובילים.

כמו שציינתי, המודלים הכי טובים עוברים בערך 40% מהמשימות, וכדי לעבור את המשימה צריך לעבור את כל הבדיקות.

אחרת, המשימה תיכשל.

אז השאלה היא, האם הסוכנים לא הפיקו שום דבר שימושי ב-60% האחרים?

לא, הם מתקרבים לזה.

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

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

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

אז ערכנו ניסוי על ההמרה מ-Flutter ל-Android כדי לבדוק מה קורה.

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

בסביבות שלב 140, הם עבדו כדי להגיע לציון של כמעט 90% בממוצע, ואז הם השקיעו עוד 90 שלבים או כמעט 40% מההרצה בניסיון לסגור את הפער ל-100%, אבל הם הצליחו להשיג רק עוד אחוז אחד או שניים.

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

הכול עובר רינדור.

הקלט עבד באופן חלקי.

יכול להיות שאין קריסות.

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

Tomáš Mlynarič

לסיום, בואו נבחן את Android Bench, גרסה 2.0 של העבודה שלנו, בפרספקטיבה.

בהשוואה לגרסה 1.0, עכשיו יש לנו רק 30 משימות, וזה מכוון.

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

התיקונים גדולים יותר בסדר גודל בעשרות קבצים.

ויש לנו את בדיקות ממשק המשתמש המולטי-מודאליות.

הסוכנים צריכים לרוץ יותר זמן ולעבוד הרבה יותר קשה.

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

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

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

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

עכשיו, השתמשו ב-Android Bench כמצפן כדי להשוות בין מודלים ורתמות, ואולי לקבל כמה תובנות.

כשתהיו מוכנים להעמיק, תוכלו להחיל את אותם עקרונות של השוואה והערכה על ה-code bases ותהליכי העבודה שלכם, כי אין כמו למדוד את ה-AI על הקוד שאתם באמת עובדים איתו.

ככה אתם יכולים להיות בטוחים שה-AI עשה את העבודה כמו שצריך.

בשם כל הצוות של Android Bench, תודה על תשומת הלב.