מדריך למודלים במשפחת GPT‑6

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

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

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

• התאימו את המודל לעומס העבודה. אזנו בין היכולות, העלות וזמן התגובה באמצעות בחירת המודל, מאמץ ה-reasoning⁠(נפתח בחלון חדש) והמהירות המתאימים למשימה.

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

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

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

• חשוב להביא בחשבון את היעילות. צמצמו את ההקשר שהמשימה לא צריכה⁠(נפתח בחלון חדש) תוך שמירה על הראיות שהיא כן צריכה. במקומות שבהם האפליקציה תומכת בכך, אפשר להריץ משימות בלתי תלויות במקביל⁠(נפתח בחלון חדש) כדי ששלב איטי אחד לא יעכב עבודה אחרת שאינה קשורה אליו.

• אפשר לעשות שימוש חוזר בהקשר משותף באמצעות מטמון פרומפטים⁠(נפתח בחלון חדש) למשימות חוזרות. טוקני קלט שנשמרו במטמון עולים עד 95% פחות⁠(נפתח בחלון חדש) מטוקני קלט שלא נשמרו במטמון, בהתאם למודל. יש להציב הנחיות יציבות וחומר עזר לפני הפרטים המשתנים של המשימה, ולשמור על עקביות בהגדרות הכלים. לוח הבקרה של מטמון הפרומפטים⁠(נפתח בחלון חדש) ו מדריך האבחון⁠(נפתח בחלון חדש) עוזרים לזהות היכן השימוש החוזר הזה אינו פועל כמצופה. בעת הערכת העלות של תהליך עבודה מלא, יש להביא בחשבון את עלויות כתיבת הנתונים למטמון ואת כל התעריפים עבור הקשר ארוך.

• בשיחות ארוכות יותר, compaction⁠(נפתח בחלון חדש) מקטין את גודל ההקשר תוך שמירה על המצב הדרוש כדי להמשיך.

• החליטו איך לעקוב אחר ההתנהגות⁠(נפתח בחלון חדש) ולבדוק את הגדרות בקרת הנתונים⁠(נפתח בחלון חדש) של האפליקציה שלכם.

• בדיקה לפני הפריסה: יש להריץ משימות מייצגות ולמדוד את שיעור ההצלחה, זמן ההשהיה והעלות לכל משימה מוצלחת. כדאי לעיין ב רשימת הבדיקה שלנו לפריסת API⁠(נפתח בחלון חדש).

כדאי לחשוב על בחירת המודל ועל רמת ה-reasoning כעל פשרה בין אינטלגנציה למחיר.

• מודל:

  • GPT‑6 Astra⁠(נפתח בחלון חדש) למשימות reasoning המורכבות ביותר, שבהן נדרשת אינטלגנציה מקסימלית.

  • GPT‑6.1 Sol⁠(נפתח בחלון חדש) לתכנות מורכב, למחקר ולשימוש במחשב.

  • GPT‑6 Luna⁠(נפתח בחלון חדש) למשימות ממוקדות בהיקף נרחב ולעבודה יומיומית חוזרת עם מטרה ברורה, כמו חילוץ שדות מחשבוניות, סיווג בקשות או הפקת סיכומים מובְנים.

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

• רמת reasoning: ב-API אפשר לבחור כמה מאמץ ישקיע המודל במשימה.

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

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

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

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

ב-API אפשר לשנות את מאמץ ה-reasoning במהלך השיחה⁠(נפתח בחלון חדש) בלי לפגוע במטמון.

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

• מהירות:

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

  • ב-Codex וב-API, כדאי לבחור באפשרות Ultrafast⁠(נפתח בחלון חדש) כשהתגובות המהירות יותר מצדיקות את העלות הנוספת, למשל במחזורי קידוד מהירים. היא מאיצה את יצירת הטוקנים בלי קשר לרמת מאמץ ה-reasoning. זמינה עבור GPT‑6 Astra⁠(נפתח בחלון חדש).

התחילו בהגדרה ברורה של המשימה: התוצאה הרצויה, למי היא מיועדת, ההקשר והמגבלות הרלוונטיים ומה נחשב להשלמה. לאחר מכן, עברו על ארבעת התחומים האלה, המסוכמים מתוך חשיבה מחדש על מיומנויות ופרומפטים עבור GPT‑6 Astra⁠(נפתח בחלון חדש), כדי להעמיק בנושא עדכון ההוראות:

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

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

• הגדרת גבולות לקבלת החלטות: יש לציין אילו פעולות יכולות להתבצע באופן עצמאי ואילו דורשות אישור, ולהחליף כללים גורפים כמו "לבקש אישור תמיד" בגבולות ברורים.

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

להנחיות נוספות, ראו שיטות עבודה מומלצות ל-reasoning⁠(נפתח בחלון חדש).

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

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

עם משפחת המודלים GPT‑6, אפשר כעת להתמודד עם משימות שנמשכות שעות או ימים. אפשר להשתמש בתכונות הבאות כדי לנהל טוב יותר סוכנים במשימות ממושכות.

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

• עדכון הוראות במהלך הרצה: הכוונה באמצע התור⁠(נפתח בחלון חדש) מאפשרת לשלוח תיקון דרך Responses WebSocket API⁠(נפתח בחלון חדש) בזמן שהמודל עובד. העדכונים נכנסים לתור; הם לא מבטלים כלים שפועלים ולא מבטלים פעולות שהושלמו.

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

• האצלת משימות משנה עצמאיות: GPT‑6.1 Sol תומך בתהליכי עבודה מרובי סוכנים ב-Responses API⁠(נפתח בחלון חדש). הוא יכול להקצות עבודה עצמאית לסוכני משנה (למשל, לחקור חלקים שונים של בסיס קוד) ולשלב את הממצאים שלהם בתשובה סופית. ריבוי סוכנים נמצא כרגע בגרסת בטא.

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

• מענה לשאלות תוך כדי העבודה: עם GPT‑6 Astra, ב-Codex אפשר לבקש הבהרות תוך כדי העבודה⁠(נפתח בחלון חדש). כדאי להשיב לשאלות שמשפיעות על השלב הבא, ולציין איזו עבודה שאינה תלויה בתשובה יכולה להימשך בזמן שאתם מחליטים. אם לא תהיו זמינים, כדאי לומר ל-Codex אילו משימות יכולות להימשך ומתי עליו לעצור ולהמתין לתשובה שלכם.

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

שימוש במחשב⁠(נפתח בחלון חדש) מאפשר ל-GPT‑6 Astra, ל-GPT‑6.1 Sol ול-GPT‑6 Luna ליצור אינטראקציה ישירה עם אתרים ועם אפליקציות למחשבים שולחניים, גם עם אפליקציות שאין להן API. לדוגמה, אפשר לבקש מהמודל לחקור באג, לתקן את הקוד ולפתוח את המוצר שלכם בדפדפן כדי לבדוק שהתיקון עובד.

יש לבחור בדרך הפשוטה והאמינה ביותר לביצוע כל שלב:

• יש להשתמש ב-API או בכלי מחובר כשאפשר לבצע את המשימה ישירות באמצעותם.

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

אם משלבים יכולת שימוש במחשב באפליקציה שלכם, כדאי לספק למודל כלי שיכול להריץ קוד כדי לשלוט בדפדפן או במחשב. Playwright עובד עם דפדפנים⁠(נפתח בחלון חדש); PyAutoGUI עובד עם אפליקציות למחשב.