מה זה code-cushman-001 ואיך מחליפים אותו בקוד

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

מה המודל הזה ידע לעשות

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

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

קודם מוצאים את הקריאה שבאמת רצה

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

• לזהות את הספק, גרסת ה-SDK, מתודת ה-API וההגדרה שבוחרת את המודל.
• לקרוא את הפרומפט המלא, כולל הוראות שתבנית או פונקציה משותפת מוסיפות בדרך.
• לעקוב אחרי פענוח התשובה ולבדוק הנחות על שדות כמו choices[0].text.
• לברר אם הקוד שנוצר מוצג לבדיקה, נכנס לקובץ או עובר לרכיב שמריץ אותו.
• לבדוק טיפול בשגיאות, ניסיונות חוזרים, מגבלת זמן ומה המשתמש רואה כשהיצירה נכשלת.

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

בוחרים מודל לפי מה שהפיצ'ר צריך לעשות

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

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

מסיימים כשהמשתמש מצליח להשלים את הפעולה

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

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