תאריך פרסום: 14 בינואר 2025
בכנס Google I/O 2024 בשנה שעברה השקנו את תובנות המסוף, התכונה הראשונה של AI ב-Chrome DevTools. התובנות מהמסוף עוזרות להבין שגיאות ואזהרות שמתועדות ביומן במסוף. לשם כך, הן שולחות ל-Gemini, מודל השפה הגדול (LLM) של Google, נתוני רשת, קוד מקור ודוחות של קריסות שקשורים להודעה ביומן. התכונה Console insights שולחת הנחיה אחת ל-Gemini, שמחזירה תשובה אחת בלי שהמפתחים יוכלו לשאול שאלות נוספות. תהליך האינטראקציה היחיד הזה מתאים למדי להסבר על הודעות שגיאה, אבל הוא לא מתאים לתרחישי שימוש מורכבים יותר לניפוי באגים ב-DevTools, שבהם לא ברור אילו נתונים מהדף שנבדק נדרשים ל-AI כדי לעזור.
דוגמה לשימוש כזה היא ניפוי באגים בבעיות שקשורות לעיצוב. דף אינטרנט אחד יכול להכיל אלפי אלמנטים וכללי CSS, ורק קבוצת משנה מהם רלוונטית לניפוי באגים בתרחיש ספציפי. זיהוי הקוד הנכון לניפוי באגים יכול להיות מאתגר, גם לבני אדם. אבל בעזרת אב טיפוס שנוצר במהלך אירוע ה-hackathon של AI ב-Google, למדנו ש-LLMs עושים את זה די טוב. לכן, כמובן שרצינו להביא את היכולת הזו למשתמשים של DevTools, ולכן יצרנו כלי שיכול לבדוק בעיות בסגנון על ידי שליחת שאילתות אינטראקטיביות לדף לקבלת נתוני הקשר נוספים. כמה חודשים לאחר מכן השקנו את התכונה עזרה מ-AI לעיצוב.
בפוסט הזה נסביר על האתגרים שניצבנו מולם כשהוספנו AI למוצר אהוב כמו Chrome DevTools – שהוא ביסודו אפליקציית אינטרנט – ונציג דרכים שבהן תוכלו להתאים את התכונות שלכם ל-AI.
איסוף הנתונים המתאימים
תובנות במסוף תמיד משתמשות באותם נקודות נתונים כדי להגיב להנחיה מוגדרת מראש. כדי שהסיוע של ה-AI יהיה שימושי בכל הנחיה מוגדרת על ידי משתמש, אנחנו צריכים לקבוע באופן דינמי אילו נתוני הקשר חשובים לשאילתה הזו.
לכן הטמענו את ReAct (Yao et al., 2022) . שיטת ההנחיה הזו מאפשרת ל-LLMs לחשוב באופן עצמאי ולהחליט מהי הפעולה הבאה על סמך התוצאות של החשיבה.
כך, התמיכה של AI פועלת במחזור של מחשבה, פעולה ותצפית, עד שהיא קובעת תשובה מתאימה לשאילתה של המשתמש. בשלב הזה, היא מסיימת את המחזור ומספקת תשובה. התהליך האיטרטיבי הזה מאפשר ל-LLM לאסוף את המידע המדויק שנחוץ כדי לנפות באגים ביעילות בבעיות שקשורות לעיצוב.
כדי לאסוף מידע, הענקנו ל-Gemini כלי אחד בלבד: הפעלת JavaScript בדף שנבדק. כך, בעזרת AI, Gemini יכול, למשל:
- גישה ל-DOM וניתוח שלו: סריקה של עץ ה-DOM, בדיקה של מאפייני הרכיבים והבנת היחסים בין הרכיבים.
- אחזור סגנונות מחושבים: גישה לסגנונות מחושבים של כל רכיב.
- ביצוע חישובים ומדידות: הפעלת קוד JavaScript כדי לחשב מרחקים, גדלים ומיקומים של רכיבים.
כך, התמיכה של AI פועלת באופן אינטראקטיבי רק על הקוד הרלוונטי, וכך משפרת את איכות התשובות, את זמן התגובה ואת השימוש במשאבי המחשוב, בהשוואה לשליחת קוד המקור המלא של HTML ו-CSS אל Gemini.
הפעלת קוד שנוצר על ידי AI במרחב המשתמש
יכול להיות שייראה לכם לא צפוי ששילבנו את JavaScript בתהליך ניפוי הבאגים של בעיות בסגנון. יש לכך שתי סיבות:
- ממשקי API של אינטרנט הם חזקים מאוד ומכסים באופן מהותי הרבה תרחישי שימוש לניפוי באגים. יכול להיות שזה יהיה משעמם למפתח להשתמש בקריאות API באופן ידני כדי לעבור על DOM או לגשת לסגנונות מחושבים לצורך ניפוי באגים, אבל ל-LLM אין בעיה ליצור קוד שמפעיל אותן.
- אפשר ליצור ממשקי API חדשים לשימוש של סוכן, אבל לרוב עדיף לעשות שימוש חוזר בממשקי API ציבוריים קיימים, כי הם כבר מוכרים ל-LLM. כדי ללמד LLM על ממשק API חדש, נדרשים הרבה משאבים לצורך כוונון נתוני אימון ספציפיים.
עם זאת, יש סיכונים בהפעלת קוד שנוצר על ידי AI במרחב המשתמש. כדי לקבל עזרה מ-AI, היינו צריכים לצמצם את הסיכון לשינויים הרסניים שהסוכן עלול לבצע בדף. לשם כך, השתמשנו בבדיקות של תופעות לוואי שV8, מנוע ה-JavaScript של Chrome, חושף דרך פרוטוקול Chrome DevTools. אותם בדיקות משמשות לפונקציונליות של ההשלמה האוטומטית במסוף DevTools: הוא מפעיל קוד JavaScript רק כל עוד הוא לא משנה את מצב הדף. הבדיקות מתבצעות בזמן ש-V8 מבצע את הקוד, והן מבוססות על רשימת ההיתרים של פונקציות מובנות ב-JavaScript שידוע שאין להן השפעות לוואי.
אם הבדיקות יזהו שהקוד שנוצר משנה את הדף שנבדק, ההפעלה תושהה והמשתמש יתבקש לבדוק את הקוד ולאשר שהוא מוכן להפעלה.
בנוסף, קוד JavaScript שנוצר מופעל ב'עולם' מבודד. זה דומה לאופן שבו תוספים מריצים סקריפטים בסביבת חול: הקוד שנוצר יכול לגשת ל-DOM ול-Web APIs, אבל לא לגשת לקוד JavaScript או למצב שהוגדרו על ידי הדף שנבדק.
מעקב אחר השינויים שבוצעו על ידי הנציג
בנוסף לבדיקה של בעיות ולתשובות על שאלות לגבי ניפוי באגים בדף, רצינו גם לתת לסוכנות העזרה מבוססת-ה-AI את היכולת לתקן סגנונות בדף באופן שניתן למעקב על ידי המפתחים.
כדי לעשות זאת, הטמענו קישור שנקרא setElementStyles שאנחנו חושפים להקשר הביצוע של הסוכן, בנוסף לממשקי ה-API של האינטרנט שמוגדרים כברירת מחדל.
כדי להודיע ל-Gemini על השיטה החדשה, אנחנו מורים לה להשתמש בה בפתיח של עזרת ה-AI:
If you need to set styles on an HTML element, always call the \`async setElementStyles(el: Element, styles: object)\` function.
למרות שמדובר ב-API שמיועד במיוחד לסוכנות, ויש לו את האתגרים שצוינו למעלה, גם בלי שדרוגים מיוחדים, Gemini משתמש בו בצורה מהימנה כשצריך לשנות סגנונות ברכיב נתון.
בצד DevTools, כשsetElementStyles נקרא מהסוכן, התמיכה ב-AI משתמשת בגיליונות סגנונות של הבודק כדי לתעד את השינוי בבורר הרכיבים. עריכת עץ ב-CSS משמשת למתן שם לשינוי ולהגברת הספציפיות של הסלקטורים של הרכיבים. כלל CSS לדוגמה שנוצר על ידי הסוכן נראה כך:
.ai-style-change-1 { /* the ID is incremented for each change*/
.element-selector { /* Element selector is computed based on the element setElementStyles was called on. */
color: blue;
}
}
הפתרון הזה לא פותר את כל העימותים האפשריים בסגנון שיכולים לקרות בדף, אבל הוא עובד ברוב המקרים.
היתרון של שימוש בגיליונות סגנונות של מבקר בהשוואה לסגנונות בקוד הוא שכך השינויים שבוצעו על ידי הסוכן מופיעים גם בחלונית Changes, וכך קל יותר לעקוב אחרי השינויים בסגנונות הרכיבים שבוצעו, ואחרי מה שהמפתח צריך להעביר לקוד המקור הבסיסי. השילוב עם החלונית 'שינויים' מאפשר גם לבטל את השינויים אם כבר אין צורך בהם.
איך משתמשים יכולים לראות את הפעולות של הסוכן
כשמוסיפים תכונות של סוכנים למוצר, חשוב שהפעולות של הסוכנים יהיו שקופות למשתמשים, כדי שתהיה להם אפשרות לעקוב אחריהן, להבין אותן ואולי גם להתערב.
לכן, כדי לקבל עזרה מ-AI, אנחנו מבקשים מ-Gemini לבנות את התשובות בפורמט ספציפי עם הוספה לכותרת:
You are going to answer to the query in these steps:
* THOUGHT
* TITLE
* ACTION
* ANSWER
* SUGGESTIONS
Use THOUGHT to explain why you take the ACTION. Use TITLE to provide a short summary of the thought.
לאחר מכן, המבנה הזה משמש להצגת התהליכים והפעולות של Gemini כשלבים מקופלים בהתחלה, כדי למנוע עומס מידע ולאפשר למשתמשים לבדוק את הפרטים הבסיסיים או להפסיק את הביצוע במקרה של תופעות לוואי לא רצויות.
הגישה הזו לא כוללת רק התבוננות ב-AI, אלא גם למידה פעילה ממנו. כשמרחיבים את הקטעים האלה, המשתמשים יכולים לנתח את הנתונים ש-Gemini סיווג כרלוונטיים לניפוי באגים בבעיה ספציפית, ולהבין את התהליך שבו המערכת פעלה. השקיפות הזו מאפשרת למשתמשים ללמוד מאסטרטגיות ניפוי הבאגים של ה-AI, כדי שיוכלו להחיל שיטות דומות על אתגרים עתידיים, גם כשהם עובדים בלי AI.
כדי לשפר עוד יותר את חוויית המשתמש, התמיכה מבוססת-ה-AI מספקת גם הצעות רלוונטיות להקשר אחרי התשובה של ה-AI. ההצעות האלה מאפשרות לכם לקצר את השיחה, להציע רעיונות לשלב הבא בניפוי הבאגים או אפילו לבצע תיקונים מומלצים ישירות בלחיצה אחת.
בהתחלה, כדי ליצור שמות של שלבים והצעות בתמיכה של AI, העלינו בחשבון להשתמש במודל נפרד וקטן יותר שמיועד במיוחד לסיכום. עם זאת, הבנו שאפשר להרחיב ביעילות את התבנית ReAct, שמארגנת את התהליך של Gemini לקבלת החלטות בלולאה של 'מחשבות' ו'פעולות'. לכן, במקום להציג מודל שני, שיגרום גם לזמן אחזור ארוך יותר, שינינו את ההנחיה כדי להורות ל-Gemini ליצור לא רק את 'המחשבות' ו'הפעולות' המרכזיות שלו, אלא גם שמות תמציתיים והצעות מועילות באותה לולאה של ReAct.
פיתוח מבוסס-בדיקה
התהליך שדרכו פיתחנו את התכונה 'עזרה מ-AI לעיצוב' כלל בדיקה קפדנית. כדי למדוד את הביצועים שלו ולזהות תחומים לשיפור, אספנו אוסף מקיף של דוגמאות לניפוי באגים באתרים בעולם האמיתי, שכוללות בעיות נפוצות של זליגת נתונים, רכיבי אינטרנט, אנימציות ועוד. כך הצלחנו למפות את היקף הבעיות באתרים שקשורות לניפוי באגים, ולהבין לעומק את האתגרים שקשורים אליהן. אבל זה תהליך מתמשך: אנחנו מוסיפים תכונות חדשות לפלטפורמת האינטרנט באופן קבוע, ולכן אנחנו צריכים לעדכן את הדוגמאות האלה בעתיד.
הדוגמאות האלה מועברות לצינור אוטומטי לעיבוד נתונים, שמתעדות את התשובות של Gemini. לאחר מכן, הנתונים מפעילויות הבדיקה האוטומטיות האלה זמינים בכלי מותאם אישית שבו אנחנו בודקים באופן ידני את הביצועים של Gemini בתחום העזרה של AI, בהתאם לקריטריונים מוגדרים מראש. הנתונים האלה משמשים אותנו לצורך פיתוח נוסף.
הגישה הזו מבוססת-הערכה מבטיחה שכל השינויים, בין שמדובר בשיפור התנהגויות קיימות ובין שמדובר בהוספת יכולות חדשות, מאומתים בקפידה כדי להשיג את השיפורים המיועדים ולמנוע נסיגה בפונקציונליות הקיימת.
כדי לשפר עוד יותר את תהליך ההערכה, אנחנו בודקים שיטות אימות אוטומטיות, כולל:
- טענות נכוֹנוּת (assertions) כדי לוודא שהתיקונים הוחלו בצורה נכונה
- בדיקות מבוססות-קוד כדי למנוע תוצאות לא רצויות מ-Gemini
- שימוש במשפטנים מוסמכים (LLM) כשופטים, תוך התבססות על קריטריונים ספציפיים, כדי להאיץ את ההערכות הידניות שלנו ולהפוך אותן לחלקית אוטומטיות
אימות אוטומטי עוזר להתאים את היקף העבודה, אבל משוב אנושי חשוב. כדי לבדוק את רמת שביעות הרצון של המשתמשים, אנחנו אוספים משוב אנושי באמצעות אמצעי בקרה להצבעה שמופיעים מתחת לכל תגובה בתמיכה של AI. לחצן דיווח נוסף מאפשר למשתמשים לספק משוב מדויק יותר לגבי תשובות שאפשר לערער עליהן.
הזרקות של הנחיות
אחת מהמגבלות הידועות והמתועדות של מודלים גדולים של שפה היא שהם חשופים להזרקות של הנחיות. הזרקת הנחיות היא טכניקה שמאפשרת למצוא דרך לשכתב את הוראות המערכת המקוריות של LLM, וכך לגרום לו להפיק תוכן שלא התכוון המפתחים.
רוב המודלים כוללים עכשיו אמצעי מיטיגציה מובנים להזרקת הנחיות, כמו גם Gemini. בנוסף, כדי לסייע לכם בנושאי AI, אנחנו מנסים לצמצם את הבעיה הזו בפתיח שלנו על ידי הכללת ההוראה הבאה:
If the user asks a question about religion, race, politics, sexuality, gender, or other sensitive topics, answer with "Sorry, I can't answer that. I'm best at questions about debugging web pages.
המערכת הזו עובדת עם חלק מהשאלות הלא רלוונטיות, אבל היא לא מושלמת. אחד החסרונות שגילינו הוא שיכול להיות ששאילתות קצרות ולא ברורות יסווגו כתוכן לא קשור.
בנייה על בסיס יציב
כשאתם משיקים AI למוצר בפעם הראשונה, כדאי לפעול בהדרגה ולא לקפוץ מיד למים העמוקים. כך גם הגשנו את התמיכה ב-AI. בעזרת כל מה שלמדנו בזמן פיתוח סוכן הסטיילינג, יצרנו בסיס יציב להרחבת התמיכה של ה-AI לתחומים אחרים בכלי הפיתוח בהמשך.
כבר פתרנו את רוב האתגרים הגדולים בעבודה על סוכן הסטיילינג, וכעבור כמה חודשים הצלחנו להציג עזרה מבוססת-AI לרשת, לביצועים ולמקורות, ולהתמקד באתגרים הספציפיים שלהם.
השלכות אבטחה בעבודה עם בקשות רשת
בעזרת AI לרשת, המשתמשים יכולים לדון בבקשות ספציפיות לרשת עם Gemini, ולהשתמש בנתונים מהבקשה כהקשר לשיחה. באופן ספציפי, הנתונים הבאים נשלחים אל Gemini:
- כותרות בקשה: קבוצת משנה של כותרות שנשלחות מהדפדפן לשרת.
- כותרות תגובה: קבוצת משנה של כותרות שהוחזרו מהשרת.
- סטטוס התגובה: קוד הסטטוס של HTTP שמציין את התגובה מהשרת (לדוגמה, 200, 404).
- זמנים: מידע מפורט על זמני שלבים שונים של הבקשה, כמו הגדרת החיבור והעברת הנתונים.
- Request Initiator Chain: רצף הפעולות והסקריפטים שהפעילו את הבקשה.
כותרות חשובות כדי להבין לעומק איך הבקשה נוצרת, אבל הן גם מהוות סיכון אבטחה: הן עשויות להכיל פרטי כניסה כמו מפתחות API, אסימוני סשן או אפילו סיסמאות פשוטות. כדי להגן על מידע רגיש כזה, אנחנו לא מעבירים את כל הכותרות אל Gemini. במקום זאת, אנחנו שומרים רשימת היתרים של כותרות מותרות. ערכים של כותרות שלא נמצאות ברשימת ההיתרים מוחלפים ב-<redacted>. הגישה הזו מבטיחה ש-Gemini מקבל את ההקשר הנדרש תוך הגנה על נתוני המשתמשים.
התאמה לפורמטים שונים של נתונים
בעזרת AI למקורות, מפתחים יכולים לשאול שאלות על קובץ מקור בחלונית 'מקורות', למשל 'מהו מטרת הקובץ הזה?'.
הנתונים על הקובץ, כולל שם הקובץ, תוכן הקובץ והאם הוא ממופה למקור, נשלחים בהנחיה אחת. הפתרון הזה עובד טוב כי הוא פשוט טקסט ללא עיצוב. אבל קבצי טקסט גדולים או קבצים בינאריים מהווים אתגר ל-LLM. לגבי קבצים בינאריים, החלטנו לציין בהנחיה שהתוכן הוא בינארי ולא לשלוח תוכן בפועל. בקבצי טקסט גדולים, אנחנו שולחים רק חלק קטן מהתוכן שנלקח מתחילת הקובץ.
גם בתכונה 'עזרה מ-AI לשיפור הביצועים', שמאפשרת למפתחים לשאול שאלות לגבי משימה מסוימת מפרופיל ביצועים שהוקלט, יש אתגר דומה: ליצור ייצוג שמתאים לחלון ההקשר של Gemini וגם ניתן לפרש כדי לספק תובנות נוספות.
כדי ליצור הצגה כזו מפרופיל ביצועים, יצרנו סריאליזטור ייעודי שנקרא AiCallTree, שמסדר את עץ הקריאות של משימה באופן ש-LLM יכול לעבד. בהמשך נבחן גם את האסטרטגיה ReAct כאן, כדי לצמצם את כמות הנתונים שצריך לשלוח מראש ל-Gemini.
עזרה מ-AI בעתיד
התוצאה של כל העבודה הזו זמינה עכשיו החל מ-Chrome 132, וכוללת עזרה מבוססת-AI בנושאי עיצוב, רשת, מקורות וביצועים. אנחנו מקווים שתיהנו להשתמש בו כמו שאנחנו נהנינו ליצור אותו.
כדי לקבל מושג מאיפה כדאי להתחיל, כדאי לעיין במדריך המפורט למתחילים בנושא עזרה מ-AI, שכולל הרבה הנחיות לדוגמה שאפשר לנסות בדפים שלכם. חשוב גם לשלוח לנו את המשוב שלכם בבאג בנושא דיון הפתוח שלנו.