Prompt Registry: איך מנהלים פרומפטים כמו קוד Production

מאת צוות מדיה דיל · 02.08.2026 · Enterprise AI · 7 דק׳

פרומפט הוא קוד ה-production הקריטי ביותר במערכת AI - אבל רוב הארגונים עדיין מנהלים אותו כמחרוזת תמימה בקוד. הנה איך בונים Prompt Registry אמיתי.

מוכר לכם המצב שבו ה-System Prompt של Agent חשוב יושב בקובץ טקסט אחד, בתוך תיקייה בשם prompts_final_v2_REALLY_FINAL, ורק אדם אחד בצוות זוכר למה נוספה שם השורה השלישית? זו לא בעיה קוסמטית - היא הבעיה הבסיסית ביותר בכל מערכת AI ארגונית שגדלה מעבר לפרויקט ניסיוני. פרומפט הוא לא מחרוזת תמימה, הוא הקוד המבצע החשוב ביותר במערכת - הוא זה שקובע איך המודל מתנהג, אילו כלים הוא קורא, ובאיזה טון הוא עונה ללקוח. Prompt Registry הוא התשתית שהופכת את הפרומפט ממחרוזת שיושבת בקוד או ב-Google Doc, למרכיב תוכנה מנוהל: עם גרסאות, בעלות, בדיקות, ומסלול פריסה מוגדר.

למה פרומפטים בקוד הם הימור מסוכן

הגישה הנפוצה ביותר - וגם הבעייתית ביותר - היא לשבץ את הפרומפט כמחרוזת קבועה בתוך הקוד של האפליקציה. זה עובד יפה בדמו, אבל בפרודקשן זה יוצר שלוש בעיות מצטברות. ראשית, כל שינוי בפרומפט דורש deploy מלא של הקוד, כולל code review, CI, ולעיתים אישור release - תהליך של שעות עבור שינוי שהוא בעצם תוכן, לא לוגיקה. שנית, אין הפרדה בין מי שכותב פרומפטים טובים (לעיתים אנשי מוצר, כותבי תוכן, או data scientists) לבין מי שכותב קוד production - וכך נוצר צוואר בקבוק מיותר סביב מהנדסים שצריכים לתווך כל שינוי טקסטואלי. שלישית, ואולי החמור מכל, אין דרך שיטתית לדעת אילו פרומפטים רצים היום מול משתמשים אמיתיים, מי כתב אותם, ולמה הם נראים כפי שהם נראים - הידע חי רק בזיכרון האנושי ובהיסטוריית git מפוזרת.

אנטומיה של Prompt Registry

Prompt Registry תקין הוא בעצם מסד נתונים ייעודי לפרומפטים, נפרד מקוד האפליקציה, עם API משלו. כל פרומפט הוא ישות (entity) עם מזהה ייחודי, גרסה, תוכן מלא (כולל template variables), metadata כמו תיאור, תגיות, ורשימת מודלים שהוא נבדק מולם. יש הבחנה חשובה בין שני סוגי תוכן: הפרומפט הסטטי - החלקים הקבועים שמגדירים תפקיד, טון וכללים - והחלקים הדינמיים שמוזרקים בזמן ריצה, כמו היסטוריית שיחה או תוצאות retrieval. Registry טוב מפריד בין השניים באמצעות templating מפורש (לדוגמה עם placeholders מסוג {{customer_name}} או {{retrieved_context}}), כך שאפשר לבדוק ולגרוס את השלד הקבוע בלי להתבלבל עם התוכן המשתנה שמוזרם אליו בכל קריאה.

{
  "prompt_id": "support-triage-system",
  "version": "12",
  "status": "production",
  "template": "אתה נציג תמיכה של {{company}}...",
  "variables": ["company", "customer_tier", "retrieved_context"],
  "owner": "team-support-ai",
  "eval_score": 0.94,
  "last_promoted": "2026-07-30T10:00:00Z"
}

Templating, Composition ושימוש חוזר

ברגע שיש יותר מ-Agent אחד בארגון, מתגלה שהרבה פרומפטים חולקים מרכיבים משותפים - הנחיות בטיחות כלליות, פורמט תשובה, כללי טון קול המותג. Registry בוגר תומך ב-composition: פרומפט "אב" עם בלוקים משותפים (shared fragments) שמוזרקים לתוך פרומפטים ספציפיים בזמן build. כך שינוי בהנחיית בטיחות אחת מתפשט אוטומטית לכל ה-Agents שמשתמשים בה, במקום להצריך עדכון ידני בעשרות מקומות - וגם מונע את התופעה השכיחה שבה שני צוותים כותבים ניסוח מעט שונה לאותו כלל, וההתנהגות נסדקת בין חלקי המערכת. מנגד, composition יתר על המידה יוצר תלות סמויה קשה למעקב, ולכן כלל אצבע טוב הוא להגביל שכבות קומפוזיציה לשתיים-שלוש לכל היותר.

A/B Testing ו-Champion/Challenger

מעבר לניהול גרסה יחידה, Registry מאפשר להריץ כמה variants של אותו פרומפט במקביל מול פלחי תעבורה שונים, ולמדוד את הביצועים בפועל - שיעור השלמת משימה, שביעות רצון, אורך שיחה, עלות טוקנים. זהו דפוס ה-Champion/Challenger: הגרסה הנוכחית (champion) ממשיכה לשרת את רוב התעבורה, בעוד variant חדש (challenger) מקבל פלח קטן, ורק כשהוא מוכיח שיפור מובהק סטטיסטית הוא מקודם להיות ה-champion החדש. חשוב להפריד כאן בין שינויים קוסמטיים (ניסוח מחדש של משפט) לשינויים מהותיים (הוספת כלל התנהגות חדש), כי שינויים מהותיים דורשים דגימה גדולה יותר וזמן ריצה ארוך יותר כדי להגיע למובהקות אמיתית ולא לרעש סטטיסטי.

קישור בין Prompt Registry ל-Evaluation ול-Model Registry

פרומפט לעולם לא רץ בוואקום - הוא תמיד רץ מול מודל ספציפי, ולכן ה-Prompt Registry לא יכול לחיות מבודד. כל פרומוציה של פרומפט חדש צריכה לעבור דרך אותה סוללת בדיקות שמתועדת ב-Evaluation Registry, ולהיבדק גם מול הגרסה הנוכחית וגם מול המודל שבו הוא ירוץ בפועל, כפי שמתועד ב-Model Registry. הסיבה לכך היא שפרומפט שעובד מצוין על מודל אחד יכול להתנהג אחרת לגמרי על מודל אחר - ניסוחי system prompt מסוימים רגישים לגרסת המודל, ולכן שינוי מודל בלי לבדוק מחדש את הפרומפטים הקיימים הוא מקור נפוץ מאוד לרגרסיות בלתי מוסברות.

גישה, הרשאות וזרימת עבודה

אחד היתרונות המעשיים הגדולים של Registry ייעודי הוא הפרדת הרשאות: אנשי מוצר וכותבי תוכן יכולים לערוך ולהציע פרומפטים חדשים דרך ממשק ייעודי, בלי גישה לקוד production כלל, בעוד שהפרומוציה בפועל ל-production דורשת אישור ועוברת דרך אותם שערי איכות אוטומטיים כמו כל שינוי אחר. זרימת עבודה טיפוסית כוללת: יצירת draft, בדיקה עצמית מול סט תרחישים לדוגמה בממשק אינטראקטיבי, שליחה ל-review, הרצת Evaluation suite מלא, ורק אז פרומוציה. חשוב שהתהליך הזה יהיה מהיר מספיק (דקות, לא ימים) כדי שלא ייווצר תמריץ לעקוף אותו - כי ברגע שצוות מוצא shortcut סביב ה-Registry, כל התועלת שלו קורסת.

טעויות נפוצות בפרודקשן

הטעות השכיחה ביותר היא לגרוס את הפרומפט אבל לא את ה-template variables שמוזרקים לתוכו - שינוי בפורמט של retrieved_context, למשל, יכול לשבור פרומפט "יציב" בלי שהתוכן שלו עצמו השתנה כלל. טעות שנייה היא לתת לכולם הרשאת עריכה ישירה על production בלי שכבת draft/review, מה שהופך כל שינוי לפוטנציאל לתקרית מיידית. טעות שלישית, עדינה יותר, היא לשמור היסטוריה שטוחה בלי metadata על הסיבה לשינוי - כשמסתכלים אחורה על עשרות גרסאות בלי הקשר, קשה להבין מה בכלל ניסו להשיג בכל שינוי, וקשה לדעת אילו ניסויים כבר נכשלו בעבר כדי לא לחזור עליהם.

מתי כדאי, ומתי זה מיותר

ברגע שיש בארגון יותר מפרומפט אחד קריטי, או יותר מאדם אחד שנוגע בפרומפטים, ההשקעה ב-Registry ייעודי משתלמת כמעט תמיד - העלות שלו (כמה ימי פיתוח לבניית שכבת ניהול בסיסית, או אימוץ כלי קיים) זניחה לעומת עלות התקרית הראשונה שנגרמת מפרומפט שהשתנה בלי שאף אחד ידע. לעומת זאת, בפרויקט חד-פעמי או POC פנימי עם פרומפט יחיד וקהל משתמשים של יחיד, קובץ טקסט תחת בקרת גרסאות רגילה מספיק לגמרי - אין טעם לבנות מערכת ניהול מלאה סביב תוכן שממילא ישתנה שינוי דרסטי ברגע שהפרויקט יתבגר.

Rollback ו-Blast Radius לפרומפטים

בדיוק כמו בכל רכיב production אחר, השאלה החשובה היא לא רק "איך פורסים פרומפט חדש" אלא "כמה מהר אפשר לחזור אחורה כשמתגלה בעיה". Registry שמאפשר rollback באמת חייב לשמור את הגרסאות הקודמות במצב מוכן להפעלה מיידית, בלי צורך לחפור בהיסטוריית git או לבנות מחדש קונטקסט ששכחו לתעד. חשוב גם למדוד blast radius לפני שמעלים גרסה חדשה לכל התעבורה: אם פרומפט חדש רץ קודם על עשרה אחוז מהמשתמשים, נזק פוטנציאלי מוגבל לאותם עשרה אחוז, וניתן לזהות בעיה ולתקן לפני שהיא פוגעת בכולם. הרעיון הזה - חשיפה הדרגתית עם יכולת חזרה מיידית - הוא בדיוק העיקרון שמפורט במאמר על AI Canary Releases, וכדאי ליישם אותו במיוחד עבור פרומפטים, כי הם הרכיב שמשתנה הכי הרבה פעמים בשבוע.

ניהול Secrets והזרקת נתונים רגישים

נקודה שלעיתים מוזנחת בבניית Prompt Registry היא ההפרדה בין תוכן הפרומפט לבין נתונים רגישים שאסור שיישמרו בו בטקסט גלוי. פרומפטים רבים כוללים דוגמאות few-shot עם נתוני לקוח אמיתיים שהועתקו "בשביל הדוגמה" ונשארו שם - זו דליפת מידע פוטנציאלית בכל פעם שמישהו עם גישת קריאה ל-Registry פותח את הגרסה ההיסטורית. כלל טוב הוא לאסור לחלוטין נתוני production אמיתיים בתוך template קבוע, ולהשתמש אך ורק בדוגמאות סינתטיות שנבנו לצורך ההדגמה. בנוסף, כל מזהה כמו מפתחות API או פרטי חיבור למערכות חיצוניות לעולם לא שייכים לטקסט הפרומפט עצמו, אלא צריכים להישאר בשכבת הקונפיגורציה המאובטחת של ה-Agent.

מבנה ארגוני: מי בעל הבית על פרומפט

שאלה שכל ארגון שמגיע לכמה עשרות Agents נתקל בה במוקדם או במאוחר היא מי בעצם אחראי על תוכן הפרומפט - צוות ההנדסה שמפעיל את ה-Agent, צוות המוצר שמגדיר את חוויית המשתמש, או צוות ה-AI/ML שמבין את המודל לעומק. התשובה הנכונה כמעט תמיד היא שילוב: ה-Registry מגדיר baseline owner לכל פרומפט (בדרך כלל צוות המוצר או תחום עסקי מסוים), אך כל שינוי מהותי עדיין עובר אישור טכני שמוודא שהוא לא שובר תאימות עם ה-Tools וה-Schema שה-Agent תלוי בהם. הפרדת האחריות הזו, כשהיא מתועדת בבירור ב-metadata של כל פרומפט ב-Registry, מונעת את התופעה השכיחה שבה שינוי "קטן וחף מפשע" בניסוח נעשה בלי מודעות להשלכות הטכניות שלו - למשל שינוי שמשנה את הפורמט שבו המודל מחזיר תשובה, ושובר parser downstream שמצפה לפורמט הישן.

מדידת עלות לצד איכות

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

סיכום

Prompt Registry הוא לא עוד כלי - הוא ההכרה בכך שפרומפט הוא קוד production, ולכן מגיע לו כל מה שמגיע לקוד production: גרסאות, בדיקות, הרשאות, ומסלול פריסה מבוקר. הארגונים שמטפלים בפרומפטים כאזרחים סוג ב׳ הם אלה שסובלים מהכי הרבה תקריות בלתי מוסברות - וההשקעה הקטנה יחסית בבניית Registry נכון היא אחת התשואות הגבוהות ביותר בכל תכנית MLOps ארגונית.

תגיות: Prompt Registry · Prompt Engineering · System Prompt · A/B Testing · MLOps · Enterprise AI · Versioning

← חזרה לבלוג · צור קשר