פרופילי מודל, הקשר ו-Extra JSON

מה הפרופיל מגדיר

המודל ב-Sapphire I.C.D.S. מתאר יכולות טכניות, והפרופיל מתאר את כללי השימוש בהן. עבור אותו מודל אפשר ליצור, לדוגמה, פרופיל תמיכה קפדני, פרופיל סיווג תמציתי ופרופיל ניתוח מורחב. לכל אחד יהיו הוראת מערכת, אורך תשובה ותקציב הקשר משלו, אך כולם חייבים להישאר בתוך המגבלות של אותו מודל רשום.

באזור AI Settings → Profiles בחרו ספק ומודל. הם חייבים להתאים זה לזה: אי אפשר לקשר פרופיל למודל של ספק אחר. Profile key הוא מזהה מכונה יציב, לדוגמה support_ru. אל תשתמשו בו בשם עובד או במספר זמני של משימה. פרופיל מופעל זמין לבחירה, ופרופיל ברירת המחדל משמש כאשר הלקוח לא ציין רשומה מסוימת. הגדירו default רק אחרי בדיקה.

הוראת מערכת ותבנית תשובה

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

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

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

Reasoning, Temperature ו-Top P

השתמשו ב-Reasoning effort רק עבור מודלים שמתעדים מצב כזה. אל תעתיקו ערך ממשפחה אחרת. ל-Temperature ול-Top P יש מתגים נפרדים. אם פרמטר כבוי, הפרופיל אינו אמור לכפות אותו על הספק; זה עדיף על ערך אפס מקרי. בדרך כלל די לשלוט בשיטה אחת של שונות ולהשאיר את האחרת כבויה. לחילוץ עובדות ולסיווג בוחרים הגדרות יציבות יותר, וליצירת חלופות הגדרות חופשיות יותר, אך תמיד משווים את הטווח המסוים לתיעוד המודל.

כיצד מחושב ההקשר

ברשומת המודל נמצאים שלושה גבולות עליונים: ההקשר הכולל, הקלט המרבי והפלט המרבי. הפרופיל מגדיר ארבעה ערכי עבודה. Max output tokens מגביל תשובה אחת. Active context tokens הוא התקציב שבו מותר לסוכן להשתמש. Compaction reserve tokens הוא חלק מתקציב זה שנשמר לדחיסה בטוחה. הסף האוטומטי הוא:

active_context_tokens - compaction_reserve_tokens

העתודה חייבת להיות חיובית וקטנה באופן מוחלט מהתקציב הפעיל. התקציב הפעיל אינו יכול לחרוג מהקלט המרבי של המודל, מגבלת התשובה אינה יכולה לחרוג מהפלט המרבי, והסכום שלהם אינו יכול לחרוג מההקשר המלא. לדוגמה, עם הקשר 128000, קלט 120000 ופלט 8192, אפשר להגדיר תקציב פעיל 64000, עתודה 16000 ותשובה 4096. סף הדחיסה יהיה 48000. זו רק דוגמה לחישוב, לא המלצה אוניברסלית לכל מודל.

Maximum agent rounds מגביל את מספר המחזורים בין מודל לכלי, ו-Maximum agent runtime מגביל את הזמן הכולל בשניות. הערך 0 פירושו היעדר התקרה המסוימת של הפרופיל, אך הוא אינו מבטל מגבלות ספק, ביטול בידי המשתמש, הגנה מפני חוסר התקדמות או מגבלות מערכת. עבור תרחיש קריטי או יקר, הגדירו ערכים סופיים מפורשים ומדדו את העבודה בפועל לפני הגדלתם.

Streaming והחלפת מודל

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

Extra JSON ללא הפתעות נסתרות

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

{}

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

{
  "metadata": {
    "integration": "sapphire-docs"
  }
}

הדוגמה תקפה רק כאשר ה-API שנבחר תומך בשדה metadata. JSON חייב להיות אובייקט עם מירכאות כפולות, ללא הערות וללא פסיקים בסוף. אל תכניסו לכאן secret, Authorization, base URL, model key, מזהי משתמשים או תוכן חסוי.

אל תשכפלו ב-Extra JSON שדות עיקריים של הבקשה, כגון מודל, כלים, בחירת כלי, הודעות קלט, temperature, Top P ו-max output tokens. סתירה תקשה על האבחון ועלולה לשנות התנהגות לאחר עדכון המתאם. השדה enable_tools אינו דרך לעקוף את ניהול הכלים, ואין להחליף מדיניות הקשר מנוהלת בהגדרה שרירותית. כלים מורשים באמצעות קטלוג השרת, הרשאות הקבוצה ובחירת השיחה.

בדיקת הפרופיל

1. שמרו את הפרופיל כשהוא מופעל, אך אל תגדירו אותו כברירת מחדל.
2. צרו שיחה חדשה ובחרו את הפרופיל במפורש.
3. בדקו תשובה קצרה, את הוראת המערכת ואת התבנית המוצהרת.
4. בצעו בדיקה ארוכה תוך מעקב אחר סף ההקשר והדחיסה.
5. בדקו עצירה לפי מחזורים וזמן אם המגבלות אינן אפס.
6. הוסיפו מפתחות ל-Extra JSON אחד בכל פעם וחזרו על הבדיקה.
7. רק לאחר מכן הגדירו את הפרופיל כ-default.

אם הבקשה נדחית, נקו תחילה את Extra JSON, כבו פרמטרי sampling אופציונליים וחזרו על הבדיקה המינימלית. לאחר מכן השוו את המגבלות ואת התמיכה ב-reasoning/response format. סדר זה מפריד בין שגיאה ברישום הבסיסי לבין אפשרות נוספת שאינה תואמת.

כיצד לבחור את גודל התקציב

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

הפרידו פרופילים למשימות שונות אם דרישות האורך, ה-reasoning או הזמן שלהן שונות. פרופיל „אוניברסלי” אחד קשה יותר לבדיקה ולשינוי בטוח. תעדו בשם ובתיאור של נוהל העבודה את מטרת הפרופיל, אך אל תקודדו ניתוב או הרשאות בתוך system prompt: בחירת הפרופיל ואישור הכלים נשלטים בשכבות אחרות.