הבלוג של ינון פרק

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

חבר כתב בפייסבוק

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

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

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

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

2. רק בגלל שמישהו מפרסם שקרסר הצליח להביא את האתר שלו לציון 100 ב Lighthouse לא אומר שהאתר שלו נטען יותר מהר או שאתם יכולים להגיע לתוצאה דומה על האתר שלכם. בביצועים יש כלל שהרבה יותר קל להגיע לשיפור של 90% מאשר לשיפור של 3% כי אם הורדת את זמן הטעינה ב 90% הקוד המקורי היה די גרוע. בדיקת ביצועים אמיתית דורשת שמירת זמני טעינה של גולשים אמיתיים וניתוח לאורך זמן.

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

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

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

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

זה הריפו של הדפדפן שהם יצרו ללא מגע יד אדם: https://github.com/wilsonzlin/fastrender

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

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

fix: resolve merge markers and restore vm-js build
- Remove unresolved merge conflict markers across fastrender + vendored vm-js.
- Fix vm-js exec.rs issues uncovered after cleanup (async yield* arm, NamedEvaluation super prop, unused binding).
- Drop duplicate Range native getter in window_realm.rs (required by conflict-marker guard).

This keeps scripts/check_no_conflict_markers.sh and  passing.

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

אבל זה לא מה שחשוב.

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

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

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

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

scope :latest, -> { order(created_at: :desc) }

ואז פקודת ה order by תצורף לשאילתה. עד לפה הכל קל, עכשיו נסתכל על סקופ יותר מסובך:

scope :with_questions, ->() {
  where("questions is not null and cardinality(questions) > 0")
}

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

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

MyModel.joins(:other_table).with_questions

ונדמיין שגם ל other_table יש עמודה בשם questions. עכשיו מקבלים את ה SQL:

SELECT "my_models".* FROM "my_models"
INNER JOIN "other_table" ON "other_table".my_model_id = "my_models".id
WHERE questions IS NOT NULL AND cardinality(questions) > 0

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

ERROR:  column reference "questions" is ambiguous

התיקון הוא פשוט אבל הכי טוב לזכור את הטיפ הכללי - כשכותבים scope שכולל SQL כדאי לצרף את שם הטבלה, כלומר נגדיר את הסקופ:

scope :with_questions, ->() {
  where("quizzes.questions IS NOT NULL AND cardinality(quizzes.questions) > 0")
}

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

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

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

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

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

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

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

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

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

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

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

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

2. אפשרות שניה הבדיקה תגיד "צור ויקי עם שלושה דפים X, Y ו Z. חפש X. תראה שהתוצאה הראשונה היא X."

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

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