רווחים:
- יכול לתכנן כיצד ההנחיה של המערכת מנחה את המודל לאורך כל השיחה
- מבין את התפקיד וההשפעה על העלות של פרמטרי חשיבה אדפטיבית ומאמץ
- מיישם בקרות פלט כגון max_tokens, רצפי עצירה ופלט מובנה
שני מוצרים שונים מאותו דגם עשויים להתנהג בצורה שונה לחלוטין. ההבדל הוא לא בדגם עצמו, אלא בהנחיית המערכת ובפרמטרים שניתנו לו. הנחיית המערכת היא "חוזה העבודה" של הדגם והפרמטרים הם "הגדרות עבודה". ביחידה זו תלמדו כיצד לעצב הנחיה חזקה למערכת, מה עושות הגדרות החשיבה והמאמץ בדגמים מודרניים וכיצד לשלוט בפלט עבור פורמט/אורך. הגדרה נכונה של הגדרות אלה מאפשרת לך לנהל את האיכות והעלות בו-זמנית.
הנחיית מערכת: הנחיה קבועה של הדגם
הנחיית המערכת היא ההוראה ברמה הגבוהה החלה לאורך כל השיחה. כללים אלה נשארים תקפים לא משנה מה המשתמש מקליד. הודעת מערכת טובה כוללת את הרכיבים הבאים:
- תפקיד/זהות: מי הדוגמנית? ("אתה עוזר תמיכה ארגוני.")
- היקף וגבול: מה זה עושה ומה זה לא עושה? ("בהתבסס רק על מסמך המדיניות שסופק").
- כללי פורמט: איך הפלט אמור להיראות? ("מקסימום 3 מאמרים, שפה רשמית").
- התנהגות באי ודאות: מה עושים כשלא בטוחים? ("אם אין מידע, המציא אותו, הפנה אותו ליחידה הרלוונטית").
- אבטחה/פרטיות: מה לא/לא רוצה? ("בקש נתונים אישיים").
טיפ: שמור את הנחיות המערכת קבועות. אין להטמיע מידע שמשתנה עם כל בקשה (תאריך נוכחי, שם משתמש, מזהה הפעלה). זה גם שובר את העקביות וגם מבטל את מטמון ההנחיות ביחידה 6. שים את המידע המשתנה בהודעת המשתמש.
מלכודת ההוראה האגרסיבית מדי
דגמים מודרניים עוקבים אחר ההוראה מקרוב. ביטויים אגרסיביים כמו "חייב", "תמיד", "בהחלט לעשות את זה" וכו', שעבדו בדגמים ישנים יותר, מובילים היום להפעלת יתר: הדוגמנית מתקשרת לסוכן כשאין לו צורך או פועלת לזמן ארוך שלא לצורך. רכך את הכלל: במקום "חייב להשתמש בכלי החיפוש", "אם התשובה לא נמצאת בשיחה, השתמש בכלי החיפוש" הוא מדויק יותר.
פרמטרים של מודל: מחשבה ומאמץ
ללימודי LLM קלאסיים היה פרמטר טמפרטורה: ערך נמוך יותר הפיק פלט ספציפי/עקבי יותר, ערך גבוה יותר הפיק פלט מגוון/יצירתי יותר. מודלים מהדור המודרני (כגון Opus 4.8, Sonnet 5) מחליפים גישה זו בשני מנגנונים חזקים יותר ואינם מקבלים עוד פרמטרי דגימה כגון טמפרטורה.
- חשיבה מסתגלת: המודל מנמק צעד אחר צעד ב"ראשו" לפני שהוא מגיב. המודל מחליט כמה לחשוב על סמך קושי המשימה. משפר באופן משמעותי את הדיוק בבעיות מורכבות מרובות שלבים; הוא חושב פחות כדי למנוע עיכובים מיותרים בשאלות פשוטות.
- מאמץ: כפתור ברמה גבוהה שמתאים עד כמה הדגם צולל לתוך משימה וכמה אסימונים הוא מוציא בסך הכל. רמות אופייניות: נמוך, בינוני, גבוה ומעלה. מאמץ גבוה עשוי לשפר את האיכות, אך הוא גם מגדיל את העיכוב והעלות; מאמץ נמוך מביא מהירות וחיסכון.
הגדרה
מה עושה
מתי
חשיבה ביטול/מאמץ נמוך
מהיר, זול, שטחי
סיווג פשוט, תגובה קצרה, עיכוב במשימות רגישות
חשיבה מסתגלת + מאמץ בינוני
איכות/עלות מאוזנת
רוב המשימות למטרות כלליות
חשיבה מסתגלת + מאמץ גבוה
דיוק גבוה ביותר
חשיבה מורכבת, קידוד, עבודת סוכנים ארוכת טווח
זהירות: רפלקס "המאמץ המקסימלי לא משנה מה" מייקר עלויות. התאם את המאמץ למשימה; במשימות פשוטות, מאמץ נמוך לרוב נותן את אותה תוצאה מדויקת במחיר הרבה יותר זול. עבור גבוה היכן שנדרש דיוק קריטי.
בקרת פלט: פורמט, אורך, מבנה
מלבד הפרמטרים, אתה גם שולט בפלט עצמו:
- max_tokens: תקרה קשה של הפלט (יחידה ראשונה ו-3).
- רצפי עצירה: עצירת המודל כאשר הוא רואה מחרוזת מסוימת. שימושי להגדרת נקודות שבירה בייצור מובנה.
- פלט מובנה: כפה על תגובת המודל להתאים לסכימת JSON שאתה מספק. זה מבטיח שהפלט ניתן לניתוח ותקף באופן תכנותי. זה אמין יותר מלומר "פשוט החזר JSON" עם הנחיה.
{ "output_config": { "format": { "type": "json_schema", "schema": { "type": "object", "additionalProperties": false, "properties": { "category": { "type": "string", "enum": ["חשבונית", "technical", "returgency":", "other"type], "other"type "enum": ["נמוך", "בינוני", "גבוה"] } }, "נדרש": ["קטגוריה", "דחיפות"] } } }}
תבניות הנחיות מערכת הניתנות להעתקה
# עוזר תמיכה ארגונית אתה עוזר תמיכה ארגונית.- הסתמכו אך ורק על מסמך המדיניות שסופק; אם זה לא מופיע במסמך, אמור "אין לי מידע זה". - תן תשובה רשמית וברורה ב-3 משפטים לכל היותר. - בקש מידע אישי (מספר תעודת זהות, מספר כרטיס) ואל תחזור עליהם בתשובתך. - אם אתה לא בטוח, אל תנחש.
# מסווג כפוי פלט מובנה אתה מסווג ביקוש. הקלט הוא הודעת לקוח. החזר רק את השדות המבוקשים, אל תכתוב הערות. אם אינך בטוח, השתמש ב"אחר".
# אנליסט עם התנהגות מוגדרת של עמידה באי ודאות אתה מנתח נתונים. הסיק רק מסקנות ניתנות לאימות מהטבלה המצורפת. לעולם אל תמציא מסקנה שאינה קיימת בנתונים. אם ההסקה אינה ברורה, כתוב "לא מספיק נתונים".
# כותב תוכן עם שליטה בטון ובאורך אתה כותב תוכן. השתמש בטון חם אך מקצועי. הגבל כל טקסט ל-120 מילים או פחות. הימנע משפה שיווקית קלישאתית.
הנחיה חלשה / הנחיה חזקה
# WEAK היה מועיל ותן תשובות טובות. תעשה כמיטב יכולתך.
# STRONGתפקיד: מומחה תמיכה טכנית. היקף: מדריך מוצר מסופק בלבד. פורמט: שלב אחר שלב, רשימה ממוספרת, מקסימום 5 שלבים. מגבלה: המלץ על פתרון שאינו במדריך; אמור "לא הצלחתי למצוא את זה במדריך." פרטיות: אין לחזור על המספר הסידורי ששותף למשתמש בתגובה.
גרסה חזקה; הוא קובע בנפרד את התפקיד, ההיקף, הפורמט, הגבולות והסודיות. עקביות הפלט מגיעה ישירות מהבהירות הזו.
שלושה מיני מארזים
מקרה 1 - הפחתת עלויות באמצעות התאמת מאמץ. צוות אחד הפעיל את כל הקריאות שלהם במאמץ גבוה + חשיבה; אפילו תקצירי אימייל פשוטים היו יקרים ואיטיים להפקה. הם הטילו משימות פשוטות כמו סיכומים למאמץ נמוך וניתוח חוזים למאמץ גבוה. הדיוק נשמר, זמן האחזור הממוצע ירד בחצי והעלות החודשית הופחתה בשליש.
מקרה 2 - אחריות JSON. צוות מבצעים ביקש את פלט הסיווג עם הנחיה שאומרת "פשוט תן JSON", אבל המודל היה כותב מדי פעם "הנה התוצאה:" והמנתח היה קורס. כאשר חיברתי את סכימת הפלט שהוגדרה, הפלט החזיר JSON חוקי בכל פעם; שגיאות ניתוח אופסו.
מקרה 3 - רתיעה מהירה אגרסיבית. הודעת עוזר אמרה, "חייב לחפש כל שאלה"; המודל ביצע חיפושים מיותרים אפילו לשאלות פשוטות שכבר ידע עליהן את התשובה, האט את הקצב והגדיל את העלויות. הם הרגיעו את הכלל ל"אם התשובה אינה בהקשר, חפש"; שיחות מיותרות ירדו ב-70% והתגובות הואצו.
טעויות נפוצות
- הטמעת נתונים משתנים בהנחיית המערכת: שובר עקביות ומבטל את תוקף המטמון.
- הוראה אגרסיבית מדי: הפעלה מוגזמת ועלות מיותרת בדגמים מודרניים.
- מאמץ גבוה בכל משימה: בזבוז במשימות פשוטות; להתאים את המאמץ למשימה.
- מבקש JSON רק באמצעות הנחיה: הוא נשבר מדי פעם; אם קריטי, השתמש בפלט מובנה.
- לא מגדיר התנהגות גבול/אי בהירות: המודל ממלא את החסר בפבריקה (הזיה).
- הרגל 'טמפרטורה' ישן: דגמים מודרניים אינם מקבלים זאת; להנחות התנהגות במהירות ובמאמץ.
עמוק יותר: כתיבת ההנחיה כמו חוזה
צוותים מנוסים מתייחסים להנחיית המערכת כאל חוזה, לא כטקסט ספרותי: סעיפים ברורים, כללים מדידים, גבולות חד משמעיים. לגישה זו שלושה יתרונות קונקרטיים. הראשון הוא עקביות: אותו קלט נותן פלט דומה בזמנים שונים. שנית היא יכולת הבדיקה: אתה יכול לבדוק כל פריט בנפרד עם דוגמה. שלישית היא קלות התחזוקה: אם התנהגות שגויה, אתה יודע איזה פריט להחליף.
תרגול טוב הוא להוביל עם דוגמאות חיוביות. במקום לספק רשימה של "אל תעשה את זה", הרבה יותר יעיל בדגמים מודרניים לספק דוגמה שאומרת "ככה בדיוק נראה הפלט הרצוי". לדוגמה, במסווג, הוספת דוגמה אחת או שתיים של ה-JSON הצפוי להנחיה מפחיתה משמעותית את שגיאות העיצוב.
טכניקה חזקה נוספת היא לכתוב את התנהגות אי הוודאות במפורש. סעיף כגון "אם אינך בטוח, אל תנחש; אמור 'לא מספיק נתונים'" מדכא את הנטייה של המודל למלא את החסר באמצעות המצאה (הזיה). המשפט הבודד הזה מוריד את שכבת האימות, אותה נסקור ביחידה 11: ברגע שהמודל כבר סימן אי ודאות, קל יותר להוביל לאימות אנושי.
לבסוף, שקול מאמץ והנחיה ביחד. במאמץ גבוה, המודל בוחן יותר ולפעמים עושה "עבודה נוספת" לא רצויה (הסבר מיותר, הצעה נוספת). האמירה "תן רק את הפלט הרצוי, אל תוסיף הערות נוספות" בהנחיה מקזזת את תופעת הלוואי הזו של מאמץ גבוה.
לסיכום
הנחיית המערכת היא ההנחיה הקבועה של המודל: היא מגדירה את התפקיד, ההיקף, הפורמט, התנהגות הערפול והסודיות. במודלים מודרניים, ההתנהגות מונעת על ידי חשיבה אדפטיבית ופרמטרים של מאמץ ולא על ידי טמפרטורה; יישור המאמץ למשימה מנהל איכות ועלות בו זמנית. אתה מאבטח את הפלט עם max_tokens, מערכי עצירה ופלט מובנה.
משימת יישום
בחר משימה. (1) כתוב הודעת מערכת עם חמישה מרכיבים (תפקיד, היקף, פורמט, אי בהירות, סודיות). (2) ציינו באיזו רמת מאמץ הייתם בוחרים למשימה זו ומדוע. (3) אם הפלט צריך להיות מובנה, שרטט סכימת JSON קטנה. (4) בדוק אם יש דפוס אגרסיבי מדי בהנחיה שלך ורכך אותה.
רשימת בדיקה
- [ ] אני יכול למנות חמישה מרכיבים של בקשת מערכת טובה.
- [ ] אני יכול להסביר מה עושים פרמטרי החשיבה האדפטיבית והמאמץ.
- [ ] אני יכול לאזן איכות/עלות על ידי התאמת מאמץ בהתאם למשימה.
- [ ] אני יודע מדוע פלט מובנה בטוח יותר מאשר בקשת JSON באמצעות הנחיה.
- [ ] אני יכול לזהות את הסיכון במודלים מודרניים של הוראות אגרסיביות מדי.