תהליכי עבודה אג'נטיים של תכנות עם מודלים קטנים

טוב.

שלום לכולם,

קוראים לי יוסי, ואני כאן עם אילן וזהר.

כולנו מכירים את המודלים הגדולים של שפה (LLM).

אנחנו משתמשים בהם לכל דבר: למציאת מתכונים, לסיכום סרטונים ב-YouTube ולתכנות.

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

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

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

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

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

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

אז כמה עולה מודל פורץ דרך?

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

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

כן, כן.

אז עכשיו, השאלה המתבקשת היא מה ההבדל באיכות ובדיוק?

בקבוצת הנתונים הספציפית הזו, Gemma 4 יכול לפתור 53% מהמשימות.

זה אומר שני דברים.

אם אתם משתמשים במודל פורץ דרך כדי להריץ את המשימות שמימין, יכול להיות שזה מיותר.

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

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

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

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

עכשיו נעבור לזואי.

תודה רבה, יוסי.

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

היא יעילה, אבל קצת לא פרופורציונלית.

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

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

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

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

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

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

לכן, אנחנו יכולים לעבוד בצורה לא לינארית.

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

זה כמעט כמו שרטוט שמתחיל להתמקד.

במקרה הזה, DiffusionGemma עובד על מקטעים של 256 טוקנים בכל פעם.

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

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

לא נכון.

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

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

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

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

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

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

אוקיי, אז יש הרבה אפשרויות, נכון?

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

אז איך בוחרים מודל קטן?

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

אליך, איאן.

תודה, זואי.

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

אבל למה כדאי לבחור במודל מקומי?

אז זה מסתכם בארבעה דברים בערך.

הראשון הוא פרטיות.

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

השני הוא זמן אחזור.

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

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

השלב הבא הוא עלות שולית אפסית.

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

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

זה לא עולה לכם כלום, ואין עלויות API מפתיעות בחלק הזה.

והאפשרות הרביעית היא גישה אופליין.

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

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

אז אחד זה זיכרון, והשני זה מהירות.

אז אם תסתכלו על הדיאגרמה הזו, בשני המודלים התחתונים, 26B ו-31B, שניהם דורשים יותר מ-50GB של זיכרון RAM של וידאו כדי לפעול ב-BF16, שהוא קוונטיזציה של 16 ביט.

האתגר הוא שזה לא יתאים להרבה סוגי חומרה.

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

עכשיו זה קצת יותר הגיוני.

אנחנו מדברים על 14GB ו-17GB, נכון?

עכשיו אפשר להריץ אותו על מכשירים כמו מחשבי Mac עם זיכרון מאוחד.

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

הוא נקרא "אימון מודע לקוונטיזציה".

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

כך אנחנו מקבלים הפחתה של 75% בדרישות ה-RAM, ועכשיו הוא יכול להתאים למכשירים האלה.

אנחנו עושים צעד אחד נוסף.

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

אז יש לנו סוג של שקית קוונטיזציה מעורבת.

כך אנחנו עוברים מ-Gemma E2B בנפח 11.4GB ל-1.1GB.

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

הגורם הבא הוא מהירות.

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

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

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

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

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

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

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

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

אז שוב, זה תלוי קצת במשימה שאתם מבצעים.

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

אז איך בעצם מעריכים מודל כזה?

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

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

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

אז זה המודל שבו אתם משתמשים, המשקלים וגישת הקוונטיזציה, זה ההסקה של זמן הריצה, אז אתם יכולים להשתמש במשהו כמו llama.cpp או Ollama או LiteRT, המעטפת האג'נטית שבה אתם משתמשים, בין אם זה כמו Pi או OpenCode או Antigravity, ואז חלון ההקשר, שהוא סוג של המרחב לכל הנתונים שאתם רוצים שהמודל שלכם יוכל לעבד.

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

לדוגמה, ערכנו כמה בדיקות עם Gemma 4 ב-Android Bench, והרצנו גרסת Ollama עם הקשר ברירת מחדל של 32k.

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

אז רק על ידי הגדלת ההקשר מ-32,000 ל-256,000, עכשיו הוא יכול לשמור את זה בזיכרון, והמודל יכול לעבור את הבדיקה הספציפית הזו.

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

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

אז איך בעצם מבצעים הערכות משלכם?

הנה שלוש הצעות מהירות.

אז אפשרות אחת היא לקחת היסטוריית Git, כלומר אוסף של בקשות משיכה (PR) שכבר הצליחו, ולהשתמש בהן כהנחיות קלט למודל ולראות איך הוא מתפקד איתן.

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

יש לנו שתי דוגמאות ממש טובות לכך.

יש לנו קומפיילר ויש לנו בדיקות יחידה.

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

והשלישי הוא מסלולי יומן.

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

ואני רוצה שתנסו לשנות את ניסוח השאלה מ"האם המודל הזה חכם כמו המודל פורץ הדרך הגדול הזה?"

לשאלה "האם אפשר לבצע את המשימה הזו בחומרה הזו עם ההגדרה הספציפית הזו?"

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

או AWTY.

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

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

כך תוכלו לדעת אם אתם מוכנים.

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

אם מריצים אותה, נניח, 10 פעמים ברצף, היא עושה את אותו הדבר בכל פעם?

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

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

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

ואז אולי תבדקו את דרישות ה-RAM.

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

אז אפשר להשתמש ב-50% או רק ב-10% מה-RAM?

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

אם הוא ירוק, סימן שההגדרה מוכנה.

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

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

אז כן, כדאי לבדוק את זה.

יש לנו כרגע גרסת טרום-השקה (Preview) ונשמח לקבל ממך משוב על מידת התועלת של הכלי הזה.

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

תודה, איאן.

אז כן, הדרך הכי מהירה לנסות את Gemma 4 היום היא כנראה דרך Android Studio.

אני אראה לכם איך עושים את זה.

בואו נעבור למחשב הנייד.

יפה מאוד.‏

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

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

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

אבל אתם יכולים גם להשתמש בשרת llama.cpp משלכם, או ב-Ollama או ב-LM Studio, מה שאתם רוצים.

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

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

אפשר להוסיף כאן מודל, כל עוד הוא תואם ל-OpenAI או ל-Anthropic.

אוקיי, בואו נראה.

אז עכשיו, אגב, הדרך לבחור מודל ב-Android Studio היא דרך התפריט הנפתח הזה, כמובן.

אז בחרתי ב-Gemma 4 26B, ואני יכול לשאול, "מה זה ViewModel?"

אוקיי.

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

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

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

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

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

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

נכון?

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

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

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

נכון?

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

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

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

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

אז אלה כמה דוגמאות, נכון?

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

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

בשביל זה יש נקודות השוואה.

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

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

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

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

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

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

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

עד כמה הוא ספציפי.

האם היא דומה לסוג המשימה שתתנו לו?

השני הוא היקף המשימה.

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

ולבסוף, האם המורכבות של המערכת דומה למורכבות של המשימה שאתם הולכים לתת?

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

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

הגרסה הראשונה כוללת 100 משימות ב-Android בגודל של בקשות משיכה (PR), ואתם יכולים להריץ אותה בעצמכם כבר היום דרך Harbor כדי לבדוק כל שילוב של סוכן, מודל ומיומנות.

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

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

אוקיי, תודה, זוהר.

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

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

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

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

לפחות לא בבת אחת.

נדבר על זה בהמשך.

בסדר, משימות קטנות.

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

לדוגמה, מודלים קטנים די טובים ב-Compose, לפחות ביסודות של Compose.

למשל, צריך להיות מרווח של 8dp בין רכיבים, או להשתמש בעיצוב במקום בצבעים בקידוד קשיח, או לחלץ מחרוזות.

למודל קטן קל מאוד לזהות אותם.

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

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

הקושי במקרה הזה הוא בהיקף, לא בידע.

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

לכן, המשימה הזו קלה יחסית גם למודל קטן, כמו Gemma 4.

במקרה הזה, זה לקח 3 דקות, וזה שינוי של שורה אחת.

טוב.

אז אני חושב שיש לנו מושג די טוב מה זה מודל קטן.

בואו נסתכל על מי- סליחה, משימה קטנה.

בואו נסתכל על משימות בינוניות.

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

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

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

אבל זה עבר.

זה לקח 10 דקות.

הוא שינה שלושה קבצים.

ודרך אגב, זה עלה 6 סנט דרך OpenRouter.

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

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

הכל הוטמע כמעט כמו שצריך, אבל הוא הניח שהערך של הסנכרון הראשוני יהיה ‎-1, אבל הוא בעצם 0.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

זה הכול.

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

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

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

אז אולי כדאי לשנות את המשימה כך שתכלול שלב אימות.

נדבר על זה עוד מעט.

אז בואו נדבר על משימות גדולות.

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

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

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

אז בואו נבחר אחת מהן.

בחרתי את המתכון הזה כי הוא פריך.

הוא עובר בערך בחצי מהמקרים שבהם הוא מופעל.

לכן, לדעתי זה הגבול של מה שמודל קטן יכול לעשות.

או לפחות מודל מאפריל.

היא עוסקת בניתוח של כתובות URL פגומות בספריית Coil.

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

בואו נסתכל על זה רגע.

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

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

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

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

אתם יודעים שאפשר להגדיר את רמת המאמץ של הסוכן?

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

אז נגדיר משימות גדולות כמשימות שמודלים קטנים יכולים להשלים בערך ב-50% מהמקרים, וזה מה ש-Gemma 4 31B יכול להשיג מול מערך הנתונים Android Bench v1, שעליו זואי דיברה קודם.

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

בהחלט, והדברים האלה לא דורשים שום מאמץ.

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

לדוגמה, אם אתם משתמשים ב-Ollama כדי להפעיל את Gemma 4, כברירת מחדל חלון ההקשר הוא 32,000 טוקנים, למרות שהמודל תומך בפי 8 יותר.

כמובן שאם אתם משתמשים ב-Gemma 4 דרך Android Studio, אתם לא צריכים להגדיר אותו.

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

במערך ההערכות שלנו, הפעלת ההקשר המלא שיפרה את התוצאות מ-26% ל-53%.

אחר כך, משתמשים ב-Android CLI, הכלי של Android CLI, במיוחד כדי לחפש במסמכי התיעוד.

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

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

בשלב הבא, מוסיפים רמזים לאימות.

דיברנו על זה.

תגידו למודל איך להריץ בדיקות, אילו סוגי בדיקות זמינים, איך לנהל אמולטורים וכו'. אתם יכולים לעשות את זה בקובץ AGENTS.md, וכך ההוראות יהיו זמינות לכל הנציגים, אבל זה דבר טוב בכל מקרה.

כדאי שיהיה לך אותו.

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

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

אחר כך, מוסיפים מיומנויות, אבל גם מסירים מיומנויות.

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

אז מה לגבי משימות ארוכות-טווח?

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

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

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

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

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

בואו נראה איך אפשר לעשות את זה.

חזרה ל-Zoe.

תודה רבה, יוסי.

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

אז תזמור יכול, למשל, לעזור לכם לא להיחסם אף פעם, נכון?

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

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

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

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

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

אז זה כמו ביקורת עמיתים.

ואפשר לראות את זה כאן.

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

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

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

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

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

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

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

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

אז החלק הראשון הוא לבחור את הכלי הנכון, נכון?

יש כמה סוגים של כלים.

להכיר אותם, לחקור אותם, נכון?

ואז לגלות לאילו משרות הם מתאימים או אפילו אילו משרות הם יכולים לעשות.

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

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

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

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

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

אבל הכי חשוב, אתם יכולים להמשיך לחקור, להמשיך לבנות ולהמשיך ליהנות, נכון?

אתם יכולים להתחיל כבר היום: צרו רשימה מצומצמת של מודלים באמצעות Android Bench והממצאים שקיבלתם שם, או התחילו עם Gemma 4 ב-Android Studio.

אז תודה רבה.