Inside Android Skills - Built for deprecation

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

למה יש כל כך מעט מיומנויות רשמיות?

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

עד עכשיו השקנו כ-20 מיומנויות רשמיות, והן מכוונות בכוונה לתחומים ספציפיים מאוד שמתפתחים במהירות, ושמודלים רגילים עדיין לא מבוססים עליהם באופן מלא – דברים כמו AGP 9,‏ Navigation 3,‏ ממשקי API מתקדמים של מצלמה ו-Perfetto SQL.

מה לגבי מיומנויות ליבה כלליות יותר? כל מיומנות מותקנת מוסיפה 100-200 טוקנים להקשר הבסיסי של כל משימה שמתחילים. אם המיומנות הזו מופעלת בפועל, המספר הזה יכול להגיע במהירות לאלפים. ברוב המקרים, אגירת כישורים בסיסיים היא לא יעילה ויקרה. לפני שמתקינים מיומנות לכתיבת קוד בסיסי ב-Kotlin או ב-Compose, כדאי לשקול אם באמת צריך את זה במודל ה-LLM שבחרתם, או שהוא כבר מכיר את הנושאים האלה מספיק טוב. 

הערכת מיומנויות

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

timeout_s: 1200
repository:
  url: [redacted - internal git repo]
  working_dir: wear_compose_m3_empty_app
category_ids:
  - wear
prompt: |-
  Add a horizontal pager to MainActivity.kt. Have three pages in the pager. Each page should contain
  the text "Page 1", "Page 2", and "Page 3" respectively in the center of the screen.
commands:
  build:
    - ./gradlew assembleDebug
acceptance_criteria:
  project_builds: true
  llm_diff_judge:
    - Must use `HorizontalPagerScaffold`.
    - Each page should use `AnimatedPage` to wrap a `ScreenScaffold`.

דוגמה לפונקציית eval שבודקת את ההטמעה הנכונה של רכיב pager אופקי באפליקציית Wear

לפחות, אנחנו בודקים את המיומנות ב-Android Studio באמצעות מודל Gemini Flash העדכני. בהתאם למיומנות, אנחנו גם מוודאים תאימות למודלים אחרים כמו Gemini Pro ולסוכנים אחרים כמו Antigravity, ולמערכות של צד שלישי.

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

שימוש במאגר הידע של Android (Android Studio או Android CLI)

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

אם אתם חושבים שהמודל בטוח מדי בעצמו, ואתם רוצים שהוא יעיין במסמכי התיעוד לעיתים קרובות יותר, דרך נפוצה מאוד לעודד אותו לעשות זאת היא להוסיף את הטקסט 'Always consult the official Android documentation when dealing with Android APIs' (תמיד צריך לעיין במסמכי התיעוד הרשמיים של Android כשעובדים עם Android API) לקובץ AGENTS.md או לקובץ מקביל. כמובן, אפשר גם לבקש מהסוכן לבדוק את התיעוד ישירות בהנחיות.

למה בקשות משיכה מושבתות?

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

מתי כדאי להשתמש במיומנויות בסיסיות או במיומנויות ליבה?

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

• ההנחיות שלכם לא ברורות: היכולות משפרות את הכוונה שלכם. אם נותנים הנחיה כללית כמו 'הוספת אנימציות למסך הזה', מיומנות ספציפית של אנימציה ב-Compose יכולה לתת השראה למודל, ולדחוף אותו לכיוון של ממשקי API מודרניים או דפוסי בדיקה של צילומי מסך שאולי לא היו נלקחים בחשבון אחרת.
• אתם רוצים להשתמש במודלים קטנים וזולים יותר: מודלים של LLM מתקדמים הם יקרים. אם אתם מעבירים משימות שגרתיות למודלים קטנים יותר בקוד פתוח כמו Gemma 4, הפעלת מיומנויות בסיסיות תעזור לכם למלא את פערי הידע שפרמטרים קטנים יותר לא מצליחים למלא.
• אתם מבצעים רפקטורינג או בודקים קוד מדור קודם: מודלים מצטיינים ביצירת קוד שעובד, אבל כשעורכים בסיסי קוד ישנים, הם לרוב נותנים עדיפות לשמירה על עקביות עם דפוסי השימוש הקודמים, במקום לשכתב את הדברים עם דיוק מודרני. נציג מומחה לבדיקת תוכן שמצויד בכישורים בסיסיים יכול לעזור לכם לשבור את ההרגל הזה.
• אתם חורגים מהנורמה: מודלים של שפה גדולה (LLM) אוהבים את הדרך הסטנדרטית של Google לתכנון אפליקציות ל-Android. אם הצוות שלכם משתמש בארכיטקטורה של שכבת תצוגה בהתאמה אישית גבוהה, המודל יתקשה לשמור על התאמה. מומלץ ליצור סקיל בהתאמה אישית שמתאר במפורש את הארכיטקטורה שלכם.

איפה אפשר למצוא מיומנויות ליבה?

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

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

יעד: הוצאה משימוש

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