Prompt engineering במדידה: מה באמת משנה את הפלט

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

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

מה שנראה כמו זיכרון בממשק צ׳אט הוא הלקוח שלך ששולח מחדש את כל השיחה, כל תור, מההתחלה. המודל קורא את הכול שוב מאפס, בכל פעם. פרק 13 מדד כמה הקריאה החוזרת הזו עולה ב־forward pass; פרק 16 הופך אותה לשורה בחשבונית. מה שחשוב כאן הוא ההשלכה לתכנון: ה־prompt אינו הודעה למערכת שיש לה מצב. הוא המצב.

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

הטענה 'ה־prompt הזה טוב יותר' היא טענה על התפלגות, ואי אפשר לראות התפלגות מהתבוננות בפלט אחד. מה שצריך משעמם: מקרים עם תשובות ידועות, N וריאציות, ורווח סמך.

ה־harness הוא חמישים שורות TypeScript באותה צורה כמו הלקוח מפרק 14 — בקשה, דדליין, קצת מקביליות, ספירה. הוא מופיע שוב בפרק 19 כדי להעריך retriever ובפרק 29 כ־golden set.

export type Case = { input: string; expected: string };
export type Variant = { name: string; build: (c: Case) => ChatMessage[] };

async function pooled<T, R>(xs: T[], n: number, f: (x: T) => Promise<R>) {
  const out: R[] = new Array(xs.length);
  let i = 0;
  await Promise.all(
    Array.from({ length: n }, async () => {
      while (i < xs.length) {
        const k = i++;
        out[k] = await f(xs[k]);
      }
    }),
  );
  return out;
}

export async function runVariant(v: Variant, cases: Case[], concurrency = 6) {
  const hits = await pooled(cases, concurrency, async (c) => {
    const answer = await complete(v.build(c));      
    return answer.trim().toLowerCase() === c.expected;
  });
  return { name: v.name, hits, k: hits.filter(Boolean).length, n: cases.length };
}

המספר שחוזר הוא לא התוצאה. זו התוצאה:

/** 95 % Wilson score interval for a proportion. Chapter 4 derives it. */
export function wilson(k: number, n: number, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const half = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [Math.max(0, centre - half), Math.min(1, centre + half)] as const;
}

פרק 4 הציג את הטיעון, והפרק הזה פודה אותו. שבע־עשרה תשובות נכונות מתוך עשרים הן 85 %, ורווח הסמך של 95 % נע מ־64 % עד 95 %. וריאציה שקולעת 13 מתוך 20 — 65 %, מה שמרגיש גרוע בהרבה — מקבלת רווח סמך מ־43 % עד 82 %. שני רווחי הסמך האלה חופפים כמעט לכל אורכם. עשרים מקרים לא יכולים להבדיל בין prompt טוב לבינוני, ורוב עצות ה־prompt שפורסמו אומתו על פחות מזה.

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

שלושה בלוקים — הכללים R, הכרטיס T, ההוראה I — משורשרים להודעת משתמש אחת. כל שש הפרמוטציות, תוכן זהה ברמת הבייט, שישים מקרים כל אחת.

מהטוב לגרוע יש 28.3 נקודות, ורווחי הסמך לא חופפים, כך שזה לא סיפור על רעש. מכיוון שכל זרוע מקבלת ציון על אותם שישים פריטים, השאלה החדה יותר היא השאלה המזווגת: מבין המקרים שבהם שתי זרועות חלוקות, עד כמה הפיצול חד־צדדי? המעבר מהסדר הגרוע ביותר לטוב ביותר הפך 21 מקרים לנכונים ו־4 לשגויים — הסתברות מזווגת מדויקת 0.0009.³

קראו את הטבלה לפי הצורה שלה, לא לפי המנצח. שתי השורות הטובות ביותר מסתיימות בכרטיס; שתי הגרועות ביותר קוברות את ההוראה באמצע או גוררות אותה אחרי הנתונים. זו אותה תופעה ש־Liu ואחרים קראו לה Lost in the Middle: חומר בקצוות של prompt משמש באופן אמין יותר מחומר במרכז.⁴ פרק 16 מתמחר את החלון ופרק 24 מודד את האפקט כראוי באורך, שם האמצע קורס כמתואר וההתאוששות ממש בסוף אינה מופיעה מחדש. כאן הכלל המעשי נופל מעצמו: המשימה למעלה, הנתונים למטה, שום דבר חשוב באמצע.

עכשיו העבירו את אותן מילים בין תורות. פרק 11 קבע שתבנית הצ׳אט אינה קישוט סביב המודל אלא חלק ממנו — <|im_start|>system ו־<|im_start|>user הם tokens אמיתיים שהמודל ראה מיליוני פעמים במהלך fine-tuning, בדיוק במיקומים האלה. לכן אמור להיות חשוב באיזה צד של הסמנים האלה ההוראה שלכם נוחתת, וזה אכן חשוב:

העברת הכללים וההוראה מעבר לגבול התבנית קנתה 21.7 נקודות — 19 מקרים השתפרו, 6 הורעו, הסתברות מזווגת 0.0146 — בלי לשנות בהם תו אחד. זו התשובה הקונקרטית ל־system prompt מול user prompt: אלה לא שתי דרכים לומר אותו דבר. אלה שני מיקומי token שונים במבנה שעליו המודל אומן, ומיקום המערכת הוא המקום שאליו שייכות הוראות שחלות על כל השיחה.

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

אותו prompt, המיקום הטוב ביותר, שישים מקרים. הדבר היחיד שמשתנה הוא מה שמקיף את טקסט הכרטיס.

פער של שמונה־עשרה נקודות מפיסוק. אבל הסתכלו על שני רווחי הסמך הקיצוניים: [73.9, 91.9] ו־[54.1, 77.3]. הם חופפים. לפי הקריאה הגסה — השוו את פסי השגיאה, ואם הם נוגעים, אל תגידו כלום — הטבלה הזו לא מוכיחה שום דבר.

הקריאה הגסה שגויה כאן, והבנת הסיבה שווה יותר מהטבלה. כל וריאציה קיבלה ציון על אותם שישים כרטיסים, כך ששתי המדידות אינן דגימות בלתי תלויות; הן מזווגות. רוב רוחב כל רווח סמך מגיע ממקור אי־ודאות ששתי הזרועות חולקות — האם שישים הכרטיסים האלה מייצגים — והמקור הזה מתבטל כשמשווים אותן זו מול זו. שאלו במקום זאת את השאלה המזווגת והתשובה חדה: מעבר ממירכאות כפולות לתג XML הפך 12 מקרים לנכונים ו־1 לשגוי, הסתברות מזווגת 0.0034. זה הבדל אמיתי.

ואז אותו מבחן מרוקן את הכותרת. תג ה־XML ניצח את תווית Ticket: הפשוטה ב־8.3 נקודות, וזה המספר שפוסט בבלוג היה שם בכותרת שלו. מזווג: 6 השתפרו, 1 הורע, הסתברות 0.1250. לא מבוסס. שבעה מקרים הם מה שעליו נשען השיפור המפורסם הזה.

אז יש שתי שאלות עם שני מכשירים שונים, וערבוב ביניהן הוא הדרך שבה עצות prompt משתבשות בשני הכיוונים בבת אחת:

הממצא הכללי — שמודלים רגישים מאוד ובאופן לא צפוי לבחירות עיצוב שאינן נושאות תוכן סמנטי — אינו חדש. Sclar ואחרים שינו רק מפרידים, ריווח ושימוש באותיות גדולות/קטנות על פני עשרות משימות, ומצאו פערי דיוק רחבים מספיק כדי להפוך דירוגי מודלים שפורסמו.⁵ ההשלכה המעשית אינה 'השתמשו בתגי XML'. היא שעיצוב הפורמט הוא hyperparameter, הוא לא עולה כלום לסריקה, וכל השוואה בין שני מודלים שמקבעת פורמט אחד משווה פורמטים לא פחות משהיא משווה מודלים.

In-context learning — להראות למודל דוגמאות פתורות ב־prompt ולגרום לו להכליל מהן בלי שום עדכון משקלים — היא היכולת שהפכה את GPT-3 למפורסם.⁶ השאלה המעשית היא אף פעם לא אם זה עובד. היא כמה דוגמאות שווה לשלם עליהן.

דוגמאות נכנסות כתורות קודמים אמיתיים, לסירוגין משתמש ו־assistant, כי זה המבנה שעליו התבנית אומנה. כל k הורץ עם חמש בחירות אקראיות שונות מתוך מאגר נפרד של שישה־עשר כרטיסים מתויגים:

שתי דוגמאות קנו שבע נקודות. שש הדוגמאות הבאות לא קנו שום דבר מדיד — 83.7, ואז 81.7, ואז 83.7, רצף שמסתובב בתוך הרעש של עצמו. שש־עשרה קנו עוד חמש וחצי. העקומה אינה טיפוס חלק; היא מדרגה, רמה, ועוד מדרגה.

העמודה החשובה ביותר היא האחרונה. ב־k = 8, אילו שמונה דוגמאות במקרה בחרתם הזיזו את הדיוק ב־10 נקודות — יותר מכל הרווח ממעבר משתי דוגמאות לשמונה. והשורה התחתונה היא הגרסה החדה ביותר: ב־k = 16 המאגר נגמר, כך שכל חמש ההרצות מכילות בדיוק אותן שש־עשרה דוגמאות, שונות רק בסדר שבו הן מופיעות. הסדר לבדו הזיז את הדיוק ב־8.3 נקודות.

זו התוצאה ש־Lu ואחרים דיווחו עליה, והיא שורדת בכל מקום שבו חיפשו אותה: סדר הדוגמאות הוא hyperparameter אמיתי עם אפקטים בני־השוואה למספר הדוגמאות.⁷ לכן העצה הישרה לגבי few-shot prompting אינה מספר. היא:

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

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

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

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

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

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

שלושה איסורים הצליחו פחות מהוראה אחת, וגרמו למודל לכתוב פי חמישה יותר טקסט — ההפך המדויק משלושתם בבת אחת. הוספת המשפט החיובי בחזרה הצילה את זה ל־68 %.

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

אפשר למדוד את זה ישירות. קחו את prompt ה־baseline והוסיפו שורה אחת: Do not use the shipping queue for software problems. ואז הסתכלו רק על ארבעים וחמישה הכרטיסים שאינם כרטיסי שילוח:

ציון שם של תור כדי לשלול אותו גרם למודל לבחור בו פי שלושה יותר, כמעט שילש את מסת ההסתברות שהקצה לו, ועלה 25 נקודות דיוק כולל — 16 מקרים אבדו מול 1 שהשתפר, הסתברות מזווגת 0.0003.

אל תחשבו על פיל, במדידה. השכתוב תמיד זהה: החליפו את האיסור בכלל חיובי שהופך אותו למיותר. לא 'אל תשתמשו בשילוח לבעיות תוכנה' אלא 'השתמשו בשילוח רק כשמדובר בחבילה פיזית'.

פרק 12 בנה chain of thought כראוי — קודם כטכניקת prompting,⁹¹⁰ ואז כמשהו שאומן פנימה עם תגמולים ניתנים לאימות — וסיים באזהרה שהוא דחה לפרק הזה: להגיד למודל לחשוב צעד־אחר־צעד מפסיק לעזור כשהמודל מסיק בעצמו, ויכול להזיק. הנה האזהרה הזו עם טבלה מתחתיה, במשימה שבה קל להניח שיותר חשיבה חייבת להיות טובה יותר.

שתי הזרועות נקראות באותו מכשיר באותו מיקום. ההבדל היחיד הוא האם chain of thought שהמודל כתב בעצמו יושב קודם ב־context.

הדיוק ירד והעלות עלתה, והכלל של הפרק הזה עצמו חל על התוצאה של הפרק הזה עצמו: הירידה היא 7 מקרים שהשתפרו מול 10 שאבדו, הסתברות מזווגת 0.629, וזה לא מבוסס. מה שכן מבוסס הוא שזה ייצר תשעים ושמונה tokens פלט נוספים לכל קריאה ולא קנה בהם שום דבר מדיד. אי־הוודאות נמצאת כולה בצד התועלת. החשבון ודאי.

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

1. Check if the issue persists on Monday.
2. Verify if there are any updates or changes in your Slack setup that
   might affect message posting.
3. If no update has been made since Tuesday, check for any recent system
   restarts or downtime affecting Slack functionality.
4. If you have recently installed new software or updated your
   environment, ensure it's compatible with Slack version.
5. Contact Slack support for further assistance or troubleshooting steps.

זו עצת troubleshooting כשירה, וזו לא המשימה. כשהתבקש לחשוב, המודל נסחף לז׳אנר ש־'חשוב צעד־אחר־צעד על כרטיס התמיכה הזה' הכי דומה לו בנתוני האימון שלו — ואז ענה על שאלת סיווג עם חמש מאות תווים של נימוק לא קשור בתוך ה־context של עצמו. Chain of thought עוזר בבעיות עם מצב ביניים ששווה לחשב: אריתמטיקה, חיפושים מרובי־קפיצות, סיפוק אילוצים. לנתב משפט לאחת מארבע קופסאות אין מצב ביניים. אין לשרשרת מה להחזיק, ולכן כל מה שהיא עושה הוא להוסיף טקסט משכנע שההחלטה הסופית צריכה אחר כך לשרוד.

שתי מסקנות מעשיות. ראשית, עבור מודל שאומן להסיק — מודלי RLVR של פרק 12 — ההוראה גרועה ממיותרת: היא יכולה להחליף את השרשרת הארוכה שהמודל היה מייצר בשרשרת קצרה בצורת prompt. ודגימת כמה שרשראות והצבעה, שזה מה ש־self-consistency עושה,¹¹ אינה יכולה להציל משימה שאין בה על מה להיות חלוקים: היא מכפילה את העלות במספר הדגימות כדי לשבור שוויונות שאינם קיימים. פרק 12 מדד את הסחר הזה במקום שבו הוא כן חל. שנית, שימו לב מה עלה שלד ההשוואה עצמו. אילוץ התשובה לשורת Final queue: הוריד את זרוע ללא־הנימוק מ־76.7 % ל־61.7 %. חמש־עשרה נקודות, ששולמו כדי להפוך את שתי הזרועות לבנות־השוואה. מבנה שקיים לנוחותכם אינו בחינם גם הוא.

מדידה אחרונה, כי זו השאלה שכולם שואלים אחרי התוצאה המפתיעה הראשונה. שישים prompts, greedy decoding, בהרצות חוזרות:

• אותה קריאה שחוזרת כשכל דבר מוחזק קבוע החזירה הסתברויות זהות ברמת הביט. דטרמיניסטי.
• אותה קריאה ב־batch עם שכנים שונים — גדלי batch 1, 4, 12, 30 ו־60 — החזירה הסתברויות שנבדלו עד 0.0128. התווית שנבחרה מעולם לא השתנתה, ב־0 מתוך 60 מקרים.

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

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

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

DSPy הולך רחוק יותר והוא הרעיון המועיל יותר למוצר.¹² אתם מצהירים מה כל שלב בצינור מקבל ומחזיר, וה־framework מקמפל את זה ל־prompts, בוחר הדגמות וממטב הוראות מול המדד שלכם. החליפו מודל ואתם מקמפלים מחדש במקום לשכתב. ה־prompt מפסיק להיות קוד מקור שמישהו מכוונן ביד והופך לארטיפקט שנוצר מול מדד, וזה מה שהוא היה צריך להיות מלכתחילה.

אף אחד מהם לא מבטל את הצורך ב־bench. שניהם הופכים אותו לדבר היחיד שצריך, כי optimiser בלי מדד לא ממטב כלום.

מה שנשאר הוא המשמעת. Prompts שייכים ל־version control, בקבצים, ליד הקוד ששולח אותם — לא בשורת מסד נתונים שמישהו ערך ביום שלישי. הם צריכים מזהה גרסה שנשמר לצד כל פלט שהפיקו, אחרת ביום שמשהו נסוג אי אפשר לגלות מה השתנה. הם צריכים את ה־bench ב־continuous integration, כי prompt הוא החלק היחיד במערכת שלכם שספק יכול להפוך ללא תקף בשקט על ידי פריסת מודל חדש. והם צריכים מקרים: לא מאה חכמים, רק העשרים המשעממים שנשברו ברבעון שעבר, שמורים לנצח. ה־bench הוא התוצר. ה־prompt הוא תוצר לוואי שלו.

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

ה־system prompt שקנה 21.7 נקודות נשלח בכל קריאה, לנצח. שתי הדוגמאות שקנו שבע נקודות נשלחות בכל קריאה, לנצח. השש־עשרה שקנו שתים־עשרה נשלחות בכל קריאה, לנצח, והן בערך פי עשרה מאורך השאלה שהמשתמש באמת שאל. ה־chain of thought שלא קנה כלום הפיק תשעים ושמונה tokens נוספים לכל בקשה, ו־tokens פלט הם הסוג היקר.

שום דבר מזה לא נראה בטבלת דיוקים, וכל זה נראה בחשבונית.

פרק 16 עוסק ביחידה שבה ההחלטות האלה באמת נקובות. ה־token כיחידת חיוב, ה־context window כתקציב ולא כזיכרון, למה שיחה של ארבעים תורות עולה הרבה יותר מארבעים פעמים התור הראשון, מה prompt caching כן ולא משלם עליו, ולמה סדר ה־prompt שלכם קובע אם ה־cache פוגע בכלל — מה שמתגלה כסיבה שנייה, כלכלית לחלוטין, לשים את החומר היציב ראשון ואת החומר המשתנה אחרון.

ה־bench וכל טבלה הופקו עם Qwen/Qwen2.5-0.5B-Instruct תחת greedy decoding, ולכן הם משתחזרים בדיוק. התיעוד של Hugging Face על תבניות צ׳אט הוא המקור למה שסמני התבנית של פרק 11 באמת מתרחבים אליו, ולעובדה שמודל שנשלח עם תבנית שגויה הוא כשל אמיתי וחוזר. עבור אפקטי מיקום ופורמט בקנה מידה של פרודקשן ולא של מעבדה, הציטוטים למעלה הם המקורות הראשוניים; מדריכי ה־prompting של הספקים מועילים בדוגמאות שלהם, וכדאי לקרוא אותם בידיעה שאף אחד מהם לא מפרסם רווח סמך.