דלג לתוכן
חזרה לבלוג

הנדסת פרומפטים בפרודקשן: מה שבאמת עובד

ששה דפוסים של הנדסת פרומפטים לפרודקשן: chain-of-thought, few-shot מנתוני דומיין, JSON schema, פרומפטים חלופיים, גרסאות ב-git ו-eval harness.

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

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

זהו פוסט 6 בסדרת ה-AI pillar. הפוסטים הקודמים כיסו אוטומציה עם AI לעסק, סוכני AI לכלים פנימיים, מתי RAG שווה לבנות, בחירת ה-LLM הנכון לסטארטאפ ועלויות LLM בפרודקשן. הפוסט הזה עוסק בששת הדפוסים שעושים את ההבדל בין פרומפט שעובד בדמואים לכזה שנשאר אמין בקנה מידה.

דפוס 1: Chain-of-thought להחלטות מורכבות

הבעיה: במשימות שדורשות חשיבה רב-שלבית — סינון, סיווג, ניתוח — לשאול את המודל לקפוץ ישירות למסקנה מייצר תוצאות לא עקביות.

לפני:

Classify this support ticket as: billing, technical, account, or other.
Ticket: {{ticket_text}}

אחרי:

Classify this support ticket. First, identify what the user is asking for
in one sentence. Then identify which category best matches that need:
billing (payments, invoices, pricing), technical (bugs, errors, performance),
account (login, permissions, profile), or other.

Output your reasoning in 2-3 sentences, then output CATEGORY: <category>.

Ticket: {{ticket_text}}

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

דפוס 2: דוגמאות few-shot עם נתוני דומיין אמיתיים

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

לפני: פרומפט עם הוראות בלבד.

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

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

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

דפוס 3: סכמת פלט JSON מובנה

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

לפני:

Summarize the key risks from this contract.

אחרי:

Analyze this contract and return a JSON object with this exact structure:
{
  "risk_level": "low" | "medium" | "high",
  "key_risks": [{"risk": "...", "clause": "...", "severity": "low"|"medium"|"high"}],
  "missing_clauses": ["..."],
  "recommendation": "..."
}

Return only valid JSON with no additional text.

Contract: {{contract_text}}

עדיף: השתמשו בממשק tool/function-calling אם הספק שלכם תומך בו — הוא אוכף עמידה בסכמה ברמת ה-API ומבטל את הצורך בחילוץ JSON מטקסט מוקף. ה-tool use של Claude, ה-function calling של OpenAI וה-JSON mode של Gemini פותרים את הבעיה הזו מבנית ולא דרך הוראות.

דפוס 4: פרומפטים חלופיים לפלטים בעלי ביטחון נמוך

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

לפני: פרומפט אחד, פלט אחד, ללא אות ביטחון.

אחרי: הוסיפו שדה confidence לסכמת ה-JSON שלכם:

{
  "category": "billing",
  "confidence": "high" | "medium" | "low",
  "reasoning": "..."
}

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

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

דפוס 5: קבצי פרומפטים מגורסאים ב-git

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

הפתרון אינו מרשים אך חיוני: טפלו בפרומפטים כקוד. אחסנו אותם כקבצים ב-repository שלכם — prompts/support-classifier/v2.txt, prompts/contract-risk/v3.json — וגרסאו אותם עם אותן פרקטיקות שאתם מחילים על קוד: הודעות commit משמעותיות, ביקורת PR לשינויים משמעותיים, רשומת changelog כשההתנהגות משתנה.

פרקטיקה זו פותחת שני דברים שחשובים בפרודקשן:

  1. מעקב רגרסיות. אם איכות הפלט יורדת אחרי שינוי פרומפט, תוכלו לעשות git blame ולחזור לאחור.
  2. A/B testing. הרצת שתי גרסאות פרומפט במקביל ומדידת הפלטים שלהן מול ה-eval suite שלכם אפשרית רק כשגרסאות הפרומפטים הן artifacts מזוהים.

הדבר השני מוביל ישירות לדפוס 6.

דפוס 6: Eval harness עם 20+ מקרי בדיקה זהב

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

הפתרון: לפני שפורסים כל שינוי פרומפט, הריצו אותו על סדרה של מקרי בדיקה זהב — קלטים עם פלטים צפויים ידועים — ומדדו שיעור מעבר. עשרים מקרים ויותר הוא המינימום לזיהוי רגרסיות בצורה אמינה; 50–100 עדיפים לפרומפטים בעלי השפעה גבוהה.

ה-eval harness לא צריך להיות מורכב:

  1. קובץ CSV עם עמודות: input, expected_output, expected_category
  2. סקריפט שמריץ כל קלט על הפרומפט החדש ומשווה פלטים
  3. סף מעבר/כישלון — למשל, 90% מהמקרים חייבים לעבור כדי לפרוס

זה הופך “אני חושב שהפרומפט הזה טוב יותר” ל-”פרומפט זה עובר 94% ממקרי הבדיקה לעומת 87% של הגרסה הקודמת.” זה האות שאתם צריכים לבצע שינויי פרומפטים בביטחון ולא בתקווה.

כלים כמו promptfoo ו-LangSmith מפרמלים דפוס זה. לצוותים בשלב מוקדם, סקריפט Python של 50 שורות עם מקרי הזהב שלכם בקובץ CSV מספיק כדי להתחיל.

הדבר האחד שמחבר את ששת הדפוסים

אף אחד מהדפוסים האלה אינו מורכב בבידוד. הבעיה המצטברת היא שרוב הצוותים מוסיפים אותם באופן תגובתי — דפוס אחרי דפוס, בעקבות כשל ספציפי בפרודקשן. chain-of-thought אחרי רגרסיית הסיווג. ה-eval harness אחרי שינוי הפרומפט שהוריד בשקט את האיכות לשבוע לפני שמישהו הבחין.

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

אם אתם בונים פיצ’רים AI ורוצים לבנות את הבסיס נכון לפני שאתם רודפים אחרי כשלים בפרודקשן, CTO חלקי יכול לעזור לכם לבנות את המבנה מהתחלה. קבעו שיחת היכרות — ללא התחייבות.

זהו פוסט 6 בסדרת ה-AI pillar. התחילו באוטומציה עם AI לעסק, המשיכו דרך סוכני AI לכלים פנימיים, RAG: מתי וכמה, בחירת ה-LLM הנכון, עלויות LLM בפרודקשן, ואז לפוסט הזה. הבא: בדיקות ומעקב לאפליקציות AI בפרודקשן — 5 המדדים והכלים שהופכים את פיצ’רי ה-LLM שלכם לגלויים כשמשהו משתבש.

שיחת היכרות חינם